微服务架构设计中的常见的10种设计模式

微服务架构设计的概念

微服务架构（Microservices Architecture）是一种用于构建分布式系统的软件设计模式。它将大型应用程序拆分成一组小型、自治的服务，每个服务都运行在其独立的进程中，服务之间通过轻量级的通信机制（如HTTP REST API）进行交互。这种架构模式具有高度的可伸缩性、可重用性、可维护性和可测试性，特别适用于构建大规模、高并发、复杂的应用系统。

微服务架构设计的常见10种设计模式

虽然直接列出并详细阐述10种微服务设计模式并达到4000字的要求较为困难，但我可以概述几种常见的微服务设计模式，包括它们的描述、优缺点、实现方式、可用技术示例以及使用场景。

1. 独享数据库（Database per Microservice）

描述：

当一家公司将大型单体系统替换成一组微服务，首先要面临的最重要决策是关于数据库。单体架构会使用大型中央数据库。即使转移到微服务架构许多架构师仍倾向于保持数据库不变。虽然有一些短期收益，但它却是反模式的，特别是在大规模系统中，微服务将在数据库层严重耦合，整个迁移到微服务的目标都将面临失败（例如，团队授权、独立开发等问题）。

更好的方法是为每个微服务提供自己的数据存储，这样服务之间在数据库层就不存在强耦合。这里我使用数据库这一术语来表示逻辑上的数据隔离，也就是说微服务可以共享物理数据库，但应该使用分开的数据结构、集合或者表，这还将有助于确保微服务是按照领域驱动设计的方法正确拆分的。

优缺点：

优点：服务间数据隔离清晰，减少数据冲突和依赖；每个服务可以独立选择最适合其业务需求的数据库技术。
缺点：跨服务的数据一致性管理复杂；分布式事务处理困难；数据冗余和同步问题。

实现方式：
每个微服务在启动时配置自己的数据库连接信息，并通过ORM（对象关系映射）框架或数据访问层（DAO）与数据库进行交互。

可用技术示例：
MySQL、MongoDB、Cassandra等数据库系统，以及Spring Data JPA、MyBatis等ORM框架。

使用场景：
适用于业务复杂度高、数据模型差异大、需要高度自治的微服务系统。

2. 聚合器（Aggregator）

描述：
聚合器模式是一种将多个微服务的响应聚合起来，以形成一个统一的响应返回给客户端的设计模式。这种模式常用于构建复杂的业务场景，其中客户端需要的数据分散在多个微服务中。

为了尽量减少服务之间的通信，我们可以使用服务聚合模式。基本上，服务聚合设计模式是接收来自客户端或 API 网关的请求，然后分配给内部多个后端微服务，再将结果合并，并在一个响应结构中发给请求发起人。

通过实现服务聚合模式，可以减少客户端和微服务之间的通信量和通信开销

服务聚合模式

微服务通信设计模式------服务聚合模式设计

优缺点：

优点：提高系统的灵活性和可扩展性；减少客户端的调用次数和复杂度。
缺点：聚合器可能成为性能瓶颈；增加了系统的复杂性和维护成本。

实现方式：
聚合器微服务通过同步或异步方式调用其他微服务，并将结果聚合后返回给客户端。

可用技术示例：
Spring Cloud Gateway、Zuul等API网关，以及Spring Boot、Node.js等后端技术栈。

使用场景：
适用于需要跨多个微服务获取数据并展示给用户的场景，如电商平台的商品详情页。

3. 链式（Chain）

描述：
链式模式是指微服务之间按照特定的顺序进行调用，形成一条服务调用链。每个服务在接收到请求后，处理部分业务逻辑，并将请求传递给链中的下一个服务。

优缺点：

优点：实现服务间的松耦合；提高系统的灵活性和可维护性。
缺点：调用链过长可能导致性能问题；服务间的依赖关系复杂。

实现方式：
通过HTTP请求或消息队列等方式实现服务间的顺序调用。

可用技术示例：
Spring Cloud OpenFeign、Apache Dubbo等RPC框架，以及RabbitMQ、Kafka等消息队列。

使用场景：
适用于业务流程具有明确顺序和依赖关系的场景，如订单处理流程。

4. 命令和查询职责分离（CQRS）

描述：
如果我们使用事件源，那么从事件存储中读取数据就变得困难了。要从数据存储中获取实体，我们需要处理所有的实体事件。有时我们对读写操作还会有不同的一致性和吞吐量要求。

这种情况，我们可以使用 CQRS 模式。在该模式中，系统的数据修改部分（命令）与数据读取部分（查询）是分离的。而 CQRS 模式有两种容易令人混淆的模式，分别是简单的和高级的。其简单形式中，不同实体或 ORM 模型被用于读写操作，如下所示：

它有助于强化单一职责原则和分离关注点，从而实现更简洁的设计。

