在本文中，我将介绍微服务中的容错以及如何实现它。如果你在维基百科上查找它，你会发现以下定义：

容错是使系统在其某些组件发生故障时能够继续正常运行的属性。

对我们来说，组件意味着任何东西：微服务、数据库（DB）、负载均衡器（LB），应有尽有。我不会介绍 DB/LB 容错机制，因为它们是特定于供应商的，启用它们最终会设置一些属性或更改部署策略。
作为软件工程师，应用程序是我们拥有所有权力和责任的地方，所以让我们照顾好它。这是模式列表，我将介绍：

• 超时
• 重试
• 断路器
• 截止日期（Deadlines）
• 速率限制器

有些模式是众所周知的，你甚至可能怀疑它们是否值得一提，但请继续阅读这篇文章——我将简要介绍基本形式，然后讨论它们的缺陷以及如何克服它们。

超时

超时是允许等待某个事件发生的指定时间段。如果您使用 SO_TIMEOUT（也称为套接字超时或读取超时），则会出现问题——它表示任何两个连续数据包之间的超时，而不是整个响应，因此执行 SLA 更加困难，尤其是当响应负载很大时。您通常想要的是超时，它涵盖了从建立连接到响应的最后一个字节的整个交互。 SLA 通常用这种超时来描述，因为它们对我们来说是人道和自然的。可悲的是，它们不符合 SO_TIMEOUT 理念。要在 JVM 世界中克服它，您可以使用 JDK11 或 OkHttp 客户端。 Go 在 std 库中也有一个机制。
如果您想深入了解，请查看我之前的文章。

重试

如果您的请求失败 - 请稍等，然后重试。基本上就是这样，重试是有意义的，因为网络可能会暂时降级或 GC 命中您的请求所针对的特定实例。现在，想象一下有这样的微服务链：

如果我们将每个服务的总尝试次数设置为 3 并且服务 D 突然开始服务 100% 的错误会发生什么？这将导致重试风暴——链中的每个服务都开始重试它们的请求，因此大大增加了总负载，因此 B 将面临 3 倍负载，C - 9 倍和 D - 27 倍！冗余是实现高可用性的关键原则之一，但我怀疑在这种情况下集群 C 和 D 上是否有足够的可用容量。将总尝试次数设置为 2 也无济于事，而且它会使用户体验在小问题上变得更糟。
解决方案：

• 区分可重试的错误和不可重试的错误。当用户没有权限或负载结构不正确时，重试请求是没有意义的。相反，重试请求超时或 5xx 是好的。
• 采用错误预算——技术，当可重试错误率超过阈值时停止重试，例如如果与服务 D 的 20% 的交互导致错误，请停止重试并尝试优雅降级。在最后几秒内滚动窗口可能会跟踪错误数量。

断路器

断路器可以解释为更严格的错误预算版本——当错误率太高时，函数根本不会被执行，并且会返回回退结果（如果提供的话）。无论如何都应该执行一小部分请求，以了解第 3 方是否恢复。我们想要的是让第 3 方有机会在不进行任何手动工作的情况下恢复。
您可能会争辩说，如果功能处于关键路径上，则启用断路器是没有意义的，但请记住，这种短暂且受控的“中断”可能会阻止一个大的且无法控制的中断。
尽管断路器和错误预算具有相似的想法，但配置它们是有意义的。由于错误预算的破坏性较小，因此其阈值必须更小。
长期以来，Hystrix 是 JVM 中的首选断路器实现。截至目前，它进入了维护模式，建议改用 resilience4j 。

截止日期/分布式超时

我们已经在本文的第一部分讨论了超时，现在让我们看看如何使它们“分布式”。首先，重新访问相互调用的相同服务链：

服务 A 愿意最多等待 400 毫秒并请求需要所有 3 个下游服务完成一些工作。假设服务 B 花了 400 毫秒，现在准备调用服务 C。这是否合理？不！服务超时，不再等待结果。进一步进行只会浪费资源并增加重试风暴的敏感性。
为了实现它，我们必须在请求中添加额外的元数据，这将有助于理解什么时候中断处理是合理的。理想情况下，这应该得到所有参与者的支持并在整个系统中传递。
在实践中，此元数据是以下之一：

• 时间戳：通过您的服务将停止等待响应的时间点。首先，网关/前端服务将截止日期设置为“当前时间戳+超时”。接下来，任何下游服务都应该检查当前时间戳是否≥截止日期。如果答案是肯定的，那么关闭它是安全的，否则 - 开始处理。不幸的是，当机器可以有不同的时钟时间时，时钟偏差就会出现问题。如果发生这种情况，请求将被卡住或/并立即被拒绝，从而导致中断发生。
• 超时：通过服务允许等待的时间量。这实现起来有点棘手。与尽快设定截止日期之前一样。接下来，任何下游服务都应该计算它花费了多少时间，从入站超时中减去它并传递给下一个参与者。重要的是不要忘记排队等候的时间！所以，如果允许服务 A 等待 400ms，服务 B 花费 150ms，则在调用服务 C 时，它必须附加 250ms 的期限超时。虽然它不计算在线上花费的时间，但期限只能稍后触发，而不是更早，因此，可能会消耗更多的资源，但不会破坏结果。截止日期在 GRPC 中以这种方式实现。

