异构系统分布式事务、安全、性能

 

现有一项目，业务场景如下：

 

 









用户通过手机发送支付请求到运营平台，运营平台通过解析请求内容，知道手机用户希望向vb开发的应用系统支付200元。此时运营平台首先会查询支付平台，该手机用户是否有足够的钱支付，如果有，则通过支付平台扣除手机用户200元，并转入到位VB应用对应帐户，支付平台支付成功后，返回信息给运营平台，运营平台会向VB应用系统发送信息XX用户通过支付平台向你支付了200元。如果运营平台在查询手机用户在支付平台的钱不够，会向银行系统发送请求，希望银行系统能从手机用户银行帐户中转帐到支付平台或者VB应用的帐户上。

在这样的一次支付过程中，手机应用、运营平台，VB应用、支付平台、银行系统会可能涉及，怎样才能做到以下几点：

一、性能。因为一个业务请求中可能在几个应用中进行数据交互，怎样提高数据的交互速度，从而提高手机客户的体验。

二、安全。因为整个应用核心就是钱的转移，安全是最重要的。

三、分布式事务。这是整个系统中最难的部分，怎样做到用户的一个支付行为，无论那个节点发生问题，所有相关的应用中数据是一致的。



各位大牛能停下来，发发你们的想法或者失败的经验。谢谢。。。

 

评论

18 楼 imlsq 2009-11-13  

你的问题，楼上 “凤舞凰扬”已经给与不错的回答了

对于这么多异构系统来说，如果要做成一个事务内控制，基本不可能实现。

1 性能：各位已经说得非常不错，如果需要有快速响应，就只能异步了。如果是同步的话，速度会很慢，对前端的web app带来很大的压力。
如果能够异步的话，最好采用异步消息机制，比如JMS之内的，速度非常快，稳定可靠

2 安全：关于安全的问题，目前有非常成熟标准的东西了，无论是jdk自带的api，还是其他第三方开源产品都非常成熟。但是无非离不了 DES加密，RSA签名...等算法。 自己调用JDK自动的lib已经可以做到非常安全。

3 事务： 这么多异构系统，不太可能做到同步事务，只能是采用 “补偿” 机制来实现。最简单的方法，就是 类似银行的 当日对账 ，比如可以采用一台服务器每隔几十秒提取各子系统的交易记录进行比对，根据业务逻辑判断是否完整，如果是异常，再进行相应的补偿操作。

17 楼 zhxp791008 2009-11-12  

凤舞凰扬 写道

   楼主有个很大的误区，也就是想在不同的系统间实现所谓的分布式事务。除非有底层的事务服务支持，比如ORB事务，否则的话是不可能实现的。
   那么我们又如何在实际的业务应用场景中来实现这样的情况呢？其实有个很清楚的概念，补偿事务。准确讲补偿事务并不是我们传统意义上的事务，而是通过补偿性行为来实现事务的原子特性。
    在楼主提出的应用场景中，有两个问题很关键，一个是事务锁实现，这个锁其实也就是一种预扣，避免查询与购买时费用合适，而付款时却出现费用被另外的交易处理而出现不够的失败情况。另外一个就是补偿性事务处理机制，也就是在事务处理失败后的恢复机制，因为涉及银行系统（银行系统有基础性事务支持），所以必须想清楚如何处理补偿。

谢谢回复！
以前就是想是不是有种在异构系统中以普通的xa协议方式实现分布式事务的可能性。
现在看来，没有传统方式实现的可能性，只有在应用层设计上考虑才可能达到数据的一致性。
如消息中间件等做。
好象tuxedo专门做这个的。

16 楼 凤舞凰扬 2009-11-11  

   楼主有个很大的误区，也就是想在不同的系统间实现所谓的分布式事务。除非有底层的事务服务支持，比如ORB事务，否则的话是不可能实现的。
   那么我们又如何在实际的业务应用场景中来实现这样的情况呢？其实有个很清楚的概念，补偿事务。准确讲补偿事务并不是我们传统意义上的事务，而是通过补偿性行为来实现事务的原子特性。
    在楼主提出的应用场景中，有两个问题很关键，一个是事务锁实现，这个锁其实也就是一种预扣，避免查询与购买时费用合适，而付款时却出现费用被另外的交易处理而出现不够的失败情况。另外一个就是补偿性事务处理机制，也就是在事务处理失败后的恢复机制，因为涉及银行系统（银行系统有基础性事务支持），所以必须想清楚如何处理补偿。

15 楼 lixjluck 2009-11-11  

可以参考 《程立：面向生产环境的SOA系统设计》里面的一些设计原则
对于这些异构系统，使用事务是个不可能的任务，只要最终达到一致性即可。

14 楼 cn_arthurs 2009-11-10  

zhxp791008 写道

总结下：
性能依靠异步机制实现，达到快速响应。
分布式事务基本上采用应用设计层面来达到事务的最终同步。中间状态不一致，通过应用层设计来达到最终的事务一致。

还有没有更好的设计，主要是事务。。

我认为对于事务的处理，应该由支付平台来做处理，运营平台最好是发起WEB SERVICE请求，支付平台如果在运行过程中如果出错的话，可以执行一个冲正流程，根据这笔订单的流水号，进行回滚操作
运营平台只接收平台返回的消息

