如果大家关注SOA的事务一致性的处理，那么不妨看看我们是怎么解决的 - 第2页 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

我们的模型和事务模型还是有较大不同的。事务模型的目标是确保当某个步骤失败时，所有变动恢复原样。我们的模型有一半类似这个机制，但另一半则相反，尽管某个时刻某个步骤没有成功，但我们还是试图让业务最终能够做成功，这是事务模型办不到的。实际业务环境中，后者可能更有效，你想，一个操作员费了很大劲，输入了很多数据，然后点了确定按钮，但你的程序处理过程中某一步有问题过不去，你就因此全部回滚，并告诉操作员交易失败，操作员一定很不爽。前台应用做的不好话，操作员还得再输一遍数据，那他恐怕就会有点烦了。
efscao 发表于 2012-2-6 10:13

我们的模型和事务模型还是有较大不同的。事务模型的目标是确保当某个步骤失败时，所有变动恢复原样。我们的 ...
我只关心最终需要手工处理的交易量在全部交易量中的比例是多少？
家住海淀 发表于 2012-2-6 09:41

手动继续尝试处理或撤消处理
还是需要手工核查？这个工作量吃得消吗？纵然分类，是不是没有问题的也得看 ...
呵呵，是我没讲清楚，但这毕竟是一个大家以前从未设想过的新模型，解释和理解都要费点劲
再抄点东西给大家分享一下，欢迎拍砖啊
Service Center的一致性保障机制
Service Center为集成型服务应用提供了完备的一致性保障机制，这一重要特征使其非常适合被用作新产品服务和大前置等集成服务类应用系统的应用平台。Service Center的一致性保障机制分为“自动撤消处理”和“手动继续尝试处理或撤消处理”两种模式（简称自动处理模式和手动处理模式）。所谓自动处理模式——也是当前金融行业已经运用的一些集成服务应用平台和框架所普遍采用的模式——就是在集成型服务应用的处理过程中，如果有一个步骤没有成功，则向访问者返回失败，并由应用框架自动发起先前已经被该应用成功调用的服务的撤消处理。
需要注意的是，自动处理模式难以应对某些一致性问题。设想这样一个场景：客户带着现金来银行购买基金，柜台系统访问的代销基金集成服务应用一般要先调用本行帐务系统的服务以登记现金的收取，成功后调用基金公司的购买基金服务，再成功后向柜台系统返回“交易成功”，由柜员收讫现金。如果规定时间内没有收到基金公司应答（一个结果不确定的步骤），我们能够使用自动处理模式解决问题么？如果我们把这种未收到应答的情形当作失败步骤并启动自动撤消处理，结果很可能就是客户既买到了基金，同时柜员又告知客户交易失败，向客户退还了现金！当然，有些银行采取这样的做法：即便未收到基金公司的应答，也当做成功步骤继续处理。这就可能造成基金没有买到而客户现金却被收取，客户必然要投诉，而问题解决起来可能相当繁琐（在试图解决问题的时候基金价格很可能已经发生变动，或者已经销售完）。
有些开发人员发现了这种问题，他们一般采用以下两种方式来处理：
1、        分解处理方式。在上述情形发生时，向柜台系统返回“没有收到基金公司应答”，根据操作说明，柜员需要立即查询基金公司的处理结果，如果成功，则收讫现金，如果不成功，则进行一致性处理——撤消本行帐务系统的现金收取登记，或者单独调用基金公司的购买基金服务。
2、        整体处理方式。在上述情形发生时，向柜台系统返回“没有收到基金公司应答，请选择继续尝试处理或撤消处理”，柜员在终端上只能选择“继续”或“撤销”。一旦选定，柜台系统会调用一个专门处理这种情形的一致性处理服务。如果柜员选择了继续尝试处理，该服务会先查询基金公司的处理结果，成功则返回“交易成功”，柜员收讫现金，失败则返回“交易失败”，并启动自动撤消处理以撤消本行帐务系统的现金收取登记，柜员退还现金；如果柜员选择了撤消处理，该服务会先查询基金公司的处理结果，成功则先调用基金公司的撤消购买基金服务，然后再调用本行帐务系统的撤消现金收取登记服务，最后返回“交易已经撤消”，柜员退还现金。
（抱歉，不知道怎么发图）

图2.1 用整体处理方式处理一致性问题的服务应用
显然，从业务角度看整体处理方式要优于分解处理方式——对于柜员而言，操作压力大大降低，不容易出错；对于银行而言，不需要向柜员开放“撤消本行帐务系统的现金收取登记”和“单独调用基金公司的购买基金服务”等功能，更好地控制了操作风险。
但是整体处理方式需要开发人员针对具体应用进行极其细致而繁琐的一致性处理设计（图2.1仍然有许多情况没有考虑到），稍有不慎，则会导致难以想象的后果，因此，目前金融行业采用整体处理方式来应对这种情形的应用比例还相当低。
所谓手动处理模式，就是由Service Center的服务应用框架代替应用，提供统一的一致性处理服务，用一种标准化的、逻辑极其严密的整体处理方式来解决所有自动处理模式无法处理的一致性问题，从而大大降低开发人员的负担。
家住海淀 发表于 2012-2-6 10:50

