高弹性架构的微服务设计模式

长期以来，开发人员一直使用单片架构，而且长期以来，这种架构一直有效。不幸的是，这些架构使用的部件较少，但体积较大，这意味着如果一个部件发生故障，它们更有可能整体失效。通常，这些应用程序以单一进程运行，这只会加剧问题。

微服务通过让每个微服务作为单独的进程运行来解决这些特定问题。如果一个齿轮坏了，并不一定意味着整个机器停止运行。此外，诊断和修复较小、高度内聚的服务中的缺陷通常比较大的单片服务更容易。

微服务设计模式提供了经过验证的基本构建块，可帮助编写微服务代码。通过在开发过程中利用模式，您可以节省时间并确保更高的准确性，而不是从头开始为微服务应用编写代码。在本文中，我们将全面概述您需要了解的微服务设计模式以及何时应用它们。

使用微服务设计模式的主要好处

微服务设计模式提供了几个主要优点，包括：

可扩展性：微服务允许将应用程序分解为更小的独立服务，每个服务负责特定的功能或特性。这种模块化架构使各个服务能够根据需求独立扩展，从而提高整体系统的可扩展性和资源利用率。
灵活性和敏捷性：微服务通过分离应用程序的不同部分来提高灵活性和敏捷性。每项服务都可以独立开发、部署和更新，使团队能够自主工作并更频繁地发布新功能。这种灵活性可以加快上市时间并更轻松地适应不断变化的业务需求。
弹性和故障隔离：微服务通过将故障隔离到特定服务来提高系统弹性和故障隔离。如果一项服务遇到问题或故障，它不一定会影响整个应用程序。这种隔离可最大限度地减少停机时间并提高系统可靠性，确保应用程序保持可用和响应。
技术多样性：微服务允许使用最适合其特定需求的技术堆栈来构建每项服务，从而实现技术多样性。这种灵活性使团队能够为每项服务选择正确的工具和技术，从而优化性能、开发速度和维护。
改进的开发和部署流程：微服务通过将复杂的应用程序分解为更小、更易于管理的组件来简化开发和部署流程。这种模块化架构简化了测试、调试和维护任务，使开发团队更容易协作和迭代软件更新。
可扩展性和成本效益：微服务使组织能够通过仅将资源分配给需要它们的服务来更有效地扩展其应用程序。这种精细的资源分配方法有助于优化成本并确保有效利用资源，尤其是在根据使用情况对资源进行计费的云环境中。
增强容错能力：微服务架构具有更好的容错能力，因为服务可以设计为优雅地降级或独立失败，而不会影响整个系统。这确保了即使在发生故障或中断的情况下，关键功能仍然可用。
更易于维护和更新：微服务简化了维护和更新，允许对单个服务进行更改而不会影响整个应用程序。这降低了意外副作用的风险，并使必要时更容易回滚更改，从而提高了整体系统的稳定性和可靠性。

让我们继续寻找不同的微服务设计模式。

每个服务对应一个数据库模式

数据库是微服务架构中最重要的组件之一，但开发人员在构建服务时忽略每个服务模式的数据库并不罕见。数据库组织会影响应用程序的效率和复杂性。开发人员在确定应用程序的组织架构时可以使用的最常见选项是：

每个服务都有专用数据库

专用于一个服务的数据库不能被其他服务访问。这是从整个端到端业务角度来看更容易扩展和理解的原因之一。

想象一下您的数据库具有不同需求或访问要求的场景。一项服务拥有的数据可能主要是关系型数据，而第二项服务可能更适合使用 NoSQL 解决方案，第三项服务可能需要矢量数据库。在这种情况下，为每个数据库使用专用服务可以帮助您更轻松地管理它们。

这种结构还可以减少耦合，因为一个服务无法将自己绑定到另一个服务的表。服务被迫通过已发布的接口进行通信。缺点是专用数据库需要针对通信失败事件的故障保护机制。

所有服务共享一个数据库

单一共享数据库不是微服务架构的标准，但仍然值得一提。这里的问题是，使用单一共享数据库的微服务会失去开发人员所依赖的许多关键优势，包括可扩展性、稳健性和独立性。

不过，在某些情况下，共享物理数据库可能是合适的。但是，当所有服务共享一个数据库时，在其中强制执行逻辑边界非常重要。例如，每个服务都应该拥有自己的架构，并且应该限制读/写访问，以确保服务不能随意访问不属于它们的地方。

Saga 模式

Saga 是一系列本地事务。在微服务应用程序中，Saga 模式可以帮助在分布式事务期间保持数据一致性。

Saga 模式是其他设计模式的替代解决方案，通过提供回滚机会来允许多个事务。

一种常见的情况是电子商务应用程序允许客户使用信用购买产品。数据可能存储在两个不同的数据库中：一个用于订单，一个用于客户。购买金额不能超过信用额度。为了实现 Saga 模式，开发人员可以在两种常见方法之间进行选择。

1. 编舞