在其高级形式中，会有不同的数据存储用于读写操作。高级的 CQRS 通常结合事件源模式。根据不同情况，会使用不同类型的写数据存储和读数据存储。写数据存储是“记录的系统”，也就是整个系统的核心源头。

对于读频繁的应用程序或微服务架构，OLTP 数据库（任何提供 ACID 事务保证的关系或非关系数据库）或分布式消息系统都可以被用作写存储。对于写频繁的应用程序（写操作高可伸缩性和大吞吐量），需要使用写可水平伸缩的数据库（如全球托管的公共云数据库）。标准化的数据则保存在写数据存储中。
对搜索（例如 Apache Solr、Elasticsearch）或读操作（KV 数据库、文档数据库）进行优化的非关系数据库常被用作读存储。许多情况会在需要 SQL 查询的地方使用读可伸缩的关系数据库。非标准化和特殊优化过的数据则保存在读存储中。
数据是从写存储异步复制到读存储中的，所以读存储和写存储之间会有延迟，但最终是一致的。

微服务架构及其最重要的10个设计模式
原文链接： https://www.infoq.cn/article/kdw69bdimlx6fsgz1bg3

优缺点：

优点：

在事件驱动的微服务中数据读取速度更快。
数据的高可用性。
读写系统可独立扩展。

缺点：

读数据存储是弱一致性的（最终一致性）。
整个系统的复杂性增加了，混乱的 CQRS 会显着危害整个项目。

可用技术示例：

写存储： EventStoreDB， Apache Kafka， Confluent Cloud， AWS Kinesis， Azure Event Hub， GCP Pub/Sub， Azure Cosmos DB， MongoDB， Cassandra. Amazon DynamoDB

读存储：Elastic Search， Solr， Cloud Spanner， Amazon Aurora， Azure Cosmos DB， Neo4j

框架：Lagom， Akka， Spring， akkatecture， Axon， Eventuate

使用场景

在高可扩展的微服务架构中使用事件源。
在复杂领域模型中，读操作需要同时查询多个数据存储。
在读写操作负载差异明显的系统中。

5. 异步消息传递（Asynchronous Messaging）

描述：
同步调用模式在调用的过程中会阻塞线程，如果服务提供方迟迟没有返回，则服务消费方会一直阻塞，严重的会撑满服务的线程池，出现雪崩效应。因此，在构建服务架构系统时，通常会梳理核心系统的最小化服务集合，这些核心的系统服务使用同步调用。而其他核心链路以外的服务可以使用异步消息队列进行异步化

优缺点：

优点：提高系统的可靠性和可扩展性；减少服务间的直接依赖。
缺点：增加了系统的复杂性和维护成本；消息的一致性和顺序性管理困难。

实现方式：
使用RabbitMQ、Kafka等消息队列产品。

可用技术示例：
RabbitMQ、Kafka、ActiveMQ等。

使用场景：
适用于对实时性要求不高，但需要高可靠性和可扩展性的场景，如订单处理、日志收集等。在这些场景中，服务之间的调用不必立即响应，可以通过消息队列进行异步处理，从而提高系统的整体性能和稳定性。

6. 事件驱动（Event-Driven）

描述：
事件驱动模式通过事件来触发服务之间的交互。当一个微服务发生特定事件时，它会发布该事件到事件总线或消息队列中，其他微服务可以订阅这些事件并在事件发生时进行相应的处理。

优缺点：

优点：实现服务间的松耦合；提高系统的可扩展性和灵活性。
缺点：事件处理的一致性和顺序性管理困难；系统复杂度增加。

实现方式：
使用事件总线（如Apache Kafka、RabbitMQ等）或分布式消息系统来实现事件的发布和订阅。

可用技术示例：
Apache Kafka、RabbitMQ、Azure Event Grid等。

使用场景：
适用于需要高度解耦、实时性要求不高的场景，如订单状态变更通知、用户行为跟踪等。

7. 服务发现（Service Discovery）

描述：
服务发现模式允许微服务在运行时自动发现其他服务的地址和端口信息，从而实现服务的自动注册和发现。这有助于实现服务的动态扩展和容错。

优缺点：

优点：提高系统的灵活性和可扩展性；减少服务间的硬编码依赖。
缺点：服务注册和发现的复杂性和开销。

实现方式：
使用服务注册中心（如Eureka、Consul、Zookeeper等）来管理服务的注册和发现。

可用技术示例：
Eureka、Consul、Zookeeper等。

使用场景：
适用于需要动态扩展和容错能力的微服务系统，特别是在云环境或容器化部署中。

8. Saga

描述：
如果微服务使用独享数据库，那么通过分布式事务管理一致性是一个巨大的挑战。你无法使用传统的两阶段提交协议，因为它要么不可伸缩（关系数据库），要么不被支持（多数非关系数据库）。

