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

wangjia

pacman2000 发表于 2012-2-6 17:06

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


图2.1 用整体处理方式处理一致性问题的服务应用
显然，从业务角度看整体处理方式要优于分解处理方式——对于柜员而言，操作压力大大降低，不容易出错；对于银行而言，不需要向柜员开放“撤消本行帐务系统的现金收取登记”和“单独调用公司的购买产品服务”等功能，更好地控制了操作风险。
但是整体处理方式需要开发人员针对具体应用进行极其细致而繁琐的一致性处理设计（图2.1仍然有许多情况没有考虑到），稍有不慎，则会导致难以想象的后果，因此，目前金融行业采用整体处理方式来应对这种情形的应用比例还相当低。
所谓手动处理模式，就是由Service Center的服务应用框架代替应用，提供统一的一致性处理服务，用一种标准化的、逻辑极其严密的整体处理方式来解决所有自动处理模式无法处理的一致性问题，从而大大降低开发人员的负担。
在ATM、自助终端等自助设备上通常不会应用这个手动处理一致性问题的模型，因为不存在运作这种模型的必需条件：业务人员。所以，我们通常也不会在这些终端上看到类似的代销投资产品的服务
说到银联卡，其实在柜台上办理的他行卡存款到是和我列举的代销投资产品非常相似，可以应用这个手动处理一致性的模型
现在柜面上的他行卡取款则通常都和ATM调用的他行卡取款是一个接口，自然一致性处理机制也一样，采用的自动撤销（即冲正）机制，但也可以改成手动的一致性处理机制——如果特别强调客户的感受的话，不过这样自然业务操作员的体验要稍差一点，这就看业务设计部门是怎么权衡的了。以银联卡这么简单的业务而言，似乎倒也没有改的必要。但如果柜员帮助企业用户做多个账户间的转账操作，而这些账户可能包含外行的，那么，应用这个手动的一致性处理机制可能就是必要的了
efscao 发表于 2012-2-6 17:24

？我记得我们谈到ATM是因为我们在讨论异步模型用在哪里（集中处理中心- 银联前置- ATM前置），而不是一致 ...
是否可以采用消息处理机制？某只交易并行调用若干服务，每个服务都会根据一定的规范返回消息，若该交易，允许不是所有服务都成功，才成功，那么可以根据最后每支服务返回的消息结果，决定全部撤销还是部分撤销。
这些不同服务返回的消息通过MQ存储。
通常不会有并行调用的，一般集成服务时都是串行地调用后面的服务
你提到的处理模式其实就是现在许多前置和中间业务平台广泛采用的自动撤销处理模式
efscao 发表于 2012-2-6 17:24

？我记得我们谈到ATM是因为我们在讨论异步模型用在哪里（集中处理中心- 银联前置- ATM前置），而不是一致 ...
你说的这种模式，本质上就是分布式事务的两阶段提交模式，这种技术２０年前就出现了，在ＴＵＸＥＤＯ、ＣＩＣＳ、ＴＯＮＧＥＡＳＹ等交易中间件上都有很好的支持。
但为什么除了一开始在大行的小分行上有所应用，到后来得改为超时反交易或补交易的处理机制？为什么有简单可实现的技术不用而要通过开发出多一倍的超时处理交易来完成？ 这说明了这种2PC的模式，在真正大规模并发的关键型银行交易系统中是弊多利少，严重时甚至出现死锁关键资源而导致全行无法营业的情况。
不要再闭门造车想当然的研发什么产品了，多经历一些大型系统的建造，积累更多的经验再去思考大型银行系统技术平台真正的需要吧！
不要再随便胡吹领先世界５－１０年这样的疯言疯语了，永远没人把它当真。
CountOnMyself 发表于 2012-2-25 14:27

你说的这种模式，本质上就是分布式事务的两阶段提交模式，这种技术２０年前就出现了，在ＴＵＸＥＤＯ、Ｃ ...
1、你真的仔细看完了我们所提的手动处理模式了么？你真的看懂了么？？
2、要论大型系统的建造，我到真是造过不少，我们建造的前置系统在一家省分行的日均交易量都超千万，怎么说我们是闭门造车呢？这个模式实际上是在总结我们01年上线的前置系统几年来运行出现的问题并研究各种解决之后的一些成果。
3、我们可从没说过领先世界5-10这样的“疯言疯语”，不知你从哪儿看到的啊
efsca 发表于 2012-2-26 18:50

1、你真的仔细看完了我们所提的手动处理模式了么？你真的看懂了么？？
2、要论大型系统的建造，我到真是 ...
呵呵，不过我们倒是的确说过我们至少要领先一家国内的“号称世界领先”的平台软件开发商好几年的话，这个恐怕不足以让你得出我们领先世界5-10年这样的推论吧
CountOnMyself 发表于 2012-2-25 14:27

你说的这种模式，本质上就是分布式事务的两阶段提交模式，这种技术２０年前就出现了，在ＴＵＸＥＤＯ、Ｃ ...
呵呵，不过我们倒是的确说过我们至少要领先一家国内的“号称世界领先”的平台软件开发商好几年的话，这个恐怕不足以让你得出我们领先世界5-10年这样的推论吧