面向软件专业人员的现代架构设计模式

许多现代应用程序需要在企业规模上构建，有时甚至需要在互联网规模上构建。每个应用程序都需要满足可扩展性、可用性、安全性、可靠性和恢复能力要求。

在本文中，我将讨论一些可以帮助您轻松实现上述功能的设计模式。我将讨论每种模式，如何在云本地环境中使用该模式，以及何时使用和何时不使用。

其中一些模式并不是很新，但在当前互联网规模的云世界中非常有用。

以下是我将在本文中讨论的模式列表：

分布式系统的设计应该考虑到故障。如今，世界已经采用了微服务，而这些服务大多依赖于其他远程服务。这些远程服务可能会由于网络、应用程序负载等各种原因而无法及时响应。在大多数情况下，实现重试应该可以解决这些问题。

但有时可能会出现服务降级或服务本身完全故障等重大问题。在这种情况下，不断重审是没有意义的。这就是断路器模式可以派上用场的地方。

上图显示了断路器模式的实施，在该模式中，当服务1了解到调用服务2时存在连续故障/超时时，服务1不会重试，而是会将呼叫跳转到服务2，并返回回退响应。

有一些流行的开源库，比如Netflix的hystrix，可以非常容易地用来实现这种模式。

如果您正在使用API网关或诸如特使之类的SideCar代理，那么这可以在代理级别本身实现。

注意：在电路打开时实施充分的日志记录和警报非常重要，以便跟踪在这段时间内收到的请求，并且运营团队意识到这一点。

您还可以在半电路打开的情况下实施断路器，以继续为服务降级的客户端提供服务。

当一个服务依赖于另一个远程服务，并且在某些情况下可能会失败。

当您处理本地依赖关系时-断路器可能会产生开销。

对于涉及使用数据存储的现代应用程序来说，CQRS是一个非常有用的模式。它基于分离数据存储中的读(查询)和写/更新(命令)操作的原则。

假设您正在构建一个需要将数据存储在MySQL/PostgreSQL等数据库中的应用程序。众所周知，当将数据写入数据存储区时，一个操作需要几个步骤-如验证、建模和持久性-因此典型的写/更新操作比简单的读操作花费更长的时间。

当您使用单个数据存储同时大规模执行读写操作时，您可能会开始看到性能问题。

在这种情况下，CQRS模式可能很有用。CQRS模式建议对读写操作使用单独的数据存储。

注意：如今大多数PaaS数据库都提供创建读副本的功能(Google Cloud SQL、Azure SQL DB、Amazon RDS等)。在帮助实现CQRS的数据存储中，CQRS的实现要容易得多。

如果您处理的是本地数据库，许多企业数据库也提供此功能。

注意：现在有些人也更喜欢将读副本实现为快速、高性能的NoSQL数据库，如MongoDB和Elasticsearch。

当您考虑扩展需要大量读写的应用程序时。

当您正在构建一个常规的CRUD应用程序，并且该应用程序不需要一次进行大量的读写操作时。

Event Sourcing是一种有趣的设计模式，其中域事件序列存储为日志，日志的聚合视图提供应用程序的当前状态。

此模式通常用于负担不起数据存储锁的系统，以及需要维护事件的审核和历史记录的系统-例如，酒店/会议/座位预订等应用程序。

考虑其中期望用户预订或取消预订的酒店房间预订系统。在这里，您需要将预订和取消存储为一系列事件。在每次预订之前，汇总视图通过查看活动日志显示可用房间。

注意：大多数云服务提供商都支持消息传递服务，如Google Pub/Sub、Azure Service Bus、AWS SQS等。这些服务与强大的一致性数据存储相结合，可用于实现此模式。

通常适用于座位预订系统-如公交车、火车、会议、电影厅等-或由购物车操作、支付等活动组成的电子商务系统。

当需要强大的审核和事件重放来创建应用程序的当前和过去状态时。

随着微服务的兴起，Sidecar模式变得流行起来。在此模式中，您将应用程序的组件部署到单独的流程或容器中。这有助于实现抽象和封装。

特使代理是目前应用最广泛、应用最广泛的侧车代理之一。它帮助您保持应用程序的核心功能独立，使用SideCar隔离网络、可观察性和安全性等常见功能。

这种类型侧车可以帮助抽象L4/L7类型的通信。像特使代理这样的旁观者甚至通过实施共同TLS来帮助实现更高的安全性。

您可以将其与服务网格结合使用，以实现各种微服务之间更好的通信和安全性。您可以在我的上一篇文章中阅读更多关于它的内容。

当您在处理通常无法应对新时代通信和安全挑战的旧式应用程序时。

当您处理需要相互通信的有限数量的服务时。

在典型的产品开发周期中，后端工程师负责创建与数据存储交互的服务，前端工程师负责构建用户界面。如今，在构建应用程序时，需要同时考虑移动和桌面使用情况。

尽管移动设备和台式设备在硬件方面的差距越来越近，但移动设备的连接和使用仍然面临挑战。

在这种情况下，BFF模式变得相当方便。在这里，您需要为特定的前端构建/定制后端服务。

要优化移动客户端的性能，您可能需要构建单独的后端服务，该服务使用轻量级和分页响应进行响应。

您可能还希望将此模式用于各种服务的聚合，以减少闲聊的通信。

注意：现在，如果您使用的是API网关，那么BFF模式可以很容易地在网关本身中实现，并且您不需要维护单独的服务。

当您想要为不同的客户端(如台式机和移动客户端)交付产品/服务时。

当期望移动和桌面应用程序显示相似的信息并提供相似的功能时。

如果您在一个正在迈向应用程序现代化之旅的组织中工作，那么扼杀设计模式是必须的。扼杀设计模式主张在您的遗留应用程序和新应用程序之上创建外观，为消费者提供抽象的视图。

注意：在典型的IT组织中，如果您要从一个ERP迁移到另一个ERP，则此类型的模式非常有用。如果您使用的是API网关，那么在网关代理本身中实现这一点就会变得更加容易。

您需要决定是要在迁移结束时保留还是删除外观。

当您迁移或现代化复杂的、高度依赖的应用程序(如ERP迁移)时