作者 | 坦梅·德什潘德
译者| 平川
策划|蔡芳芳
许多现代应用程序需要在企业规模上构建，有时甚至在互联网规模上构建。 每个应用程序都需要满足可扩展性、可用性、安全性、可靠性和弹性要求。 在本文中软件设计模式有哪些，我将讨论一些可以帮助您轻松实现上述功能的设计模式。 我将讨论每种模式、如何在云原生环境中使用它，以及何时使用它和何时不使用它。 其中一些模式并不新鲜，但在当前互联网规模的云计算世界中很有用。
本文原创发表于BetterProgramming，经原作者授权由InfoQ英文站翻译分享。
图片来自：
以下是本文将讨论的模式：
开始吧。
断路器
分布式系统的设计应考虑到故障。 如今，世界早已接受微服务，而微服务主要依赖于其他远程服务。 由于网络、应用负载等各种原因，该远程服务可能难以及时响应。 在大多数情况下，实施重试应该可以解决问题。
但有时，可能会出现重大问题，例如服务降级或服务本身完全故障。 在这些情况下，继续重试是没有意义的。 这就是断路器模式的用武之地。
断路器，图片由作者提供。
上图显示了断路器模式的实现，其中当服务 1 识别出调用服务 2 时出现连续失败/超时时，服务 1 将手动中断对服务 2 的调用并返回回退响应，而不是重试。
有一些流行的开源库，例如 Netflix 的 Hystrix，可以用来非常轻松地实现这些模式。
如果您使用 API 段或像 Envoy 这样的 sidecar 代理，那么这可以在代理层本身完成。
注意：在发生停机时实施足够的日志记录和警报非常重要，以便可以跟踪在此期间收到的请求并了解运营团队。
您还可以实施半开断路器，并继续为客户提供降级服务。
何时使用这些模式
何时不使用这些模式
命令和查询职责分离 (CQRS)
对于涉及数据存储的现代应用程序来说，CQRS 是一种非常有用的模式。 其基本原理是将数据存储中的读（查询）和写/更新（命令）操作分开。
假设您正在创建一个应用程序，需要将数据存储在数据库（例如 MySQL/PostgreSQL）中。 众所周知，将数据写入数据存储时，操作需要几个步骤，例如验证、建模和持久化，因此典型的写入/更新操作比简单的读取操作需要更长的时间。
当您使用单个数据存储同时执行大规模读写操作时，您可能会开始遇到性能问题。
在这些情况下，CQRS 模式可能很有用。 CQRS 模式建议使用不同的数据模型进行读取和写入操作。 此模式的一些变体还建议为此类模型使用单独的数据存储。
CQRS，图片由作者提供
注意：目前大多数PaaS数据库都提供了创建数据存储只读副本的能力（Google CloudSQL、AzureSQLDB、AmazonRDS等），这使得数据复制更容易实现。
如果你使用的是本地数据库，那么很多企业数据库也提供这些功能。
注意：现在有些人还喜欢将只读副本实现为快速且高性能的 NoSQL 数据库，例如 MongoDB 和 Elasticsearch。
何时使用这些模式
何时不使用这些模式
干扰源
Storm Feed 是一种有趣的设计模式，它将一系列域风暴存储为日志，日志的聚合视图提供了应用程序的当前状态。
这些模式通常用于不提供数据存储锁且需要维护事件审核和历史记录的系统 - 例如餐厅/会议/座位预订应用程序。
风暴来源，图片由作者提供。
考虑一个酒店卧室预订系统，用户可以在其中预订或取消预订。 在这里，您需要将预订和取消存储为一系列事件。 每次预订之前，聚合视图都会通过查看风暴日志来显示可用的卧室。
注意：大多数云服务提供商都支持 Microsoft Pub/Sub、Azure Service Bus、AWSSQS 等消息传递服务。 该服务与高度一致的数据存储相结合，实现了这种模式。
何时使用这些模式
何时不使用这些模式
边车
随着微服务的流行，sidecar 模式开始流行。 在此模式中，应用程序的组件被部署到单独的进程或容器中。 这有助于表示和封装。
EnvoyProxy 是最常用的 sidecar 代理之一，有着广泛的应用。 它有助于保持应用程序的核心功能分离，使用 sidecar 来分离网络、可观察性和安全性等常见功能。
Sidecar，图片由作者提供。
这些 sidecar 可以帮助体现 L4/L7 通信。 像 EnvoyProxies 这样的 Sidecar 甚至可以通过实施 MutualTLS 来帮助提高安全性。
您可以将其与服务网格结合起来，以实现各种微服务之间更好的通信和安全性。 要了解更多信息软件设计模式有哪些，您可以阅读我之前的文章。
何时使用这些模式
何时不使用这些模式
BFF（后端换前端）
在传统的产品开发周期中，前端工程师创建与数据存储交互的服务，后端工程师构建用户界面。 如今，在构建应用程序时需要同时考虑联通和桌面的使用情况。
虽然联通设备与桌面设备在硬件方面的差异越来越小，但对于联通设备来说，连接和使用一直是其面临的挑战。
在这些情况下，BFF模式就非常方便。 在这些模式下，您需要为特定后端创建/自定义前端服务。
后端换前端，图片由作者提供。
为了优化联通客户端的性能，您可能需要创建一个单独的前端服务，以轻量级寻呼响应进行响应。
您可能还想使用此模式来聚合各种服务以减少流量。
注意：如果你现在使用的是API网段，那么在网段内就可以轻松实现BFF模式，不需要单独维护服务。
何时使用这些模式
何时不使用这些模式
扼杀者
如果您的组织正在走向应用程序现代化，那么 Strangler 设计模式是必须的。 Strangler 设计模式主张在遗留应用程序和新应用程序之上创建一个外观，为用户提供具体的视图。
绞杀者，图片由作者提供。
此模式向用户提供迁移活动。
注意：如果传统 IT 组织从一种 ERP 迁移到另一种 ERP，这些模式尤其有用。 如果您使用 API 分段，则在分段代理中实现它会更容易。
您需要决定在迁移结束时是保留 Facade 还是删除它。
何时使用这些模式
何时不使用这些模式
英文原文链接：
软件专业人员的现代架构设计模式
2020年即将结束，InfoQ来给大家福利啦~
参与形式：
关注InfoQ公众号并回复“2020”即可获得个人专属海报。 邀请好友推广参与活动，就有机会赢取苹果AirPodsPro、Redmi小爱触屏音响8、小度智能耳机等众多精美礼品，并在后台快速回复“2020”即可领取独家海报
