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

分层API架构中的状态复制（事件源）

本质上，状态复制模式是用来解决状态隔离模式产生的问题；具体来说，状态复制模式跟状态隔离模式一样，也需要数据的一致性。举个简单的例子，假设有一个包含目录、价格和货币三个模块的微服务架构，如果该架构中的每一个模块都包含各自事件的隔离状态，那目录、价格和货币就会变得相互依赖。这也就意味着，架构中目录、价格和货币的任何一个出现故障或者更改，都会导致另一个功能的失败。

上面所讲的模块间相互依赖的问题是可以通过复制状态来解决的；换句话说，提供一个单独的位置来存储所有状态变化，每个独立的微服务都可以根据这些变化来重建其内部状态。通常情况下，状态复制与事件源的代码共存，基于事件驱动的微服务仅通过一个不可变的事件日志进行通信——这提供了一个独立且单一的状态数据源，数据一致但难以查询，因此完成了事件日志的 “物化视图”工作。

状态复制模式的设计，本质上是为了实现最终一致性。虽然在传统的事务设计中，最终一致性似乎是一个问题，但是通过深入了解设计的本质是可以改进这个问题的。比如，人们可能认为银行账户的借记是固有的交易，但大多数现代银行已经意识到，与其花费精力确保每一笔交易都是一致的，还不如创建一个最终一致的借记（如果账户存在则借记，然后确保产生资金不可用的可能时的正确性）。这代表了对IT系统的一种新的思考方式，但它能够带来更大的灵活度和更改速度，从而加快价值实现的速度。

当然，状态复制模式具有一定的挑战性。它需要对其管理的状态以及每个微服务的行为有深入的了解，以便能够预测。然而，状态复制模式也直接解决了在其他模式中产生的问题，因此，这种模式可以看作是一个非常具体的权衡。这种模式能够带来最终一致性（而不是直接的）、自上而下设计的内聚性和可预测的更改速度。

问题：

当存在多个状态数据源时，很难实现数据的完整性。

解决方案：

对数据的所有更改保持单一的数据源，并根据需要复制数据。

应用：

1.将所有的状态更改作为事件发送到永久事件日志。当需要查询数据时，通过计算事件日志中的所有更改来构建物化视图。

2.通常，事件日志的计算是通过沿着视图创建快照来简化的，这样就不需要每次都进行完整的重新计算。

影响：

1.状态复制模式具备强内聚性。

2.由于设计中固有的命令-查询请求分离原则，复制状态模式具有很强的可伸缩性。

3.状态复制模式很难可视化和理解其逻辑依赖性（物理依赖性已明显减少）。

目标：

1.内聚性：由于其标准化的特性，复制状态模式的架构非常容易使用和理解。

2.可伸缩性：具有很强的可伸缩性。

3.更改速度：非常快速。

主要特点：

1.异步通信机制将带来高效的IPC（Inter-Process Communication，进程间通信）。

2.这种模式的设计非常灵活，所以具有非常快速的更改速度。

3.数据的一致性很好，但是有一个单一的真实源（通常是事件日志）。

4.很强的可伸缩性；这种模式的设计优先考虑独立扩展每个部件的能力。

5.自主性非常高，但同时带来了非常复杂的设计。

复制状态模式如何与现有系统、SOA或API共存？

与状态隔离模式不同，状态复制模式只需要一个关键的更改，就可以很好地与现有的IT系统共存：这种模式中的事件日志必须成为它所包含的任何内容的唯一真实源。这意味着，只要现有的IT系统和API在更新事件日志的同时并从中更新，它们就可以继续使用。

状态复制模式还可以以一种“扼杀”的方式来使用：通过将事件逐个迁移到这种模式，为服务获得更改速度和高伸缩能力。如果你愿意的话，这将用一个稳定的方式逐步替换现有的实现，并与现有的IT系统保持同步。

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