对任何应用程序来说，快速增长有利有弊。快速增长可增加收入，但也带来技术挑战。为了缓解这些挑战，开发人员应该考虑云设计模式。

企业很少会讨论管理基于云的应用程序的设计模式，除非企业发展到一定规模。现在有无数设计模式可供选择，最大的挑战之一是在必要时处理规模。为了更好地扩展工作负载，下面有5种设计模式可以使任何基于云的应用程序更容错，并能缓解流量增加带来的问题。

让我们看看这五个云设计模式，以帮助开发人员更好地处理意外吞吐量的增加：

1. 隔板模式。
2. 重试。
3. 断路器。
4. 基于队列的负载均衡（QBLL）。
5. 节流。

此外，企业还最好了解构建弹性应用程序的各种最佳实践。

1. 隔板模式

隔板模式以分隔船舶舱室的隔板命名，可以防止应用程序中的单次故障级联为完全故障。部署这种模式并不总是显而易见，它通常存在于在性能下降时仍能运行的应用程序中。

采用隔板模式的应用程序是基于弹性而构建。当电子邮件或缓存层出现故障时，并非所有操作都能继续运行，但采用隔板模式的应用程序仍然可以运行，保持与最终用户沟通。

由于隔离的应用程序部分可以相互独立运行，子系统故障可以安全地减少该应用程序的整体功能，而不需要全部关闭。隔板模式的很好的例子是，任何可以在离线模式下运行的应用程序。大多数基于云的应用程序需要外部API才能充分发挥其潜力，但容错客户端可以在没有云的情况下运行，通过依赖缓存资源和其他变通办法来确保客户端基本可用。

2. 重试

在很多应用程序中，失败是最终状态。然而，在更具弹性的服务中，失败的请求可能会被重新发送。

重试模式是第三方交互的常见云设计模式，它鼓励应用程序预见失败。部署重试模式的流程创建了容错系统，需要最少长期维护。这些流程能够安全地重试失败的操作。

重试模式经常出现在webhook实现中。当一个服务尝试将webhook发送到另一个服务时，该请求可以做以下两件事之一：

1. 成功。如果成功，操作就完成。
2. 失败。如果失败，发送服务可以重新发送webhook的次数有限次，直到请求成功。为了避免目标系统过载，很多webhook实现使用指数回退，增加每个请求之间的时间延迟，以便在失败前提供故障目标恢复时间。这些延迟通常会在计时中引入一些随机性（称为抖动）以防止同步重试进一步压倒系统。

只有当发件人和收件人都知道失败的请求可以重新发送时，重试模式才有效。在webhook示例中，通常为每个webhook提供唯一标识符。然后，接收者可以验证请求永远不会被处理超过一次。这可避免重复，同时使发件人能够遭遇自己的错误，这些错误可能会错误地重新发送冗余数据。

3. 断路器

在基于云的应用程序中，处理规模可能是令人难以置信的微妙的问题，特别是对于性能不可预测的进程。断路器模式通过在进程消耗超过必要的资源之前将其降低，来防止进程“逃跑”。

想象一下，有个网页，从几个不同的数据源生成报告。在典型情况下，此操作可能只需要几秒钟。然而，在极少数情况下，查询后端可能需要更长的时间，这消耗了宝贵的资源。断路器可以阻止任何需要超过10秒才能生成的报告的执行，这可以防止长期运行的查询霸占应用程序资源。

更现代的部署可以更进一步，通过结合故障阈值与动态恢复时间，从而在具有不可预测的资源限制（例如无服务器环境）的系统中实现更大的弹性。

4. 基于队列的负载均衡

QBLL是一种通用的云设计模式，它使用队列来执行请求。这些操作不会在请求时执行几个复杂的操作（这会增加延迟性，对用户使用的功能），而是进入队列。这种队列在给定时间段内执行更少的请求。在很多操作不需要显示即时结果的系统中，这种设计模式很有价值，例如发送电子邮件或计算总值。

考虑一个API端点，每当执行大型数据集时，它都必须对数据集进行追溯性更改。虽然这个端点是考虑到一定的流量阈值而构建的，但大量请求或用户快速增长可能会对应用程序的延迟产生负面影响。通过将此功能转移到QBLL系统，应用程序基础设施可以一次处理固定数量的操作，从而更容易地承受增加的吞吐量。

5. 节流

QBLL的替代设计模式是节流模式，它与噪声邻居问题相关。QBLL模式将多余的工作负载转移到队列中，以便更易管理的处理，而节流模式设置并强制限制单个客户端使用服务或端点的频率，以防止嘈杂的邻居对每个人的系统产生负面影响。节流模式也可以补充QBLL模式。这可以对多余的工作负载进行管理处理，并确保队列深度不会太满。

回顾QBLL示例，想象一下，在繁重的工作被转移到队列之前，API端点最初可以每分钟处理约100个请求。API可以支持每分钟约10,000个请求的最大吞吐量。这与100相比是大幅跃升，但队列每分钟只能支持100个请求，才不会对最终用户产生任何明显的影响。这意味着1000个API请求可能需要10分钟才能处理，10000个API请求可能需要两个小时。

