微服务的设计模式

点击“终码一生”，关注，置顶公众号

每日技术干货，第一时间送达！

了解微服务架构的设计模式以克服其挑战。

微服务架构已成为现代应用程序开发的事实上的选择。虽然它解决了某些问题，但它不是灵丹妙药。它有几个缺点，在使用这种架构时，必须解决许多问题。这就需要学习这些问题中的常见模式并用可重用的解决方案来解决它们。因此，需要讨论微服务的设计模式。在深入研究设计模式之前，我们需要了解微服务架构的构建原则：

可扩展性
可用性
弹性
独立、自主
去中心化治理
故障隔离
自动配置

应用所有这些原则会带来一些挑战和问题。让我们讨论这些问题及其解决方案。

分解模式

按业务能力分解

问题

微服务就是让服务松耦合，应用单一职责原则。然而，将应用程序分解成更小的部分必须在逻辑上完成。我们如何将应用程序分解为小服务？

解决方案

一种策略是按业务能力分解。业务能力是企业为了产生价值而做的事情。给定业务的功能集取决于业务类型。例如，保险公司的能力通常包括销售、营销、承保、索赔处理、计费、合规等。每个业务能力都可以被认为是一种服务，除了它是面向业务的而不是技术的。

按子域分解

问题

使用业务能力分解一个应用程序可能是一个好的开始，但是你会遇到所谓的“上帝类”，它不容易分解。这些类将在多个服务中通用。比如Order类会用到Order Management、Order Takes、Order Delivery等，我们如何分解它们呢？

解决方案

对于“God Classes”问题，DDD（领域驱动设计）来拯救。它使用子域和有界上下文概念来解决这个问题。DDD 将为企业创建的整个域模型分解为子域。每个子域都有一个模型，该模型的范围称为有界上下文。每个微服务都将围绕有界上下文开发。

注意：识别子域并非易事。这需要对业务的了解。与业务能力一样，通过分析业务及其组织结构并识别不同的专业领域来识别子域。

扼杀者模式

问题

到目前为止，我们讨论的设计模式是为新建应用程序分解，但我们所做的工作中有 80% 是针对新建应用程序，它们是大型的单体应用程序。将上述所有设计模式应用于它们将是困难的，因为在实时使用的同时将它们分解成更小的部分是一项艰巨的任务。

解决方案

扼杀者模式来救援。Strangler 模式类似于藤蔓缠绕缠绕的树。此解决方案适用于来回调用的 Web 应用程序，并且对于每个 URI 调用，可以将服务分解为不同的域并作为单独的服务托管。这个想法是一次做一个域。这会创建两个独立的应用程序，它们并排存在于同一个 URI 空间中。最终，新重构的应用程序会“扼杀”或替换原始应用程序，直到您最终可以关闭单体应用程序。

集成模式

API 网关模式

问题

当应用程序分解为更小的微服务时，需要解决一些问题：

如何调用多个微服务抽象生产者信息。
在不同的渠道（如桌面、移动和平板电脑）上，应用程序需要不同的数据来响应相同的后端服务，因为 UI 可能不同。
不同的消费者可能需要来自可重用微服务的不同格式的响应。谁来做数据转换或字段操作？
如何处理生产者微服务可能不支持的不同类型的协议。

解决方案

API 网关有助于解决微服务实现引起的许多问题，不仅限于上述问题。

API 网关是任何微服务调用的单一入口点。
它可以作为代理服务将请求路由到相关的微服务，抽象生产者的详细信息。
它可以将请求扇出到多个服务并聚合结果以发送回消费者。
一刀切的 API 无法解决所有消费者的需求；这个解决方案可以为每种特定类型的客户端创建一个细粒度的 API。
它还可以将协议请求（例如 AMQP）转换为另一个协议（例如 HTTP），反之亦然，以便生产者和消费者可以处理它。
它还可以卸载微服务的身份验证/授权责任。

聚合器模式

问题

