微服务架构的分布式事务解决方案

标签: 微服务 架构 分布 | 发表时间:2016-07-25 22:44 | 作者:小黄牛
出处:http://www.iteye.com

分布式系统架构中,分布式事务问题是一个绕不过去的挑战。而微服务架构的流行,让分布式事问题日益突出!

下面我们以电商购物支付流程中,在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析!

images/yCGMB8jPtrsxKWf5PCQBpGCeKZKhzPBb.jpg

如上图所示,假设三大参与平台(电商平台、支付平台、银行)的系统都做了分布式系统架构拆分,按上数中的流程步骤进行分析:

 

1、电商平台中创建订单:预留库存、预扣减积分、锁定优惠券,此时电商平台内各服务间会有分布式事务问题,因为此时已经要跨多个内部服务修改数据;

 

2、支付平台中创建支付订单(选银行卡支付):查询账户、查询限制规则,符合条件的就创建支付订单并跳转银行,此时不会有分布式事务问题,因为还不会跨服务改数据;

 

3、银行平台中创建交易订单:查找账户、创建交易记录、判断账户余额并扣款、增加积分、通知支付平台,此时也会有分布式事务问题(如果是服务化架构的话);

 

4、支付平台收到银行扣款结果:更改订单状态、给账户加款、给积分帐户增加积分、生成会计分录、通知电商平台等,此时也会有分布式事务问题;

 

5、电商平台收到支付平台的支付结果:更改订单状态、扣减库存、扣减积分、使用优惠券、增加消费积分等,系统内部各服务间调用也会遇到分布式事问题;

 

images/K4QcRFdKnbkT44AFFtzQYCAAX25FifDS.jpg

如上图,支付平台收到银行扣款结果后的内部处理流程:

1、支付平台的支付网关对银行通知结果进行校验,然后调用支付订单服务执行支付订单处理;

2、支付订单服务根据银行扣款结果更改支付订单状态;

3、调用资金账户服务给电商平台的商户账户加款(实际过程中可能还会有各种的成本计费;如果是余额支付,还可能是同时从用户账户扣款,给商户账户加款);

4、调用积分服务给用户积分账户增加积分;

5、调用会计服务向会计(财务)系统写进交易原始凭证生成会计分录;

6、调用通知服务将支付处理结果通知电商平台;

 

images/b387t8iM6nsBkNfbztBABaCRChTWc3Bd.jpg

如上图,把支付系统中的银行扣款成功回调处理流程提取出来,对应的分布式事务问题的代码场景:

 

/** 支付订单处理 **/

 

@Transactional(rollbackFor = Exception.class)

 

public void completeOrder() {

 

  orderDao.update();  // 订单服务本地更新订单状态

 

  accountService.update();  // 调用资金账户服务给资金帐户加款

 

  pointService.update();  // 调用积分服务给积分帐户增加积分

 

  accountingService.insert();  // 调用会计服务向会计系统写入会计原始凭证

 

  merchantNotifyService.notify();  // 调用商户通知服务向商户发送支付结果通知

}

 

本地事务控制还可行吗?

 

以上分布式事务问题,需要多种分布式事务解决方案来进行处理。

 

订单处理:本地事务

 

资金账户加款、积分账户增加积分:TCC型事务(或两阶段提交型事务),实时性要求比较高,数据必须可靠。


 

会计记账:异步确保型事务(基于可靠消息的最终一致性,可以异步,但数据绝对不能丢,而且一定要记账成功)

 

商户通知:最大努力通知型事务(按规律进行通知,不保证数据一定能通知成功,但会提供可查询操作接口进行核对)

文章出处: http://www.roncoo.com/article/detail/124243

 



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [微服务 架构 分布] 推荐:

微服务架构的分布式事务解决方案

- - 研发管理 - ITeye博客
分布式系统架构中,分布式事务问题是一个绕不过去的挑战. 而微服务架构的流行,让分布式事问题日益突出. 下面我们以电商购物支付流程中,在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析. 如上图所示,假设三大参与平台(电商平台、支付平台、银行)的系统都做了分布式系统架构拆分,按上数中的流程步骤进行分析:.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

基于支付系统场景的微服务架构的分布式事务解决方案

- - 研发管理 - ITeye博客
分布式系统架构中,分布式事务问题是一个绕不过去的挑战. 而微服务架构的流行,让分布式事问题日益突出. 下面我们以电商购物支付流程中,在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析. 如上图所示,假设三大参与平台(电商平台、支付平台、银行)的系统都做了分布式系统架构拆分,按上数中的流程步骤进行分析:.

面向服务与微服务架构

- - CSDN博客推荐文章
最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章  Microservices, 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务,和我最近几年工作的实践比较相关感觉深受启发. 本文吸收了部分原文观点,结合自身实践经验来探讨下服务架构模式的演化. 面向服务架构 SOA 思想概念的提出已不是什么新鲜事,大概在10年前就有不少相关书籍介绍过.

微服务架构实践感悟

- - mindwind
从去年初开始接触微服务架构的一些理念,然后到今年开始实施系统第四个大版本的架构升级决定采用这套架构理念. 最近关于微服务架构的讨论还是多起来,因为国外一些著名互联网公司(如:Amazon、Netflix 等)从实践中摸索出了一套新的大型系统架构方法论,并取得了成功,树立了很好的示范,然后这套方法论渐渐就被一些技术理论派 人士命名为微服务架构(Microservices).

微服务架构成功之路

- - CSDN博客推荐文章
本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2015/07/success-of-microservices. 近年来,在软件开发领域关于微服务的讨论呈现出火爆的局面,有人倾向于在系统设计与开发中采用微服务方式实现软件系统的松耦合、跨部门开发;同时,反对之声也很强烈,持反对观点的人表示微服务增加了系统维护、部署的难度,导致一些功能模块或代码无法复用,同时微服务允许使用不同的语言和框架来开发各个系统模块,这又会增加系统集成与测试的难度,而且随着系统规模的日渐增长,微服务在一定程度上也会导致系统变得越来越复杂.

微服务架构-模块迁移

- - 人月神话的BLOG
对于遗留的单体应用,要进行微服务架构的改造往往比一个全新应用基于微服务架构实现更加困难. 对于单体应用的微服务架构改造,最常见的方式仍然是将低耦合的模块逐步迁出. 下面以一个采购系统中招投标模块迁出为例进一步思考单体应用的微服务架构改造步骤. 在整个模型中我们将模型进行简化,当迁出一个功能模块进行微服务化的时候,首先要考虑的就是对该模块进行集成架构分析,考虑该模块和外围的集成情况,其次才是考虑该模块内部的私有数据.

SOA和微服务架构沟通(2.8)

- - 人月神话的BLOG
今天在广州交流SOA和微服务架构,特对关键内容做简单记录. 对于SOA和微服务架构的区别,在知乎一个回答里面我已经进行了详细的说明,即微服务架构强调的第一个重点就是 业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用. 这些小应用之间通过服务完成交互和集成.

微服务下的数据架构

- - IT瘾-dev
微服务是一个软件架构模式,对微服务的讨论大多集中在容器或其他技术是否能很好的实施微服务,而本文将从以下几个角度来和大家分享在微服务架构下进行数据设计需要关注的地方,旨在帮助大家在构建微服务架构时,提供一个从数据方面的视角:. 按照 Martin Fowler 的定义,微服务是一个软件架构模式,通过开发一系列的小型服务的方式来实现一个应用.