前几天做了一个微服务的趋势投资的小项目，现在对我这个项目学到的知识，以及我对一些概念的理解做一下总结
首先介绍一下这个项目，这是一个趋势投资的项目，简单来说就是，根据不同的筛选条件，选出合适的股票指数基金，进行趋势投资。关于什么是趋势投资呢，就是认为凡事都有一定的惯性。 比如基金上涨到一定程度形成了趋势，有一定的概率后面还是会上涨。同样的，下跌的趋势一旦形成了，也有一定的概率后面还是继续下跌。所以趋势投资其实就是等待两种信号，当上涨趋势形成，就会得到一个买入信号，此时就进行买入。 当跌倒一定程度了，就会得到一个卖出信号，就进行卖出操作。说白了，就是追涨杀跌。
项目展示
再说一下项目应用的技术
-
Eureka注册中心
其实就是微服务总管。利用这个注册中心，它可以把所有的微服务都管理起来，统一调配他们彼此之间的访问。这个是注册中心服务器运行起来之后，本项目会管理的各种微服务一览。
-
redis数据缓存：缓存数据
-
网关
-
git版本控制，客户端服务器配置，RabbitMQ消息队列
-
zipkin链路追踪。
- 断路(聚合)监控
谈谈关于本项目我对分布式集群的理解：
-
单体架构:
需要做一个趋势投资系统，所以做了一个SpringBoot项目，这个项目，包括，数据采集获取，指数代码，指数数据，模拟回测，视图。这些功能都由这一个项目实现。 这种叫做单体架构。 -
集群：
一个项目，什么都做，当大数据量访问时，可能会造成端口压力过大，出现内存过大，导致项目崩溃，那怎么解决呢，那就再用一个端口部署相同的功能，当访问的时候，用户被随机分配到两个端口，这样就帮忙减轻了用户访问数据过大，这样就减轻了单个端口的压力，多个这样的端口就组成了一个集群。 -
高可用概念：
单体架构，如果有一天突然崩了，就叫做服务中断了，如果没有集群的话整个项目就直接崩溃了，但是因为添加了多个端口的集群部署，一个端口的服务崩了，另一个还是能用，虽然相比较吃力一些，但是毕竟还是能用的，这个现象叫做高可用。 -
分布式：
一个端口部署所有业务，一次访问就要调用这个端口的所有业务，这样就造成如果大量用户单独访问一个业务，那就造成单个业务数据压力太大，还是会导致服务器忙不过来，怎么办呢？ 那就再弄一个微服务专门用来处理数据采集获取，一个微服务专门用来处理模拟回测，一个微服务专门用来处理视图等等。。。 这样服务本来仅仅是由一个端口提供的，变成了与处理数据采集获取由8001端口负责，处理模拟回测由8051端口负责，处理视图由8041端口负责等等。。。 这就叫做分布式了。 -
低耦合概念：
做据采集获取的服务挂了，不影响模拟回测的服务。 做处理模拟回测的服务挂了，也不影响处理视图由8041端口，这叫做低耦合。 -
高内聚概念：
和数据采集相关的事情都是8001在做，数据采集方式快慢，只会影响自己，对处理视图由8041端口服务没影响. 这叫做高内聚。 -
集群+分布式：
视图由8041端口负责，大数据访问量来啦了，也累啊，也会受不了啊。 那么就再加一个8042端口，帮忙处理视图这个服务。 这样视图这个服务，就由8041和8042这个集群来承担啦。她们俩，一个挂了，都有另一个端口继续提供视图服务。 这就叫做集群+分布式。
关于网关的理解
对每个服务配置好网关，当访问网关地址：
http://127.0.0.1:8031/api-codes/codes
就可以达到访问以下任意个微服务的效果
http://127.0.0.1:8011/codes
http://127.0.0.1:8012/codes
http://127.0.0.1:8013/codes
因为这3个微服务是属于一个集群的，所以访问网关会自动在集群里的这些微服务之间进行切换，这样就达到了动态平衡的效果，但是我怎么感觉和nginx实现的功能差不多呢？
到底nginx 和Zuul的区别是什么?
感觉这两个好像差不多的样子,于是我就去搜寻了一下.
原来,还是有点区别的,下面就来说一下它们两者之间的区别:
不同点:
-
首先 , Nginx是C语言开发,而 Zuul 是Java语言开发
-
其次,Nginx负载均衡实现,采用服务器实现负载均衡,而Zuul负载均衡的实现是采用 Ribbon + Eureka 来实现本地负载均衡.
-
Nginx适合于服务器端负载均衡,Zuul适合微服务中实现网关
-
Nginx相比Zuul功能会更加强大,因为Nginx整合一些脚本语言( Nginx + lua )
-
Nginc 是一个高性能的HTTP 和反向代理服务器, 也是一个 IMAP / POP3 /SMIP 服务器. Zuul是 Spring Cloud Netflix 中的开源的一个API Gateway 服务器,本质上是一个web servlet 应用, 提供动态路由,监控,弹性,安全等边缘服务的框架. Zuul 相当于是设备和Netflix 流应用的Web 网站后端所有请求的前门
那么既然说了这么多的不同点,那我们也说一下它们的相同点吧!!!
相同点:
- 可以实现负载均衡 (Zuul使用的是Ribbon实现负载均衡)
- 可以实现反向代理 (即隐藏真实ip地址)
- 可以过滤请求,实现网关的效果
zuul中请求的流程
Zuul架构图：
从上图可以看出，一个完整的请求流程过程时这样的：
-
请求——>zuulServlet处理；zuulServlet里面定义了整个请求的执行顺序；preRoute()——>route()——>postRoute();
-
zuulservlet中有一个zuulRunner对象，该对象中初始化了RequestContext，RequestContext继承了ConcurrentHashMap,并且它是一个单例的；所以它被用来存储整个请求中的与请求相关的数据，被所有的zuulFilter共享。
-
zuulRunner中含有FilterProcessor，FilterProcessor中定义了zuulfilter过滤器的执行规则（filterType,filterOrder,run）。
-
FilterProcessor从filterloader中获取zuulfilter;
-
zuulfilter是被filterFileManager所加载，并支持groovy热加载，采用了轮询的方式热加载。
-
加载的过滤器都存放在filterRegistry中。
-
得到这些过滤器后，就开始按preRoute()——>route()——>postRoute()的顺序开始执行这些过滤器。
-
执行这些过滤器有错误的时候会执行error过滤器。
-
执行完这些过滤器后，将请求结果返回给客户端。
-
路由转发时在route阶段执行的。
我对链路追踪的理解
当有多个微服务，分别是代码微服务和数据微服务，网关， 回测微服务，回测视图微服务，随着业务的增加，就会有越来越多的微服务存在，他们之间也会有更加复杂的调用关系。这个调用关系，仅仅通过观察代码，会越来越难以识别，所以就需要通过 zipkin 服务链路追踪服务器，zipkin会用画图的方式显示出各服务之间的关系。
我对配置消息总线的理解
在这个项目中用消息总线来做版本的更新工作，配置git服务器与客户端时，当更新版本信息时，需要把相关的一些微服务全都重启一遍，才能更新版本，当有多个端口集群时，就要每个端口的服务都重启一变，这样就要进行大量的重启操作。这个在生产环境肯定是不可接受的。
所以要能够做到实时刷新。 为了做到这一点，我们需要借助于 rabiitMQ 来广播配置服务器获取到的信息。
如上图，它的业务逻辑是这样的，
- 通过运行FreshConfigUtil类， 以 post 方式访问地址 http://localhost:8041/actuator/bus-refresh，通知 view:8041 刷新配置。
- view:8041 告诉 index-config-server 获取新的配置数据
- index-config-server 从 git 拿到数据，返回给 view:8041
- view:8041 拿到数据不仅自己用了，还发给了 rabbitMQ
- rabbitMQ 拿到这个数据广播给其他的，比如 view:8042
我对断路器的理解
到后台数据微服务挂了后就会出现屏幕截图里的这个问题。
为了解决这个问题，就需要做断路器啦
其概念很简单，就是去获取一个资源，如果这个资源不存在的时候。断路器就返回一个空数据，或者自己定义好的静态资源，进行显示。
我对断路器监控的理解
hystrix时进行断路器监控的网页，访问http://localhost:8070/hystrix进入登录页面，输入参数：
http://localhost:8051/actuator/hystrix.stream，对8051端口进行断路监控，
当8051挂了的时候
断路器就会显示最近错误比例100%。
我对断路器聚合监控的理解
针对一个微服务的断路器监控，但是微服务通常会是多个实例组成的一个集群。 倘若集群里的实例比较多，难道要挨个挨个去监控这些实例吗？ 何况有时候，根据集群的需要，会动态增加或者减少实例，监控起来就更麻烦了。
所以为了方便监控集群里的多个实例，springCloud 提供了一个 turbine 项目，它的作用是把一个集群里的多个实例汇聚在一个 turbine里，这个然后再在 断路器监控里查看这个 turbine, 这样就能够在集群层面进行监控啦。
注： turbine 是漩涡的意思，就表示把一个集群里的实例的监控信息，都漩啊漩啊的，漩到它这里来了。
我对分布式项目优缺点的理解
优点：
1.分而治之；单个服务功能内聚，复杂性低；方便团队的拆分和管理；
2.单独部署，独立开发；
3. 增量扩展容易，比如数据微服务不够用了，那么新增一个就可以缓解一定程度的性能压力
4. 各种监控，方便监管
缺点：
1.开发难度大；垮服务的调用通常是不同的机器，甚至是不同的机房，开发人员需要处理超时、网络异常等问题。
2.效率相对低，团队依赖强，一个服务的版本延迟会拖慢整个应用的开发周期。
3.分布式部署费心费力，维护成本高