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

标签: 系统 服务 架构 | 发表时间:2017-02-04 12:37 | 作者:小黄牛
出处:http://www.iteye.com

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

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



 

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

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

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

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

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

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

 



 

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

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

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

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

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

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

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

 



 

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

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

@Transactional(rollbackFor = Exception.class)

public void completeOrder() {

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

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

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

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

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

}

 

本地事务控制还可行吗?

 

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

 

订单处理:本地事务

 

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




 

 

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



 

 

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



 

针对上以分布式事务问题,龙果学院的 《微服务架构的分布式事务解决方案》视频教程中将提供详细完整的方案供大家学习和应用。



 

 

 

龙果支付系统(开源版)



 

开源中国地址: http://www.oschina.net/p/roncoo-pay
         http://git.oschina.net/roncoocom/roncoo-pay
GitHub地址: https://github.com/roncoo/roncoo-pay
在线支付演示: http://demo.pay.roncoo.com
后台运营管理: http://demo.pay.roncoo.com/boss 



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


ITeye推荐



相关 [系统 服务 架构] 推荐:

案例|服务化架构系统监控难题解决方案

- - 企业架构 - ITeye博客
原文网址链接:http://url.cn/kVjUVO. 众所周知,系统监控一直是拥有复杂IT架构的企业所面临的一个重要问题,而这也并不是每家企业都能够轻松解决的技术挑战. OPPO作为一家国际智能终端设备及移动互联网服务供应商,推出过多款外观精细、功能可靠的智能手机产品,其品牌知名度也一直名列前茅.

解析微服务架构(一)单块架构系统以及其面临的挑战

- - 博客园_知识库
  多年来,我们一直在技术的浪潮中乘风破浪,扬帆奋进,寻找更优秀的方法来构建IT系统,也一直在积极的学习并观察先进的公司如何以不同的架构方式构建或者优化其IT系统,来积极应对市场的变化,迅速做出响应,从而为客户提供更多的价值.   微服务架构模式(Microservice Architect Pattern)是近两年在软件架构模式领域里出现的一个新名词.

HBase 系统架构

- - 博客园_首页
HBase是Apache Hadoop的数据库,能够对大型数据提供随机、实时的读写访问. HBase的目标是存储并处理大型的数据. HBase是一个开源的,分布式的,多版本的,面向列的存储模型. 5 可在廉价PC Server搭建大规模结构化存储集群. HBase是Google BigTable的开源实现,其相互对应如下:.

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

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

日处理 20 亿数据,实时用户行为服务系统架构实践

- - IT瘾-dev
携程实时用户行为服务作为基础服务,目前普遍应用在多个场景中,比如猜你喜欢(携程的推荐系统)、动态广告、用户画像、浏览历史等等. 以猜你喜欢为例,猜你喜欢为应用内用户提供潜在选项,提高成交效率. 旅行是一项综合性的需求,用户往往需要不止一个产品. 作为一站式的旅游服务平台,跨业务线的推荐,特别是实时推荐,能实际满足用户的需求,因此在上游提供打通各业务线之间的用户行为数据有很大的必要性.

SOA面向服务架构

- - 人月神话的BLOG
今年在这点上谈的比较多,也逐步开始落地实施,将SOA咨询和实施方法论从系统间真正的引入到系统内,将面向对象的需求分析方法和SOA思想进一步融合,从业务建模到系统用例建模,从流程分析到服务识别和分析,从业务组件化到系统模块化,这些工作都逐步开始落地实施. 这样做的好处就是进一步的体现SOA可复用组件的价值,真正的做到业务组件化和组件能力化.

谈微服务架构

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

微服务与架构师

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

面向服务与微服务架构

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

Facebook 的系统架构

- Ivan - 博客园新闻频道
  来源:http://www.quora.com/What-is-Facebooks-architecture (由Micha?l Figuière回答).   根据我现有的阅读和谈话,我所理解的今天Facebook的架构如下:. Web 前端是由 PHP 写的. Facebook 的 HipHop [1] 会把PHP转成 C++并用 g++编译,这样就可以为模板和Web逻贺业务层提供高的性能.