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

分层API架构中隔离状态

除了合并微服务架构的数据交换模式(例如，合并为事件)之外，还有一种获得一致性的方法是合并每个微服务的内部一致性。相比较于期望通过数据交换获得一致性，不如期望查询时数据的一致性。

通常，这是通过隔离状态来实现的，换句话说，“每个微服务都包含它自己的状态”。在这种隔离状态模式中，每个微服务都包含一个内部数据存储，它不断地与外部存储（无论是事件日志还是企业资产）进行协调，使内部存储成为“单一真实源”。实际上，这可能是很困难的，因为单一真实源的模式往往反映了主数据管理的复杂性及其相关挑战。

相比而言，使用外部存储作为微服务的单一真实源要实际得多，因为给定微服务通常具有单一用途的特性。例如，隔离客户的状态很困难，但是隔离客户电子邮箱地址的状态并不困难。因此，隔离状态模式必须支持非常细粒度的微服务才能成功。并且，隔离状态模式往往还需要异步事件传播，将状态更改从一个点传递到另个一点。隔离状态模式也可以看作是某种“分布式数据库”，对于传统的RDBMS设计来说，每个微服务几乎都代表一列数据。

微服务包含一个数据存储，它是微服务所代表的实体的真实源。例如，“产品”微服务可以包含一个MySQL数据库，该数据库包含有关产品的所有信息，并且是查询或更新“产品”概念的唯一方法。

与接近于SOA的模式不同，重用性在隔离状态模式设计中并不是优先考虑的问题。当然，该模式中每个微服务都有一个“用途”，并经常在不同的场景中被访问。但是每个微服务的设计并没有考虑到重用性。如果发生了重用，那将是偶然的，而不是SOA架构设计附带的意图。

问题：

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

解决方案：

为每个给定的业务实体指定一个代表单一真实源的微服务，并将状态封装在微服务中。

应用：

微服务包含一个数据存储，它是微服务所代表的实体的真实源。例如，“产品”微服务可以包含一个MySQL数据库，该数据库包含有关产品的所有信息，并且是查询或更新“产品”概念的唯一方法。

影响：

1.为了确保状态数据不被复制或其他方式访问，隔离状态模式需要某种治理。

2.在处理现有资产（如ERP）时，必须使用“扼杀”模式，用新的微服务架构逐个替换现有系统的数据存储。

3.隔离状态模式回避了数据同步的问题，所以如果数据实体不同步，就无法轻松回退。

目标：

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

2.可伸缩性：隔离状态模式的架构具有很强的可伸缩性（每个小组件都可以实现自己的伸缩模型）。

3.更改速度：由于架构的强内聚性，隔离状态模式具有快速的更改速度，但是需要治理来确保该架构不会被破坏。

主要特点：

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

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

3.这种模式只有单一的真实源，所以数据一致性很好。

4.可伸缩性可能会带来挑战，因为同时需要扩展数据存储。

5.在规模上，很难将数据模型划分为完全独立的模块。在某些阶段，视图之间的一致性变得非常重要。

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

无法共存。如果您构建一个具有隔离状态的微服务架构，那么对于前面讲过的目标来说，微服务是“真实数据和功能的来源”是很重要的。如果现有系统也处理相同的数据或功能，您将需要在边界之外同步它，在这里实现双向同步通常是一个糟糕的模式。

隔离状态模式通常与“扼杀”模式很好地结合在一起，在“扼杀”模式中，您试图减少对给定企业应用程序或其他系统的使用，因为这些应用程序或系统没有给您足够的时间来评估所需的价值。随着时间的推移，您将用这些隔离的微服务替换原始系统中的功能，并停用原始系统中的那些特定功能。

换句话说，这不是集成模式。这里的目标是使用微服务创建一个新的、快速移动的部分实现，这将使您获得现有系统无法提供的速度和规模优势。

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

转载于:https://my.oschina.net/u/4102084/blog/3094636