微服务容错限流Hystrix架构和实践

微服务容错限流Hystrix架构和实践

1、容错限流的需求

• 微服务化后，存在多个服务，若果其中某一个服务响应很慢，阻塞了所有的请求，导致系统雪崩

2、基本的容错模式

• 超时
• 限流：限制最大并发数
• 熔断：错误达到阈值时，类似保险丝熔断
• 隔离：隔离不同的依赖调用
• 降级：服务降级（大量用户请求进入时候，优先保证vip用户请求）

3、Hystrix设计原理（自适应反馈机制）

• 依赖的调用使用了Hystrix后，首先会被封装在一个HystrixCommond的类里。

• execute同步执行方式，queue一步执行方式，最新的版本支持响应式执行。

• circult open开关不通，不同的时候判断是否存在降级函数，没有降级函数直接抛出异常

  有降级函数就执行，存在执行成功（返回降级响应），执行失败抛出异常

• circult open开关通，如果用的是线程隔离，去判断线程池是否满，如果满了是走降级流程

• 线程池如果没满，就真正的执行run方法，调用封装方法，超时或执行失败也是走降级流程，

  如果成功响应，就是report Metrics，就是把执行情况做一个记录

• Metrics会把成功或失败的情况报告给Health组件，health组件相当于一个脑袋，他会计算Hystrix的执行情况，用来判定开关是打开还是闭合

4、断路器内核设计

• 基于滚筒式的统计方式，每一秒产生一个桶，每个桶里记录相关的Metrics的成功或失败，

  没过一秒产生一个通，前面的桶丢弃，所有的计算都是基于这10个桶

• 当HystricsCommond请求过来的时候，首先判断是否允许请求通过，允许通过的话就直接执行

• 不允许通过的时候，会判断sleep time passed（睡眠周期）是否已过，熔断之后会有一个睡眠周期，如果没过睡眠周期，拒绝访问，如果过会放一个请求过来尝试，试通了电路就会打开

• 判断是否打开时，计算失败数/(成功数+失败数),大于设定的错误阈值时，会触发熔断（根据10个桶的值计算）

5、Hystrix的主要概念

• HystrixCommond

业务逻辑实现要集成HystrixCommond基类，业务逻辑写在run方法里

• Fail fast 快速失败：run方法里直接抛异常

• Fail silent 安静失败：getFailBack降级函数里，放回一个null或空值

  

• Static fallback：也是降级函数返回一个缺省值，true或缺省对象
  

• fallback via network 通过防落进行降级，主服务失败了，降价方法里调用一个辅助服务，通过缓存之类的

• primary+secondary with fall back（主次降级机制）

就是一个功能有一个老版本，一个新版本，都放在开关后边，用那个开那个

6、Hystrix请求合并

• 很多小请求过来的时候，会做一个请求Batch合并，例如把 10毫秒的请求合并打包发给服务器，

  响应成功后拆解响应给用户

7、Hystirx请求缓存

8、Hystrix隔离机制

8.1、线程隔离

• 为每个调用的服务建立单独的线程池，每次调用都发生在单独的线程里，通过线程池里的线程去调用服务，线程池里可以设置线程数量，比如设置10个线程，线程数量消耗光了，就不能再调用了

8.2、信号量隔离

• 信号量隔离，简单来讲就是一个计数器，比如设置为10个信号量，进来一个请求会消耗一个信号量，请求结束将信号量还回去，10的信号量消耗完了，就不能再请求了

8.3 信号量隔离 vs 线程隔离

• 信号量隔离

  优点：轻量，无额外开销

  不足： 不支持任务排队和主动超时，不支持一步调用

  适用：守信客户（自己开发的服务）、高扇出（网关上使用）、高频高速调用（调用缓存cache）

• 线程隔离

  优点：支持排队和超时，支持异步调用

  不足：线程调用会产生额外的开销

  使用：不受信的客户、有限的扇出

9、Hystrix主要配置项

maxQueueSize：为 -1的时候表示是同步队列