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

2016.8.21, 深圳, Ken Fang

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

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 微服务之间是完全解藕的; 微服务间不存在著数据库间的藕合, 微服务间也不需知道对方是谁?

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏腾讯大数据的专栏

Hermes与开源的Solr、ElasticSearch的不同

谈到Hermes的索引技术,相信很多同学都会想到Solr、ElasticSearch。Solr、ElasticSearch真可谓是大名鼎鼎,是两个顶级项目,最...

2435
来自专栏架构师之旅

《Spring敲门砖之基础教程第一季》 第一章 概要介绍

百度百科say: Spring是一个开源框架,Spring是于2003 年兴起的一个轻量级的Java 开发框架,由Rod Johnson创建。简单来说,Spri...

1825
来自专栏cloudskyme

15个nosql数据库

1、MongoDB 介绍 MongoDB是一个基于分布式文件存储的数据库。由C++语言编写。主要解决的是海量数据的访问效率问题,为WEB应用提供可扩展的高性能数...

3306
来自专栏张善友的专栏

VS2010测试方面的文章

      VS 2010 带来了更多崭新的功能,这些新功能贯穿了整个测试周期 : 测试计划、测试执行和测试执行进度跟踪,VS 2010 引入了一个全新的工具,...

17010
来自专栏前端架构

透析SOA、RPC、SOAP、REST、ICE、ESB模型发展史

最初的程序全是单机程序,没有网络,没有RPC,更没有RESTful。程序猿写的东西孤独运行在单机上。

822
来自专栏即时通讯技术

脑残式网络编程入门(六):什么是公网IP和内网IP?NAT转换又是什么鬼?

搞网络通信应用开发的程序员,可能会经常听到外网IP(即互联网IP地址)和内网IP(即局域网IP地址),但他们的区别是什么?又有什么关系呢?另外,内行都知道,提到...

370
来自专栏blackheart的专栏

[信息安全] 2.密码工具箱(续)

在上一篇1.密码工具箱中介绍了一些密码技术相关的一些基本工具,同时遗留了一个鸡生蛋蛋生鸡的问题和公钥的认证问题( ̄▽ ̄)",这里再补充几个常用的工具先。 1. ...

19310
来自专栏圣杰的专栏

性能优化知多少

1. 引言 最近一段时间,系统新版本要发布,在beta客户测试期间,暴露了很多问题,除了一些业务和异常问题外,其他都集中在性能上。有幸接触到这些性能调优的机会,...

1849
来自专栏FreeBuf

英特尔AMT功能远程提权高危漏洞分析

本周早些时候,英特尔发布了一个高危提权漏洞,影响的范围包括过去7年英特尔服务器芯片的远程管理功能。远程攻击者可以利用漏洞控制存在PC、笔记本电脑和服务器。 这款...

1828
来自专栏Java架构沉思录

谈谈高并发之限流特技

大流量,我们很可能会冒出:TPS(每秒事务量),QPS(每秒请求量),1W+,5W+,10W+,100W+...。其实并没有一个绝对的数字,如果这个量造成了系统...

1052

扫码关注云+社区