ESB产品架构之事务管理

1  概述

       在企业内事务在所有的业务交互几乎都是需要的，作为一个业务交易集中者的ESB有时也不得不面对这个问题。ESB是所有企业服务的集中者，它面对的是多种的异构的系统，由此会遇到了非常大的挑战性。大都多的情况下，我们建议如果不是业务上非常的必要，最好不要使用事务，因为在ESB的环境下，事务是一个非常昂贵，他会占用大量的资源。

 

2    ESB事务的特性

2.1    基本特性

     事务最基本的特性是以下描述的ACID

• Atomicity（原子性） ，事务中的所有操作，要么全部成功，要么全部失败
• Consistency（一致性） ：在事务开始与结束时，数据库处于一致的状态。
• Isolation（隔离性） ：在事务开始与结束时，事务如同只有这一个操作在被数据库所执行一样。
• Durability（持久性） ：在事务结束时，此操作将不可逆转。

 

2.2    ESB特有的特性

    ESB事务除了事务本身带有的ACID的特点之外，还有一些自身的特性而带来的特点。
1.    分布式： 应该是由SOA的架构从产生开始就注定存在的特点，而为此而生的ESB当然也继承了这个特点。在分布式的应用的环境下，事务当然也是分布式的，这也是ESB事务带来的最大的挑战。
2.    无状态： 很多的ESB的架构都会使用WebService或者其它一些无状态的协议，这无状态也为我们的分布式带来了一定的麻烦。虽然WebService有一个事务的标准WS-AtomicTransaction。但使用这个准标的实现，一个服务的调用需要十次以上的协同调用，在性能上是一个非常大的消耗，想要使用这个标准也非易事。
3.    存在多种事务环境： ESB是一个集成者，他集成了多个系统，这些系统可能使用不同的事务环境。这个时候我们就需要把一种事务环境的上下文传播到别一种上下文中去。例如IBM的CICS Transaction Server要传播到微软事务处理服务(MTS)。

 

3    事务种类

在企业中，为了完成一个分布式事务，主要有两种方式，一种是两段式事务，一种是使用冲正交易。

3.1    两段式事务

      两段式事务，在实际的使用过程中，为了提高事务的性能，出现了两种不同的事实，一种是使用事务的协调架构，另一种是TCC事务架构，

3.1.1    事务的协调架构

     这种事务协调服务，可以在使用者透明的情况来达到一种分布式事务的能力。在J2EE的环境，最典型的就是JTA（Java Transaction API）。一般情况下我们会使用JTS的事实，这个事实基于OMG（Object Management Group）的OTS(http://www.omg.org/spec/OTS/)实现。在WS协议簇中的WS-AtomicTranscation也是基于这个原理来实现的。

3.1.2    TCC事务架构

      TCC的事务架构是网上看到的支付宝使用的一种事务架构，它没有事务的协调架构那么的严谨不能保证在一个事务结点失效下的情况下保证事务的完整性，更没有事务的协调架构使用上的方便，它的产生，最主要的原因是，事务的协调架构性能的低下。
    TCC实际上是一种手工的两段式事务，我们先来看看TCC缩写下的含义：

• T：try，它是一种试图去完成当前事务结点下的事务，在JDBC的事务下它是事务提交或回滚之前做的所有动作。它需要把SQL执行到数据库中，又不能让这些SQL在事务外生效，保证其事务的隔离性。
• C：commit，提交事务。
• C：cancel，回滚。

      这些动作都是各个系统手工去完成的，也就是一个TCC的事务服务，以上的三个方法，这三个动作都由一个事务上下文的ID来关联，当try执行完后，它不会提交本地的事务，他把事务的现场，根据key(事务)-value(事务现场)的形式保存起来，通过另一支交易commit或cancel来提交或回滚本地事务。这时他根据事务的id找到事务的现场，然后提交或回滚本地事务。
 

3.2    冲正交易

      冲正交易，在某种意义上来说，它不是一种事务构架，它是无法满足事务的ACID的特性，冲正服务。它不能透明的使用，需要用户专门开发一个服务对应的冲正服务来回滚这个服务已经提交的数据，这就使得当前分布事务还没有提交的情况下，这个事务结点的本地事务已经提交了，这也就没有办法满足事务的隔离性。运作方式请看下图。

 
 

4    服务事务分类

      根据上面对事务的特性和事务种类的描述，我们可以知道，事务会带来性能的问题，除了冲正架构这种不完全的事务之外，最少都需要多调用一次才能完成一次事务，所以我们虽然对交易进行一下事务分类，根据这些配置来对按需对事务进行配置，从而最大程度上节约在事务上的性能消耗。

• 严格一致服务： 这些服务是业务的核心，他们是绝对要严格按ACID来运行的。这种服务最好能使用两段式的事务来完成，如果是存量的服务下，才使用冲正交易这种不完全的事务手段来完成。
• 最终一致服务： 这些服务虽然也是必需要以严格一致的服务相一致，可以使用日间跑批的方式来完成事务的一致性，如果系统中没有日间跑批的设施，我们也可以使用冲正交易这种方式来完成。这种事务只能保证事务是最终是一致的，而不能保证事务的隔离性。
• 尽最大努力达成的服务： 这些服务不是核心，他们只要尽最大的努力分完成就可以了，就算完成也不会对业务的整体产生致命的影响。
• 不需要事务的服务：这类的服务主要是一些查询的服务。

 

5    ESB事务管理

      ESB事务管理是在不同的事务环境下提供一个整合不同的事务环境，提供一个相对快速和安全的分布式事务的能力。       ESB事务管理中应该有一个事务中心，所有的事务的上下文都会注册到事务中心，这个事务中心，事务中心是可以允许事务的嵌套的，ESB中如果去调用其它服务时，如果这个服务有配置事务，那么它就会被当作一个子事务来注册到事务管理中心去。当事务的发起方进行提交时，事务管理中心会统一的对其子事务进行提交。       如果用户可以使用ESB的endpoint，那么，我建议在endpoint嵌入TCC事务架构。如果用户使用的事务协调架构时，我们应当去监听事务协调架构的几个事件，当事务开始时，我们要给把事务注册到事务中心去。这样，如果用户把交了，可以把事务中心中的当事务下的所有子事务都提交。       这种事务中心的事务管理器，我觉得应该是ESB中比较合适事务管理方式，他不能处理在一个事务节点失效这些的事务的特殊情况。       我觉得自己还没有很全面的去考虑实现的方式，这里只是一个不是很成熟的想法，也没有去仔细的去细化，ESB的事务管理器非常的复杂，有些ESB的产品也没有提供相关的能力，对于ESB来说，也不是一个非常迫切的功能。