微服务设计模式 - 快速指南

微服务设计模式 - 概述

微服务是一种基于服务的应用程序开发方法。在这种方法中，大型应用程序将被划分为最小的独立服务单元。微服务是通过将整个应用程序划分为互连服务的集合来实现面向服务的架构（SOA）的过程，其中每个服务仅服务于一个业务需求。

走向微观的概念

在面向服务的架构中，整个软件包将被细分为小的、互连的业务单元。每个小型业务部门都将使用不同的协议相互通信，以便为客户提供成功的业务。现在的问题是，微服务架构（MSA）与 SOA 有何不同？简而言之，SOA是一种设计模式，微服务是一种实现SOA的实现方法论，或者说微服务是SOA的一种。

以下是我们在开发面向微服务的应用程序时需要牢记的一些规则。

独立- 每个微服务应该是独立部署的。
耦合- 所有微服务应彼此松散耦合，以便其中一个微服务的更改不会影响另一个微服务。
业务目标- 整个应用程序的每个服务单元应该是最小的，并且能够实现一个特定的业务目标。

为了应用这些原则，必须解决某些挑战和问题。微服务设计模式讨论了这些常见问题并提供了解决方案。在接下来的部分中，我们将使用适用的设计模式讨论问题和解决方案。

与微服务相关的设计模式分为五个主要类别。

分解设计模式- 应用程序将被分解为更小的微服务。分解设计模式提供了如何逻辑地进行设计的见解。
集成设计模式- 集成设计模式完整地处理应用程序Behave。例如，如何在一次调用中获取多个服务的结果等。
数据库设计模式- 数据库设计模式涉及如何为微服务定义数据库架构，例如每个服务应该有一个单独的数据库或使用共享数据库等。
可观察性设计模式- 可观察性设计模式考虑跟踪日志记录、性能指标等。
横切关注点设计模式- 横切关注点设计模式处理服务发现、外部配置、部署场景等。

按业务能力分解

问题陈述

微服务架构将应用程序构建为一组松散耦合的微服务，每个服务应以敏捷的方式独立开发，以实现持续交付/部署。当使用微服务架构构建大型复杂应用程序时，主要问题是如何设计松耦合的微服务或将大型应用程序分解为小的松耦合服务？

解决方案

我们可以定义一个对应特定业务能力的微服务。业务能力是指以产生价值为目标的业务活动。业务能力可以称为业务对象。例如 -

订单管理- 订单管理业务能力是指订单。
客户管理- 客户管理业务能力是指客户。

业务能力可以进一步划分为多级层次结构。例如，订单管理可以将交付、库存、服务等作为业务能力。

例子

考虑一个在线书店的例子。它可以具有以下业务能力和相应的微服务 -

图书目录管理
库存管理
订单管理
保修管理

优点

架构稳定- 由于业务能力稳定，所以架构高度稳定。
跨职能团队- 开发团队独立工作，跨职能，并围绕功能特性而不是技术特性进行组织。
松散耦合服务- 开发的服务将是松散耦合和内聚的。

缺点

需要对业务有很好的了解- 了解业务后需要确定业务能力。了解组织结构会有所帮助，因为组织是根据其能力构建的。
需要高级域模型- 需要业务域对象，因为它们对应于业务功能。

按子域分解

问题陈述

解决方案

我们可以定义与领域驱动设计（DDD）子域相对应的微服务。DDD是指业务作为一个域，一个域可以有多个子域。现在每个子域指的是不同的区域。例如 -

订单管理- 订单管理子域是指订单。
客户管理- 客户管理子域是指客户。

子域可以使用以下标准进一步分类 -

核心- 应用程序最重要和最关键的差异化因素。
支持- 与业务相关并用于支持业务活动。
通用- 不特定于业务，但用于增强业务运营。

例子

考虑一个在线书店的例子。它可以具有以下子域和相应的微服务 -

图书目录管理
库存管理
订单管理
保修管理

优点

稳定的架构- 由于业务子域是稳定的，因此该架构高度稳定。
跨职能团队- 开发团队独立工作，跨职能，并围绕功能特性而不是技术特性进行组织。
松散耦合服务- 开发的服务将是松散耦合和内聚的。

缺点