使用编排方法，服务将执行交易，然后发布事件。在某些情况下，其他服务将响应这些已发布的事件并根据其编码指令执行任务。根据预设，这些次要任务可能会也可能不会发布事件。在上面的示例中，您可以使用编排方法，以便每个本地电子商务交易都会发布一个事件，从而触发信用服务中的本地交易。

2. 编排

编排方法将使用对象来编排事件，从而执行事务并发布事件，触发其他服务通过完成其任务来做出响应。编排器会告诉参与者要执行哪些本地事务。

Saga 是一种复杂的设计模式，需要很高的技能才能成功实施。但是，正确实施的好处是可以保持多个服务之间的数据一致性，而无需紧密耦合。

API 网关模式

对于具有多个客户端的大型应用程序，实现 API 网关模式是一个引人注目的选择。最大的好处之一是它使客户端无需了解服务是如何分区的。但是，不同的团队会因为不同的原因而重视 API 网关模式。其中一个可能的原因是，它通过充当客户端应用程序和服务之间的反向代理，为微服务组授予单一入口点。另一个原因是客户端不需要知道服务是如何分区的，并且服务边界可以独立发展，因为客户端对它们一无所知。

客户端也不需要知道如何查找或与众多不断变化的服务进行通信。您还可以为特定类型的客户端创建网关（例如，为前端创建后端），这可以改善人体工程学并减少获取数据所需的往返次数。此外，API 网关模式可以处理身份验证、SSL 终止和缓存等关键任务，从而使您的应用更安全、更易于使用。

另一个优点是，该模式使客户端无需了解服务是如何分区的。在继续介绍下一个模式之前，还有一个好处需要介绍：安全性。该模式提高安全性的主要方法是减少攻击面。通过提供单一入口点，API 端点不会直接暴露给客户端，并且可以有效地实现授权和 SSL。

开发人员可以使用此设计模式将内部微服务与客户端应用分离，以便利用部分失败的请求。这确保整个请求不会因为单个微服务无响应而失败。为此，编码的 API 网关利用缓存提供空响应或返回有效的错误代码。

断路器设计模式

此模式通常应用于同步通信的服务之间。当服务表现出高延迟或完全无响应时，开发人员可能会决定使用断路器。这里的实用性是，当单个微服务无响应时，可以防止跨多个系统发生故障。因此，调用不会堆积并占用系统资源，这可能会导致应用程序内出现严重延迟，甚至一系列服务故障。

在断路器设计中将此模式作为函数实现需要调用一个对象来监控故障情况。当检测到故障情况时，断路器将跳闸。一旦跳闸，对断路器的所有调用都将导致错误并被定向到其他服务。或者，调用可能导致检索默认错误消息。

开发人员应该了解断路器模式函数的三种状态。这些是：

打开： 当故障次数超过阈值时，断路器模式将打开。处于此状态时，微服务会向调用发出错误，而不会执行所需的功能。
关闭： 断路器关闭时，它处于默认状态，所有调用都会得到正常响应。这是开发人员希望断路器微服务保持的理想状态 — 当然，在理想情况下是这样。
半开： 断路器在检查潜在问题时，会保持半开状态。有些呼叫可能会得到正常响应，但有些则可能不会。这取决于断路器最初切换到此状态的原因。

命令查询责任分离（CQRS）

如果开发人员想要解决数据争用风险等传统数据库问题，他们可能会使用命令查询责任分离 (CQRS) 设计模式。当应用程序性能和安全性复杂且对象同时暴露于读取和写入事务时，也可以使用 CQRS。

其工作方式是，CQRS 负责更改实体的状态或在事务中返回结果。可以提供多个视图用于查询，并且可以分别优化系统的读取端和写入端。这种转变可以通过分别查询模型和命令来降低所有应用程序的复杂性，因此：

模型的写入端处理持久性事件，并充当读取端的数据源
模型的读取端生成数据的投影，这是高度非规范化的视图

异步消息传递

如果服务不需要等待响应并且可以在发生故障后继续运行其代码，则可以使用异步消息传递。使用这种设计模式，微服务可以以快速且响应迅速的方式进行通信。有时这种模式被称为事件驱动通信。

为了实现速度最快、响应速度最快的应用，开发人员可以使用消息队列来最大限度地提高效率，同时最大限度地减少响应延迟。此模式可以帮助连接多个微服务，而无需创建依赖关系或紧密耦合它们。虽然异步通信存在一些权衡（例如最终一致性），但它仍然是一种灵活、可扩展的微服务架构设计方法。

事件溯源

当开发人员想要捕获实体状态的所有变化时，事件源设计模式可用于微服务。使用 Kafka 或其他替代方案等事件存储将有助于跟踪事件变化，甚至可以充当消息代理。消息代理有助于不同微服务之间的通信、监控消息并确保通信可靠稳定。为了实现此功能，事件源模式存储了一系列状态变化事件，并可以通过重播实体的发生来重建当前状态。

当事务对应用程序至关重要时，在微服务中使用事件源是一种可行的选择。当需要避免更改现有数据层代码库时，这种方法也很有效。