开发者应该书写他们自己的事务协调逻辑吗?

  • Jean-Jacques Dubray
  • 王志雄

2008 年 1 月 16 日

话题:SOA架构

Mark Little 是 Red Hat 的 JBoss 部门的标准主管和开发经理。他把大部分的职业时间都投入到了分布式计算和分布式事务协议上。他是好几个工作组的成员,这些工作组试图为 Web 服务定义一个事务协议,比如 BTP,WS-CAF 和 WS-TX。

在十二月,Mark 发表了博文“大规模分布式事务”。他解释说,由于他过去从事复制(replication)协议方面的工作,他得出一个结论:为了获得性能和可用性,需要牺牲一致性。这与 Werner Vogels 在QCon 伦敦 2007 大会上的发言一致。

Mark 声称:

对事务来说,有一点也是一样的(译注:即和服务实现一样,事物实现也是各异的):事实上,如果你想将不同的服务和域粘合在一起,在 Web 服务中这是必须的。在服务边界的背后,它们中的一部分可能并不是使用相同的事务实现。

他指出,其他人比如 Pat Helland 也考虑过放宽事务能力。Mark 用海森堡测不准原理(Heisenberg's Uncertainty Principle)来阐明他的观点: 

你可以知道所有的参与者的任一状态,但不知道何时到达;反之亦然。

他还给我们指出 WS-BP 规范是 WS-CAF(组合应用框架)规范集的一部分:

业务流程事务模型和传统的 2PC 事务模型的一个关键差异是它假定成功。也就是说 BP 模型是乐观,它假设失败的案例是少数,在需要情况下可以被处理或者离线解决,或者通过重试(replay)/ 空操作(void)/ 补偿(compensation),但不会始终是自动的,经常需要人工交互。

这个方法在 Pat用于阐明他的论文的例子中得到回应:

考虑一个买房者以及他和第三方担保(escrow)公司的关系。购买者和第三方担保公司达成一个信任协议。卖家、抵押公司、以及事务中涉及的所有其他方也是如此。

当你签了一份购买一套房子的文件,你并不知道交易的结果。你承认,除非第三方担保公司倒闭你才会是不可靠的。控制决策的唯一方是第三方担保公司。这是一个两方关系的星型(hub-and-spoke)集合,被用于一大群当事人在不使用分布式事务下取得一致意见。

Pat 补充:

当你考虑几乎无限规模的情形时,再去回想两方关系就很有意思了。这可以通过从两方试探 / 取消 / 确认 (就像传统的工作流) 逐步进行构造。

Greg Pavlik,也是许多 Web 服务事务规范的合作者,开始思考不同的方面

应用系统可能包含协调者的角色,在某种程度上它变得越来越不清晰,为什么协议的必要性要远大于业务逻辑本身?

这里有些需要被应用开发人员理解的模式。它们可能被一些框架支持。但是有一点很明显:事务管理不会在上下文中扮演主要角色。

Mark 答复,是的,

[他不] 认为分布式 ACID 事务(译注:原子性 Atomicity、一致性 Consistency、隔离性 Isolation、持久性 Durability)在大规模系统上有很大的前途。

但是,

仍然有一个可靠的协调者,它控制状态转换、在故障和恢复的时候“做正确的事情”。

去年夏天,Juval Löwy ——IDesign.net 的首席架构师——在一个播客(podcast)里暗示了相似的结论

当几个软件代理参与执行一个公共工作单元的时候,重新发明专用事务协议去完成状态调整不是一个好主意。
查看英文原文Should developers write their own transaction coordination logic?
译者简介:王志雄,长期从事软件开发工作,项目集中在 EAM 和设备点检管理领域。2004 年转入 JAVA 领域,曾经在项目中使用过 Hibernate、Struts、Spring 等。关心软件技术和相关工具的动态,将其中成熟的技术和工具应用到实际的项目之中。关心开源软件的发展动态以及软件过程和敏捷开发的实践探索。
SOA架构