微服务——服务容错保护-Hystrix

服务雪崩：微服务架构下，会存在服务之间相互依赖调用的情况，当某个服务不可用时，很容易因为服务之间的依赖关系使故障扩大，甚至造成整个系统不可用的情况，这种现象称为服务雪崩效应。

产生原因：比如说代码的 Bug 问题，由于某些代码问题导致 CPU 飙升，将资源耗尽等，比如服务器出现问题，磁盘出问题，导致数据读写特别慢，一下就拉高了响应时间。比如说某个新来的同事对业务不太熟悉，写了个查询的 SQL 语句，join 了多个表，并且没用到索引，出现慢 SQL。又比如请求量太大了，已经超出了系统本身的承受能力。

解决方案：

针对服务器端：

1、对于这种请求量超出承受能力的问题，我们可以进行扩容来支持高并发或者进行限流，自己能处理多少请求就处理多少，处理不了的请求直接拒绝，这样才不会将自己拖垮。（令牌桶、信号量）

2、对于代码的 Bug 问题，通过测试、Code Review 等方式来避免，对于慢 SQL 这种问题，我们需要去做数据库性能优化。对于服务器硬件故障问题，我们可以加大运维粒度，通过监控等手段来提前预防。

针对客户端：

1、资源隔离，快速失败

Hystrix：Hystrix 通过 HystrixCommand 对调用进行隔离，这样可以阻止故障的连锁反应，能够快速失败并迅速恢复服务或者进行回退并优雅降级。（跟 Feign、Zuul 等组件做了集成，极大的降低了使用的难度）

避免线程耗尽：由于被调用方出现问题，调用方无法及时获取响应结果，而一直在发送请求，最终会耗尽所有线程的资源。

快速失败：当被调用方出现问题后，调用方发起的请求可以快速失败并返回，这样就不用一直阻塞住，同时也释放了线程资源。

支持回退：我们可以让用户有回退的逻辑，比如获取备用数据，从缓存中获取数据，记录日志等操作。

资源隔离：A、B、C 三个服务都是相互隔离的，互不影响。

近实时监控：它能帮助我们了解整个系统目前的状态，有哪些服务有问题，当前流量有多大，出问题后及时告警等。

Hystrix Dashboard ：Hystrix 会实时记录所有 HystrixCommand 的执行信息，其中有每秒执行了多少次请求，多少次是成功的，多少次是失败的等信息。

Hystrix 项目中使用经验：

1、配置可以对接配置中心进行动态调整。

2、回退逻辑中可以手动埋点或者通过输出日志进行告警。

3、用了线程池隔离模式再用 ThreadLocal 会有坑。

4、网关中尽量用信号量隔离。（如果用线程池隔离，那么需要创建上百个独立的线程池，开销太大了。用信号量隔离开销就小很多，还能起到限流的作用。）