共计 3099 个字符，预计需要花费 8 分钟才能阅读完成。
本文是笔者 2019 年暑期在 HULU 的实习我的项目，拖了一年之后才把这篇博客整理出来，留作留念吧。
提早与差错控制问题
首先让咱们相熟一下问题的背景。一个古代的后端服务（下文称之为 App）可能会有多个依赖服务（下文简称为依赖），依赖须要通过网络申请，但这些依赖不肯定总是能保持稳定。比方，举荐零碎后盾可能须要从一个依赖中获取读取用户配置，从另一个依赖中读取用户历史。这样就存在一个问题：如果服务有十分多的依赖，那么在任意时刻，都很有可能有某个依赖出问题。
依赖呈现问题个别体现为对一些申请会抛异样，如果没有兜底逻辑，App 就不能解决这些申请了。另外，出问题的依赖延时会变长，这会导致该依赖的申请大量占用线程池、TCP 连贯等资源，直至耗尽资源。于是，如果 App 没有过错容忍能力，那么本 App 的 downtime 可能会是所有的依赖的 downtime 之和，而且 App 追随上游依赖挂掉之后，还会引起上游服务追随挂掉，导致雪崩式解体，这是不可承受的。
为了防止 App 追随上游依赖挂掉，至多须要做到以下两点：
- 有一个 fallback 逻辑，也即当上游的依赖服务挂掉之后的兜底逻辑。一般而言，这应该是个简略的本地逻辑，比方返回正当的空值。
- 可能检测服务的衰弱状态，如果服务挂掉，尽快切换到 fallback 逻辑。同时，可能在服务恢复正常后及时切换回来。
Hystrix & Resilience4j 就是实现后一个要求的工具。它们能够检测依赖的衰弱状态，并在依赖状态不佳时及时切换到兜底逻辑，以及依赖恢复正常之后切换回来。
Hystrix 原理
在这里偏原理的介绍一下 Hystrix. Hystrix 首先将依赖的调用形象成函数（办法）调用，函数须要用户本人继承 Hystrix 提供的类来实现，在函数中能够应用 HttpClient 等进行依赖的调用。函数调用有三种可能的后果：失常返回，抛出异样，超时。简略起见，超时这里也纳入异样。Hystrix 的基本原理就是对于每个依赖，别离统计其在一段时间内抛出异样的概率，异样概率过高时即认定依赖曾经不衰弱。
Hystrix 断定依赖呈现问题之后，新的申请不会再调用依赖，而是会调用 Fallback 逻辑（兜底逻辑）。此时咱们称为短路状态，依赖被短路。短路状态下，Hystrix 每隔一段时间会尝试调用一下依赖，在肯定次数的尝试胜利之后，断定依赖曾经复原，并勾销短路状态，否则会持续短路。
通过短路掉不失常的依赖，Hystrix 一方面能够升高本服务的压力，避免大量的超时拉高本服务的响应工夫，也避免占用线程池等资源。同时也防止给依赖带来更大的压力。
Hystrix 具体原理参考 官网 wiki.
Hystrix 配置探索
Hystrix 个别用来治理依赖服务，所以个别搭配 HttpClient 应用，如 Apache HttpClient. 这样 Hystrix & Http Client 次要会有如下参数：
- HttpClient 连贯数目
- HttpClient 超时
- Hystrix 线程池大小
- Hystrix 超时
我的实习工作就是通过一个 mock 系统对这些参数和咱们应用 Hystrix 的形式进行调优。Mock 零碎包含一个虚构的依赖，次要是能够在运行时不便的调整其响应工夫散布和返回的 payload 大小；以及一个虚构的 App，其调用依赖的形式与咱们的线上服务雷同。有了 Mock 零碎之后，咱们能够再现依赖的不同状态，而后不同参数下察看调用依赖时的开销与行为等等。
通过前辈的教训和我的试验补充，咱们失去了以下配置准则。
首先，须要通过实测失去依赖的均匀响应工夫，u99 (upper99 工夫，也即 99% 的响应耗时小于该工夫) 等响应工夫散布参数，据此设置 HttpClient & Hystrix 的超时工夫。Hystrix 的超时设置成略长于 HttpClient 即可，因为 Hystrix 的超时即便被触发，Hystrix 受 Java 限度也无奈杀死过程，并不会开释资源，因而超时应该由 HttpClient 管制。超时工夫设置过短会导致大量超时触发并抛出大量的异样，但如果设置的过长，则会在依赖响应延时变长时迅速耗费线程池等资源。比方，如果超时设置成 100ms, 在 1000 rps 流量下，一旦依赖挂掉，在超时开释资源之前，这个依赖在 100ms 之内会消耗掉 100 个 TCP 连贯和线程。超时正当的设置能够参考服务的 u99 (upper99) 响应工夫，比这个工夫略长 1.5 倍左右。
线程池设置次要依据服务的均匀响应工夫和 RPS 确定，依据排队论，实践上最小值应该是 N=RPS×1s/λN=RPS×1s/λ, 其中 λλ 就是均匀响应工夫，1s1s 也即一秒钟。当然，理论应用时要比这个值设置的大一些，比方 1.5 倍到 2 倍，均匀响应工夫也要依据服务压力比拟大时的均匀响应工夫指定。这个参数最好设置成 Hystrix 与 HttpClient 等同，特地不要设置成 Hystrix 线程池比 HttpClient 最大连贯数目大，否则 Hystrix 的线程会在期待 HttpClient 资源时排队会排队，导致延时回升。
线程池耗尽后，Hystrix 对新来的申请也会间接调用 fallback 逻辑。
另外，特地须要留神的是，应用 Hystrix 时应该实现 Fallback 逻辑，不要留空，并且留神代码逻辑中妥善处理异样。这是因为 Hystrix 在没有 Fallback 逻辑时会向下级抛出异样，如果业务逻辑没有解决好这些异样，可能会持续上抛直到本服务的 Servlet 容器，如 Jetty. 尽管 Servlet 容器个别不会因而挂掉，但异样解决代价是昂扬的，特地是如果代码中顺手打印了调用栈，打印异样的调用栈是串行的，因而在 RPS 较高的服务中很容易把整个 Java 过程搞挂，而此时可能正是流量顶峰，于是雪上加霜。
对此，集体的思考是异样本不应该大量抛出，解决异样的代价总体而言是要比失常逻辑代价高很多的。调用依赖失败在网络环境下其实是比拟失常的一种状况，并且可能大量产生，用异样示意依赖调用失败是略显不合理。个别异样解决代码不必过于在意效率，因为异样是常见的。但唯独这种情境下必须思考效率，因为高 RPS 下异样可能频率十分高。特地留神，Hystrix 短路时如果没有 Fallback 逻辑，就会大量抛出异样。短路逻辑顾名思义，其解决代价应该小于失常逻辑，但如果 Hystrix 抛出异样并且没有尽快被业务逻辑解决掉，则短路状态下解决代价就有可能很高，导致服务挂掉。
这些论断大部分都是之前的前辈调研和总结的，我的 Mock 平台上的试验次要发现了 HttpClient & Hystrix 的参数相互之间的优先关系，以及异样解决的问题。咱们起初复盘时有一些总结：
- 这个 Mock 零碎的服务和其依赖都是假的，形象称之为「空对空」，零碎行为过于现实，无奈再现理论业务场景下服务的 CPU 负载等简单行为，导致其参考价值不高。
- 有条件的场合，最好思考把实在的线上服务在一个受控环境中启动，并通过流量重放等形式进行测试。然而，我过后须要测试的服务过于简单。它是举荐零碎的后盾，依赖过多，把这些依赖全副 Mock 过于艰难。
- 总体而言，复现网络环境、网络相干的问题是很艰难的。或者，增强监控，出问题时及时登录到出问题的机器节点上察看是更适合的抉择。
Resilience4j 简介
Hystrix 曾经不再沉闷开发。其应用要借助继承机制，略显繁琐。Hystrix 自身也有肯定的开销。而 Resilience4j 是其官网举荐的后续。两者的性能类似，但 Resilience4j 默认应用 Java8 提供的 lambda 表达式实现，更为简洁优雅，同时也更为轻量、模块化。据笔者测试，其开销也要远远小于 Hystrix. 具体介绍参考其官网 github.
