架构 - 微服务 - 分布式微服务下的数据一致性

微服务架构 (九): 分布式微服务下的数据一致性

我觉得这篇文章说的很好，copy下来！

微服务都拥有各自的数据库且微服务都是部署在一分布式的环境下的。所以, 微服务间要维持彼此间数据库中的数据的一致性, 便需采用:

BASE – Basic Availability, Soft State, Eventual Consistency。

分布式微服务采用 BASE, 以维持彼此间数据库中的数据的一致性, 主要的思路是: 当某一个微服务 A 改变了其自身数据库中的数据时, 因为, 微服务 A 与其他相关的微服务是分布式部署的, 也就是说, 其他的微服务并不会 (也没办法) 在与微服务 A 相同的数据库交易 (DBTransaction) 中, 知道必需针对自身的数据库, 也做出相对应的改变。

所以, 当微服务 A 改变了其自身数据库中的数据时, 其他相关的微服务, 并未能实时跟进作出相对应的改变; 此时, 整体微服务架构下的相关数据,便形成了不一致性; 我们便称这种不一致性的状态是: Soft State。

当整体微服务架构下的相关数据是 Soft State时, 便需经过一段时间; 也许是几分钟, 也许是一个晚上…等等; 整体微服务架构下的相关数据才能达到一致性。

当整体微服务架构下的相关数据是由 Soft State, 经过一段时间后, 整体微服务架构下的相关数据达到一致性, 我们便称这种一致性的状态是: Eventual Consistency。

举个例子说明下 BASE:

下表中有三个微服务。

三个微服务都同时各自拥有 Customer ID: ABC001 的客户资料。

微服务

Customer ID

customer information

ABC001

customer wish list

ABC001

customer preference

ABC001

当 customer information 微服务, 被其外部的使用者介面要求: 删去 Customer ID: ABC001 时, customer information 微服务便删去了自身数据库中的 Customer ID: ABC001 的数据。但是, customer wish list 微服务与 customer preference 微服务, 因为, 无法与 customer information 微服务同属于同一个数据库交易 (DB Transaction) 中, 所以, customer wish list 微服务与 customer preference 微服务, 并未实时跟进删除自身数据库中的 Customer ID: ABC001 的数据。

这时, 整体微服务架构下的相关数据, 便形成了如下表中的不一致性; 此时, 整体微服务架构下的相关数据的状态是: Soft State。      

微服务

Customer ID

customer information

ABC001  [已删除]

customer wish list

ABC001   [未删除]

customer preference

ABC001   [未删除]

架构师在 BASE下, 便能采取以下的四种架构设计方案, 使整体微服务架构下的相关数据从 Soft State 时, 经过一段时间后; 也许是几分钟, 也许是一个晚上…等等; 最终, 使得整体微服务架构下的相关数据, 达到一致性; Eventual Consistency。

A.      Batch Data Synchronization:

顾名思义此设计方案, 便是执行一批处理; 也许, 是在夜间执行 :

1.       删除 customer wish list 微服务的数据库中的 Customer ID:ABC001的数据。

2.       删除 customer preference 微服务的数据库中的 Customer ID:ABC001 的数据。

架构师在采用此方案时,必需先行确认: 未维持数据一致性的微服务; customer wish list 微服务与 customer preference 微服务; 是可以接受从 Soft State 到 Eventual Consistency, 需经过一段较长的时间的; 也许是一天, 或甚至是更久。

另外, 架构师在采用此方案时, 也应该清楚的知道: 此设计方案将使得各微服务间的数据库, 因为, 批处理而形成了 “藕合”。

这就代表著, 有任何一个微服务在数据库表节构上的任何的变更, 都将会造成批处理代码 (脚本) 维护上的工作量; 假如, 某一个产品拥有上百或上千个微服务时, 则批处理代码 (脚本) 维护的工作量, 往往会是一不小的负担。

B.      Periodic Async Data Synchronization:

每隔一特定的周期时间; 5分钟, 10 分钟, 一小时…等等; 执行一批处理:

1.       检查 customer information 微服务, customer wish list 微服务, customer preference 微服务, 是否有变更各自所拥有的数据库的数据; 假如, 没有变更, 便进入到下一个周期。

2.       在下一个批处理检查周期到来前, customer information 微服务, 被其外部的使用者介面要求: 删去 Customer ID: ABC001。

3.       下一个批处理检查周期到来, 批处理便执行:

            i.    删除 customer wish list 微服务的数据库中的 Customer ID:ABC001的数据。

            ii.   删除 customer preference 微服务的数据库中的 Customer ID:ABC001 的数据。

此设计方案, 虽缩短了从 Soft State 到 Eventual Consistency, 所需经过的时间, 但, 也是与 Batch Data Synchronization 有著一样的问题: 各微服务间的数据库, 因为, 批处理而形成了 “藕合”。

C.      Request-Based Data Synchronization:

当 customer information 微服务, 被其外部的使用者介面要求: 删去 Customer ID: ABC001时, customer information 微服务便删去了自身数据库中的 Customer ID: ABC001 的数据, 并同时以同步或异步远程调用的方式调用 customer wish list 微服务与 customer preference 微服务; 要求 customer wish list 微服务与 customer preference 微服务, 删除 Customer ID: ABC001。

此设计方案虽因为微服务间直接的同步或异步远程的调用, 而不存在著各微服务间数据库藕合的问题, 但是, 也存在著其他的问题:

1.       当 customer information 微服务, 删去了自身数据库中的 Customer ID: ABC001 的数据后, customer information 微服务便必需要知道, 它需同步或异步远程调用哪些的微服务? 假如, customer information 微服务少调用了一个微服务, 则将使得整体微服务的数据, 很难再维持一致性; 因为, 这样的缺陷, 有时在数百, 甚至是数千个的微服务当中, 是相当不容易被定位到的。

2.       customer wish list 微服务与customer preference 微服务, 将必需要负责处理自身数据库上的事务; 如：回退、确认是否有回传数据库处理确认的信息给 customer information 微服务…等等。这将增加 customer wish list 微服务与 customer preference 微服务在开发与测试上的复杂度。

3.       当 customer information 微服务是采用同步调用 customer wish list 微服务与 customer preference 微服务时, customer information 微服务将必需等待 customer wish list 微服务与 customer preference 微服务回传数据库处理确认的信息, 才能向其外部的使用者介面确认: Customer ID: ABC001 的数据已被成功的删除。而这将使得 customer information 微服务的外部使用者介面, 将花费时间等待; 在性能上可能会有一不好的使用者体验。

4.       customer wish list 微服务与 customer preference 微服务都有著重复的代码, 处理著自身数据库上相同的事务。

D.      Event-Based Data Synchronization:

在微服务的架构中置入 Message Queue; 如：JMS, RabbitMQ。

当 customer information 微服务, 被其外部的使用者介面要求: 删去 Customer ID: ABC001时, customer information 微服务便删去了自身数据库中的 Customer ID: ABC001 的数据, 并同时送出个事件到 Message Queue中; 宣告了customer information 微服务, 刚刚删去了CustomerID: ABC001。

而因为 customer wish list 微服务与 customer preference 微服务订阅了此事件, 所以, customer wish list 微服务与 customer preference 微服务, 便会因为此事件, 而被触发并删除了自身数据库中的 Customer ID: ABC001 的数据。

这设计方案的优点是显而易见的:

customer information 微服务、customer wish list 微服务、customer preference 微服务之间是完全解藕的; 微服务间不存在著数据库间的藕合, 微服务间也不需知道对方是谁?