一致性问题只是一个数据完整性问题
还要关注的就是对海量并发处理的响应
非常正确！
我再抄一些东西大家分享：
Service Center的服务重入机制
        由于经常需要访问远程服务系统（尤其是合作企业的服务系统），许多集成型服务应用完成整个处理过程往往需要较长时间。如果处理线程/进程以堵塞方式——每发出一个服务请求后线程/进程就处于堵塞状态，直到收到服务应答才继续执行下一个指令——执行集成服务处理流程的话，将会导致大量服务系统资源（内存和处理线程/进程）的浪费，造成堵塞，数据差错急剧增多，甚至宕机。
        以前面提到的代销基金为例。市场好的时候，基金销售量会直线上升，基金公司的服务系统可能由于压力增大而反应缓慢，很快就会导致银行端代销基金集成服务处理线程/进程大量堵塞。通常，服务系统常备的处理线程/进程总数都在20到50之间（过多则操作系统调度效率会大大下降），在所有处理线程/进程都处于堵塞状态时，就会产生大量排队等候处理的服务请求，服务系统响应能力和可靠性迅速下降，直至宕机。当然，有些服务系统在紧急时刻会创建更多的线程/进程，但与大量排队等候处理的服务请求比较起来，仍然是杯水车薪。
有些银行采用部署更多的服务系统节点的方法来应对，这不但要大大增加部署成本，而且还不能根本地解决堵塞问题，只不过是延缓了宕机时刻的到来。
还有一些银行采用流量控制的方法来应对，即在调用处理时间可能较长的服务前，检查该服务当前的调用流量，超过一定的阈值则放弃调用，作为“调用流量已满，暂停该类服务”错误来处理。这种方案一定程度上能够保证服务系统不至于宕机，但显然会招致柜员和客户的不满——为什么系统总是暂停服务？
目前，最根本的解决方法就是彻底改变这类服务应用的编程模型，把一个服务处理过程拆解为多个，无论是为客户端系统提供服务，还是调用其它服务系统提供的处理时间可能较长的服务，都采用异步工作模式——即服务应用的异步编程模型。
仍以代销基金为例。在柜员收取客户现金并通过柜台系统发出代销基金服务请求后，服务应用先调用本行帐务系统的服务以登记现金的收取，成功后向基金公司发出购买基金服务请求，请求发出后服务应用休眠——保存当时的重要状态，释放处理线程/进程。在稍后一个时刻，银行收到了基金公司的应答，再唤醒该服务应用——分配处理线程，获取休眠时的状态。如果购买基金交易失败，则启动自动撤销处理，生成“交易失败”服务应答，结束服务处理过程，柜台系统受到服务应答后，在终端上显式“交易失败”，柜员退还现金；如果购买基金交易成功，则生成“交易成功”服务应答，结束服务处理过程，柜台系统受到应答后，在终端上显示“交易成功”，柜员收讫现金。


图2.2按异步编程模型重构的服务应用
服务应用的异步编程模型对开发人员的要求极高。开发人员必须极为小心慎重地针对具体应用制订相应的服务处理过程分拆方案，分拆后如何保障集成服务的一致性则更是一些令人头痛的问题，因此，目前金融行业采用异步编程模型来开发的服务应用极为稀少，在国内，基本上仅限于银联和各大银行的交换系统。
Service Center提供了一种被称为服务重入的机制来解决堵塞问题。这种机制不要求开发人员改变他们习惯的编程模型，仍然只需要用一个流程来描述集成服务的完整处理过程。运行时刻，这个流程在执行到某些耗时较长的处理步骤时，在处理步骤启动后可以执行Service Center的服务应用框架提供的“休眠”方法，由服务应用框架完成应用休眠工作。在这些处理步骤完成时可以执行服务应用框架提供的“唤醒”方法，由服务应用框架唤醒应用，并让它从刚才调用“休眠”方法的语句处继续向下执行，直到完成整个流程。
服务重入机制使得基于Service Center构建的产品服务具有极高的吞吐能力，能够应对过去难以承受的突发的业务高峰，而这一切的获得并不需要开发人员做出许多改变和适应。
efscao 发表于 2012-2-6 10:53

非常正确！
我再抄一些东西大家分享：
归根结底还是分布式事务处理。
只不过是将分布式事务处理应用到金融业中。
个人的判断：
1. 如果是实时交易，要保证多系统间的事务处理，而不是传统的冲正方式，效果未必优于后者。
主要是保证事务处理会影响程序效率，而后者简单明了，当然冲正给柜员带来了麻烦，但系统做得好的话，柜员完全可以不必重新输入数据。
有可能某些特殊业务，实现多系统间的事务处理有必要性和优越性。
2. 如果是批处理，通常是自动化的。
实现多系统间的事务处理当然是必要的。
efscao 发表于 2012-2-6 10:53

非常正确！
我再抄一些东西大家分享：
归根结底还是分布式事务处理。
只不过是将分布式事务处理应用到金融业中。
个人的判断：
1. 如果是实时交易，要保证多系统间的事务处理，而不是传统的冲正方式，效果未必优于后者。
主要是保证事务处理会影响程序效率，而后者简单明了，当然冲正给柜员带来了麻烦，但系统做得好的话，柜员完全可以不必重新输入数据。
有可能某些特殊业务，实现多系统间的事务处理有必要性和优越性。
2. 如果是批处理，通常是自动化的。
实现多系统间的事务处理当然是必要的。
姑且不论这个代销基金的例子并不合适（代销基金根本不是LZ所说的流程）。
LZ所说的就是分布式事务处理的机制，分布式事务处理并不是“不成功则全部失败”，完全可以实现挂起、回退或继续