断路器模式

断路器模式有助于处理在应用程序连接到远程服务或资源时可能需要不同时间才能恢复的故障。 断路器在检测到故障后暂时阻止访问故障服务。 此作可防止反复尝试失败，以便系统能够有效地恢复。 此模式可以提高应用程序的稳定性和复原能力。

上下文和问题

在分布式环境中，由于暂时性故障，对远程资源和服务的调用可能会失败。 暂时性故障包括资源过度分配或暂时不可用的资源、网络连接缓慢或超时。 这些错误通常在短时间内自行纠正。 为了帮助管理这些故障，应设计云应用程序以使用策略，例如 重试模式。

意外事件可能会创建需要更长时间才能修复的故障。 这些故障的严重性范围从部分连接丢失到完整的服务故障。 在这些情况下，应用程序不应持续不断地重试那些不太可能成功的操作。 相反，应用程序应快速识别失败的操作并相应地处理该失败。

如果服务繁忙，系统一部分发生故障可能会导致级联故障。 例如，您可以配置一个调用服务以实现超时的操作。如果服务在此时间段内无法响应，操作将回复失败消息。

但是，此策略可以阻止对同一操作的并发请求，直到超时期限结束。 这些被阻止的请求可能会保存关键的系统资源，例如内存、线程和数据库连接。 此问题可能会耗尽资源，这可能会使系统的其他不相关部分无法使用同一资源。

在这些情况下，操作应立即失败，并且只有在成功可能性较高时才尝试调用服务。 若要解决此问题，请设置较短的超时时间。但确保超时时间足够长，使作在大部分时间成功。

解决方案

断路器模式设计有助于防止应用程序反复尝试执行可能失败的操作。 此模式使应用程序能够继续运行，而无需等待故障得到修复或浪费 CPU 周期来确定故障是永久性的。 断路器模式还使应用程序能够检测故障何时解决。 如果故障得到解决，应用程序可以尝试再次调用该作。

针对可能失败的操作，断路器充当其代理。 代理应监视最近的失败次数，并使用此信息决定是允许操作继续进行还是立即返回异常。

可以将代理实现为包含以下状态的状态机。 这些状态模拟断路器的功能：

• 关闭： 来自应用程序的请求将路由到操作。 代理会记录最近失败的次数。 如果代理对操作的调用失败，就会递增此计数。 如果最近的失败次数超过给定时间段内的指定阈值，则代理将进入 “打开 ”状态，并启动超时计时器。 计时器过期时，代理将置于 半打开 状态。

  注释

  在超时时间，系统尝试修复导致故障的问题之后，它才允许应用程序再次尝试该操作。

• 打开： 来自应用程序的请求会立即失败，并将异常返回到应用程序。

• 半开： 允许应用程序发送有限数量的请求以调用该操作。 如果这些请求成功，断路器假定导致故障的故障已修复，断路器将切换到 “已关闭 ”状态。 故障计数器已重置。 如果任何请求失败，断路器假定故障仍然存在，因此它将恢复为 “打开 ”状态。 它会重启超时计时器，以便系统能够从故障中恢复。

  注释

  半开放状态有助于防止恢复服务突然被请求淹没。 当服务恢复时，它可能能够支持有限的请求量，直到恢复完成。 但是，虽然恢复正在进行中，但大量工作可能导致服务超时或再次失败。

下图显示了每种状态的计数器操作。

关闭状态的失败计数器基于时间。 它会定期自动重置。 此设计有助于防止断路器在偶尔发生故障时进入 “打开 ”状态。 仅当指定间隔内发生指定数量的故障时，故障阈值才会触发 Open 状态。

半打开状态的成功计数器记录成功尝试执行操作的次数。 断路器在指定数量的成功连续操作调用后还原为“已关闭”状态。 如果任何调用失败，断路器会立即进入 “打开 ”状态，成功计数器下次进入 半打开 状态时重置。

断路器模式在系统从故障中恢复时提供稳定性，并将对性能的影响降至最低。 它可以帮助维护系统的响应时间。 此模式快速拒绝可能会失败的操作请求，而不是等待操作超时或永不返回。 如果断路器每次更改状态时引发事件，此信息可帮助监视受保护系统组件的运行状况，或者在断路器切换到 “打开 ”状态时向管理员发出警报。

可以自定义此模式并将其适应不同类型的故障。 例如，可以将增加的超时计时器应用于断路器。 最初可以将断路器置于 “打开 ”状态几秒钟。 如果故障问题仍未解决，请将超时设置为几分钟，并根据情况进行调整。 在某些情况下， Open 状态可以返回对应用程序有意义的默认值，而不是返回失败并引发异常。

问题和注意事项

实现此模式时，请考虑以下因素：

