实战丨Hystrix服务降级原理和实践

Posted 2021-04-30 金融电子化

欢迎金融科技工作者积极投稿！

各抒己见！

投稿邮箱： 

[e-mail]

                                 ——金融电子化

编者按

本文主要讨论了微服务架构下的服务降级的原理和基于Hystrix服务降级实践。就如何利用有限的资源，保证系统核心功能稳定、高效、持续可用进行了阐述。

微服务架构是将单体应用分解为多组服务，每个服务作为轻量级子服务，通过RPC实现服务间接口调用。每个服务可根据自己需要进行技术选型，服务间相互独立，实现敏捷开发和部署。由于各个服务之间的依赖关系复杂，微服务具备多项优势的同时，也对微服务管理和稳定性提出了挑战。举例来说，如上游依赖的某服务因网络故障或者资源不足出现调用延迟，直接导致上游服务也出现延迟；此时若上游继续不断增加请求，会因等待依赖的某服务响应结果出现业务积压，最终导致自身服务的瘫痪，即所谓的雪崩效应。

为有效应对雪崩效应，提高关键业务的可用性，可使用熔断器原理，对部分非核心业务、低服务质量的业务进行服务降级。如Netflix Hystrix借助熔断器功能，通过监控远程调用状态，统计分析远程调用数据，一旦发现服务质量较差服务或故障服务，则进行服务降级，不再直接调用远程服务，避免出现雪崩效应，有效为微服务系统提供了保护。

服务降级原理

服务降级是指上游依赖的某服务响应结果延迟，导致整理服务质量不高，为了提高服务吞吐量，将一些不重要或者服务质量较差的服务延迟使用或暂停使用。

那么，Hystrix是如何实现服务降级的呢？Hystrix通过将依赖的服务调用封装在Command中，监控统计服务调用情况，分析响应结果，包含：成功、失败、拒绝、超时。在服务窗口期内，当请求量超过指定值，错误率超过阀值的服务调用，将会开启熔断器，进行服务降级，直接返回友好信息或者使用简单的逻辑进行处理，缓解依赖服务的压力，减少请求的积压，避免问题的蔓延。

Hystrix实现服务降级主要从三个方面：

●隔离（线程池隔离和信号量隔离）：限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用。

●优雅的降级机制：超时降级、资源不足时(线程或信号量)降级，降级后可以配合降级接口返回托底数据。

●融断：当失败率达到阀值自动触发降级(如因网络故障/超时造成的失败率高)，熔断器触发的快速失败会进行快速恢复。

Hystrix熔断器实现原理流程图如下：

服务降级是否开启由依赖调用的错误比率决定。在服务窗口期内，服务请求量大于预设阈值，依赖调用的错误比率=请求失败数/请求总数。Hystrix中断路器打开的默认请求服务错误比率为50%，对于被熔断的服务请求，并不是永久被切断，而是被暂停一段时间（默认是5S）之后，允许部分请求通过。若请求响应正常则恢复依赖服务请求（取消熔断），如果不是健康的，则继续暂停请求服务（继续熔断）。

服务降级实践

微服务使用Hystrix熔断器实现了服务的自动降级，让微服务具备自我保护的能力，提升了系统的稳定性，也较好的解决雪崩效应。其使用方式目前支持两种策略：

1、线程池隔离策略：使用一个线程池来存储当前的请求，线程池对请求作处理，设置任务返回处理超时时间，堆积的请求堆积入线程池队列。这种方式需要为每个依赖的服务申请线程池，有一定的资源消耗，好处是可以应对突发流量（流量洪峰来临时，处理不完可将数据存储到线程池队里慢慢处理）

2、信号量隔离策略：使用一个原子计数器（或信号量）来记录当前有多少个线程在运行，请求来先判断计数器的数值，若超过设置的最大线程个数则丢弃改类型的新请求，若不超过则执行计数操作请求来计数器+1，请求返回计数器-1。这种方式是严格的控制线程且立即返回模式，无法应对突发流量（流量洪峰来临时，处理的线程超过数量，其他的请求会直接返回，不继续去请求依赖的服务）

线程池和型号量两种策略功能支持对比如下：

有关服务降级执行流程如下图：

●两个核心代理HystrixCommand，HystrixObservableCommand，任何依赖的服务只需要继承这两个类就可以了。其中HystrixObservableCommand使用观察者模式。

●HystrixCommand 可以采用同步调用和异步调用，异步返回Future对象。

●判断断路器是否开启，开启则直接调用getFallback。

●判断是否满足信号量隔离或线程池隔离的条件，如果隔离则抛异常。

●执行run方法。

●metrics包含了一个计数器，用来计算当前服务的状态，无论是成功调用，还是抛异常都会记录数据。

●执行服务降级策略。

往期精选：

（点击查看精彩内容）

《金融电子化》新媒体部：主任 / 邝源  编辑 / 潘婧