与面向对象设计模式一样，微服务模式也是一种经过验证的解决方案，用于解决开发、部署和扩展微服务时遇到的常见问题。

举例来说，SAGA模式解决了分布式事务失败的问题，而API网关则简化了客户端代码，并充当许多微服务的前端控制器和负载均衡器，提高了微服务的可维护性。

本文介绍一些常见的微服务设计模式，每个从事微服务开发或将单体应用程序拆分为微服务以分离代码、数据和接口的开发人员都应该了解和学习。

1 服务注册模式

服务注册模式提供了一个中央存储库，用于按名称发现微服务。它是一种微服务架构模式，使服务能够发现其他微服务并相互通信。

在这种模式中，使用一个中央服务注册表或目录来记录可用服务及其位置。微服务可以向注册表注册自己，其他微服务可以查找注册表以找到所需服务的位置。

举个例子，假设有一个大型电子商务网站，包含许多微服务，如订单服务、支付服务、物流服务和客户服务。每个服务都有自己的REST API，其他服务可以使用它来进行通信。

为了让这些服务更容易相互发现，可以使用服务注册模式。我们可以设置一个服务注册表，例如Consul或Eureka（Spring Cloud提供此功能），它维护着所有可用服务及其终点的列表。

当一个服务启动时，它可以通过提供自己的名称和终点来向注册表注册自己。

例如，订单服务可以将自己注册为“order-service”，终点为“http://order-service:8080”。其他需要与订单服务通信的服务可以通过在注册表中查找其名称来获取其终点。

例如，支付服务可以在注册表中查找“order-service”的终点，以向订单服务发送支付信息。同样，物流服务可以在注册表中查找“order-service”的终点，以获取订单的物流信息。

这样，每个服务可以独立开发和部署，而不需要在其代码中硬编码其他服务的终点。服务注册模式使得服务能够动态地相互定位，使系统更具灵活性和适应变化的能力。

图片

2 断路器模式

顾名思义，断路器模式通过断开电路来防止级联故障，并使应用程序在一个或多个服务失败时继续运行。用于处理微服务架构中可能发生的故障。

在这种模式中，断路器充当客户端和服务之间的安全网，保护客户端免受服务故障的影响。断路器监视服务的状态，如果检测到服务失败，它可以打开断路器，并阻止进一步的请求发送到服务，直到服务恢复正常。

举个例子，假设一个微服务应用程序正在使用一个不可靠的外部服务，而且即使外部服务失败，应用程序也需要继续运行。

在这种情况下，可以使用断路器模式来检测外部服务是否不可用，并切换到备用服务或降级服务，直到外部服务再次可用。

图片

在微服务架构中，可以使用Netflix的Hystrix或Spring Cloud Circuit Breaker等工具来实现断路器模式，这些工具提供了一种管理断路器行为的方式，允许应用程序以可控的方式对服务故障做出反应。

3 API网关模式

API网关模式是微服务架构中常用的设计模式之一，涉及到一个API网关，它充当所有传入API请求的入口点。它为所有微服务提供了一个统一的入口点，并充当客户端和微服务之间的代理，将请求路由到适当的服务。

API网关的主要目的是解耦客户端和微服务，将系统的复杂性抽象到一个简化和一致的API后面。这也意味着您不需要查找和记住100多个微服务REST API的地址。

它还提供了额外的安全性和治理层，允许组织控制和管理对其服务的访问，监控系统的性能，并在所有服务中强制执行策略。

以下是一个简单电子商务系统中API网关模式的工作示例：

假设一个电子商务系统有多个微服务来处理不同的功能，如订单管理、产品目录和用户身份验证。每个微服务都有自己的处理请求的API终点。然而，客户端（可以是Web或移动应用程序）需要通过一个入口点访问所有这些微服务。

这就是API网关发挥作用的地方。API网关充当反向代理，接收来自客户端的所有传入请求。然后，它根据请求的终点将每个请求路由到适当的微服务。

例如，API网关可能会将请求路由到/orders终点的订单管理微服务，将请求路由到/products终点的产品目录微服务。

图片

API网关还可以执行其他功能，如请求和响应转换、速率限制、身份验证和授权以及缓存。

它还可以提供统一的API，隐藏微服务的内部细节，并向客户端呈现更简单和一致的接口。

总的来说，API网关模式提供了一种在复杂系统中管理微服务的可扩展、灵活和安全的方式，使得开发、部署和维护基于微服务的应用程序更加容易。

图片

4 Saga模式

Saga模式提供了一种管理涉及多个微服务的事务的方式。它用于确保跨多个服务的一系列事务成功完成，如果失败，则回滚或撤销到目前为止所做的所有更改。

Saga模式由一系列本地事务组成，每个事务更新单个服务的状态，以及一组相应的补偿事务，用于在发生故障时撤销原始事务的影响。

以下是在基于微服务的电子商务应用程序中使用Saga模式的示例：

假设您有两个微服务，一个负责处理订单，另一个负责发货。

当下订单时，订单处理服务负责验证订单并确保货物有库存，而发货服务负责将订单打包并发送给客户。

如果订单处理服务确定订单有效且所有商品有库存，它会向发货服务发送消息以启动发货流程。此时，Saga模式就会发挥作用。

发货服务将创建一个新的事务来打包和发货订单，如果事务成功，它将标记订单为已发货。

另一方面，如果事务失败（例如与发货提供商的问题），发货服务将启动一个补偿事务来撤销原始事务的影响，例如取消发货并重新补充库存。

图片

同时，订单处理服务也使用Saga模式来管理自己的事务。如果发货服务报告订单已成功发货，订单处理服务将标记订单为已完成。

如果发货服务报告失败，订单处理服务将启动一个补偿事务来取消订单并退还支付的款项。