但您还是可以在微服务架构中使用 Saga 模式实现分布式事务。Saga 是 1987 年开发的一种古老模式，是关系数据库中关于大事务的一个替代概念。但这种模式的一种现代变种对分布式事务也非常有效。Saga 模式是一个本地事务序列，其每个事务在一个单独的微服务内更新数据存储并发布一个事件或消息。Saga 中的首个事务是由外部请求（事件或动作）初始化的，一旦本地事务完成（数据已保存在数据存储且消息或事件已发布），那么发布的消息或事件则会触发 Saga 中的下一个本地事务。

优缺点：

优点：

为高可伸缩或松耦合的、事件驱动的微服务架构提供一致性事务。
为使用了不支持 2PC 的非关系数据库的微服务架构提供一致性事务

缺点：

需要处理瞬时故障，并且提供等幂性。
难以调试，而且复杂性随着微服务数量增加而增加。

实现方式：
使用熔断器库（如Netflix的Hystrix、Resilience4j等）来实现熔断逻辑。

可用技术示例：
Axon， Eventuate， Narayana

使用场景：

在使用了事件源的高可伸缩、松耦合的微服务中。
在使用了分布式非关系数据库的系统中。

9. 缓存（Caching）

描述：
缓存模式通过在服务之间添加缓存层来减少对底层数据源的访问频率，从而提高系统的响应速度和吞吐量。

优缺点：

优点：提高系统的响应速度和吞吐量；减少对底层数据源的访问压力。
缺点：数据一致性问题；缓存击穿和雪崩问题。

实现方式：
使用缓存中间件（如Redis、Memcached等）来实现缓存逻辑。

可用技术示例：
Redis、Memcached等。

使用场景：
适用于读多写少、数据更新频率不高的场景，如商品信息、用户信息等。

10.边车模式（Sidecar Pattern）

描述：

边车模式（Sidecar Pattern）是一种在微服务架构中常见的模式，它通过将辅助性质的服务（通常被称为sidecar）与主要的服务实例部署在一起，以提供额外的功能、能力或支持。边车模式的设计思想是将控制和逻辑分离，使得主要服务实例可以更专注于其核心业务逻辑，而边车则负责处理如日志记录、监控、安全性、通信等辅助功能。这种设计模式允许主服务更加单一职责，便于维护和升级，同时也提高了系统的灵活性和可扩展性。

优点：

解耦与模块化：将服务治理功能从业务逻辑中分离出来，实现了关注点的分离和模块化，使得业务逻辑更加清晰和简洁，同时治理功能也更加可重用和灵活。
可扩展性：允许对治理功能进行独立的扩展和升级，而不需要修改业务逻辑代码，提高了系统的可扩展性。
多语言支持：对业务逻辑的代码侵入性较小，支持多种编程语言和技术栈，使得在混合语言环境中进行微服务治理变得更加容易。
灵活性：可以灵活地添加或移除治理功能，以满足不同业务场景的需求，降低了维护成本。

缺点：

复杂性增加：引入边车模式会增加系统的复杂性，需要额外管理和维护边车进程，增加了开发和运维的工作量。
资源消耗：每个微服务实例都需要一个边车进程，可能会导致资源（如CPU、内存等）的消耗增加，在资源受限的环境中可能成为一个问题。
网络延迟：边车进程需要与微服务实例进行通信，可能会增加网络延迟，尽管可以通过优化网络配置来降低延迟。

实现方式：

边车模式的实现通常涉及使用特定的技术或工具，这些工具可以作为辅助性质的服务与主服务实例一起部署。常见的实现方式包括：

使用容器化技术：如Docker容器，将边车服务作为独立的容器与主服务容器部署在同一个Pod中（在Kubernetes等容器编排系统中）。
部署代理：如Envoy、Linkerd等高性能的代理和通信总线，负责处理服务之间的网络通信、负载均衡、故障恢复等任务。

可用技术示例：

Istio：一个开源的服务网格框架，通过在应用程序的每个服务实例旁边部署一个Envoy Sidecar来实现边车模式，提供了流量管理、安全性、可观察性等功能。
Linkerd：由Buoyant公司开源的服务网格实现，通过在每个服务实例旁边部署一个Linkerd Proxy来实现边车模式，提供了负载均衡、故障注入、监控和可观察性等功能。
Consul Connect：HashiCorp公司的Consul服务发现和配置管理工具的一部分，通过在每个服务实例旁边运行一个代理来实现边车模式，提供安全的服务到服务通信功能。
NGINX：虽然主要作为Web服务器和反向代理服务器使用，但也可以作为Sidecar部署在每个服务实例旁边，通过配置NGINX作为反向代理，实现负载均衡、安全性和其他网络功能。

使用场景：