最后要讨论的是——当超过最后期限时，不中断调用链是否有意义？答案是肯定的，如果你的服务有足够的可用容量并且完成请求会使它变得更热（缓存/JIT），那么继续处理是可以的。

速率限制器

前面讨论的模式主要解决了级联故障的问题——依赖服务崩溃后依赖崩溃，最终导致完全关闭的情况。现在，让我们介绍一下服务超载时的情况。它可能发生的原因有很多技术和特定领域的原因，假设它发生了。

每个应用程序都有其未知的容量。这个值是动态的，取决于多个变量——例如最近的代码更改、当前运行的 CPU 应用程序的模型、主机的繁忙程度等。
当负载超过容量时会发生什么？通常，会发生这种恶性循环：

• 响应时间增加，GC 占用空间增加
• 客户端获得更多超时，甚至更多负载到达
• 转到 1，但更严重

这是可能发生的事情的一个例子。当然，如果客户有错误预算/断路器，第二项可能不会产生额外的负载，从而有机会离开这个循环。相反，可能会发生其他事情——从 LB 的上游列表中删除实例可能会在负载和关闭邻居实例等方面造成更多不平等。

限制器来救援！他们的想法是优雅地卸载传入的负载。这就是理想情况下应该如何处理过多的负载：

• 限制器降低超出容量的额外负载，从而让应用程序根据 SLA 处理请求
• 过度负载重新分配到其他实例/集群自动缩放/集群由人工缩放

有两种类型的限制器——速率（rate ）和并发，前者限制入站 RPS，后者限制任何时刻正在处理的请求数量。
为了简单起见，我假设所有对我们服务的请求在计算成本上几乎相等并且具有相同的重要性。计算不平等源于这样一个事实，即不同的用户可以有不同数量的与之关联的数据，例如喜欢的电视剧或以前的订单。通常，采用分页有助于实现请求的计算平等。
速率限制器使用更广泛，但没有提供像并发限制那样强大的保证，所以如果你想选择一个，坚持并发限制，这就是原因。
在配置速率限制器时，我们认为我们强制执行以下操作：

该服务可以在任何时间点每秒处理 N 个请求。

但我们实际上声明的是这样的：

假设响应时间不会改变，该服务可以在任何时间点每秒处理 N 个请求。

为什么这句话很重要？我会用直觉“证明”它。对于那些愿意基于数学证明的人——检查利特尔定律。假设速率限制为 1000 RPS，响应时间为 1000 毫秒，SLA 为 1200 毫秒，在给定的 SLA 下，我们很容易在一秒钟内准确地处理 1000 个请求。

现在，响应时间增加了 50 毫秒（依赖服务开始做额外的工作）。从现在开始服务的每一秒都会面临越来越多的请求同时被处理，因为到达率大于服务率。拥有无限数量的工作人员意味着您将耗尽资源并崩溃，尤其是在工作人员以 1:1 映射到操作系统线程的环境中。 1000 名工作人员的并发限制如何处理？它将可靠地提供 1000/1.05 = ~950 RPS 而不会违反 SLA，并放弃其余的。此外，无需重新配置即可赶上！
我们可以在每次依赖关系发生变化时更新速率限制，但这是一个巨大的负担，可能需要在每次变化时重新配置整个生态系统。
根据设置限制值的方式，它可以是静态限制器，也可以是动态限制器。

静止的

在这种情况下，限制是手动配置的。价值可以通过定期的性能测试来评估。虽然它不会 100% 准确，但为了安全起见，它可以被悲观。这种类型的限制需要围绕 CI/CD 管道完成工作，并且资源利用率较低。静态限制器可以通过限制工作线程池的大小（仅限并发）、添加计数请求的入站过滤器、NGINX 限制功能或 envoy sidecar 代理来实现。

动态的

在这里，限制取决于度量，它会定期重新计算。 很有可能，您的服务在过载和响应时间增长之间存在相关性。 如果是这样，度量可以是响应时间的统计函数，例如 百分位、中等或平均水平。 还记得计算相等属性吗？ 此属性是更准确计算的关键。
然后，定义一个谓词来回答指标是否健康。 例如，p99 ≥ 500ms 被认为是不健康的，因此应该降低限制。 如何增加和减少限制应该由应用反馈控制算法决定，如 AIMD（用于 TCP 协议）。 这是它的伪代码：

if healthy {
    limit = limit + increase;
} else {
    limit = limit * decreaseRatio; // 0 < decreaseRatio < 1.0
}

AIMD in action

如您所见，限制增长缓慢，探测应用程序是否运行良好，如果发现错误行为，则急剧减少。
Netflix 率先提出了动态限制的想法并开源了他们的解决方案，这里是 repo。 它实现了几种反馈算法、静态限制器实现、GRPC 集成和 Java servlet 集成。

呵呵，就是这样！ 我希望你今天学到了一些新的和有用的东西。 我想指出，这个列表并不详尽，您还希望获得良好的可观察性，因为可能会发生意想不到的事情，最好了解您的应用程序目前正在发生什么。 然而，实施这些将解决您当前或潜在的大量问题。

参考

• Google SRE book, especially chapters Addressing Cascading Failures and Handling Overload
• Netflix article about dynamic limits

原文：https://itnext.io/5-patterns-to-make-your-microservice-fault-tolerant-f…

本文：