为什么需要Hystrix

为什么需要Hystrix

为什么需要Hystrix

在微服务架构中，业务被拆分成多个独立的服务，并通过RPC进行相互调用。为了确保高可用性，单个服务通常会集群部署。然而，由于网络问题或自身原因，服务无法做到100%稳定运行。一旦某个服务出现问题，可能导致请求延迟甚至形成任务堆积，引发服务瘫痪和“雪崩”现象。为解决这一挑战，断路器模型应运而生，其中Hystrix就是一款用于处理分布式系统交互时超时与容错的库，具备保护系统的能力。

什么是服务雪崩

在分布式系统中，某一基础服务不可用可能引发整个系统的故障，这种现象被称为服务雪崩效应。面对服务雪崩，除了手动降级服务外，Hystrix提供了另一种解决方案。

服务雪崩应对策略

针对不同原因导致的服务雪崩，可采用以下策略：

1. 流量控制

   • 网关限流
   • 用户交互限流
   • 关闭重试

2. 改进缓存模式

3. 服务自动扩容

4. 服务调用者降级服务

服务雪崩解决办法

服务雪崩的原因

1. 机器故障：如硬件驱动错误、特定机器上的bug(如内存中断或死锁)。
2. 服务器负载变化：例如用户活动导致服务器压力骤增，若未提前预估并增加资源，可能会导致服务崩溃。
3. 人为因素：例如代码中的路径在特定时间出现bug。

解决或缓解服务雪崩的方案

通常有三种主要方法来保护服务依赖：

1. 熔断模式：借鉴电路熔断原理，在目标服务调用变慢或存在大量超时时，中断对该服务的调用，后续请求不再继续调用该服务，直接返回，待服务情况好转后再恢复调用。
2. 隔离模式：通过将系统请求按类型划分成独立资源单元，即使某个类型的请求出现问题，也不会影响其他类型。例如，使用线程池对不同类型的请求进行资源隔离，当某类请求线程耗尽时，不再接受新的同类请求。
3. 限流模式：作为预防措施，预先设置各类请求的QPS阈值，超出阈值则直接拒绝，避免进一步加重系统负担。不过，限流不能解决服务依赖问题，只能调节整体资源分配。

熔断设计

Hystrix在熔断设计上主要包括三个核心模块：熔断请求判断算法、熔断恢复机制、熔断报警。

• 熔断请求判断机制算法：使用无锁循环队列计数，每个熔断器默认维护10个bucket，每秒记录一次成功、失败、超时、拒绝状态，当错误率超过50%且10秒内超过20个请求时触发熔断。
• 熔断恢复：被熔断的请求每隔5秒允许部分请求通过，如果所有请求健康(RT<250ms)，则恢复正常调用。
• 熔断报警：对于熔断的请求记录日志，异常请求达到一定数量时触发报警。

隔离设计

隔离方式主要有两种：

1. 线程池隔离模式：利用线程池存储当前请求，设置任务超时处理时间，堆积请求进入线程池队列，这种方式可以应对突发流量但需为每个依赖服务申请线程池，占用额外资源。
2. 信号量隔离模式：使用原子计数器记录当前运行线程数量，新请求先判断是否超过最大线程数，超过则丢弃，否则执行计数操作。此模式严格控制线程数量，不支持突发流量。

超时机制设计

超时分为等待超时和运行超时：

• 等待超时：在任务入队列时设置超时时间，若等待时间超过阈值，则丢弃任务。
• 运行超时：可通过线程池提供的get方法实现运行超时控制。

熔断机制

熔断机制是在下游服务出现问题时，为保证系统正常运行提供的一种降级服务机制，通过返回缓存数据或设定好的数据防止系统雪崩。在Spring Cloud中，可通过配置的方式集成到项目中。

Hystrix作用

1. 断路器机制：当Hystrix Command请求后端服务失败次数超过一定比例(默认50%)，断路器切换至开路状态(Open)，阻止请求发送到后端服务。断路器保持开路一段时间(默认5秒)后转为半开路状态(HALF-OPEN)，根据下一次请求结果决定是否切回闭合状态(CLOSED)。Hystrix断路器类似于家庭电路中的保险丝，能及时切断问题服务链路，避免系统吞吐量受影响，并具有自我检测和恢复能力。
2. Fallback：Fallback相当于降级操作。对于查询操作，可实现一个fallback方法，在请求后端服务异常时返回fallback方法的值，其返回内容通常是默认值或来自缓存的数据。
3. 资源隔离：在Hystrix中，主要通过线程池实现资源隔离。按照调用远程服务的不同划分多个线程池，以确保各服务环境的独立性。尽管维护多个线程池会带来一定的性能开销，但在必要时也可以选择信号量(Semaphores)隔离模式以减少资源消耗。

原文链接 https://www.hanyuanhun.cn | https://node.hanyuanhun.cn