WHY

当一个 service 去调用另一个 service 时，就有可能会产生故障。这些故障可能是由与各种起因所引起的，比方：

• 服务器端
• 客户端
• 网络
• 负载均衡器
• 软件
• 操作系统

设计零碎的目标是缩小产生故障的可能性，但咱们无奈构建永不中断的零碎。因而咱们须要做的是进一步设计咱们的零碎，以“容忍”故障，并防止将一小部分故障放大为一次系统性的故障。

WHAT

超时（timeouts）

许多类型的失败体现为申请破费的工夫比平时更长，并且可能永远无奈实现。如果客户端期待响应的工夫比个别状况下长得多，则在客户端期待时，会将资源持有更多工夫。这会导致内存，线程，连贯，长期端口或其余任何无限资源的耗尽。为了防止这种状况，客户端设置了timeouts，即客户端违心期待申请实现的最长工夫。

重试（retry）

通常，将失败的申请再次进行尝试会胜利。产生这种状况是因为咱们构建的零碎通常不会作为一个整体而失败：相同，它们会产生局部故障（肯定比例的申请胜利）或短暂故障（申请在短时间内失败）。重试容许客户端通过再次发送雷同的申请来防止“随机”产生的局部故障或短暂故障。被重试的服务肯定须要是幂等的。

HOW

如何设置超时工夫

设置超时工夫是一个须要衡量的事件。如果咱们将超时工夫设置的过大，那么就会失去设置它的意义，因为 client 在期待超时时仍会耗费资源。而如果咱们设置的过小，会导致重试次数过多，减少后端流量，进而会减少服务的提早，而该提早的减少，又会进一步导致更多的重试，进而有可能造成齐全的中断。
抉择一个好的超时工夫通常须要咱们观测 RPC 申请延时，一般来说会设置为申请延时的 p99。这样的设置会有可能在网络中产生两个雷同的申请，期待较早返回的申请即可。但在某些状况下须要咱们更加认真的进行剖析，比方：

• 某些地区的客户端总是产生比拟大的提早。比方可能是因为咱们的客户遍布寰球，而该地区间隔服务器很远等起因。在这种状况下，咱们要思考的正当的最坏状况下的网络提早。
• 此办法也不适用于 latency 相差不大的状况下，比方 p50 十分靠近 p99。在这些状况下，能够增加一些 buffer。

如何设置重试次数以及重试间隔时间

始终记住的一点是：Retries are“selfish.”

重试的危险

1. 重试会加大间接上游的负载。假如 A 服务调用 B 服务，重试次数设置为 r（包含首次申请），当 B 高负载时很可能调用不胜利，这时 A 调用失败重试 B，B 服务的被调用量疾速增大，最坏状况下可能放大到 r 倍，不仅不能申请胜利，还可能导致 B 的负载持续升高，甚至间接打挂。
2. 更可怕的是，重试还会存在链路放大的效应。假如当初场景是 Backend A 调用 Backend B，Backend B 调用 DB Frontend，均设置重试次数为 3。如果 Backend B 调用 DB Frontend，申请 3 次都失败了，这时 Backend B 会给 Backend A 返回失败。然而 Backend A 也有重试的逻辑，Backend A 重试 Backend B 三次，每一次 Backend B 都会申请 DB Frontend 3 次，这样算起来，DB Frontend 就会被申请了 9 次，理论是指数级扩充。假如失常访问量是 n，链路一共有 m 层，每层重试次数为 r，则最初一层受到的访问量最大，为 n * r ^ (m - 1)。这种指数放大的效应很可怕，可能导致链路上多层都被打挂，整个零碎雪崩。

重试治理

1. 动静配置
   如何让业务方简略接入是首先要解决的问题。如果还是一般组件库的形式，仍旧免不了要大量入侵用户代码，且很难动静调整。字节跳动应用了 middleware（中间件）模式，将业务代码和非业务代码进行理解耦。他们定义了一个 middleware 并在外部实现了对 RPC 的反复调用，把反复的配置信息用分布式存储核心进行存储，这样 middleware 能够读取配置核心的配置并进行重试，对用户来说不须要批改调用 RPC 的代码，而只须要在服务中引入一个全局的 middleware 即可。
   如上面的整体架构图所示，他们专门提供了配置的网页和后盾，使用户可能在专门进行服务治理的页面很不便的对 RPC 进行配置批改并主动失效，外部的实现逻辑对用户通明，对业务代码无入侵。
   
   配置的纬度依照了字节的 RPC 调用特点，选定[调用方服务，调用房方集群，被调用方服务，被调用方办法] 为一个元组，依照元组进行配置。Middleware 中封装了读取配置的办法，在 RPC 调用的时候会主动读取并失效。
   这种 middleware 形式可能让业务方很容易接入，一次接入当前就具备动静配置的能力，能够很不便地调整或者敞开重试配置。

2. 退却策略

   • 线性退却：每次期待固定工夫后重试。
   • 随机退却：在肯定范畴内随机期待一个工夫后重试。
   • 指数退却：间断重试时，每次等待时间都是前一次的倍数。(罕用)

