1. 回顾服务器
前面已用Eureka实现了微服务的注册与发现，Ribbon实现了客户端侧的负载均衡，Feign实现了声明式的API调用。网络
2. 实现容错的手段架构
若是服务提供者响应很是慢，那么消费者对提供者的请求就会被强制等待，知道提供者响应或超时。并发
在高负载场景下，若是不作任何处理，此类问题可能会致使服务消费者的资源耗竭甚至整个系统的崩溃。负载均衡
例如，曾经发生过一个案例——某电子商务网站在一个黑色星期五发生过载。过分的并发请求，致使用户支付的请求延迟好久微服务
都没有响应，在等待很长时间后最终失败。支付失败又致使用户从新刷新页面并再次尝试支付，进一步增长了服务器的负载，网站
最终整个系统都崩溃了。spa
当依赖的服务不可用时，服务自身会不会被拖垮？这是咱们要考虑的问题。线程
3. 雪崩效应代理
微服务架构的应用系统一般包含多个服务层。微服务之间经过网络进行通讯，从而支撑起整个应用系统，所以，微服务之间不免存在
依赖关系。任何微服务都并不是100%可用，网络每每也很脆弱，所以不免有些请求会失败。
咱们常把“基础服务故障”致使“级联故障”的现象称为雪崩效应。雪崩效应描述的是提供者不可用致使消费者不可用，并将不可用逐渐放大的过程。
好比，A做为服务提供者（基础服务），B做为A的服务消费者，C和D是B的服务消费者。当A不可用引发B的不可用，并将不可用像滚雪球同样
放大到C和D时，雪崩效应就造成了。
4. 如何容错
要想防止雪崩效应，必须有一个强大的容错机制。该容错机制需实现如下两点。
- 为网络请求设置超时
正常状况下，一个远程调用通常在几十毫秒内就能获得响应了。若是依赖的服务不可用或网络有问题，那么响应时间就会变得很长（几十秒）
一般状况下，一次远程调用对应着一个线程/进程。若是响应太慢，这个线程/进程就得不到释放。而线程/进程又对应着系统资源，
若是得不到释放的线程/进程越积越多，资源就会逐渐会耗尽，最终致使服务的不可用。
所以，必须为每一个网络请求设置超时，让资源尽快释放。
- 使用断路器模式
若是对某个微服务的请求有大量超时（经常说明该微服务不可用），再去让新的请求访问该服务已经没有任何意义，只会无谓耗费资源。
例如，设置了超时时间为1秒，若是短期内有大量的请求没法在1秒内获得响应，就没有必须再去请求依赖的服务了。
断路器可理解为对容易致使错误的操做的代理。这种代理可以统计一段时间内调用失败的次数，并决定是正常请求依赖的服务仍是直接返回。
断路器可实现快速失败，若是它在一段时间内检测到许多相似的错误（例如超时），就会在以后的一段时间内，强迫对该服务的调用快速失败，
即再也不请求所依赖的服务。这样，应用程序就无需再浪费CPU时间去等待长时间的超时。
断路器也可自动诊断依赖的服务是否已经恢复正常。若是发现依赖的服务已经恢复正常，那么就会恢复请求该服务。使用这种方式，
就能够实现微服务的“自我恢复”——当依赖的服务不正常时打开断路器时快速失败，从而防止雪崩效应；当发现依赖的服务恢复正常时，
又会恢复请求。
断路器的大体流程以下：
> 正常状况下，断路器关闭，可正常请求依赖的服务。
> 当一段时间内，请求失败率达到必定阈值（例如错误率达到50%，或100次/分钟等），断路器就会打开。此时，不会再去请求依赖的服务。
> 断路器打开一段时间后，会自动进入“半开”状态。此时，断路器可容许一个请求访问依赖的服务。
若是该请求可以调用成功，则关闭断路器；不然继续保持打开状态。
5. 总结
本文讲解了容错机制的重要性，以及一个良好的容错机制应该实现哪些功能。
下文将讲解使用Hystrix实现容错。敬请期待~~~
6. 参考
周立 --- 《Spring Cloud与Docker微服务架构与实战》