45. hystrix高可用系统架构介绍

前言

之前的章节专注在高并发这一块，缓存架构，承载高并发，在各种高并发导致的令人崩溃/异常的场景下能够运行。
现在我们研究什么样的情况下，可能会导致系统的崩溃，以及系统不可用，针对各种各样的一些情况，然后我们用什么技术，去保护整个系统处于高可用的一个情况下

hystrix高可用框架

如何学习

1. 如何用hystrix，来构建高可用的服务的架构
2. 用一个真实的项目背景，作为业务场景，来带出来在这个特定的业务场景下，可能会产生哪些各种各样的可用性的一些问题；
3. 针对这些问题，我们用hystrix的解决方案和原理是什么

参考博客： Hystrix都停更了，我为什么还要学？

hystrix功能

1. 资源隔离：让你的系统里，某一块东西，在故障的情况下，不会耗尽系统所有的资源，比如线程资源
2. 限流：高并发的流量涌入进来，比如说突然间一秒钟100万QPS，废掉了，10万QPS进入系统，其他90万QPS被拒绝了
3. 熔断：系统后端的一些依赖，出了一些故障，比如说mysql挂掉了，每次请求都是报错的，熔断了，后续的请求过来直接不接收了，拒绝访问，10分钟之后再尝试去看看mysql恢复没有
4. 降级：mysql挂了，系统发现了，自动降级，从内存里存的少量数据中，去提取一些数据出来
5. 运维监控：监控+报警+优化，各种异常的情况，有问题就及时报警，优化一些系统的配置和参数，或者代码

分布式依赖服务

1. 在分布式系统中，每个服务都可能会调用很多其他服务，被调用的服务就是依赖服务，有的时候某些依赖服务出现故障也是很正常的。
2. Hystrix在分布式系统中对服务间的调用进行控制，加入一些调用延迟或者依赖故障的容错机制。
3. Hystrix通过将故障的依赖服务进行资源隔离，同时Hystrix还提供故障时的fallback降级机制

Hystrix的设计原则

1. 对依赖服务调用时出现的调用延迟和调用失败进行控制和容错保护
2. 在复杂的分布式系统中，阻止某一个依赖服务的故障在整个系统中蔓延，服务A->服务B->服务C，服务C故障了导致服务B也故障，进而导致服务A故障，整套分布式系统全部故障，整体宕机
3. 提供 fail-fast（快速失败）和快速恢复的支持
4. 提供fallback优雅降级的支持
5. 支持近实时的监控、报警以及运维操作

这些设计原则构成了整个分布式系统的高可用的架构

Hystrix要解决的问题

依赖服务故障蔓延。

Hystrix如何实现

1. 阻止任何一个依赖服务耗尽所有的资源，比如tomcat中的所有线程资源
2. 避免请求排队和积压，采用限流和fail fast来控制故障
3. 提供fallback降级机制来应对故障
4. 使用资源隔离技术，比如bulkhead（舱壁隔离技术），swimlane（泳道技术），circuit breaker（短路技术），来限制任何一个依赖服务的故障的影响
5. 通过近实时的统计/监控/报警功能，来提高故障发现的速度
6. 通过近实时的属性和配置热修改功能，来提高故障处理和恢复的速度
7. 保护依赖服务调用的所有故障情况，而不仅仅只是网络故障情况
8. 调用这个依赖服务的时候，client调用包有bug，阻塞，等等，依赖服务的各种各样的调用的故障，都可以处理

Hystrix资源隔离

1. 通过HystrixCommand或者HystrixObservableCommand来封装对外部依赖的访问请求，这个访问请求一般会运行在独立的线程中，资源隔离
2. 对于超出我们设定阈值的服务调用，直接进行超时，不允许其耗费过长时间阻塞住。这个超时时间默认是99.5%的访问时间，但是一般我们3. 为每一个依赖服务维护一个独立的线程池，或者是semaphore，当线程池已满时，直接拒绝对这个服务的调用
3. 对依赖服务的调用的成功次数，失败次数，拒绝次数，超时次数，进行统计
4. 如果对一个依赖服务的调用失败次数超过了一定的阈值，自动进行熔断，在一定时间内对该服务的调用直接降级，一段时间后再自动尝试恢复
5. 当一个服务调用出现失败，被拒绝，超时，短路等异常情况时，自动调用fallback降级机制
6. 对属性和配置的修改提供近实时的支持