在一个请求分布均匀的系统中，每个用户都会经历同样缓慢的处理。但是，如果一个用户发送所有10,000个请求，所有其他用户在工作量开始前都会遇到两个小时的延迟。限制所有用户每秒1000个请求的节流架构可确保，没有单个用户能够霸占应用程序资源，而牺牲任何其他用户。

弹性应用程序的最佳实践

构建弹性应用程序不仅仅是关于设计模式。这也是关于开发人员如何思考应用程序开发，以及他们对风险管理、架构和应用程序设计的方法。以下是一些最佳实践，可以帮助采用上述模式并将其成功应用于业务系统。

为失败做好计划

说到技术，失败从来不是“如果”的问题，而是“何时”的问题。

设计弹性应用程序的一个关键组成部分是假设每个组件最终都会失败。我们可以基于此观点制定行动计划，以确定应用程序可能出问题的地方，或以其他方式容易受到规模问题影响。

不要止步于为失败做好计划。通过一种叫做混沌工程的技术，制造故障。混沌工程是故意将故障、错误和其他故障引入运行系统的过程，以更好地了解该系统的情况。混沌工程由Netflix推广，这是常见的做法，它可测试系统的弹性，并帮助用户更好地了解他们应该如何改进系统。

分离和隔离服务

有一个常见的软件开发模式，叫做关注点分离。这种模式涉及将代码库整理成不同的组件，每个组件都有一个重点专业领域。这种松散耦合使开发人员能够构建更可扩展和更可维护的系统。由于每个组件都有不同的关注点，因此一个组件的故障导致整个应用程序失败的可能性会降低。

虽然隔板模式在基础设施层面上实现这一点，但在扩展时考虑其他更先进的技术很重要。事件驱动架构、数据库分片和工作负载分区可以包含故障，并提高系统的整体稳定性。

自动恢复

恢复是指将失败的系统恢复到正常状态。然而，恢复可能很耗时，会消耗资源和精力。构建弹性应用程序需要不断改进的文化，优先考虑故障的解决，并为未来自动恢复。

在任何系统中，每个已知的故障状态都有相应的恢复方法。这可能需要扩展资源、终止失控的进程或重定向流量。当开发人员确定了他们的故障状态和解决程序，他们就可以开始通过智能健康检查和其他监控技术来识别导致这些故障状态的原因。这使得开发人员能够构建一个全面的系统，该系统可以在故障发生之前从故障中恢复。

转移弹性

虽然其中一些设计模式看起来很复杂，但它们不需要全部从零开始构建。有时，值得将一些弹性转移给具有更多经验和专业知识的第三方，例如API网关、负载平衡器或应用程序缓存。很多云提供商服务和功能可以减少开销和复杂性，同时提高应用程序的稳定性和弹性。

这里部署的常见模式是大使模式。这涉及使用大使（例如API网关）作为应用程序代码或客户端与应用程序依赖的服务之间的代理。在这种模式中，大使处理断路和重试逻辑，使开发人员能够将精力集中在业务逻辑上。

是牲畜而非宠物

在DevOps中，“cattle，not pets”（在云计算领域，这句话用来区分两种不同的服务器管理理念。cattle 意味着将服务器当作无差别、可替换的量产品。pets 意味着将每台服务器当作独一无二、不可替代的个体）意味着，在构建基础设施时，每个服务和组件都是可互换的，而不是被视为独一无二。换一种说法，当基础设施处于糟糕的状态时，不需要担心；只需构建新的资源。

这被称为不可变的基础设施，它强调替换应用程序实例和其他服务，而不是修补它们。虽然以这种方式管理基础设施可以确保一切永远不会过时，但它具有额外的好处，即启用更先进的部署技术，例如蓝绿版本和金丝雀版本。这些可以帮助避免停机，并使发布过程更加稳定。

构建现实世界的复原力

用外行的话来说，云是存在于世界某个地方的一堆计算机。如果数据中心所在位置遭遇自然灾害，任何混沌工程和QBLL做法都无法拯救应用程序。真正的弹性还考虑基础设施的物理位置，并相应地进行规划。

在企业的主要数据中心停用的情况下，跨多个地区或可用性区域进行部署可以帮助安全地故障转移。想要覆盖其基地的开发人员应该采用多云战略，不仅要承受区域数据中心的损失，还要承受整个云提供商的损失。

6个月规则

扩展基于云的应用程序可能非常困难。通常，IT团队必须做出选择，是选择能够支持应用程序再增长六个月的设计模式，还是能够再支持应用程序增长六年的设计模式。

根据我的经验，六个月时间表的选项是最具成本效益的。花几周时间购买六个月，以支持业务和用户的需求。这比花一年时间建立一个更难改变的更广泛的系统更有效。

仔细实施通用设计模式可以支持应用程序的长期维护，同时也有足够的灵活性来适应环境的变化。