一、 服务容错的核心知识
1.1 雪崩效应
在微服务架构中，一个请求需要调用多个服务是非常常见的。如客户端访问A服务，而A服务需要调用B服务，B服务需要调用C服务，由于网络原因或者自身的原因，如果B服务或者C服务不能及时响应，A服务将处于阻塞状态，直到B服务C服务响应。此时若有大量的请求涌入，容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，造成连锁反应，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。
雪崩是系统中的蝴蝶效应导致其发生的原因多种多样，有不合理的容量设计，或者是高并发下某一个方法响应变慢，亦或是某台机器的资源耗尽。从源头上我们无法完全杜绝雪崩源头的发生，但是雪崩的根本原因来源于服务之间的强依赖，所以我们可以提前评估，做好熔断，隔离，限流。
1.2 服务隔离
顾名思义，它是指将系统按照一定的原则划分为若干个服务模块，各个模块之间相对独立，无强依赖。当有故障发生时，能将问题和影响隔离在某个模块内部，而不扩散风险，不波及其它模块，不影响整体的系统服务。
1.3 熔断降级
熔断这一概念来源于电子工程中的断路器（Circuit Breaker）。在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。这种牺牲局部，保全整体的措施就叫做熔断。
所谓降级，就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。 也可以理解为兜底方法。
1.4 服务限流
限流可以认为服务降级的一种，限流就是限制系统的输入和输出流量已达到保护系统的目的。一般来说系统的吞吐量是可以被测算的，为了保证系统的稳固运行，一旦达到的需要限制的阈值，就需要限制流量并采取少量措施以完成限制流量的目的。比方：推迟解决，拒绝解决，或者部分拒绝解决等等。
二、Hystrix介绍
Hystrix是由Netflix开源的一个延迟和容错库，用于隔离访问远程系统、服务或者第三方库，防止级联失败，从而提升系统的可用性与容错性。Hystrix主要通过以下几点实现延迟和容错。
- 包裹请求：使用HystrixCommand包裹对依赖的调用逻辑，每个命令在独立线程中执行。这使用
- 了设计模式中的“命令模式”。
- 跳闸机制：当某服务的错误率超过一定的阈值时，Hystrix可以自动或手动跳闸，停止请求该服务一段时间。
- 资源隔离：Hystrix为每个依赖都维护了一个小型的线程池（或者信号量）。如果该线程池已满，发往该依赖的请求就被立即拒绝，而不是排队等待，从而加速失败判定。
- 监控：Hystrix可以近乎实时地监控运行指标和配置的变化，例如成功、失败、超时、以及被拒绝的请求等。
- 回退机制：当请求失败、超时、被拒绝，或当断路器打开时，执行回退逻辑。回退逻辑由开发人员自行提供，例如返回一个缺省值。
- 自我修复：断路器打开一段时间后，会自动进入“半开”状态。
三、Rest实现服务熔断
3.1 配置依赖
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> </dependency>
3.2 开启熔断
在启动类 OrderApplication 中添加 @EnableCircuitBreaker 注解开启对熔断器的支持。
//@EnableCircuitBreaker //开启熔断器 //@SpringBootApplication @SpringCloudApplication public class OrderApplication { //创建RestTemplate对象 @Bean @LoadBalanced public RestTemplate restTemplate() { return new RestTemplate(); } public static void main(String[] args) { SpringApplication.run(OrderApplication.class, args); } }
可以看到，我们类上的注解越来越多，在微服务中，经常会引入上面的三个注解，于是Spring就提供了一个组合注解：@SpringCloudApplication
3.3 配置熔断降级业务逻辑
@RestController @RequestMapping("/order") public class OrderController { @Autowired private RestTemplate restTemplate; //下订单 @GetMapping("/product/{id}") @HystrixCommand(fallbackMethod = "orderFallBack") public Product findProduct(@PathVariable Long id) { return restTemplate.getForObject("http://shop-serviceproduct/product/1", Product.class); } //降级方法 public Product orderFallBack(Long id) { Product product = new Product(); product.setId(-1l); product.setProductName("熔断:触发降级方法"); return product; } }
有代码可知，为 findProduct 方法编写一个回退方法findProductFallBack，该方法与 findProduct 方法具有相同的参数与返回值类型，该方法返回一个默认的错误信息。
在 Product 方法上，使用注解@HystrixCommand的fallbackMethod属性，指定熔断触发的降级方法是 findProductFallBack 。
- 因为熔断的降级逻辑方法必须跟正常逻辑方法保证：相同的参数列表和返回值声明。
- 在 findProduct 方法上 HystrixCommand(fallbackMethod = “findProductFallBack”) 用来声明一个降级逻辑的方法
3.3.1 默认的Fallback
我们刚才把fallback写在了某个业务方法上，如果这样的方法很多，那岂不是要写很多。所以我们可以把Fallback配置加在类上，实现默认fallback：
3.3.2 超时设置
在之前的案例中，请求在超过1秒后都会返回错误信息，这是因为Hystix的默认超时时长为1，我们可以通过配置修改这个值：
hystrix: command: default: execution: isolation: thread: timeoutInMilliseconds: 2000
四、Feign实现服务熔断
SpringCloud Fegin默认已为Feign整合了hystrix，所以添加Feign依赖后就不用在添加hystrix，那么怎么才能让Feign的熔断机制生效呢，只要按以下步骤开发：
4.1 修改application.yml在Fegin中开启hystrix
在Feign中已经内置了hystrix，但是默认是关闭的需要在工程的 application.yml 中开启对hystrix的支持
feign: hystrix: #在feign中开启hystrix熔断 enabled: true
4.2 配置FeignClient接口的实现类
基于Feign实现熔断降级，那么降级方法需要配置到FeignClient接口的实现类中
/** * 实现自定义的ProductFeginClient接口 * 在接口实现类中编写熔断降级方法 */ @Component public class ProductFeginClientCallBack implements ProductFeginClient { /** * 降级方法 */ public Product findById(Long id) { Product product = new Product(); product.setId(-1l); product.setProductName("熔断:触发降级方法"); return product; } }
4.3 修改FeignClient添加hystrix熔断
在@FeignClient注解中添加降级方法
//指定需要调用的微服务名称 @FeignClient(name="shop-service-product",fallback = ProductFeginClientCallBack.class) public interface ProductFeginClient { //调用的请求路径 @RequestMapping(value = "/product/{id}",method = RequestMethod.GET) public Product findById(@PathVariable("id") Long id); }
@FeignClient注解中以fallback声明降级方法
