如何使用断路器模式进行站点可靠性工程

分布式系统对站点可靠性工程师 (SRE) 有着独特的要求。维护站点可靠性的最佳方法之一是实施一套最佳实践。这些实践作为配置基础设施和策略的指南。

什么是断路器模式？

当另一个服务没有响应时，断路器模式可以防止您的服务停止或崩溃。

图片来源

(Robert Kimani, CC BY-SA 40)

例如，在示例图片中，业务逻辑微服务与用户身份验证服务、账户服务和网关服务进行通信。

正如您所见，此业务应用程序的“引擎”是业务逻辑微服务。但是，这里有一个陷阱。假设账户服务崩溃了。可能是内存耗尽了，或者后端数据库宕机了。当这种情况发生时，调用微服务开始产生反向压力，直到最终崩溃。这会导致您的 Web 服务性能下降，从而导致其他组件崩溃。必须实施断路器模式，以将您的分布式系统从这个问题中解救出来。

实施断路器模式

当远程服务失败时，理想的情况是让它快速失败。与其拖垮整个应用程序，不如在应用程序与它所依赖的服务失去联系时，以功能降低的方式运行应用程序。例如，保持您的应用程序在线，但牺牲其账户服务的可用性。像断路器这样的设计有助于避免级联故障。

以下是断路器设计的秘诀

1. 跟踪调用远程服务时遇到的故障次数。

2. 当达到预定义的计数或超时时，失败（断开电路）。

3. 再次等待预定义的时间，然后重试连接到远程服务。

4. 成功连接后，闭合电路（这意味着您可以重新建立与远程服务的连接）。但是，如果服务持续失败，则重新启动计数器。

与其依赖于性能不佳的远程服务，不如快速失败，以便您可以继续应用程序的其他操作。

开源断路器模式

开源提供了一些非常具体的组件，可以在您的基础设施中启用断路器逻辑。首先，使用代理层，例如 Istio。Istio 是一种与技术无关的解决方案，并使用“黑盒”方法（意味着它位于您的应用程序之外）。

或者，您可以使用 Hystrix，这是一个来自 Netflix 的开源库，已被许多应用程序团队广泛而成功地使用。Hystrix 构建到您的代码中。人们普遍认为，Hystrix 可以提供比 Istio 更多的功能和特性，但它必须“硬编码”到您的应用程序中。这对于您的应用程序是否重要取决于您如何管理代码库以及您实际需要哪些功能。

实施有效的负载均衡

负载均衡 是在资源集（计算单元）上分配一组任务的过程，目的是使其整体处理尽可能高效。负载均衡可以优化响应时间，并避免一些计算机节点过载而不均，而其他计算机节点则处于空闲状态。

图片来源

(Robert Kimani, CC BY-SA 40)

左侧的用户与负载均衡器上的虚拟 IP (vIP) 通信。负载均衡器在系统池中分配任务。用户不知道后端系统，仅通过负载均衡器与系统交互。

负载均衡有助于确保高可用性 (HA) 和良好的性能。高可用性意味着可以容忍服务器池中的故障，从而使您的服务在很大程度上保持可用。通过向池中添加更多服务器，可以通过水平扩展负载来提高有效性能（这称为水平扩展）。

 3 种负载均衡方式

1. DNS 负载均衡： 这是最直接且免费的方式。您无需购买任何专用硬件，因为它​​是 DNS 协议的基本功能，您只需返回多个 A 记录。A 记录将主机名映射到 IP 地址。当 DNS 服务器为一个主机名返回多个 IP 地址时，客户端将随机选择一个 IP 地址，换句话说，负载均衡会自动从客户端完成。

2. 专用硬件负载均衡器： 这是数据中心内通常使用的，它功能丰富且性能高。

3. 当您拥有 软件负载均衡器 时，您无需为此类型的负载均衡配备专用硬件，您只需在通用硬件上安装负载均衡器软件并将其用于您的负载均衡用例即可。

