和平统一-微服务场景下的数据一致性解决方案

举报
无微不至 发表于 2018/06/06 09:28:48 2018/06/06
【摘要】 2017年12月21日,华为微服务架构师殷湘在“华为ServiceComb在线直播”进行《和平统一-微服务场景下的数据一致性解决方案》演讲分享

内容来源:2017年12月21日,华为微服务架构师殷湘在“华为ServiceComb在线直播”进行《和平统一-微服务场景下的数据一致性解决方案》演分享。IT 大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。

阅读字数:1971 | 4分钟阅读


摘要

华为微服务架构师殷湘从“离合断”三个方面归纳总结了微服务场景下的数据一致性解决方案。


离——数据一致性的起因单体应用

在单体应用所有模块(A/B/C)使用同一个数据库,如果要同时修这三个模块的数据,它的一致性是通过数据库来保证的。

如果三个模块的数据都写入成功,那么这个事务就成功了。假如有一个失败,数据库则会帮我们做一个rollback。

微服务场景

微服务要做到四个“独立”,独立进程、独立部署、独立技术和独立团队。


独立进程是指微服务可能在不同的进程中运行,也就是说微服务之间可能是处于不同的网段。


独立技术就是说每个微服务使用的数据库可能是不同的技术,比如第一个微服务使用的是MySQL,第二个是MongoDB,第三个可能是Cassandra。


因为网络的隔离和独立技术,所以我们没有办法通过数据库来保证数据一致性。


合——数据一致性的解决方案Soga

我们用的Saga是基于1987年Hector 和 Kenneth发表的一篇论文。Saga代表的是一个Long Live Transaction。Hector 和 Kenneth认为一个长活事务可以将它分成N个子事务,每一个子事务对应的都是一个本地事务。每个本地事务Tx我们会提供对应的补偿Cx,这样的话从T1到Tn,都有对应的补偿C1到Cn。如果长活事务执行正常的话,那么T1到Tn都是正常执行;假如其中有一个执行异常,就需要对前面已经完成的事务予以补偿。


目前已知使用Saga的厂商有Microsoft、Twitter和Uber。


Saga是一个最终一致的一段式方案。在收到请求的时候,会直接对A/B/C三个服务发起事务的请求,A/B/C三个服务会分别执行请求并返回。

2 2 2

我们的Saga实现可以归纳为三个数字:2 2 2。即两种恢复策略,两个特点,以及两种运行模式。


两种恢复策略是指向前恢复和向后恢复。两个特点是和平、统一。以及两种运行模式,图遍历和Akka Actor异步模型。

恢复策略

向前恢复:重试N次直到成功或采取回退措施。

向后恢复:补偿策略。如果这种情况下B失败了,就对已经完成的两个服务进行补偿。

和平统一

和平:低侵入。减少业务代码集成,降低运维难度,剥离业务与数据一致性复杂度。


统一:集中式。让运维监控更加简单。利用集中式的方法,可以对长事务所有的子事务进行监控,可视化事务的拓补关系和调用链。通过调用链可以知道在哪个部分性能最差。


高可用:Saga本身无状态,可集群,可分片。Saga基于Event Sourcing架构,每一个事务都会通过事件的方式记录下来。

运行模式

要求

现在的Saga实现对业务系统有两个要求。第一个是事务接口幂等,如果服务多次收到同样的请求,则认为是同一个操作,不会有任何额外的影响。因为我们是一个分布式的环境,Saga可能先发起一个子事务的请求T,由于通过网络发送,T可能会超时,超时后Saga进行重试请求T’。如果T’成功了,而T因为网络阻塞,在很久以后才会被业务服务A收到。假如这时业务服务A不满足幂等的要求,就会导致处理出现问题。


另一个要求是可交换。当遇到事务请求T超时的情况时,第二次发送请求T’的时候,可能由于其它服务的事务失败了触发补偿。这时Saga会对服务A发起补偿操作。不幸的是可能在补偿结束后,那个超时的事务请求T才会被服务A收到。


这两个要求的应对方法就是给事务的记录加一个状态,标记为已删除的状态,而不是真正从数据库中把那些记录删掉。


断——一致性方案的选择建议一致性方案的选择建议

内刚:在微服务内,聚合要通过数据库事务保证强一致。


外柔:而在微服务间,要保证最终一致性。

微服务架构与领域驱动设计

《微服务设计》这本书提出,领域驱动设计是微服务系统架构的最佳指南。微服务和领域驱动设计中限界上下文的概念是一一对应的。

聚合与数据一致性

《实现领域驱动设计》这本书提出的两个原则,聚合内要实现强一致,跨聚合只需要最终一致。由此可得,聚合的边界其实就是强一致的边界。

一致性方案选择建议

微服务和限界上下文有一一对应的关系,聚合的边界和强一致边界也有一一对应的关系。


而一个限界上下文对应一个或多个聚合。由此可得,微服务内部的聚合应通过数据库事务保证强一致,微服务间只需要最终一致。如果需要分布式强一致,首先考虑设计是否合理而非追求最新技术,合理的设计能大大减少技术复杂度和商业成本。

总结

数据一致性的起因是“离”,也就是因为进程通过网络分离,以及数据库的技术不一致。我们的方案是Saga,总结为 2 2 2,一致性方案选择建议是“内刚外柔”。


未来的开发计划

SAGA开发当前主要聚焦在易用性上,具体的设计可以在邮件列表上查询到相关的Proposal(https://lists.apache.org/thread.html/dcd7cd6d238d211d09f6f90e447656bec38c2179e5f8f3ba0d76cbf0@%3Cdev.servicecomb.apache.org%3E),欢迎热心的伙伴们参与Proposal的讨论,有兴趣参与社区贡献的人也可以自行认领JIRA上的相关任务,


SCB-24:做可视化事务拓扑,定位异常最多的服务。


SCB-163:使用bytecode instrumentation实现异步事务支持。


SCB-164:事务一致性方案alpha集群的异常恢复。



立即体验:https://console.huaweicloud.com/cse/?region=cn-north-1#/cse/home

 

了解详情:https://www.huaweicloud.com/product/cse.html


【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。