Hystrix & Resilience4j 与差错控制

本文是笔者 2019 年暑期在 HULU 的实习项目，拖了一年之后才把这篇博客整理出来，留作纪念吧。

延迟与差错控制问题

首先让我们熟悉一下问题的背景。一个现代的后端服务（下文称之为 App）可能会有多个依赖服务（下文简称为依赖），依赖需要通过网络请求，但这些依赖不一定总是能保持稳定。比如，推荐系统后台可能需要从一个依赖中获取读取用户配置，从另一个依赖中读取用户历史。这样就存在一个问题：如果服务有非常多的依赖，那么在任意时刻，都很有可能有某个依赖出问题。

依赖出现问题一般表现为对一些请求会抛异常，如果没有兜底逻辑，App 就不能处理这些请求了。另外，出问题的依赖延时会变长，这会导致该依赖的请求大量占用线程池、TCP 连接等资源，直至耗尽资源。于是，如果 App 没有差错容忍能力，那么本 App 的 downtime 可能会是所有的依赖的 downtime 之和，而且 App 跟随上游依赖挂掉之后，还会引起下游服务跟随挂掉，导致雪崩式崩溃，这是不可接受的。

为了避免 App 跟随上游依赖挂掉，至少需要做到以下两点：

• 有一个 fallback 逻辑，也即当上游的依赖服务挂掉之后的兜底逻辑。一般而言，这应该是个简单的本地逻辑，比如返回合理的空值。
• 能够检测服务的健康状态，如果服务挂掉，尽快切换到 fallback 逻辑。同时，能够在服务恢复正常后及时切换回来。

Hystrix & Resilience4j 就是完成后一个要求的工具。它们可以检测依赖的健康状态，并在依赖状态不佳时及时切换到兜底逻辑，以及依赖恢复正常之后切换回来。

Hystrix 原理

在这里偏原理的介绍一下 Hystrix. Hystrix 首先将依赖的调用抽象成函数（方法）调用，函数需要用户自己继承 Hystrix 提供的类来实现，在函数中可以使用 HttpClient 等进行依赖的调用。函数调用有三种可能的结果：正常返回，抛出异常，超时。简单起见，超时这里也归入异常。Hystrix 的基本原理就是对于每个依赖，分别统计其在一段时间内抛出异常的概率，异常概率过高时即认定依赖已经不健康