Nginx 和 HAProxy 主要用作软件负载均衡器，并且在您可以快速启动其功能的开发环境中非常有用。

DNS 负载均衡

当客户端查找主机名时，DNS 服务器可能会返回多个 IP 地址。这是因为在大型部署中，网络目标不仅仅在一个服务器上运行，甚至不仅仅在一个集群上运行。通常，客户端软件会从返回的地址中随机选择一个 IP 地址。控制客户端选择哪个 IP 并不容易。

除非您构建了自定义软件来确定服务器的健康状况，否则纯 DNS 负载均衡不知道服务器是启动还是关闭，因此客户端可能会被发送到已关闭的服务器。

客户端还会按设计缓存 DNS 条目，并且不容易清除它们。许多供应商提供根据地理位置选择客户端路由到哪个数据中心的功能。最终，影响客户端访问您的服务的重要方法是通过负载均衡。

专用负载均衡器

负载均衡可以发生在 OSI（开放系统互连）模型的第 3 层（网络）、第 4 层（传输）或第 7 层（应用层）。

• L3 负载均衡器在源 IP 地址和目标 IP 地址上运行。
• L4 负载均衡器使用 IP 地址和端口号（使用 TCP 协议）工作。
• L7 负载均衡器在最后一层（应用层）运行，通过利用整个有效负载。它利用整个应用程序数据，包括 HTTP URL、cookie、标头等。它能够为路由提供丰富的功能。例如，您可以根据传入的数据类型将请求发送到特定的服务。例如，当请求视频文件时，L7 负载均衡器可以将该请求发送到流媒体设备。

如今，有 5 种常用的负载均衡方法

• 轮询： 这是最简单和最常用的方法。负载均衡池中的目标按循环方式轮换。
• 加权轮询： 类似于轮询，但为后端目标手动分配了重要性。
• 最少负载或最少连接： 请求根据目标后端报告的负载进行路由。
• 具有慢启动的最少负载 或 最短响应时间： 根据目标的负载选择目标，并随着时间的推移逐渐增加请求，以防止淹没负载最少的后端。
• 利用率限制： 基于后端报告的每秒查询数 (QPS) 或每秒事件数 (EPS)。

有基于软件的负载均衡器。这可以是运行在通用硬件上的软件。您可以拿起任何 Linux 机器并在其上安装 HAProxy 或 Nginx。软件负载均衡器往往发展迅速，因为软件通常如此，并且相对便宜。

您还可以使用基于硬件的、专门构建的负载均衡器设备。这些设备可能很昂贵，但它们可能为专业市场提供独特的功能。

过渡到基于 Canary 的部署

在我之前的文章中，我解释了基于 Canary 的部署如何帮助 SRE 确保平稳的升级和过渡。您用于基于 Canary 的推出的确切方法取决于您的需求和环境。

通常，您首先在一个服务器上发布更改，只是为了看看已部署的软件包的运行情况。您此时要查找的是确保没有灾难性故障，例如，服务器没有启动或服务器在启动后崩溃。

一旦一个服务器的部署成功，您就希望继续将其安装在最多 1% 的服务器中。同样，这 1% 是通用指南，但实际上取决于您拥有的服务器数量和您的环境。如果适用于您的环境，则您可以继续为早期采用者发布。

最后，一旦 Canary 测试完成，您就希望在此时为所有用户发布。

请记住，Canary 失败是一个严重的问题。分析并实施稳健的测试流程，以便可以在测试阶段而不是在 Canary 测试期间捕获此类问题。

可靠性至关重要

可靠性是关键，因此在分布式系统中使用断路器模式以快速失败。您可以使用 Hystrix 库或 Istio。

设计负载均衡时，请混合使用 DNS 和专用负载均衡器，尤其是当您的应用程序是 Web 规模时。DNS 负载均衡可能不是完全可靠的，主要是因为 DNS 服务器可能不知道哪些后端服务器是健康的，甚至是启动并运行的。

最后，您必须使用 Canary 发布，但请记住，Canary 不能替代测试。