需要对业务有很好的了解- 在了解业务后需要识别业务子域。了解组织结构会有所帮助，因为组织是根据其能力构建的。
需要高级域模型- 需要业务域对象，因为它们对应于业务子域。

被绞杀者分解

问题陈述

解决方案

我们可以使用扼杀者模式定义微服务。扼杀者应用程序有两种类型的服务 -

现有Behave- 这些服务展示了以前驻留在 Monolith 中的Behave。
新功能- 这些服务实现了新的Behave。

因此，随着开发时间的推移，随着功能从单体应用程序转移到 Strangler 应用程序，微服务不断增加，而单体应用程序不断缩小。

例子

考虑一个在线书店的例子。最初我们只开发了图书目录管理服务，其他服务在遗留单体应用程序中得到支持。在开发过程中，越来越多的服务被开发出来，功能也逐渐远离单体。

因此，当开发新服务时，单体将被扼杀，旧组件将被停用，新的微服务将被部署并支持新功能。扼杀者模式可以通过三个步骤来实现 -

转型- 独立开发微服务以实现整体的特定功能。
共存- 整体架构和微服务都可以工作。用户可以访问这两个组件的功能。
消除- 一旦新开发的功能准备好投入生产，就从整体中删除该功能。

优点

测试驱动开发- 由于服务是分块开发的，我们可以使用 TDD 进行业务逻辑并确保代码质量。
独立团队- 团队可以在整体服务和微服务上以并行方式工作，从而形成强大的交付机制。

微服务设计模式 - API 网关

问题陈述

微服务架构将应用程序构建为一组松散耦合的微服务，每个服务都可以以敏捷的方式独立开发，以实现持续交付/部署。当使用微服务架构构建大型、复杂的应用程序时，微服务可以使用不同的协议。例如，一些微服务使用 REST，一些微服务遵循 AMQP。现在的问题是如何让客户端无缝地访问每个微服务，而无需担心协议和其他复杂问题。

解决方案

我们可以定义一个 API 网关，它将充当所有类型客户端的单一入口点。以下是 API 网关的其他好处 -

简单代理- API 网关可以充当某些请求的简单代理，将它们重定向到相关服务。
多个服务- API 网关可以将调用重定向到多个服务。
客户端特定的 API - API 网关也可以提供客户端特定的 API，例如桌面版本的 API 与移动应用程序不同的 API。
协议处理- API 网关在内部处理每个服务调用的通信协议，客户端只关心请求/响应。
安全性和身份验证- API网关可以实现安全性，即每个请求只有在身份验证和授权后才进入服务。

例子

考虑一个在线书店的例子。API网关允许在多个设备上无缝地使用在线图书商店API。

优点

客户端隔离- 客户端不知道微服务的位置或如何调用它们。
多个服务调用- API网关可以处理多个服务并将结果作为一个给出，因此可以减少往返并提高性能。
标准接口- API 网关为客户端提供标准接口以获取微服务的响应。

微服务设计模式 - 聚合器

问题陈述

微服务架构将应用程序构建为一组松散耦合的微服务，每个服务都可以以敏捷的方式独立开发，以实现持续交付/部署。当使用微服务架构构建一个大型、复杂的应用程序时，我们常常需要得到多个微服务的组合结果并展示在应用程序上。

解决方案

我们可以将聚合器定义为一个简单的 Web 模块，充当负载均衡器，这意味着它将根据需求调用不同的服务。下图描述了具有聚合器设计的简单微服务 Web 应用程序。如下图所示，“聚合器”负责一一调用不同的服务。如果我们需要对服务 A、B 和 C 的结果应用任何业务逻辑，那么我们可以在聚合器本身中实现业务逻辑。

聚合器可以再次作为另一种服务暴露给外部世界，其他人可以在需要时使用它。在开发聚合器模式 Web 服务时，我们需要记住，每个服务 A、B 和 C 都应该有自己的缓存层，并且本质上应该是全栈。

微服务设计模式 - 代理

问题陈述

微服务架构将应用程序构建为一组松散耦合的微服务，每个服务都可以以敏捷的方式独立开发，以实现持续交付/部署。当使用微服务架构构建大型、复杂的应用程序时，我们通常需要准备一个统一的接口，用于在每次服务调用之前完成身份验证和授权等常见工作。

解决方案

