微服务下的数据一致性思考

标签: | 发表时间:2017-07-20 00:52 | 作者:
出处:https://mp.weixin.qq.com

之前讲到了数据库层缓存层的改造思路,而对于业务层的改造,采用了集中式服务转微服务的架构方案。既然是微服务,就意味着面临大量的服务间的内部调用及服务依赖,这就意味着,如果一次请求的调用涉及到两个或多个微服务之间的调用,恰好有下游的微服务调用失败,我们就必须要考虑到回滚及服务间保证数据一致性的问题。所以,今天我将列出可能出现的失败情况及对应的解决方案,希望对大家正在做微服务改造的团队有所帮助。

首先,我们对微服务间调用做一个分类:

  1. 服务间没有直接依赖,采用异步化调用,上游服务完成后,发一个消息异步通知下游服务,下游服务成功与否对上游服务没有影响。

  2. 上游服务弱依赖于某个下游服务的处理结果,可降级。降级时可以不返回这部分的数据。同步调用降级时转为异步。

  3.  上下游微服务强依赖,上游服务依赖于下游服务的返回或者回调,下游必须正常执行,如果下游服务失败了,本次请求判定为失败。

    

        服务间纯异步调用,需保证幂等性和队列重试机制

        对于Case1, 只需要考虑2点:幂等性和消息队列重试机制,幂等性意味着,重复消息不会对下游服务的结果产生任何影响;消息队列重试机制保证了,消息本身不会出现丢失,即便消息队列在发给下游队列前挂掉了,重启后,能继续发送对应的消息。



       上下游同步执行失败,通过消息执行异步调用

        对于Case2, 采用的方案如下图所示,主服务依赖于A,B,C 三个下游服务,同步调用过程中,服务C调用失败。由于服务C不是强依赖,我们便可以给消息队列发送一条消息,保证主服务可以正常返回,同时保证服务C能继续被执行,保证数据的一致性。

        





    采用TCC进行提交与回滚,保证数据的一致性

    Case3是服务间调用最严格的情况,意味着如果下游服务中有一个服务调用失败,上下游的所有服务必须回滚。意味着服务间必须保证同一个事务。业界公认的一个解决方案就是 TCC (Try-Confirm-Cancel) 模式:

  1. 主业务服务分别调用下游业务执行try操作,并在活动管理器中登记所有下游服务。当所有下游微服务的try操作都调用成功,或者某个下游微业务服务的try操作失败。

  2. 业务活动管理器根据第1步的执行结果来执行confirm或cancel操作。如果之前所有try操作都成功,则活动管理器调用所有下游微业务,执行confirm操作。否则调用所有下游微服务的cancel操作。

  3. 如果第2步,执行confirm或concel操作出现失败,活动管理器会启动重试机制,保证所有微服务最终提交或者回滚操作成功。

    



小结



上文对微服务间调用的3种情况的数据一致性方案做了说明:

1. 确保接口幂等性,消息队列具备重试机制,实际上几乎现在所有的MQ都支持重试。

2. 服务调用同步转异步,确保上游服务成功执行,并保证服务间的数据一致性。

3. 利用TCC方案解决服务间调用强依赖的数据一致性。



 扫描二维码或手动搜索微信公众号: ForestNotes

欢迎转载,带上以下二维码即可

    



相关 [服务 数据 思考] 推荐:

微服务下的数据一致性思考

- -
之前讲到了数据库层和缓存层的改造思路,而对于业务层的改造,采用了集中式服务转微服务的架构方案. 既然是微服务,就意味着面临大量的服务间的内部调用及服务依赖,这就意味着,如果一次请求的调用涉及到两个或多个微服务之间的调用,恰好有下游的微服务调用失败,我们就必须要考虑到回滚及服务间保证数据一致性的问题.

移动问答服务思考

