几十年来，应用程序一直使用单体架构构建。现在，许多应用程序正在转向微服务架构。微服务架构为我们提供了更快的开发速度、可伸缩性、可靠性，以及使用最佳技术栈开发每个组件的灵活性，等等。微服务架构依赖独立部署的微服务，每个微服务都有自己的业务逻辑和数据库，它们由特定的领域上下文组成。每个服务的测试、增强和伸缩都独立于其他微服务。

然而，微服务架构也有其自身的挑战和复杂性。为了解决最常见的挑战和问题，已经发展出了一些设计模式。在本文中，我们将研究其中的几个。

在一个典型的微服务架构中，要实现顺畅的开发，可采用的设计模式不止八种。在本节中，我们将详细地探究这些模式。我们根据应用程序类型将它们分为两个部分——新应用程序和遗留应用程序。

用于构建新应用程序的设计模式

当我们从零开始构建应用程序时，可以自由地应用所有最新的现代化的微服务架构设计模式。让我们深入了解其中的一些。

API 网关模式

将整个业务逻辑分解为多个微服务会带来各种问题：

• 如何处理横切关注点，如授权、速率限制、负载均衡、重试策略、服务发现等？

• 如何避免由于客户端和微服务之间的直接通信而导致过多的流量往返和紧密耦合？

• 如果客户端需要数据的子集，谁来进行数据过滤和映射？

• 如果客户端需要调用多个微服务来获取数据，谁来进行数据聚合？为了解决这些问题，我们在客户端应用程序和微服务之间部署了 API 网关。它带来了很多功能，如反向代理、请求聚合、网关卸载、服务发现等。它可以为每个客户端公开不同的 API。

图 1：API 网关示例

客户端 UI 组合模式

在这种模式中，微服务由面向业务功能的团队负责开发。一些 UI 页面可能需要使用来自多个微服务的数据。例如，一个购物网站包含目录、购物车、购买选项、客户评论等功能。每个数据项属于一个特定的微服务。现在显示的每个数据项都由不同的团队负责维护。那么我们如何解决这个问题？

UI 团队应该创建一个页面骨架，通过组合多个 UI 组件来构建页面。每个团队开发一个特定于某个服务的客户端 UI 组件。这个骨架也称为单页面应用程序（SPA）。AngularJS 和 ReactJS 都支持 SPA。用户可以在数据变化时刷新屏幕的特定区域，从而获得更好的用户体验。

服务与数据库一一对应模式

微服务需要是独立的和松散耦合的。那么，微服务应用程序的数据库架构应该是什么样子的？

• 典型的业务事务可能涉及由不同团队开发的多个服务的查询、连接或数据持久化操作。

• 在多语言微服务架构中，每个微服务可能有不同的数据存储需求，如非结构化数据（NoSQL 数据库）、结构化数据（关系数据库）和/或图形数据（Neo4j）。

• 数据库需要通过复制和分片来实现伸缩性。

• 

图 2：服务与数据库一一对应模式

微服务的事务必须被限制在它自己的数据库中，其他服务要想使用数据，必须通过服务 API 来获取。如果你使用的是关系数据库，那么一个服务对应一个 Schema 是实现数据私有化的最佳选择。要创建这种屏障，可以为每一个服务分配不同的数据库用户 ID，这样可以确保开发人员不会绕过微服务的 API 直接访问数据库。

这使得每个微服务可以使用最适合其需求的数据库类型。例如，Neo4j 用于社交图数据，Elasticsearch 用于文本搜索。

Saga 模式

如果我们为每一个服务使用一个数据库，在实现跨多个微服务的事务时就会出现问题。在这种情况下，我们该如何保持数据一致性？本地 ACID 事务在这里不起作用，解决办法就是采用 Saga 模式。Saga 是一种本地事务链，事务链中的每一个事务更新数据库并发布一个事件来触发下一个本地事务。Saga 模式要求在本地事务失败时对事务进行补偿。

Saga 模式有两种实现方式：

• 编配（Orchestration）——编配器负责协调所有的服务执行本地事务、获取更新和执行下一个事件。如果失败，它负责触发补偿事件。

• 编排（Choreography）——每个微服务负责监听和发布事件，并且在失败时触发补偿事件。编配比编排更容易实现。在编配实现中，只有一个组件需要协调所有事件，而在编排实现中，每个微服务都必须监听和响应事件。

断路器模式

在微服务架构中，一个事务涉及调用多个服务，如果下游微服务发生故障，它会继续调，并耗尽所有其他服务的网络资源。它还会影响用户体验。那么我们如何处理级联故障？

受电气断路器功能启发的断路器模式可以解决这个问题。在客户端和微服务之间有一个代理，它会跟踪连续调用失败的次数，如果超过了一个阈值，它就会中断连接并立即宣告失败。在经过一个超时时间之后，断路器再次允许有限数量的测试请求，检查连接是否可以恢复。否则，超时时间将被重置。

图 3：断路器模式示例

resilence4j 框架就提供了这个代理服务。

按业务能力或子域分解模式

在微服务架构中，复杂的大型应用程序必须进行分解、内聚和松耦合。它还应该是自主的，并且足够小，可以由“萨饼”的团队（6 到 8 名成员）负责开发。那么我们如何分解它？

我们有两种方法来分解一个新应用程序——根据业务能力或子领域。

• 业务能力是产生价值的东西。例如，在航空公司中，业务功能可以是预订、销售、支付、座位分配，等等。

• 子域概念来自于领域驱动设计（DDD）。一个域由多个子域组成，例如产品目录、订单管理、交付管理，等等。

用于遗留应用程序的设计模式

因为我们几十年来一直在构建应用程序，大约 80%的公司在运行遗留的应用程序，这些应用程序被称为 Brownfield（即遗留）应用程序。将遗留应用程序迁移到微服务架构是最具挑战性的任务。让我们来看看一些可以帮助简化迁移过程的设计模式。

绞杀榕模式

我们如何将单体应用程序迁移到微服务架构？绞杀榕模式以藤蔓作为类比，藤蔓会扼死它所缠绕的树。在这个模式中，单体应用程序的一小部分被转换为微服务，对于用户来说，外部 API 保持不变，看起来没有任何变化。慢慢地，所有的部分都被重构为微服务，新的架构“扼杀”或取代了原来的单体架构。

反腐蚀层模式

当现代应用程序需要与遗留应用程序集成时，与过时的基础设施协议、API 和数据模型交互将是一项巨大的挑战。坚持旧的模式和语义可能会腐蚀新系统。那么我们该如何避免这种情况？

这需要一个层来转换两个系统之间的通信。反腐蚀层与遗留系统或新系统的数据模型相匹配，具体取决于它从哪个系统获取数据。它确保旧的系统不需要做出改变，同时新系统也不需要在设计和技术方面做出妥协。

图 4：反腐蚀层模式示例

结论

微服务架构为开发人员提供了很大的灵活性，但随着需要管理的组件数量的增加，也带来了许多挑战。在本文中，我们讨论了构建和开发微服务应用程序所必需的最重要的设计模式。

原文链接：

https://dzone.com/articles/popular-design-patterns-for-microservices-architec