代理微服务模式是聚合器模型的变体。在这个模型中，我们将使用代理模块而不是聚合模块。代理服务可以单独调用不同的服务。

在代理模式中，我们可以通过提供转储代理层来构建一级额外的安全性。该层的作用类似于接口。

优点

代理模式提供了统一的接口，而不是每个微服务提供不同的接口。
代理模式允许在一个地方应用统一的关注点，例如日志记录、安全性等。

客户端 UI 组成

问题陈述

微服务架构将应用程序构建为一组松散耦合的微服务，每个服务都可以以敏捷的方式独立开发，以实现持续交付/部署。现在如何开发一个可以显示来自多个服务的数据的 UI 页面/屏幕。

解决方案

每个 UI 团队都可以开发一个客户端 UI 组件，例如实现或对应于特定微服务的 Angular 组件。对于多个服务，UI 团队负责通过构建由多个服务特定 UI 组件组成的页面来准备 UI 骨架或页面骨架。

优点

独立的 UI 团队- 一旦微服务合同可用，每个 UI 团队都可以工作，而不需要所有微服务可用性。
可管理的 UI 开发- 在组件中开发的 UI 变得易于管理且高效。
更容易开发- UI 开发变得更容易且可维护。

责任链

问题陈述

微服务架构将应用程序构建为一组松散耦合的微服务，每个服务都可以以敏捷的方式独立开发，以实现持续交付/部署。现在，如果一个服务需要另一个服务的输出作为依赖项，那么如何处理这种情况。

解决方案

我们可以使用责任链模式。顾名思义，这种构图模式将遵循链式结构。在这里，我们不会使用客户端和服务层之间的任何内容。相反，我们将允许客户端直接与服务进行通信，并且所有服务将以这样的方式链接起来，即一个服务的输出将成为下一个服务的输入。下图显示了典型的链式模式微服务。

坏处

这种架构的一个主要缺点是，客户端将被阻塞，直到整个过程完成。因此，强烈建议保持链条的长度尽可能短。

微服务设计模式 - 分支

问题陈述

微服务架构将应用程序构建为一组松散耦合的微服务，每个服务都可以以敏捷的方式独立开发，以实现持续交付/部署。现在考虑一种情况，其中一个服务需要另一个服务的输出作为依赖项，并且客户端可以调用任何服务。

解决方案

我们可以在这里使用分支微服务设计模式。分支微服务模式是聚合器模式和链式模式的扩展版本。在这种设计模式中，客户端可以直接与服务进行通信。此外，一项服务一次可以与多个服务进行通信。以下是分支微服务的图示。

优点

分支微服务模式允许开发人员动态配置服务调用。所有服务调用都将以并发方式发生，这意味着服务 A 可以同时调用服务 B 和 C。

每个服务的数据库

问题陈述

微服务架构将应用程序构建为一组松散耦合的微服务，每个服务都可以以敏捷的方式独立开发，以实现持续交付/部署。基于微服务的应用程序中的数据库结构/体系结构应该是什么。

解决方案

我们可以将每个微服务数据保留为该微服务的私有，并且这些数据只能通过相关的微服务访问。微服务将使用自己的数据库进行事务。下图显示了每个服务设计模式实现的数据库。

每个服务的数据库并不总是需要配置单独的数据库。考虑到关系数据库，我们可以使用以下方法来实现该模式。

每个服务的私有表- 每个微服务都可以使用一组表，并且这些表只能通过其相关的微服务访问。
每个服务的架构- 每个微服务可以定义单独的架构。
每个服务的数据库服务器- 可以每个微服务配置整个数据库服务器。

每个服务共享数据库

问题陈述

解决方案

我们可以使用在微服务之间共享的数据库。每项服务都可以免费使用其他服务可访问的数据。数据库将维护 ACID 事务。

在这种模式中，每个服务都应该使用底层数据库的事务管理，以便可以利用数据库的ACID属性。考虑以下伪代码 -

BEGIN TRANSACTION
…
SELECT * FROM ORDERS WHERE CUSTOMER_ID = ?
…
SELECT CREDIT_LIMIT FROM CUSTOMERS WHERE CUSTOMER_ID = ?
…
INSERT INTO ORDERS ... WHERE ORDER_LIMIT < CREDIT_LIMIT
…
COMMIT TRANSACTION