- Ehaagwlke - 所有文章 - UCD大社区
    社会化问答服务现在很火,国外的Quora、Stackexchange系列站点,以及国内Quora山寨版本的知乎都受到了大家的追捧. 以StackOverflow为例,在Google搜索技术相关的问题,StackOverflow上的回答经常处于Google搜索结果的第一位,回答的质量颇高.     如果说Yahoo Answer、百度知道这类早期的问答服务为问答服务的1.0版本的话,Quora、StackOverflow这样的问答服务可以称之为问答服务的2.0版本,相对于1.0版本的问答服务的最大区别为其社会化属性.

[服务器架构]微服务的深入思考

- - CSDN博客推荐文章
微服务有且仅有一种非常专项的功能,通过远程API来提供系统其余功能. 举个例子:试想一下仓库的管理系统,这样的系统中微服务可能提供的一些功能有: . 计算新的库存该存到什么地方. 计算在仓库内将库存运往正确放置点的路线. 计算仓库内指定一组订单的拣货路线. 以上这些功能(可能还会有更多)都是由单个微服务实现的.

对数据库架构的再思考

- - 人月神话的BLOG
前面在谈PaaS的时候曾经谈到过共享数据库,私有数据库的问题,在这里再谈谈在多业务系统建设过程中的数据架构模式问题. 首先来看下传统的数据交换解决方案如下图:. 业务场景为单独构建的四个业务系统,在四个业务系统中SID数据为需要跨四个应用交互和共享的数据. 传统的做法则是对四个应用存在的SID库数据进行数据集成和交换,则后续的每一个业务系统中都有全部的共享基础数据,任何一个应用的SID库数据需要通过数据交换和集成同步四份.

正祥的淘宝海量数据库思考分享

- alex zhao - 淘宝核心系统团队博客
正祥(阳振坤老师)最近在个人新浪博客上发表了一系列针对淘宝分布式数据服务系统思考性文章,特此分享. 淘宝海量数据库之一:来自业务的挑战. 淘宝海量数据库之二:一致性选择. 淘宝海量数据库之三:事务的ACID. 淘宝海量数据库之四:系统架构与跨表事务. 淘宝海量数据库之五:数据结构.

数据库设计之外键的思考

- - CSDN博客数据库推荐文章
    关于是否使用外键在业界也没有统一的标准,大家争论的焦点是数据一致性和性能上.     支持使用外键方,强调如果不使用外键,数据一致性无法保证,性能消耗可以忽略.     反对使用外键方,数据一致性可以通过程序保证,性能有大问题,数据维护很麻烦,如果是大系统,整个外键的关系就像编制的一张大网.

高速数据同步服务器——Doozer

- Tim - Some reminiscences, some memories
昨天在讨论平台新架构的时候,还在说要搞个配置管理的服务出来,方便接口的管理. 然后今天就看到了这个……人品爆发了吗. 好吧,不扯淡,直接翻译 Doozer 的 README 吧. Doozer 我还没实测,不过感觉,如果真得像 README 上面说得那样,还是很有用,很有用的. 关键——这个玩意提供了 go 的接口.

数据服务简介-转载

- - 人月神话的BLOG
原文: http://www.infoq.com/cn/articles/narayanan-soa-data-services?utm_source=bshare&utm_campaign=bshare&utm_medium=sinaminiblog&bsh_bid=148096884.

数据交换和SOA服务共享

- - 人月神话的BLOG
数据本身只是一种资源,而服务是一种能力;数据仅限于各种结构化和非结构化的数据资源,对于数据资源提供的能力可以使一种数据服务,而数据资源+业务规则形成的某种业务能力也可以作为一种服务提供,也就是说各种技术,数据,业务,平台,流程能力都可以做为服务提供. 交换本质是资源会从一个系统通过传输的方式进入到多个系统,资源在多个系统中形成多种拷贝.

微服务架构--服务框架,metrics 和调用链数据

- - 行业应用 - ITeye博客
微服务化以后,为了让业务开发人员专注于业. 务逻辑实现,避免冗余和重复劳动,规范研发. 提升效率,必然要将一些公共关注点推到框架. 服务框架 ( 图 9) 主要封装公共关注点. 服务注册、发现、负载均衡和健康检查,. 假定采用进程内 LB 方案,那么服务自注. 册一般统一做在服务器端框架中,健康检.