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

181 阅读4分钟

分层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系统保持同步。

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