这里的订单服务使用数据库事务来确保在订单期间检查客户的信用额度。

命令查询职责分离器

问题陈述

微服务架构将应用程序构建为一组松散耦合的微服务，每个服务都可以以敏捷的方式独立开发，以实现持续交付/部署，如果我们使用每个服务一个数据库设计模式，那么如何进行需要来自多个服务的数据的查询服务。

解决方案

我们可以定义一个视图数据库，它是只读数据来支持所需的查询。应用程序将通过订阅拥有数据的服务引发的事件来保持视图数据库最新。在此设计模式中，我们将更新和读取操作分开。一项服务将仅读取数据，其他服务将更新数据。

为了实现这种模式，我们经常需要重构领域模型以支持单独的查询数据和更新数据的操作，以便每个操作都可以由微服务独立处理。CQRS 模式确保读取数据的操作与更新数据的操作分开。因此，一个操作可以读取或写入数据，但不能同时执行两者。

现在，多个服务可以更新记录并将事件发送到应用程序以更新视图数据库。这有助于查询服务获得一致的数据，而不会影响性能。

微服务设计模式 - Saga

问题陈述

微服务架构将应用程序构建为一组松散耦合的微服务，每个服务都可以以敏捷的方式独立开发，以实现持续交付/部署，如果我们使用每个服务一个数据库设计模式，那么如何实现跨多个服务的事务。

解决方案

我们可以使用Saga模式。saga 是一系列本地事务。在此模式中，每个事务都会更新数据库并触发事件或为 saga 中的下一个事务发布消息。如果任何本地事务失败，saga 将触发一系列事务来撤消本地事务迄今为止所做的更改。

考虑订单服务和客户服务的示例。订单服务可以下订单，然后询问客服是否超出信用额度。如果信用被交叉，客服会向订单服务发起事件，取消订单，否则下单成功。

为了实现这种模式，我们经常需要基于 Choreography 的 saga 或基于 Orchestrator 的 saga。

在基于编排的传奇中，服务在本地事务期间处理域事件，并完成事务或撤消相同的事务，而在基于编排器的传奇中，编排器对象在本地事务期间处理事件，然后告诉协调器要执行哪个本地事务。

异步消息传递

问题陈述

微服务架构将应用程序构建为一组松散耦合的微服务，每个服务都可以以敏捷的方式独立开发，以实现持续交付/部署。微服务处理来自客户端的请求，并且通常需要与其他微服务通信来满足请求。所以就需要进程间通信协议。

解决方案

我们可以使用异步消息模式进行服务间通信，因为使用同步通信将导致服务的紧密耦合，并且还要求客户端和服务在请求期间都可用。

使用异步消息传递，服务可以通过消息传递通道交换消息来进行通信。以下是异步消息通信的一些不同方式。

请求/同步响应- 在这种方法中，服务向另一个服务发出请求并期望立即回复。
通知- 在此方法中，服务向收件人发送消息，但不期望任何响应。预计收件人也不会发送回复。
请求/异步响应- 在这种方法中，服务向另一个服务发出请求，并期望在合理的时间范围内得到答复。
发布/订阅- 在此方法中，服务向零个或多个收件人发布消息。订阅该消息的服务也会收到相同的消息。无需回应。
发布/异步响应- 在此方法中，服务向零个或多个收件人发布消息。订阅该消息的服务也会收到相同的消息。他们中的一些人发回确认/答复。

例子

RabbitMQ 和 Apache Kafka 是微服务领域异步消息传递的好例子。

事件溯源

问题陈述

解决方案

我们可以使用事件源模式进行服务间通信。在这种类型的通信中，每个服务都会将所采取的每个操作的事件保存在事件存储中。每个服务都可以订阅这些事件并相应地更新其事务状态。考虑订单服务与客户服务的案例。客户服务可以订阅订单服务更新的事件并相应地更新其状态。

优点

以下是使用事件溯源模式的优点 -

