Spring Cloud 学习之旅 --- 断路器

本文部分摘录翟永超的个人博客

---

背景介绍

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

举个例子，在一个电商网站中，我们可能会将系统拆分成，用户、订单、库存、积分、评论等一系列的服务单元。用户创建一个订单的时候，在调用订单服务创建订单的时候，会向库存服务来请求出货（判断是否有足够库存来出货）。此时若库存服务因网络原因无法被访问到，导致创建订单服务的线程进入等待库存申请服务的响应，在漫长的等待之后用户会因为请求库存失败而得到创建订单失败的结果。如果在高并发情况之下，因这些等待线程在等待库存服务的响应而未能释放，使得后续到来的创建订单请求被阻塞，最终导致订单服务也不可用。

在微服务架构中，存在着那么多的服务单元，若一个单元出现故障，就会因依赖关系形成故障蔓延，最终导致整个系统的瘫痪，这样的架构相较传统架构就更加的不稳定。为了解决这样的问题，因此产生了断路器模式。

---

什么是断路器

断路器模式源于Martin Fowler的Circuit Breaker一文。“断路器”本身是一种开关装置，用于在电路上保护线路过载，当线路中有电器发生短路时，“断路器”能够及时的切断故障电路，防止发生过载、发热、甚至起火等严重后果。

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

---

准备工作

启动 注册中心 和 服务提供者 作为基础。

创建含有断路器的消费者

在Spring Cloud 学习之旅 — 服务的消费的基础上，我们添加上如下的依赖：

<dependency>
    <groupId>org.springframework.cloudgroupId>
    <artifactId>spring-cloud-starter-hystrixartifactId>
dependency>

打开我们的 ConsumerApplication 类，在类上方添加上 @EnableHystrix 注解（摘录的博客中使用的是 @EnableCircuitBreaker，这两者效果相同，但是为了个人觉得 @EnableHystrix 更方便记住，因为我们用的组件就是Hystrix）
注意：同样的，@EnableDiscoveryClient 注解也可以换成 @EnableEurekaClient ，效果与前者相同，具体可以查阅其源码

至此，我们这个类一共有3个注解，分别是 @SpringBootApplication、@EnableEurekaClient(或@EnableDiscoveryClient)、@EnableHystrix(或@EnableCircuitBreaker)。这里其实可以精简为一个注解，即 @SpringCloudApplication 。这也从侧面说明了一个标准的Spring Cloud应用至少应该包含服务注册和发现、Spring Boot以及断路器。最后的效果如下：

我们接着对控制器进行改造。
在原有的基础上，我们添加一个统一的处理错误的方法，暂时取名为error吧。紧接着为 helloConsumer 方法添加断路器的使用注解 @HystrixCommand 并指定其 fallbackMethod 参数的结果为刚刚定义的 error 方法，其余的断路器注解在此暂时不做过多的介绍。最后效果具体如下：

至此我们就利用了Spring Boot为我们带来的便利，快速的使用了Hystrix断路器组件。我们简单的访问以下，查看一下效果。

貌似到这里都看不出效果。我们把所有的服务提供者都关闭掉，然后看看效果。

至此我们的断路器就生效了。

---

那么，看完这篇博文的你，赶紧动手试一试吧^_^