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,即观察者,订阅者。