服务容错保护，Hystrix，这些你都知道么？

01

——————－－

Hystrix的应用背景

我们的微服务被拆分成很多服务单元，各单元通过订阅的方式或者服务注册相互依赖。各个单元都有独立的进程，它们通过远程调用的方式。由于依赖服务自身问题或者网络等原因，出现延迟或者故障。若此时服务请求不断累加，造成任务积压，势必造成服务器自身服务的瘫痪。

举个简单的例子，在电商网站中，我们很容易把系统拆分成用户、库存、积分、支付、评论等一系列服务单元。假设用户创建一个订单。

客户端调用订单创建接口，订单接口向库存服务请求出货。假设库存这个时候由于自身原因造成响应缓慢。会导致库存服务被挂起。等待时间过长可能导致创建订单失败。

在高并发情况下，因这些挂起的线程在等待库存服务的响应而未能释放，使得创建订单服务请求被阻塞，最终导致订单服务也不可用。

02

——————－－－

Spring cloud断路器

Spring Cloud实现了断路器hystrix，线程隔离等一系列服务保护机制。它是基于Netflix的开源框架，该框架的目标在于控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。Hystrix具备服务熔断，服务降级，线程和信号隔离。

请求缓存，请求合并以及服务监控等强大功能。

03

——————－－－—－－－

Spring cloud断路器的简单构建

我们启动一个服务注册中心，端口为1111，建立一个hello-service工程，作为服务单元。两个服务，端口分别为8081，8082。Ribbon-customer工程，端口为9000.在这个消费者中加入依赖hystrix。当然在主类中要增加注解@Enable-CircuitBreaker注解，开启断路器功能。

下面我们通过断路器实现的服务回调逻辑，确保所有进程都已启动。

此时我们继续断开8081的服务。访问服务，输出为error。说明hystrix的服务回调生效。

04

——————－－－—－－－

原理分析

Hystrix的工作流程是怎样的？

1.创建HystrixCommand或HystrixObservableCommand对象。

用来表示对依赖服务的操作请求，同时传递所有需要的参数。从它们的命名我们可以知道它们用了“命令模式”来实现对服务调用的操作。第一个对象针对服务返回单个操作结果的应用场景。第二个对象用来针对服务返回多个操作结果的时候。

从源码中，我们知道里面看到几个这样的对象。

Recever：接收者，它知道如何处理具体的业务逻辑。

Command：抽象命令。包括execute，undo，redo命令。当命令操作调用的时候就会触发接收者做具体命令的业务逻辑。

ConcreteCommand：具体的命令实现。它来绑定command和接收者之间的关系。

Invoker：调用者，它持有一个命令对象，通过命令对象完成具体的业务逻辑。

2.命令执行

Hystrix一共存在4种命令的执行方式，在执行时候创建command对象来决定具体的情况选择哪一个执行。它的底层实现了RXJava，即观察者，订阅者。