我们已经讨论过解决 API 网关模式中的聚合数据问题。但是，我们将在这里整体地讨论它。将业务功能分解为几个较小的逻辑代码段时，有必要考虑如何协作每个服务返回的数据。这个责任不能留给消费者，因为它可能需要了解生产者应用程序的内部实现。

解决方案

聚合器模式有助于解决这个问题。它讨论了我们如何聚合来自不同服务的数据，然后将最终响应发送给消费者。这可以通过两种方式完成：

1.复合微服务将调用所有需要的微服务，整合数据，并在发回之前转换数据。

2. API Gateway还可以将请求划分为多个微服务，并在发送给消费者之前聚合数据。

如果要应用任何业务逻辑，建议选择复合微服务。否则，API 网关是既定的解决方案。

客户端 UI 组合模式

问题

当通过分解业务能力/子域来开发服务时，负责用户体验的服务必须从多个微服务中拉取数据。在单体世界中，曾经只有一次从 UI 调用后端服务来检索所有数据并刷新/提交 UI 页面。但是，现在情况将不一样了。我们需要了解如何去做。

解决方案

对于微服务，UI 必须设计为具有屏幕/页面的多个部分/区域的骨架。每个部分都会调用一个单独的后端微服务来提取数据。这称为组合特定于服务的 UI 组件。AngularJS 和 ReactJS 之类的框架有助于轻松做到这一点。这些屏幕称为单页应用程序 (SPA)。这使应用程序能够刷新屏幕的特定区域而不是整个页面。

数据库模式

每个服务的数据库

问题

存在如何为微服务定义数据库架构的问题。以下是需要解决的问题：

1. 服务必须是松耦合的。它们可以独立开发、部署和扩展。

2. 业务交易可以强制执行跨越多个服务的不变量。

3. 一些业务事务需要查询多个服务拥有的数据。

4. 数据库有时必须复制和分片才能扩展。

5. 不同的服务有不同的数据存储要求。

解决方案

为了解决上述问题，必须为每个微服务设计一个数据库；它必须仅对该服务私有。它只能由微服务 API 访问。它不能被其他服务直接访问。例如，对于关系数据库，我们可以使用 private-tables-per-service、schema-per-service 或 database-server-per-service。每个微服务都应该有一个单独的数据库 ID，以便可以提供单独的访问权限来设置障碍并防止它使用其他服务表。

每个服务共享数据库

问题

我们已经讨论过每个服务一个数据库是微服务的理想选择，但是当应用程序是未开发并使用 DDD 开发时，这是可能的。但是如果应用程序是一个单体应用程序并试图闯入微服务，那么非规范化就不是那么容易了。在这种情况下，合适的架构是什么？

解决方案

每个服务共享数据库并不理想，但这是上述场景的有效解决方案。大多数人认为这是微服务的反模式，但对于棕地应用程序，这是将应用程序分解为更小的逻辑部分的良好开端。这不适用于新建应用程序。在这种模式下，一个数据库可以与多个微服务对齐，但它必须限制在最多 2-3 个，否则扩展、自治和独立性将难以执行。

命令查询职责分离 (CQRS)

问题

一旦我们实现了每个服务的数据库，就需要查询，这需要来自多个服务的联合数据——这是不可能的。那么，我们如何在微服务架构中实现查询呢？

解决方案

CQRS 建议将应用程序分成两部分——命令端和查询端。命令端处理创建、更新和删除请求。查询端使用物化视图处理查询部分。事件溯源模式通常与它一起用于为任何数据更改创建事件。通过订阅事件流来保持物化视图的更新。

Saga 模式

问题

当每个服务都有自己的数据库，一个业务事务跨越多个服务时，我们如何保证跨服务的数据一致性？例如，对于客户有信用额度的电子商务应用程序，该应用程序必须确保新订单不会超过客户的信用额度。由于订单和客户位于不同的数据库中，因此应用程序不能简单地使用本地 ACID 事务。

解决方案

