首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

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

内容来源: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集群的异常恢复。

如何参与到ServiceComb社区

官网:http://servicecomb.incubator.apache.org/cn/

通过订阅邮件列表参与讨论:

2、收到来自dev-help的邮件后,再回复任意内容来确认订阅邮件列表

在Apache JIRA(https://issues.apache.org/jira/browse/SCB)上提issue或查看最新的开发任务及进展

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180111A0VI6E00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券