• 异常处理： 一个通过断路器调用操作的应用程序必须能够在操作不可用时处理异常。 异常管理基于应用程序。 例如，应用程序可能会暂时降级其功能，调用替代作以尝试执行相同的任务或获取相同的数据，或向用户报告异常，并要求他们稍后重试。

• 异常类型： 请求失败的原因可能因严重性而异。 例如，请求可能会失败，因为远程服务崩溃，需要几分钟才能恢复，或者因为重载的服务会导致超时。断路器可能能够检查发生的异常类型，并根据这些异常的性质调整其策略。 例如，与不可用服务引起的失败次数相比，熔断器可能需要更大量的超时异常来触发到打开状态。

• 监测： 断路器应为失败和成功的请求提供明确的可观测性，以便运营团队能够评估系统运行状况。 使用分布式跟踪实现跨服务的端到端可见性。

• 可恢复性： 应将断路器配置为匹配其所保护操作的可能恢复模式。 例如，如果断路器长时间处于 “打开 ”状态，即使故障原因得到解决，它也会引发异常。 同样，如果断路器从 Open 状态切换到 半打开 状态太快，则断路器可能会波动并减少应用程序的响应时间。

• 失败操作测试： 在打开状态中，断路器可以定期向远程服务或资源发送ping请求，以确定其是否可用，而不是使用计时器来确定何时切换到半打开状态。 这个 ping 可以尝试调用以前失败的操作或使用远程服务提供的特殊健康检查操作。 有关详细信息，请参阅 运行状况终结点监视模式。

• 手动覆盖： 如果故障操作的恢复时间极其可变，则应提供一个手动重置选项，使管理员能够打开断路器并重置故障计数器。 同样，如果受保护的操作暂时不可用，管理员可以强制断路器进入开启状态，并重启超时计时器。

• 并发： 应用程序的大量并发实例可以访问相同的断路器。 该实现不应阻止并发请求，或对操作的每个调用添加过多的开销。

• 资源差异化： 如果可能存在多个独立的基础提供商，在为某一种类型的资源使用单一断路器时请务必谨慎。 例如，在包含多个分片的数据存储中，一个分片可能完全可访问，而另一个分片则遇到临时问题。 如果在这些场景中合并了错误响应，应用程序可能会尝试访问某些分片，即使发生故障的可能性很大。 即使可能会成功访问其他分片，也可能被阻止。

• 加速断路器： 有时，故障响应可以包含足够的信息，使断路器能够立即断开，并保持停留断开的最短时间。 例如，来自重载的共享资源的错误响应可以指示应用程序应在几分钟内重试，而不是立即重试。

• 多区域部署： 可以为单区域或多区域部署设计断路器。 若要针对多区域部署进行设计，请使用全局负载均衡器或自定义区域感知线路中断策略，以帮助确保受控故障转移、延迟优化和法规符合性。

• 服务网格断路器： 可以在应用程序层或作为交叉抽象特征实现断路器。 例如，服务网格通常支持以 sidecar 或独立功能的形式中断线路，而无需修改应用程序代码。

  注释

  如果服务限制客户端，则服务可以返回 HTTP 429（请求过多），如果服务不可用，则返回 HTTP 503（服务不可用）。 响应可以包含其他信息，例如延迟的预期持续时间。

• 失败的请求重播： 在打开状态，而不是简单地快速失败，断路器还可以将每个请求的详细信息记录到日志中，并安排在远程资源或服务可用时重播这些请求。

• 外部服务中的不当超时： 熔断器可能无法完全保护应用程序免受具有长时间超时的外部服务故障的影响。 如果超时时间过长，那么运行断路器的线程可能会长时间被阻塞，直到断路器表明操作失败。 在此期间，许多其他应用程序实例可能还会尝试通过断路器调用服务，并在它们全部失败之前连接多个线程。

• 计算多元化的适应性： 断路器应考虑到不同的计算环境，从无服务器工作负荷到容器化工作负荷，其中冷启动和可伸缩性等因素会影响故障处理。 自适应方法可以根据计算类型动态调整策略，这有助于确保异类体系结构的复原能力。

何时使用此模式

在以下情况下使用此模式：

• 如果这些操作可能会失败，您希望通过停止对共享资源的过多远程服务调用或访问请求来防止级联故障。

• 你想要根据实时故障信号智能路由流量，以增强多区域复原能力。

• 您希望应对响应缓慢的依赖项，以保持服务级别目标，并避免由于高延迟服务而导致的性能下降。

• 你想要管理间歇性连接问题，并减少分布式环境中的请求失败。

在以下情况下，此模式可能不适用：

• 需要管理对应用程序中本地专用资源的访问，例如内存中数据结构。 在此环境中，断路器会增加系统开销。

• 你需要将其用作处理应用程序业务逻辑中的异常的替代方法。