3. 避免 retry storm

   • 退却策略中增加适当的随机抖动
     增加抖动不是齐全随机的抖动，咱们须要应用某种办法，使得每次在同一台主机上产生雷同的抖动。这样，如果服务超载或服务故障，则该主机的行为模式会完全相同。这样不便咱们发现并剖析问题产生的根本原因。
   • 限度单点重试
     咱们能够基于断路器的思维，限度 申请胜利 / 申请失败 的比率，给重试减少熔断性能。这里采纳了滑动窗口的办法来实现，如下图，内存中为每一类 RPC 调用保护一个滑动窗口，窗口中含有 10 个 bucket，每个 bucket 中记录了一秒内 RPC 的申请后果（胜利 / 失败）。新的一秒到来时，生成新的 bucket，并淘汰最早的一个 bucket，只维持 10s 的数据。在新申请这个 RPC 失败时，依据前 10s 内的 失败 / 胜利 是否超过阈值来判断是否能够重试。默认阈值能够设置为 0.1，即上游最多接受 1.1 倍的 QPS，用户能够依据须要自行调整熔断开关和阈值。
     

   • 限度链路重试
     尽管有了重试熔断之后，重试不再是指数增长(每一单节点重试扩充限度了 1.1 倍)，但还是会随着链路的级数增长而扩充调用次数，因而还是须要从链路层面来思考重试的安全性。链路层面的防重试风暴的外围是限度每层都产生重试，现实状况下只有最下一层产生重试。
     Google SRE 中指出了 Google 外部应用非凡错误码的形式来实现：

     • 对立约定一个非凡的 status code，它示意：调用失败，但别重试。
     • 任何一级重试失败后，生成该 status code 并返回给下层。
     • 下层收到该 status code 后进行对这个上游的重试，并将错误码再传给本人的下层。

     但该办法对业务代码有肯定入侵，字节跳动外部用的 RPC 协定中有扩大字段，他们在 Middleware 中封装了错误码解决和传递的逻辑，在 RPC 的 Response 扩大字段中传递错误码标识 nomore_retry，它通知上游不要再重试了。Middleware 实现错误码的生成、辨认、传递等整个生命周期的治理，不须要业务方批改自身的 RPC 逻辑，错误码的计划对业务来说是通明的。
     
     在链路中，推动每层都接入重试组件，这样每一层都能够通过辨认这个标记位来进行重试，并逐层往上传递，下层也都进行重试，做到链路层面的防护，达到“只有最靠近谬误产生的那一层才重试”的成果。

   • 超时解决
     对于 A -> B -> C 的场景，假如 B -> C 超时，B 重试申请 C，这时候很可能 A -> B 也超时了，所以 A 没有拿到 B 返回的错误码，而是也会重试 B , 这个时候尽管 B 重试 C 且生成了重试失败的错误码，然而却不能再传递给 A。这种状况下，A 还是会重试 B，如果链路中每一层都超时，那么还是会呈现链路指数扩充的效应。
     因而为了解决这种状况，除了上游传递重试谬误标记以外，还须要实现“ 对重试申请不重试 ”的计划。
     对重试申请，在 request 上打上一个非凡的 retry flag，在下面的 A ->B->C 的链路中，当 B 收到 A 的申请时，会先读取这个 flag 判断是不是重试申请，如果是，那么它调用 C 即便失败也不会重试，否则调用 C 失败后会重试 C。同时 B 也会把这个 retry flag 向下传，它收回的申请也会有这个标记位，它的上游也不会再对这个申请重试。
     
     这样即便 A 因为超时而拿不到 B 的返回，对 B 收回重试申请后，B 能感知到并且不会对 C 重试，这样 A 最多申请 r 次，B 最多申请 r +r- 1 次，如果前面还有更上层的话，C 最多申请 r +r+r- 2 次，第 i 层最多申请 i *r-(i-1) 次，最坏状况下是倍数增长，不是指数增长了。加上理论还有重试熔断限度，增长的幅度要小很多。

   通过 重试熔断 来限度单点的放大倍数，通过 重试谬误标记链路回传 的形式来保障只有最上层产生重试，又通过 重试申请标记链路下传 的形式来保障对重试申请不重试，多种控制策略联合，能够无效的升高重试放大效应。

4. 联合 DDL
   DDL 是“deadline request 调用链超时”的简称，在 TCP/IP 协定中的 TTL 用于判断数据包在网络中的工夫是否太长而应该被抛弃，DDL 与之类似，它是一种 全链路 式的调用超时，能够用来判断以后的 RPC 申请是否还须要继续下去。字节的根底团队实现了 DDL 性能，在 RPC 申请的调用链中会带上超时工夫，并且每通过一层就减去该层解决的工夫，如果剩下的工夫曾经小于 0，则能够不须要再申请上游，间接返回失败即可。
   
   DDL 的形式能无效缩小对上游的有效调用，在重试治理中联合 DDL 的数据，在每一次发动重试前都会判断 DDL 的残余值是否还大于 0，如果曾经不满足条件了，那也就没必要对上游进行重试，这样能做到最大限度的缩小无用的重试。

总结

在分布式系统中，不可避免的是刹时故障或近程交互中的提早。超时避免零碎等待时间过长，重试能够覆盖这些故障，退却策略和增加抖动能够缩小 retry storm。
字节的重试治理零碎，反对动静配置，无需入侵业务代码，并应用了多种策略管制重试放大效应，兼顾 易用性 ， 灵活性 ， 安全性。

参考

https://aws.amazon.com/cn/bui…
https://www.infoq.cn/article/…