事件驱动架构的理想选择- 这种模式允许在状态发生变化时可靠地发布事件。
持久事件- 由于事件而不是域对象被持久化，因此永远不会发生对象关系不匹配的情况。
审核日志- 由于事件捕获了每个更改，因此审核日志涵盖了 100% 的更改。
实体状态识别- 我们可以在事件数据库上创建临时查询来检查实体在任何时刻的当前状态。
单体架构到微服务架构的迁移变得更容易- 使用事件源模式，我们可以创建通过事件进行通信的松散耦合的微服务。因此，从整体应用程序开发迁移到基于微服务的应用程序开发变得更加容易。

日志聚合

问题陈述

微服务架构将应用程序构建为一组松散耦合的微服务，每个服务都可以以敏捷的方式独立开发，以实现持续交付/部署。请求通常跨越多个服务。每个服务实例以标准化格式在其日志文件中写入一些信息。这些日志可以是信息、错误、警告或调试日志。如何使用这些日志来分析和解决应用程序问题。

解决方案

我们可以使用集中式日志记录服务来聚合来自每个服务的日志。用户应该能够搜索和分析该日志服务提供的日志。当日志中出现某种类型的消息时，用户应该能够配置警报。

关联ID

当第一个微服务收到调用时，它应该生成一个 corelation id，然后可以将其传递给下游服务。应在所有微服务中记录此相关 ID。它将有助于跟踪跨多个服务的信息。

可搜索的日志

由于日志应放置在集中位置，下图展示了如何使用 Kafka、LogStash 和 Kibana 聚合日志并使用所需的过滤器搜索索引日志。

微服务生成日志，使用 kafka 日志附加程序发布日志，然后将日志消息输出到 kafka 集群。LogStash 从 kafka 获取消息，转换消息并发布到弹性搜索容器。现在 kibana 提供了一个可视化界面来从弹性搜索容器中搜索/读取索引日志，并提供所需的过滤器。

性能指标

问题陈述

微服务架构将应用程序构建为一组松散耦合的微服务，每个服务都可以以敏捷的方式独立开发，以实现持续交付/部署。如何分析和解决应用程序问题。如何跟踪应用程序性能并检查瓶颈。如何以最小的运行时开销跟踪多个服务？

解决方案

我们可以实现一个仪器服务，该服务将负责收集有关各个操作的统计数据，以及一个中央指标服务，该服务应该聚合指标并提供报告和警报。这些服务可以通过两种方式收集性能指标 -

推送- 服务将指标推送到中央指标服务。
Pull - 中央指标服务从服务中提取指标。

例子

以下是仪器库的示例 -

Java Metrics Library - 一个 Java 库，用于深入了解代码在生产中的作用。
Prometheus 客户端库- 用于监控服务的 Prometheus 库。

以下是指标聚合库的示例 -

Prometheus - 开源系统监控和警报工具包。
AWS Cloud Watch - AWS 资源和服务可观察性和监控服务。

分布式追踪

问题陈述

微服务架构将应用程序构建为一组松散耦合的微服务，每个服务都可以以敏捷的方式独立开发，以实现持续交付/部署。请求通常跨越多个服务。使用外部监控，我们可以检查总体响应时间和数量。调用的数量，但如何深入了解各个交易/操作。服务可能使用数据库、消息队列、事件源等。如何跟踪跨多个服务的分散日志？

解决方案

我们可以检测旨在执行以下操作的服务 -

Corelation ID - 每个外部请求生成一个唯一的外部请求 ID，并将该外部 ID 传递给处理请求所涉及的每个服务。
记录相关 ID - 处理服务生成的每条日志消息都应具有此相关 ID。
记录详细信息- 当服务处理请求时，在日志中记录开始/结束时间和其他相关详细信息。

可搜索的日志

由于日志应放置在集中位置，下图展示了如何使用 Kafka、LogStash 和 Kibana 聚合日志并使用所需的过滤器搜索索引日志。

微服务设计模式-健康检查

问题陈述

微服务架构将应用程序构建为一组松散耦合的微服务，每个服务都可以以敏捷的方式独立开发，以实现持续交付/部署。现在，如果数据库出现故障或无法承受更多连接，那么监控系统应该发出警报。负载均衡器/服务注册表/API 网关不应将任何请求重定向到此类失败的服务实例。因此，我们需要检测正在运行的服务实例是否能够接受请求。

解决方案

我们可以为每个服务添加一个健康检查点，例如 HTTP /health，它返回服务健康状态。该端点可以执行以下任务来检查服务运行状况 -