• 已知的重试算法已足够，并且依赖项旨在处理重试机制。 在此方案中，应用程序中的断路器可能会向系统添加不必要的复杂性。

• 等待断路器重置可能会导致不可接受的延迟。

• 你有消息驱动或事件驱动的体系结构，因为它们通常会将失败的消息路由到死信队列，以便进行手动或延迟处理。 内置故障隔离和重试机制通常已足够。

• 故障恢复在基础结构或平台级别进行管理，例如全局负载均衡器或服务网格中的运行状况检查。

工作负荷设计

在设计工作负载时，评估如何使用断路器模式，以便满足 Azure Well-Architected Framework 支柱所涉及的目标和原则。 下表提供有关此模式如何支持每个支柱目标的指南。

如果此模式在某个支柱中引入权衡取舍，请将它们与其他支柱的目标进行对比。

示例：

此示例实现断路器模式，以利用 Azure Cosmos DB 永久免费层来帮助防止配额超出。 此层主要用于非关键数据，并且根据容量计划运行，该计划分配每秒资源单位的特定配额。 在季节性事件期间，需求可能会超过提供的容量，这可能会导致 429 响应。

发生需求高峰时， 具有动态阈值的 Azure Monitor 警报 会检测并主动通知运营和管理团队，数据库需要更多容量。 同时，使用历史错误模式调节的断路器被触发，以防止级联故障。 在此状态下，应用程序通过返回默认或缓存的响应来正常降级。 应用程序通知用户某些数据的暂时不可用，同时保持系统的整体稳定性。

此策略可增强与业务理由一致的复原能力。 它控制容量激增，以便工作负荷团队可以故意管理成本增加和维护服务质量，而不会意外增加运营费用。 确认需求消退或增加容量后，断路器将重置，应用程序将恢复与技术和预算目标保持一致的完整功能。

下载此体系结构的 Visio 文件。

流 A：已关闭状态

• 系统正常运行，所有请求到达数据库时均未返回任何 429 HTTP 响应。

• 断路器保持关闭状态，不需要默认或缓存的响应。

流 B：打开状态

1. 当断路器收到第一个 429 响应时，它会进入 “打开 ”状态。

2. 后续请求会立即短路，这会返回默认或缓存的响应，并通知用户临时降级。 应用程序受到防止进一步重载的保护。

3. Azure Monitor 接收日志和遥测数据，并针对动态阈值评估日志和遥测数据。 如果满足警报规则的条件，则会触发警报。

4. 作组主动通知运营团队重载情况。

5. 在工作负荷团队批准后，运营团队可以增加预配的吞吐量，以缓解超载，或者如果负载自然减轻，则延迟拓展。

流 C：Half-Open 状态

1. 预定义超时后，断路器进入 半开放 状态，允许有限数量的试用请求。

2. 如果这些试验请求成功而不返回 429 响应，断路器将重置为 关闭 状态，正常操作将恢复至流 A。如果故障持续存在，断路器将恢复为 打开 状态或流 B。

组件

• Azure 应用服务 托管用作客户端请求的主要入口点的 Web 应用程序。 应用程序代码实现用于强制实施断路器策略的逻辑，并在线路打开时提供默认或缓存的响应。 此体系结构有助于防止下游系统上的过载，并在高峰需求或故障期间保持用户体验。

• Azure Cosmos DB 是应用程序的数据存储之一。 它通过免费层提供非关键数据，非常适合小型生产工作负荷。 断路器机制有助于在高需求时段限制到数据库的流量。

• Azure Monitor 充当集中式监视解决方案。 它将聚合所有活动日志，以帮助确保全面、端到端的可观测性。 Azure Monitor 从应用服务接收日志和遥测数据，并从 Azure Cosmos DB 接收关键指标（例如 429 响应数），用于聚合和分析。

• Azure Monitor 警报 根据 动态阈值权衡警报规则， 根据历史数据确定潜在的中断。 违反阈值时，预定义警报会通知运营团队。

  有时，工作负荷团队可能会批准增加预配的吞吐量，但运营团队预计系统可以自行恢复，因为负载不是太高。 在这些情况下，断路器超时自然会过去。 在此期间，如果 429 响应停止，阈值计算将检测长时间的中断，并将其从学习算法中排除。 因此，下次发生重载时，阈值会等待 Azure Cosmos DB 中出现更高的错误率，这会延迟通知。 这种调整允许断路器在不立即发出警报的情况下处理问题，从而提高成本和运营效率。

相关资源

• 可靠 Web 应用模式将断路器模式应用于在云上聚合的 Web 应用程序。

• 重试模式描述应用程序在尝试连接到服务或网络资源时如何通过透明地重试以前失败的作来处理预期的临时故障。

• 健康终端监控模式描述断路器如何通过向服务所公开的终端发送请求来检查服务的运行状况。 服务应返回指示其状态的信息。