Spring Cloud微服务实战

服务融创保护：Spring cloud Hystrix

       在微服务架构中，我们将系统拆分成很多服务单元，各个单元的应用间通过服务注册与订阅的方式相互依赖。由于每个单元都在不同的进程中运行。依赖通过远程调用的方式咨询。这样就有可能因为网络原因或者是依赖服务自身问题出现调用故障或延迟，而这些问题会直接导致调用方的对外服务也出现延迟，若此时调用方的请求不断增加，最后就会因为等待出现故障的依赖方响应形成任务积压，最终导致自身服务的瘫痪。

      举个例子，在一个电商网站中，我们可能会将系统拆分成用户、订单、库存、积分、评论等一系列服务单元。用户创建一个订单的时候，客户端将调用订单服务的创建订单接口，此时创建订单接口又会向库存服务来请求出货(判断是否有足够库存来出货)。此时若库存服务因自身处理逻辑等原因造成响应缓慢，会直接导致创建订单服务的线程被挂起，以等待库存申请服务的响应，在漫长的等待之后用户会因为请求库存失败而得到创建订单的失败的结果。如果在高并发情况之下，因这些挂起的线程在等待库存服务的响应而未能释放，使得后续到来的创建订单请求被阻塞，最终导致订单服务也不可用。

      在微服务架构中，存在着那么多的服务单元，若一个单元出现故障，就很容易因依赖关系而引发故障的蔓延，最终导致整个系统的瘫痪，这样的架构相较传统构架更加不稳定。为了解决这样的问题，产生了断路器等一系列的服务保护机制。

     在分布式架构中，断路器模式的作用也是类似的，当某个服务单元发生故障（类似用电器发生短路）之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个错误响应，而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。

消息总线：  Spring Cloud Bus

      当前版本的Spring Cloud Bus 仅支持两款中间件产品：Rabbit 和 Kafka。两款消息中间件与Spring Cloud Bus 配合实现消息总线。

kafka的设计中依赖了Zookeeper

 

--- SpringCloud 微服务实战