绍一下Spring Cloud微服务架构

Spring Cloud解决的第一个问题就是：服务与服务之间的解耦。不少公司在业务高速发展的时候，服务组件也会相应的不断增长。服务和服务之间有着复杂的相互调用关系，常常有服务A调用服务B，服务B调用服务C和服务D ...，随着服务化组件的不断增多，服务之间的调用关系成指数级别的增加，这样最容易致使的状况就是牵一发而动全身。常常出现因为某个服务更新而没有通知到其它服务，致使上线后惨案频发。这时候就应该进行服务治理，将服务之间的直接依赖转化为服务对服务中心的依赖。Spring Cloud 核心组件Eureka就是解决这类问题。前端

Eureka
Eureka是Netflix开源的一款提供服务注册和发现的产品，它提供了完整的Service Registry和Service Discovery实现。也是Spring Cloud体系中最重要最核心的组件之一。数据库

用大白话讲，Eureka就是一个服务中心，将全部的能够提供的服务都注册到它这里来管理，其它各调用者须要的时候去注册中心获取，而后再进行调用，避免了服务之间的直接调用，方便后续的水平扩展、故障转移等。以下图：后端

固然服务中心这么重要的组件一但挂掉将会影响所有服务，所以须要搭建Eureka集群来保持高可用性，生产中建议最少两台。随着系统的流量不断增长，须要根据状况来扩展某个服务，Eureka内部已经提供均衡负载的功能，只须要增长相应的服务端实例既可。那么在系统的运行期间某个实例挂了怎么办？Eureka内容有一个心跳检测机制，若是某个实例在规定的时间内没有进行通信则会自动被剔除掉，避免了某个实例挂掉而影响服务。缓存

所以使用了Eureka就自动具备了注册中心、负载均衡、故障转移的功能。安全

Hystrix
在微服务架构中一般会有多个服务层调用，基础服务的故障可能会致使级联故障，进而形成整个系统不可用的状况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用致使“服务消费者”的不可用,并将不可用逐渐放大的过程。架构

以下图所示：A做为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引发了B的不可用，并将不可用像滚雪球同样放大到C和D时，雪崩效应就造成了。负载均衡

在这种状况下就须要整个服务机构具备故障隔离的功能，避免某一个服务挂掉影响全局。在Spring Cloud 中Hystrix组件就扮演这个角色。分布式

Hystrix会在某个服务连续调用N次不响应的状况下，当即通知调用端调用失败，避免调用端持续等待而影响了总体服务。Hystrix间隔时间会再次检查此服务，若是服务恢复将继续提供服务。微服务

Hystrix Dashboard和Turbine
当熔断发生的时候须要迅速的响应来解决问题，避免故障进一步扩散，那么对熔断的监控就变得很是重要。熔断的监控如今有两款工具：Hystrix-dashboard和Turbine
Hystrix-dashboard是一款针对Hystrix进行实时监控的工具，经过Hystrix Dashboard咱们能够直观地看到各Hystrix Command的请求响应时间, 请求成功率等数据。可是只使用Hystrix Dashboard的话, 你只能看到单个应用内的服务信息, 这明显不够. 咱们须要一个工具能让咱们汇总系统内多个服务的数据并显示到Hystrix Dashboard上, 这个工具就是Turbine. 监控的效果图以下：工具

配置中心
随着微服务不断的增多，每一个微服务都有本身对应的配置文件。在研发过程当中有测试环境、UAT环境、生产环境，所以每一个微服务又对应至少三个不一样环境的配置文件。这么多的配置文件，若是须要修改某个公共服务的配置信息，如：缓存、数据库等，不免会产生混乱，这个时候就须要引入Spring Cloud另一个组件：Spring Cloud Config。

Spring Cloud Config
Spring Cloud Config是一个解决分布式系统的配置管理方案。它包含了Client和Server两个部分，Server提供配置文件的存储、以接口的形式将配置文件的内容提供出去，Client经过接口获取数据、并依据此数据初始化本身的应用。

其实就是Server端将全部的配置文件服务化，须要配置文件的服务实例去Config Server获取对应的数据。将全部的配置文件统一整理，避免了配置文件碎片化。

若是服务运行期间改变配置文件，服务是不会获得最新的配置信息，须要解决这个问题就须要引入Refresh。能够在服务的运行期间从新加载配置文件。

当全部的配置文件都存储在配置中心的时候，配置中心就成为了一个很是重要的组件。若是配置中心出现问题将会致使灾难性的后果，所以在生产中建议对配置中心作集群，来支持配置中心高可用性。

Spring Cloud Bus
上面的Refresh方案虽然能够解决单个微服务运行期间重载配置信息的问题，可是在真正的实践生产中，可能会有N多的服务须要更新配置，若是每次依靠手动Refresh将是一个巨大的工做量，这时候Spring Cloud提出了另一个解决方案：Spring Cloud Bus

Spring Cloud Bus经过轻量消息代理链接各个分布的节点。这会用在广播状态的变化（例如配置变化）或者其它的消息指令中。Spring Cloud Bus的一个核心思想是经过分布式的启动器对Spring Boot应用进行扩展，也能够用来创建一个或多个应用之间的通讯频道。目前惟一实现的方式是用AMQP消息代理做为通道。

Spring Cloud Bus是轻量级的通信组件，也能够用在其它相似的场景中。有了Spring Cloud Bus以后，当咱们改变配置文件提交到版本库中时，会自动的触发对应实例的Refresh，具体的工做流程以下：

服务网关
在微服务架构模式下，后端服务的实例数通常是动态的，对于客户端而言很难发现动态改变的服务实例的访问地址信息。所以在基于微服务的项目中为了简化前端的调用逻辑，一般会引入API Gateway做为轻量级网关，同时API Gateway中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。

Spring Cloud体系中支持API Gateway落地的技术就是Zuul。Spring Cloud Zuul路由是微服务架构中不可或缺的一部分，提供动态路由，监控，弹性，安全等的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。

它的具体做用就是服务转发，接收并转发全部内外部的客户端调用。使用Zuul能够做为资源的统一访问入口，同时也能够在网关作一些权限校验等相似的功能。

链路跟踪
随着服务的愈来愈多，对调用链的分析会愈来愈复杂，如服务之间的调用关系、某个请求对应的调用链、调用之间消费的时间等，对这些信息进行监控就成为一个问题。在实际的使用中咱们须要监控服务和服务之间通信的各项指标，这些数据将是咱们改进系统架构的主要依据。所以分布式的链路跟踪就变的很是重要，Spring Cloud也给出了具体的解决方案：Spring Cloud Sleuth和Zipkin

Spring Cloud Sleuth为服务之间调用提供链路追踪。经过Sleuth能够很清楚的了解到一个服务请求通过了哪些服务，每一个服务处理花费了多长时间。从而让咱们能够很方便的理清各微服务间的调用关系。

Zipkin是Twitter的一个开源项目，容许开发者收集 Twitter 各个服务上的监控数据，并提供查询接口。