企业不断发展，很多长期需要人为操作或者流程定制来处理的业务问题，为了提高效率会考虑引入软件应用系统来解决，比如财务系统 、ERP（企业资源计划）系统、CRM（客户管理管理）系统等。引入这些系统在当时是解决了一部分的问题，但是随着应用系统数量的增加，新的问题也慢慢暴露了出来。因为，每个应用系统都有不同的开发需求前提和问题背景，系统之间数据也是相互孤立；所以在企业内部，每个应用系统其实就是一个“孤岛”，相互之间没有畅通的信息交流与数据共享。于是经过一段时间之后新的问题就出现了：比如，信息和数据的更新的不同步甚至不一致的问题，更严重的是给客户也经常提供一些前后不一致的信息，导致客户无法接受，这会严重影响到企业的形象和信誉。一般的应用系统是属于独立完成一项应用的软件产品，比如：ERP系统、OA系统、财务系统 、人事管理系统等等；而系统集成是指将两种、甚至多种类型的应用系统通过二次开发将他们互相集成在一起，可以进行信息资源的共享和相互调用，比如将MIS管理系统和ERP系统进行集成后，管理员可以通过ERP系统方便地查看物料零件的当前库存和标准价格等信息；而ERP系统也可以直接将库存管理统中单个零件清单和入库、出库、货品盘点操作等信息自动进行导入，以提高工作效率。

　　从集成深度上理解，企业内系统集成通常可以分为：表示集成、数据集成、流程集成和应用集成等四类。

　　同步方式，即主业务线程在事务提交前发起远程调用并在同一线程内等待响应结果的数据集成方式。流程图如下：

　　异步方式，即应用发起方在事务提交后异步发起远程调用，发起方不等待响应结果的数据集成方式。流程图如下：

　　同步方式的优点是业务系统开发简单，开发成本低。缺点是应用和数据集成相耦合，影响用户体验（发起方需等待响应），且没有处理一致性问题，有多种可能会造成一致性问题出现，如：

　　A 发起者（业务系统）在远程调用超时，本地事务回滚。而接受者（业务系统）成功提交本地事务。此时，会造成接收者存在脏数据

　　B 发起者（业务系统）在远程调用后，进行业务处理失败，或者因不可抗力因素（网络抖动、服务器异常宕机等）导致事务提交失败。此时业务造成接收者存在脏数据。

　　异步方式的优点是应用和数据集成解耦，用户体验较好。缺点是 实时性差，适用场景有限。被动方应用有可能处理失败，这时需要提供补偿或者人工介入。

　　TCC是柔性事务的一种实现。TCC是三个首字母，Try-Confirm-Cancel，具体描述是将整个操作分为上面这三步。两个服务间同时进行Try，在Try的阶段会进行数据的校验，检查，资源的预创建，如果都成功就会分别进行Confirm，如果两者都成功则整个TCC事务完成。如果Confirm时有一个服务有问题，则会转向Cancel，相当于进行Confirm的逆向操作。

　　TCC 可以解决服务之间一致性问题，且有部分相对成熟的开源实现。但是异构系统间TCC实现目前较少，开发难度较大。TCC需要应用层处理资源的回滚和提交，因此对业务层具有很强的侵入性。

　　2) MQ接受到消息后，先进行持久化，则存储中会新增一条状态为待发送的消息

　　因各个异构系统不是一家厂商开发的，使用TCC的实现难度较大，协调和联调各异构系统厂商也是很大工作量 。

　　一般来说我们推荐基于可靠消息做为异构系统间的数据集成一致性解决方案，方便各异构系统又能数据集成同时也能解耦。

　　通过可靠消息队列的方式，实现发起方应用和被动方应用的解耦。发起方应用不直接调用被动方应用服务，而是通过消息队列的方式进行异步调用。其中，通过消息发送一致性保证消息不会误发、不会产生脏数据。消息处理的幂等性保证消息处理失败时能通过消息服务进行定时补偿消费且不会重复处理。

　　（一）消息存储与业务存储在同一个本地事务中进行,消息存储后设置为待确认状态,并异步将消息发送(注意需要异步发送消息,不要影响主流程).

　　（三）业务方回收到消息,成功处理业务,并持久化完成后调主动方接口,通知主动方此消息已经处理完成,主动方将数据库中消息状态改为已发送.（或者直接删除）

　　（四）实现一个消息管理系统,手动处理多次重发失败已死亡的消息.（消息补偿发送）

　　（二）从应用设计开发的角度实现了消息数据的可靠性,消息数据的可靠性不依赖于MQ中间件,弱化了对MQ中间件的依赖

　　（三）业务系统在使用关系型数据库的情况下,消息服务性能会受到关系型数据库并发性能的局限

　　（一）存储预发送消息(主动方业务执行之前进行,预发送的消息存储后状态为待确认)

　　（二）确认并发送消息(主动方业务完成之后,主动方或消息状态确认系统通过此接口将消息变为取消或发送中)

　　独立消息服务最终一致性与本地消息服务最终一致性最大的差异就在于将消息的存储单独地做成了一个服务，这个过程其实就是模拟了事务消息的消息预发送过程，如果预发送消息失败，那么主动方业务就不会去执行，因此对于主动方的业务而言，它是强依赖于该消息服务的

　　普通基于消息的最终一致性方案基本能满足大部分数据集成的最终一致性要求。但必须保证被动方应用在业务上的操作没障碍的业务场景。它只允许系统异常的失败，不允许业务上的失败。但是异构系统数据集成时往往存在主动方的业务动作依赖被动方的响应结果的业务场景，例如：

　　主动方弃审单据时，被动方因单据被引用无法删除，此时应当主动方也不允许弃审完成。基于可靠消息很难满足这一类的场景需求。

　　在进行消息发送前 主动方对被动方进行一次消息预处理，此次处理以同步方式进行且强依赖被动方的响应结果。失败将不继续业务操作，成功则进行后续的业务操作

　　被动方在接收到预处理请求时，可以先对业务资源进行锁定或者检验。确保后续的消息处理能够顺利进行。