在微服务中，我们将系统拆分为很多个服务单元，各单元之间通过服务注册和订阅消费的方式进行相互依赖。但是如果有一些服务出现问题了会怎么样？
比如说有三个服务（ABC），A调用B，B调用C。由于网络延迟或C本身代码有问题导致B迟迟得不到回应，这样B调用C的请求就会被挂起，等待。
在高并发的访问的情况下，这些挂起的线程得不到释放，使后续的请求阻塞，最终导致B也挂掉了。依次类推，A可能也会挂掉，进而使整个系统全部崩溃。
为了解决整个问题，Spring Cloud 使用Hystrix进行服务容错保护，包括断路器、线程隔离等一系列的保护功能，接下来我们就来看下如何通过Hystrix实现断路器。
Spring Cloud Hystrix是基于Netflix的开源框架Hystrix实现的，其目的是为了通过控制那些访问远程系统、服务和第三方的节点，从而对延迟和故障提供强大的容错能力。
断路器类似于我们家里面强电箱里面用到的漏电断路保护器，当服务单元出现故障（类似于电器发生短路），通过断路器的故障监控功能（类似于保险丝），向调用方返回一个错误响应，避免长时间等待，从而避免故障蔓延到整个系统。
在前一篇文章[Springcloud负载均衡]的基础上，我们来实现断路器:
1.启动eureka服务注册中心，端口号911
2.启动cloud_cart_service1服务提供者，端口号分别为2221
3.启动cloud_cart_service2服务提供者，端口号分别为2222
4.启动cloud_cart_client服务消费者，端口号为9999;这个时候我们多次访问http://localhost:9999/clien/details.do?id=20191203110227280001是没有问题的
将cloud_cart_service2端口号为2222的服务关掉，再去多次访问http://localhost:9999/clien/details.do?id=20191203110227280001，报错了
为什么要多次访问，是因为我们通过ribbon实现了负载均衡，访问http://localhost:9999/clien/details.do?id=20191203110227280001的时候，会轮询访问cart-service的两个服务，当访问到端口号是2222的服务时才报错，访问2221的服务就不会有问题。
这样就会造成前面所说的在高并发的情况下请求被挂起导致系统崩溃的问题。
接下来断路器代码来救场，我们不去修改服务注册中心和服务提供者，只需要修改服务消费者cloud_cart_client。
1.在pom文件里面加入依赖
<!-- 引入hystrix 依赖 ，用来实现服务容错保护-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>2.修改启动类，追加注解@EnableCircuitBreaker，开启断路器
这个时候你会发现，这个启动类加了三个注解，这个是不是很麻烦?没关系，我们可以使用注解@SpringCloudApplication，如图：
@SpringCloudApplication = @EnableDiscoveryClient +@SpringBootApplication＋@EnableCircuitBreaker，从源码就能看出来：
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public @interface SpringCloudApplication {
}
3. 追加service
4. 修改controller
5. 测试，多次访问，当报错的时候，会显示如下内容
此时说明，当cloud_cart_service2不可用时，通过ribbon调用此服务会执行降级策略，快速失败并返回预先设置好的默认信息，而不是等待服务调用超时，导致调用堵塞。