微服务设计模式（下）

平台开发 360云计算

女主宣言

本文旨在让大家了解微服务体系结构的设计模式以克服微服务所带来的挑战。文章会分为上下两篇，上篇包含1、分解模式2、集成模式，下篇包含3、数据库模式4、可观测性模式5、横切关注点的模式。

PS：丰富的一线技术、多元化的表现形式，尽在“HULK一线技术杂谈”，点关注哦！

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

可伸缩性
可用性
弹性
独立的，自主的
分散治理
故障隔离
自动预配
通过DevOps持续交付

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

微服务设计模式（上）

数据库模式

a、每个服务一个数据库

问题

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

服务必须松散耦合。它们可以独立地开发、部署和扩展。
业务事务可能强制跨多个服务的不变量。
一些业务事务需要查询由多个服务拥有的数据。
数据库有时必须复制和切分，以便进行扩展。
不同的服务有不同的数据存储需求。

解决方案

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

b、每个服务共享数据库

问题

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

解决方案

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

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

问题

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

解决方案

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

d、Saga 模式

问题

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

解决方案

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

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

可观测性模式

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端点，并且该实现也可以自定义。

横切关注点的模式

a、外部配置

问题

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

解决方案

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

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

b、服务发现模式

问题

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

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

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

解决方案

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

c、断路器模式

问题

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

解决方案

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

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

d、蓝绿部署模式

问题

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

解决方案

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

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

总结

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

更多相关文章

随机推荐