如果平台不能提供复杂业务流程，那只能在运营平台与其他各平台之间专门增加一个业务层
或者如果条件允许的话，我感觉还是采用比较专业的EAI工具（如：TIBCO）来做更合适

13 楼 zhxp791008 2009-11-10  

总结下：
性能依靠异步机制实现，达到快速响应。
分布式事务基本上采用应用设计层面来达到事务的最终同步。中间状态不一致，通过应用层设计来达到最终的事务一致。

还有没有更好的设计，主要是事务。。

12 楼 prowl 2009-11-10  

helian 写道

楼上专业。

比较要注意的是不要向银行重发请求，可能会造成扣款多次。可能的状况是请求发出去了，自己的数据库更新前应用挂了。下次系统起来可能认为这笔请求还没发，再发一次。

支付平台和银行的接口有不同的地方，但是流水号作为唯一标示，是不会出现重复缴费的情况。其实在我之前描述的银行端日志记录又可细分为两种，在生成流水号记一次，缴费成功或失败，更新刚才的那条记录，作为缴费日志。同时，还有一张表来记录接口调用情况，记录出入参成功与否等，作为调用日志。这样基本就可以确保不会出现重发缴费请求，流水对不上，系统崩溃造成的异常等等

11 楼 helian 2009-11-10  

楼上专业。

比较要注意的是不要向银行重发请求，可能会造成扣款多次。可能的状况是请求发出去了，自己的数据库更新前应用挂了。下次系统起来可能认为这笔请求还没发，再发一次。

10 楼 prowl 2009-11-10  

zhxp791008 写道

整个应用最难的就是事务，如果银行、支付平台、运营平台数据不一致的话，我想这用户可能是无法接受的。

其实这是一个三方的对账，原来做的一个项目里有遇到。但是不是你所说的这三方（银行，支付平台，运营平台），而是用户，银行，SP。

从钱的角度来分析，用户和银行实际上可以看成一体，因为用户手里的钱最直接的体现就是银行账户上的数字。来看看会出几种情况：

1.用户钱被银行扣了，SP钱没有增加（可能是SP内部系统异常）。
2.用户钱被银行扣了，SP钱增加。（正常）
3.用户钱没有扣，SP钱没有增加。（正常）
4.用户钱没有扣，SP钱增加。（这种情况基本不存在）

一般来说，无论是支付平台还是银行的接口（WS,HTTP）内部都有很完善的事务系统，你都不需要关心，你关心的就是发的请求和响应，钱是否扣得成功。其次，在执行本身SP支付系统之前都会检查银行返回的是否成功（这就是为什么第四种情况不存在）。成功，调用本地支付接口，如果调用失败，会产生第一种情况。

我们采取的解决办法：

1.银行及支付平台接口调用，记录详细日志（包括时间，流水，钱，返回串等）。
2.本地支付系统客户端调用日志。
3.本地支付系统服务端执行日志。

日志系统通过事先约定的协议对账，达到平帐。

9 楼 helian 2009-11-10  

异步肯定是必然的,同步就见了鬼了.楼主的系统不说.单是银行内转笔钱就可能去人行转了一圈才回来.

8 楼 ywlqi 2009-11-10  

接口的两端两两保证数据一致，从而保证整个流程下来数据一致，不知道行不行？

另外数据不要求实时吧？比如新进了一笔钱，允许过一段时间才能查到记录。这样可以用缓存或临时表啥的来提高性能

没做过跟钱相关的系统，胡言乱语的，希望大虾指正。

7 楼 tibetjungle 2009-11-10  

zhxp791008 写道

整个应用最难的就是事务，如果银行、支付平台、运营平台数据不一致的话，我想这用户可能是无法接受的。

　　保持数据的一致性是目的，使用事务是其中的一种手段。涉及金额的数据不一致，无论问题出在哪一方都无法接受。如我上面所说，可以考虑使用异步的方式。

6 楼 tibetjungle 2009-11-10  

　　从用户扣费的时效要求有多高？如果不高，可以考虑用异步的方式，模仿企业向银行送盘的方式从移动运营商或者银行扣款。这既可提升用户的体验，还可以避开使用全局事务带来的一系列恐怖问题。
　　另外，异常总是不可避免的，要考虑到扣款成功，但被告知失败（反之亦然）的处理方案。这种事故发生的几率很小，但不可不考虑。

5 楼 zhxp791008 2009-11-10  

整个应用最难的就是事务，如果银行、支付平台、运营平台数据不一致的话，我想这用户可能是无法接受的。

4 楼 wufisher 2009-11-10  

得SOA吧，用些产品容易些

3 楼 helian 2009-11-10  

跟银行和支付平台的接口基本上不是你能决定的吧。如果是JMS的还有可能跟你的java平台统一事物。如果是文件什么的不能控制分布式事务的方式就本着宁可漏发，不要重发的原则做吧。

2 楼 魔力猫咪 2009-11-09  

速度方面可以尝试使用MQ，用异步处理以提高用户体验。告知其已经提交，处理完发短信确认就是。
安全一般使用证书加密验证。
事务方面最麻烦。分布式系统的事务恐怕只能通过BASE和CAP策略解决。不过如何实现这两种策略我不清楚。

1 楼 helian 2009-11-09  

1. 业务处理速度基本取决于银行和支付系统，你再快也没用
2. 各环节都加密吧
3. 全局事务就别想了，那素不可能的。就算勉强实现了，也会慢得要死。