很多人好奇，为什么会有容错保护这种机制。试想一下，在一个电商网站中，我们会将系统拆分为用户、订单、库存、积分、评论等一系列的服务单元。用户创建一个订单的时候，客户端调用订单服务的创建订单的接口，此时创建订单接口又会向库存服务来请求出货（判断是否有足够的库存来出货）。此时若库存服务因自身的原理造成响应缓慢，那么会导致创建订单服务的线程被挂起，以等待库存申请服务的响应，在漫长的等待之后用户会因为请求库存失败而得到创建订单失败的结果。如果在高并发之下，因这些挂起的线程在等待库存服务的响应而未能释放，使得后续到来的创建订单请求被阻塞，最终导致订单服务不可用。
在微服务架构中，存在很多的服务单元。若一个单元出现故障，就很容易因依赖关系而引发故障的蔓延，最终导致整个系统的崩溃，这样的架构相比于传统架构更加不稳定。为了解决这种问题，产生了断路器等一系列服务保护机制。
雪崩效应
微服务架构中通常有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用，并将不可用逐渐放大的过程。
举个例子来说，如下图所示：A作为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A的不可用引起了B的不可用，并将不可用像滚雪球一样放大到了C和D时，雪崩效应就形成了。
Hystrix简介
Hystrix时由Netflix开源的一个延迟和容错库，用于隔离访问远程系统、服务或者第三方库，防止级联失败，从而提高系统的可用性与容错性。Hystrix主要通过以下几点实现延迟和容错。
- 包裹请求：使用HystrixCommand（或者HystrixObservableCommand）包裹对依赖的调用逻辑，每个命令在独立线程中执行。用到了设计模式中的“命令模式”。
- 跳闸机制：当某服务的错误率超过一定阈值时，Hystrix可以自动或者手动跳闸，停止请求该服务一段时间。
- 资源隔离：Hytrix为每个依赖都维护了一个小型的线程池（或者信息量）。如果该线程池已满，发往该依赖的请求就被立即拒绝，而不是排队等候，从未加速失败判定。
- 监控：Hystirx可以近乎实时的监控运行指标和配置的编号，例如成功、失败、超时、以及被拒绝的请求等。
- 回退机制：当请求失败、超时、被拒绝，或当断路器打开时，执行回退逻辑。回退逻辑可由开发人员自行提供，例如返回一个缺省值。
- 自我修复：断路器打开一段时间，会自动进入“半开”状态。
下面用两张图来说明它的工作机制：
正常情况：
异常情况：
当ServiceB出现问题的时候，调用B的请求线程被拒绝然后进行回滚，最后返回给用户的结果就是请求失败，需要重新请求。但是却可以保护系统免受崩溃。
快速入门
我们需要在order模块中增加Hystrix实现容错。首先需要导入依赖：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
<version>2.0.0.M1</version>
</dependency>
然后修改ItemService的queryItemById的方法：
/**
*调用商品的微服务提供的接口进行查询数据
* @param id
* @return
*/
@HystrixCommand(fallbackMethod = "queryItemByIdFallbackMethod")
public Item queryItemById(Long id) {
String serviceId = "xushu-microservice-item";
return this.restTemplate.getForObject("http://" + serviceId + "/item/" + id, Item.class);
}
/**
* 请求失败执行的方法
* @param id
* @return
*/
public Item queryItemByIdFallbackMethod(Long id){
return new Item(id, "查询商品信息出错!", null, null, null);
}
然后进行测试，会发现如果将商品服务停掉，访问订单服务是，会返回查询商品出错的信息，从而实现容错效果。