一个 Saga 代表一个由多个子请求组成的高级业务流程，每个子请求都更新单个服务中的数据。每个请求都有一个在请求失败时执行的补偿请求。它可以通过两种方式实现：

编排——当没有中央协调时，每个服务都会产生并监听另一个服务的事件，并决定是否应该采取行动。
编排——编排器（对象）负责 saga 的决策制定和业务逻辑排序。

可观察性模式

日志聚合

问题

考虑一个应用程序由在多台机器上运行的多个服务实例组成的用例。请求通常跨越多个服务实例。每个服务实例都会生成一个标准化格式的日志文件。我们如何通过日志了解特定请求的应用程序行为？

解决方案

我们需要一个集中的日志服务来聚合来自每个服务实例的日志。用户可以搜索和分析日志。他们可以配置在日志中出现某些消息时触发的警报。例如，PCF 确实有 Loggeregator，它从 PCF 平台的每个组件（路由器、控制器、diego 等）以及应用程序中收集日志。AWS Cloud Watch 也这样做。

性能指标

问题

当服务组合由于微服务架构而增加时，密切关注事务就变得至关重要，以便可以监控模式并在问题发生时发送警报。我们应该如何收集指标来监控应用程序性能？

解决方案

需要度量服务来收集有关各个操作的统计信息。它应该聚合提供报告和警报的应用程序服务的指标。聚合指标有两种模型：

Push — 服务将指标推送到指标服务，例如 NewRelic、AppDynamics
Pull — 指标服务从服务中提取指标，例如 Prometheus

分布式跟踪

问题

在微服务架构中，请求通常跨越多个服务。每个服务通过跨多个服务执行一个或多个操作来处理请求。那么，我们如何端到端地跟踪请求来解决问题呢？

解决方案

我们需要一项服务

为每个外部请求分配一个唯一的外部请求 ID。
将外部请求 ID 传递给所有服务。
在所有日志消息中包含外部请求 ID。
记录有关在集中式服务中处理外部请求时执行的请求和操作的信息（例如开始时间、结束时间）。

Spring Cloud Slueth 和 Zipkin 服务器是一个常见的实现。

健康检查

问题

实现微服务架构后，服务可能会启动但无法处理事务。在这种情况下，您如何确保请求不会发送到那些失败的实例？使用负载平衡模式实现。

解决方案

每个服务都需要有一个端点，可用于检查应用程序的健康状况，例如/health. 此 API 应检查主机的状态、与其他服务/基础设施的连接以及任何特定逻辑。

Spring Boot Actuator 确实实现了 /health 端点，并且还可以自定义实现。

跨领域关注模式

外部配置

问题

服务通常也会调用其他服务和数据库。对于 dev、QA、UAT、prod 等每个环境，端点 URL 或某些配置属性可能不同。任何这些属性的更改都可能需要重新构建和重新部署服务。我们如何避免因配置更改而修改代码？

解决方案

外部化所有配置，包括端点 URL 和凭据。应用程序应在启动时或运行时加载它们。

Spring Cloud 配置服务器提供了将属性外部化到 GitHub 并将它们作为环境属性加载的选项。这些可以由应用程序在启动时访问，也可以在不重新启动服务器的情况下刷新。

服务发现模式

问题

当微服务出现时，我们需要解决调用服务方面的一些问题：

使用容器技术，IP 地址被动态分配给服务实例。每次地址更改时，消费者服务都可能中断并需要手动更改。
每个服务 URL 都必须被消费者记住并紧密耦合。

那么消费者或路由器如何知道所有可用的服务实例和位置呢？

解决方案

需要创建一个服务注册表来保存每个生产者服务的元数据。服务实例应在启动时注册到注册表，在关闭时应注销。消费者或路由器应该查询注册表并找出服务的位置。注册中心还需要对生产者服务进行健康检查，以确保只有服务的工作实例可以通过它使用。有两种类型的服务发现：客户端和服务器端。客户端发现的一个示例是 Netflix Eureka，而服务器端发现的一个示例是 AWS ALB。