许多现代应用程序需要跨整个企业构建，有时甚至需要跨Internet构建。每个应用程序必须满足可伸缩性，可用性，安全性，可靠性和弹性的要求。
在本文中，我将介绍一些设计模式，这些模式可以轻松地帮助您实现上述功能。我将介绍每种模式，如何在云中使用该模式，何时使用以及何时不使用。
这些模式中的某些并不是那么新，但在当今的Internet云世界中非常有用。
这是我将在本文中讨论的模式的列表：
- 断路器
- 命令和查询责任隔离（CQRS）
- 活动采购
- 边车
- 后端换前端
- 扼杀者
因此，让我们开始吧。
1.断路器
分布式系统的设计必须考虑到故障。目前，微服务已在世界范围内采用，这些服务主要依赖于其他远程服务。这些远程服务可能由于各种原因（例如网络，下载应用程序等）而无法及时响应。在大多数情况下，重试的实施应该能够解决问题。
但是有时可能会出现严重的问题，例如服务降级或服务本身完全失败。在这种情况下继续尝试是没有意义的。在这种情况下，断路器模型可能会有用。
上图显示了断路器方案的实现，其中，当服务1意识到呼叫服务2连续失败/超时时，服务1禁用对服务2的调用，并在失败的情况下返回响应，而不是重试。
有流行的开源库，例如Netflix Hystrix
或Reselience4J，可以很容易地实现此模式。
如果您是使用API网关或代理
类似特使，这可以在代理级别本身来实现。
注意：当链条打开时，必须实施足够的日志和警告以跟踪这段时间内收到的请求，并且操作团队也应意识到这一点，这一点非常重要。
您还可以实施半断路器，以继续为服务受损的客户提供服务。
何时使用此模式
- 当服务依赖于另一个远程服务时，在某些情况下，它很可能会失败。
- 当服务具有非常强的依赖性时（例如主数据服务）。
何时不使用此模式
- 在处理本地依赖性时，断路器会产生开销。
2. Command and Query Responsibility Segregation (CQRS) ( (CQRS))
CQRS是用于现代数据仓库应用程序的非常有用的模型。它基于分离数据存储区中的读取（查询）和写入/更新（命令）操作的原理。
假设您正在构建一个需要将数据存储在MySQL / PostgreSQL等数据库中的应用程序。众所周知，将数据写入存储时，操作必须经历几个阶段-例如，验证，建模和持久性-因此，典型的写入/更新操作要比简单的读取操作花费更长的时间。
当您使用同一数据存储区同时并大规模执行读取和写入操作时，您可能会开始发现性能问题。
在这种情况下，CQRS模板可能会很有用。 CQRS模式建议对读写操作使用不同的数据模型。一些变体还建议为这些模型使用单独的数据存储。
注意：如今，大多数PaaS数据库都具有创建 数据存储的可读副本（Google Cloud SQL，Azure SQL DB，Amazon RDS
等）的能力，这使实现数据复制更加容易。
如果您要处理本地数据库，许多企业数据库也提供此功能。
注意：如今，有些人还选择将可读副本实现为像MongoDB和Elasticsearch这样的快速和高性能的NoSQL数据库。
何时使用此模式
- 当您考虑扩展应用程序时，需要大量的读写操作
- 当您要分别设置读写操作时。
- 当您的读取操作接近真实或最终一致时。
何时不使用此模式
- 当您构建一个常规的CRUD应用程序时，它不会一expect而就。
3.活动来源
事件源是一种有趣的设计模式，其中将一系列域事件存储为日志，并且聚合日志视图给出了应用程序的当前状态。
此模式通常用于无法负担数据存储锁且需要维护审核和事件历史记录的系统，例如，旅馆/会议/座位等应用程序。
给定一个酒店房间预订系统，希望用户预订或取消预订。在这里，您需要将预订和取消存储为一系列事件。通过查看事件日志，可在每次预订之前以摘要形式显示可用的房间。
注意：大多数云服务提供商都支持消息传递服务，例如Google Pub / Sub，Azure服务总线，AWS SQS等。这些服务与强大的一致数据存储相结合，可用于实施此方案。
何时使用此模式
- 当正常的CRUD操作不能满足要求时
- 通常适用于座位预定系统，例如公共汽车，火车，会议，电影院等。-或用于电子商务系统，其中包括购物车交易，付款等活动。
- 需要强大的审核和事件重播以创建应用程序的当前和过去状态时。
何时不使用此模式
- 正常的CRUD操作足以满足用户需求时。
4. Sidecar（Sidecar设计模式）
随着微服务的出现，Sidecar模式开始流行。在此方案中，应用程序组件被部署到单独的进程或容器中。这有助于实现抽象和封装。
Envoy代理是最流行的Sidecar代理服务器之一，被广泛使用。它通过使用边机隔离公用功能（例如网络，可观察性和安全性）来帮助您分离应用程序的主要功能。
这种类型的边车可以帮助抽象的L4 / L7类型的通信。像Envoy Proxies这样的Sidecar甚至通过实现双向TLS来帮助实现更高的安全性。
您可以将其与服务网格结合使用，以实现不同微服务之间更好的连接性和安全性。您可以在上一篇文章中了解更多有关此的内容。
何时使用此模式
- 当您在产品组合中处理众多且异构的微服务时。
- 在处理传统应用程序时，这些应用程序往往无法应对新时代的互操作性和安全性挑战。
何时不使用此模式
- 当您处理数量有限的需要相互通信的服务时。
- 侧轮椅展开可能不经济或操作不便的小型应用
5.前端后端（BFF）
在典型的产品开发周期中，后端工程师负责创建与数据仓库交互的服务，而前端工程师则负责创建用户界面。这些天的应用程序必须同时考虑移动设备和桌面设备。
尽管移动设备和台式设备之间的硬件差距越来越小，但连接和使用仍然是移动设备面临的挑战。
在这种情况下，BFF模板变得非常方便。在这里，您应该为特定的前端构建/配置内部服务。
为了优化移动客户端的性能，您可能需要构建单独的后端服务，以轻量级和基于页面的响应进行响应。
您可能还希望使用此模式来聚合各种服务，以减少后端和前端之间的数据通信。
注意：如今，如果您正在使用API网关，则可以在网关本身中轻松实现BFF模式，并且不需要提供单独的服务。
何时使用此模式
- 当您想为各种客户端（例如台式机和移动客户端）提供产品/服务时。
- 当您要针对特定类型的客户优化响应时。
- 当您想减少移动客户端和其他服务之间的聊天时。
- , .
- , .
6. Strangler ( )
如果您要为正在使应用程序现代化的组织工作，则必须使用Strangler设计模式。Strangler模式提倡在您的旧有和新应用程序之上构建外观覆盖，使消费者能够客观地查看事物。
这种模式将客户端与应用程序新旧部分之间的迁移活动分开。
注意：在典型的IT组织中，如果要从一个ERP系统迁移到另一个ERP系统，这种类型的架构将非常有用。如果您使用网关API，则在代理网关本身中更容易实现。
您需要确定是否要在迁移结束时保留加载项（外观）或将其删除。
何时使用此模式
- 迁移或升级高度依赖的复杂应用程序时，例如ERP迁移
何时不使用此模式
- 如果迁移容易且直接替换是最佳选择。