使用 Ribbon 和 Spring Cloud 实现客户端负载均衡-使用熔断器防止服务雪崩
官网demo：
https://spring.io/guides/gs/circuit-breaker/
概念
1、介绍
Spring cloud 使用 hystrix 组件实现服务的熔断，防止因某个服务出现故障，导致服务级联调用而引发雪崩问题。
1.1 雪崩效应
在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用，并将不可用逐渐放大的过程。
如果下图所示：A 作为服务提供者，B 为 A 的服务消费者，C 和 D 是 B 的服务消费者。A 不可用引起了 B 的不可用，并将不可用像滚雪球一样放大到 C 和 D 时，雪崩效应就形成了。
1.2 熔断器
Circuit Breaker，熔断器的原理很简单，如同电力过载保护器。它可以实现快速失败，如果它在一段时间内侦测到许多类似的错误，会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费 CPU 时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作。
熔断器模式就像是那些容易导致错误的操作的一种代理。这种代理能够记录最近调用发生错误的次数，然后决定使用允许操作继续，或者立即返回错误。熔断器就是保护服务高可用的最后一道防线。熔断器开关相互转换的逻辑如下图：
熔断器发现A1，多次执行失败（设置一个阀值），超过阀值。
当请求到B1时，B1直接快速返回失败（减少链接超时的时间，减少系统相应差的问题）。
B1可以自定义如何返回错误信息和补偿。
A1可以自定义重试机制
2、hystrix 熔断 2.1 熔断机制
断路器很好理解，当 Hystrix Command 请求后端服务失败数量超过一定比例（默认 50%，断路器会切换到开路状态（Open）。
这时所有请求会直接失败而不会发送到后端服务。
断路器保持在开路状态一段时间后（默认 5 秒），自动切换到半开路状态（HALF-OPEN）。
这时会判断下一次请求的返回情况，如果请求成功，断路器切回闭路状态（CLOSED），否则重新切換到开路状态（OPEN). Hystrix 的断路器就像我们家庭电路中的保险丝，一旦后端服务不可用，断路器会直接切断请求链，避免发送大量无效请求影响系统吞吐量，并且断路器有自我检测并恢复的能力
3、创建bookstore模块
3.1 编写pom.xml,官网导航上的pom复制下来
3.2 编写BookstoreApplication类
@SpringBootApplication
@RestController
public class ReadingApplication {
// 此种方式不能起到融合熔断的作用，因此如果服务提供者故障，程序得到 500异常。
@RequestMapping("/to-read")
public String readingList() {
RestTemplate restTemplate = new RestTemplate();
URI uri = URI.create("http://localhost:3333/recommended");
return restTemplate.getForObject(uri, String.class);
}
public static void main(String[] args) {
SpringApplication.run(ReadingApplication.class,
args);
}
}
3.3 编写application.properties文件
server.port=3333
4、创建reading模块 -reading模块是消费者模块。
4.1 编写pom.xml
4.2 编写ReadingApplication类
@SpringBootApplication
@RestController
public class ReadingApplication {
@RequestMapping("/recommended")
public String readingList() {
return "Spring in Action (Manning), "
+ "Cloud Native Java (O'Reilly), Learning Spring Boot (Packt)";
}
public static void main(String[] args) {
SpringApplication.run(ReadingApplication.class, args);
}
}
上述代码只是简单编程。并不是熔断
4.3 熔断模式说明
Netflix的Hystrix库提供了熔断模式的实现:
当对方法进行熔断处理时， Hystrix 会监控方法的失败调用，如果失败 次数达到阈值，Hystrix就打开熔断以致后续访问自动失败。
熔断开启后，Hystrix把对方法的调用重定向到特定回调 方法中。
Spring Cloud Netflix Hystrix会查找加了@HystrixCommand注解的方法，并使用代理模式对该方法进行包装，该 代理会连接到熔断器以便Hystrix能够监控。当前只对标记了@Component和@Service注解的类有效。
4.4 创建BookService服务类
@Service
public class BookService {
@HystrixCommand(fallbackMethod = "reliable")
public String readingList() {
RestTemplate restTemplate = new RestTemplate();
URI uri = URI.create("http://localhost:3333/recommended");
return restTemplate.getForObject(uri, String.class);
}
/**
* 回调方法
*/
public String reliable() {
return "Cloud Native Java (O'Reilly)";
}
}
通过@HystrixCommand注解实现在Spring Cloud使用Hystrix组件相关的工程
cloud-registration-center：注册中心
cloud-service-hystrix: 作为服务方的工程
cloud-consumer-hystrix：通过hystrix调用cloud-service-hystrix的接口
4.5 修改ReadingApplication类
@SpringBootApplication
@RestController
//启用熔断器
@EnableCircuitBreaker
public class ReadingApplication {
@Autowired
private BookService bookService;
@RequestMapping("/to-read")
public String toRead() {
return bookService.readingList();
}
public static void main(String[] args) {
SpringApplication.run(ReadingApplication.class, args);
}
}
4.6 修改application.properties文件
server.port=2222
5、测试
5.1 启动bookstore模块
5.2 启动reading模块
5.3 访问reading服务
5.4 杀死bookstore进程
5.5 重启bookstore进程
当两个模块都启动：
第一步：访问to-read方法，会发现执行的是to-read方法的返回结果。
第二步：将bookstore服务断掉
发现执行的结果是熔断自定义返回的reliable()方法结果。
证明已经实现熔断
第三步：重新将bookstore服务启动。半开放状态
每隔5秒的重试时间。5秒后执行发现 ，执行了原来的readList()方法