六种常用的微服务架构设计模式 第三种模式

状态管理

接下来的四种模式都关注状态管理。状态是分布式体系结构最具挑战性的方面之一，因为传统的系统设计能够支持一致的数据查询和更改，但在分布式体系结构中，要保证数据的一致性通常是相当困难的。

对许多人来说，微服务设计的重点是集成各种使用用例；在实施过程中取得少量的成功后，状态管理也会成为首要和中心的问题。因为提供连接性和集成意味着微服务系统本质上要么是查询状态，要么是更改状态（或者两者都是）。对于给定的实体或信息，查询和更改状态的方法通常并不是唯一的。为了避免数据损坏或意外结果，您需要考虑以下两种策略之一：

显式声明状态，并使用某种策略来处理更改和查询状态带来的副作用。

通过这种策略，每个微服务组件可以实现更高物理级别上的自治，从而允许更快的更改速度。

 

第三种模式：分层API架构上面向消息的状态管理

 

分层API架构上面向消息的状态管理通常是用于避免访问和更改状态带来的副作用的第一种模式。通过提供异步的消息队列在服务之间传递状态的更改（通过命令或事件），或是查询其他微服务，能够让每个微服务都有必要的时间来汇聚事件，从而最终达成对外的数据一致性。

分层API架构上面向消息的状态管理模式经常被具有SOA和ESB经验的团队使用，因为遵循他们之前的架构经验，这种模式是非常直观的。

我们建议这种模式通常用作过渡状态；企业可以在开始实施微服务架构时使用该模式，但随着实施方法变得更加成熟，这种模式可能也就不再适合需求。通过使用队列来临时解耦组件，每个微服务的实现和行为变得模糊，这意味着设计这种模式带来的副作用往往比简单地将现有系统暴露于微服务设计中更加突出。例如，看到用于传送事件、命令、批处理甚至只是流数据的消息以相同的方式呈现在上层组件，这种情况并不罕见。这时，系统可能会变得不可预测。而在更传统的环境中(例如ESB)，这类不可预测性是可以被管理的，但当演化到微服务的规模（数千个服务，几十万个消息类型）时，管理很快将会变得不切实际。因此，这种模式通常是一个短暂的过渡，仅仅是为了让团队意识到消息队列是有用的，但是为了真正成功，他们需要围绕消息队列中传递的内容建立一些标准。

问题：

为了确保系统内数据的完整性，需要在微服务或数据存储之间复制关键业务数据的状态。

解决方案：

使用消息队列允许将状态异步、可靠地发送到不同的地方。

应用：

当数据发生更改时，将其作为消息，通过消息队列或者ESB发送到需要接收变更通知的任何其他微服务或数据存储。

影响：

1.增加复杂性，因为这种模式让状态以一种新的方式更改和移动。

2.不提供任何标准模式，实现可能是不一致的，除非建立并实践统一的标准。

3.对于在发生故障时如何处理数据冲突或重建状态，不提供任何具体的解决方案。

目标：

可伸缩性。

使用消息队列提供了任务处理者独立于任务生产者扩展的方法。并在这两者之间提供了具有较为可靠的支撑层。

主要特点：

1.异步通信存在低效的IPC（Inter-Process Communication，进程间通信）。

2.数据一致性和状态管理能力将变得更糟。由于行为的不可预测，重用性受到了阻碍。

3.由于与现有模式的相似性，已有的问题往往同样会出现。

4.技术上，这种模式在大规模扩容时使用良好，但在操作运维上，往往会变得不可预测。

5.由于缺乏设计标准，内聚性较差。

分层API架构上面向消息的状态管理模式如何与现有系统、SOA或API共存？

分层API架构上面向消息的状态管理模式可能是现有资产以最小的变更实现互联的最佳办法。通过使用消息在接口层解耦，您可以获得很大的灵活性和可靠性。在消息层中转换和路由消息的能力意味着数据的更改与其源头隔离，而不是发生在接口层。但同时，灵活性的增加往往伴随着可视性的缺乏，这可能需要新的管理工具和故障排除技术手段。例如，一个常见的步骤是将跟踪数据添加到消息报头中，来了解给定消息所通过的路径，以便进行故障排除和调试。

未经同意，本文禁止转载或摘编。