微服务设计模式（下）

微服务体系结构已经成为现代应用程序开发的实际选择。虽然它解决了某些问题，但它不是一颗银弹。它也有一些缺点，在使用这种体系结构时，有许多问题必须解决。这就需要学习这些问题中的通用模式，并使用可重用的解决方案来解决它们。因此，需要讨论微服务的设计模式。在深入研究设计模式之前，我们需要了解微服务体系结构的构建原则：

1.可伸缩性

2.可用性

3.弹性

4.独立的，自主的

5.分散治理

6.故障隔离

7.自动预配

8.通过 DevOps 持续交付

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

3 数据库模式

a、每个服务一个数据库

问题

如何为微服务定义数据库体系结构是一个问题。以下是需要解决的问题：

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

2.业务事务可能强制跨多个服务的不变量。

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

4.数据库有时必须复制和切分，以便进行扩展。

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

解决方案

为了解决上述问题，每个微服务必须设计一个数据库;这项服务必须是私人的。它只能由 microservice API 访问。其他服务不能直接访问它。例如，对于关系数据库，我们可以使用针对服务的私有表、针对服务的模式或针对服务的数据库-服务器。每个微服务都应该有一个单独的数据库 id，以便能够提供单独的访问，以设置障碍，并防止它使用其他服务表。

b、每个服务共享数据库

问题

我们已经讨论过，每个服务有一个数据库对于微服务来说是理想的，但是当应用程序是 greenfield 并且可以用 DDD 开发时，这是可能的。但如果应用程序是一个整体，并试图进入微服务，反规范化不是那么容易。在这种情况下，什么是合适的体系结构？

解决方案

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

c、命令查询责任隔离(CQRS)

问题

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

解决方案

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

d、Saga 模式

问题

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

解决方案

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

• 编排——当没有中央协调时，每个服务产生并监听另一个服务的事件，并决定是否应该采取行动。

• 编配——编配者(对象)负责传奇的决策制定和业务逻辑的排序。

4 可观测性模式

a、日志聚合

问题

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

解决方案

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

b、性能标准

问题

当由于微服务体系结构而导致的服务组合增加时，对事务进行监视就变得非常重要，以便在出现问题时可以监视模式并发送警报。我们应该如何收集指标来监控应用程序性能？

解决方案

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

• 推送——服务将指标推送到指标服务，例如 NewRelic, AppDynamics

Pull - 度量服务从服务中提取度量指标，例如 Prometheus

c、分布式跟踪

问题

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

解决方案

我们需要一种服务

• 分配每个外部请求一个唯一的外部请求 id。

• 将外部请求 id 传递给所有服务。

• 在所有日志消息中包含外部请求 id。

• 记录在集中服务中处理外部请求时执行的请求和操作的信息(例如，开始时间、结束时间)。

Spring Cloud Slueth 以及 Zipkin server 都是通用实现。

d、健康检查

问题

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

解决方案

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

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

5 横切关注点的模式

a、外部配置

问题

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

解决方案

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

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

b、服务发现模式

问题

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

1.使用容器技术，IP 地址被动态分配给服务实例。每次地址更改时，使用者服务可能会中断，并需要手动更改。

2.每个服务 URL 都必须被使用者记住并成为紧密耦合的。

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

解决方案

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

c、断路器模式

问题

服务通常调用其他服务来检索数据，下游服务可能会停机。这样做有两个问题：首先，请求将继续使用 down 服务，耗尽网络资源并降低性能。其次，用户体验将是糟糕的和不可预测的。如何避免级联服务故障并优雅地处理故障？

解决方案

使用者应该通过代理调用远程服务，代理的行为类似于断路器。当连续故障数超过阈值时，断路器跳闸，在超时期间，所有调用远程服务的尝试都会立即失败。超时过期后，断路器允许有限数量的测试请求通过。如果这些请求成功，断路器将恢复正常工作。否则，如果出现故障，超时周期将再次开始。

Netflix Hystrix 是断路器模式的良好实现。它还可以帮助您定义一个备用机制，可以使用断路器跳闸。这提供了更好的用户体验。

d、蓝绿部署模式

问题

使用微服务体系结构，一个应用程序可以有许多微服务。如果我们停止所有服务，然后部署一个增强版本，停机时间将是巨大的，并可能影响业务。此外，回滚将是一场噩梦。我们如何避免或减少部署期间服务的停机时间？

解决方案

可以实现蓝绿色部署策略以减少或消除停机时间。它通过运行两个相同的生产环境(蓝色和绿色)来实现这一点。让我们假设绿色是现有的活动实例，蓝色是应用程序的新版本。在任何时候，只有一个环境是 live, live 环境服务于所有生产流量。所有云平台都提供了实现蓝绿色部署的选项。

与微服务体系结构一起使用的还有许多其他模式，比如 Sidecar、链式微服务、分支微服务、事件源模式、持续交付模式等等。随着我们在微服务方面获得更多的经验，这个名单还在不断增长。我现在停下来是为了了解您正在使用的微服务模式。

总结

在本篇中，我们给大家介绍了数据库模式、可观测性模式和横切关注点的模式。希望对大家在理解微服务方面有所帮助。

本文转载自公众号 360 云计算（ID：hulktalk）。

原文链接：

https://mp.weixin.qq.com/s/9yNL3fpnV1-Wk3Dz4GohFw