连接可用性- 数据库连接或当前服务使用的基础设施服务的连接的状态。
主机状态- 主机的状态，如磁盘空间、CPU 使用情况、内存使用情况等。
应用程序特定逻辑- 确定服务可用性的业务逻辑。

现在，监控服务（例如负载均衡器）、服务注册表定期调用健康检查端点来检查服务实例的健康状况。

外部配置

问题陈述

微服务架构将应用程序构建为一组松散耦合的微服务，每个服务都可以以敏捷的方式独立开发，以实现持续交付/部署。这些服务通常与基础设施服务或第三方服务交互。

基础设施服务可以包括服务注册表、消息代理、数据库服务器。第三方服务可以是支付服务、电子邮件服务、消息服务。除了不同的服务之外，环境也常常不同。考虑以下情况 -

配置数据- 外部/第三方服务的配置应提供给微服务，例如数据库凭据、网络 URL 等。
多个环境- 通常有不同的环境，如开发、质量保证、测试、登台或预生产和生产。服务应该部署在每个环境上，而无需修改任何代码。
配置数据不同- 外部/第三方服务的配置也因开发而异，例如开发数据库到生产数据库、测试支付处理器与原始支付处理器服务。

解决方案

我们可以将所有配置从数据库凭据外部化到网络 URL。服务将在启动期间读取配置数据，例如从属性文件/系统环境变量或使用命令行参数。此模式有助于部署微服务，无需任何修改/重新编译。

服务发现

问题陈述

微服务架构将应用程序构建为一组松散耦合的微服务，每个服务都可以以敏捷的方式独立开发，以实现持续交付/部署。这些服务通常在容器化/虚拟环境中运行，其实例数量和位置会动态变化。

因此，我们需要一种机制来使微服务的客户端能够向动态更改的服务实例发出请求。

解决方案

我们可以使用服务发现模式。为了实现这种模式，我们需要一个在特定固定位置运行的路由器/负载均衡器和一个注册所有微服务实例的服务注册表。

现在客户端发出服务请求，它将到达负载均衡器，然后负载均衡器查询服务注册表。如果服务实例可用，则请求将重定向到可用的服务实例。

微服务设计模式 - 断路器

问题陈述

微服务架构将应用程序构建为一组松散耦合的微服务，每个服务都可以以敏捷的方式独立开发，以实现持续交付/部署。这些服务经常与其他微服务交互。现在总是有可能服务过载或不可用。在这种情况下，调用者服务也会等待。如果多个服务被阻止，则会影响性能，并对整个应用程序产生级联影响。

现在，如何防止服务故障或网络故障级联到其他服务。如果一项服务出现故障，则不应再向其发出进一步的请求。

解决方案

我们可以使用断路器模式，其中代理服务充当断路器。每个服务都应该通过代理服务来调用。代理服务维护超时和失败计数。如果连续故障超过故障计数阈值，则代理服务将触发断路器并启动超时期限。在此超时期间，所有请求都将失败。一旦超时期限结束，代理服务就允许将给定的有限数量的测试请求传递给提供者服务。如果请求成功，代理服务将恢复操作，否则，它会再次触发断路器并启动超时期限，在此期间不会受理任何请求。

蓝绿部署

微服务架构将应用程序构建为一组松散耦合的微服务，每个服务应以敏捷的方式独立开发，以实现持续交付/部署。当要使用微服务架构构建大型复杂应用程序时，主要问题是如何设计松散耦合的微服务或将大型应用程序分解为小型松散耦合服务，同时保持系统处于生产状态。

解决方案

我们可以使用蓝绿部署来定义部署新开发的微服务。在该模型中，用户流量逐渐从旧应用转移到新的微服务应用。一旦微服务在生产中可用，负载均衡器会将针对旧应用程序的请求重定向到新微服务。

蓝色环境- 在生产中运行的旧应用程序称为蓝色环境。
绿色环境- 复制旧应用程序给定部分的部署的新服务称为绿色环境。

因此，随着开发时间的推移，随着功能从整体应用程序转移到微服务应用程序，微服务会增加，而单体会缩小。

例子

这种部署模式有助于在从单体应用程序迁移到基于微服务的应用程序时减少停机时间甚至零停机时间。