总体而言，Saga模式提供了一种管理跨多个微服务的复杂事务的方式，以确保一致性和可靠性。如果您只想学习一种模式，最好学习Saga模式，因为它在微服务应用程序中非常有帮助。

5 事件溯源模式

事件溯源是一种用于在应用程序中持久化和查询数据的微服务模式。它不存储对象的当前状态，而是持久化应用程序中发生的所有事件，从而可以在任意时间点重构对象的状态。

在这种模式中，应用程序中的每个状态变化都被捕获为一个事件，并存储为事件日志。通过回放这些事件，可以重新构建应用程序的状态。这意味着事件溯源提供了应用程序中所有变更的审计日志。

例如，考虑一个电子商务应用程序。当用户下订单时，会生成并存储一个OrderPlaced事件到日志中。当订单发货时，会生成并存储一个ShipmentMade事件到日志中。

如果订单被取消，则会生成并存储一个OrderCanceled事件到日志中。通过回放这些事件，可以确定订单的当前状态。

事件溯源有几个优点：

• 审计性：可以审计和追溯系统的所有更改，找到其来源。
• 可扩展性：可以并行处理事件，提供更好的可扩展性。
• 灵活性：因为事件是真实的数据源，可以在不改变数据本身的情况下更改数据的查询和持久化方式。
• 容错性：因为事件是不可变的，它们无法被修改，确保数据始终正确。

然而，实现事件溯源可能会很复杂，并且需要仔细的规划。此外，查询数据可能会较慢，因为涉及回放所有事件，所以在使用之前要确保真正需要。

6 命令查询责任分离 (CQRS) 模式

命令查询责任分离 (CQRS) 模式是另一种流行的微服务设计模式，将命令（写操作）和查询（读操作）分别分离到不同的模型中，每个模型都有自己的数据库。

该模式基于这样一个思想：用于写入数据的模型与用于读取数据的模型不同。

在这种模式中，命令模型接收来自客户端的命令并写入数据库。查询模型从数据库中读取数据并将数据发送给客户端。该模式可以用于提高系统的性能和可扩展性，因为每个模型可以针对其特定任务进行优化。

例如，考虑一个使用传统的CRUD（创建、读取、更新、删除）方法来管理产品信息的电子商务应用程序。同一模型和数据库被用于处理产品信息的读取和写入。随着应用程序的增长，模型变得越来越复杂，数据库成为性能瓶颈。

使用CQRS，应用程序将具有一个专门用于写入产品信息的命令模型，以及一个专门用于读取产品信息的查询模型。命令模型针对快速写入进行优化，而查询模型针对快速读取进行优化。

命令模型将数据存储在一个针对写入进行优化的数据库中，而查询模型将数据存储在一个针对读取进行优化的数据库中。这两个模型通过事件总线或消息队列进行通信。

总体而言，CQRS可以提高系统的可扩展性和性能，并通过分离关注点简化代码库。然而，它也可能增加复杂性，并需要更多的开发工作，因为需要使用独立的模型和数据库。

7 隔离模式

隔离设计模式是一种将系统的不同部分隔离开来的方式，以防止一个部分的故障影响到系统的其他部分。在微服务架构中，隔离模式可以用于隔离不同的微服务，以防止一个微服务的故障导致整个系统崩溃。

这个模式与断路器模式有些相似，都是为了防止级联故障，但是隔离模式更侧重于隔离和自给自足的微服务，如下图所示，Service A拥有自己的连接池，与Service B和Service C不共享。

8 面向前端的后端 (BFF) 模式

面向前端的后端 (BFF) 是一种在微服务架构中使用的设计模式，用于处理多个用户界面下的客户端-服务器通信的复杂性。它建议为每个前端界面创建一个单独的后端服务，以处理该界面的特定需求。

这样可以让开发人员针对前端的特定需求优化数据流、缓存和身份验证机制，同时保持后端服务的模块化和解耦。

例如，假设您有一个需要访问相同一组服务的Web应用程序和移动应用程序。在这种情况下，您可以为每个应用程序创建单独的后端服务，每个服务针对特定平台进行优化。

Web应用程序后端可以处理大量数据以实现更快的加载，而移动应用程序后端可以针对较低的延迟和网络使用优化。

这种模式使团队能够通过为每个界面使用单独的后端服务来优化用户体验。它还允许避免一个需要为多个不同需求的界面提供服务的单个后端服务，这可能变得越来越复杂和难以维护。

总结

本文虽然篇幅较长，但我们学习了一些关键的微服务设计模式。现在用一句话来总结每个模式，以便读者能轻松记住并在适当的时候使用它们：

一句话总结流行的微服务设计模式：

• 服务注册模式（Service Registry）：为服务提供中心位置，使其能够注册自身。
• 断路器模式（Circuit Breaker）：允许服务快速失败并防止级联故障，该模式用于隔离出现故障的服务。
• API网关模式（API Gateway）：为系统中的所有请求和响应提供统一的入口点。因此，客户端只需记住一个主机/端口地址，而不是每个微服务的多个IP地址。
• Saga 模式：用于管理跨多个服务的长事务的模式。
• 事件溯源模式（Event Sourcing Pattern）：是一种将应用程序状态的变化表示为事件序列的设计模式。
• 命令查询责任分离模式（Command Query Responsibility Segregation，CQRS）：将应用程序的读取和写入请求分离开来，以实现更好的扩展性和性能。
• 隔离模式（Bulkhead Pattern）：在微服务内部隔离故障，以防止单个故障导致整个系统崩溃。
• 面向前端的后端模式（Backends for Frontends，BFF）：为每个客户端提供一个特定的后端。它允许前端团队快速开发功能并添加特定于客户端的功能。