应用集成实战系列：服务总线中的服务补偿机制

在应用集成项目中，经常会遇到多个集成应用之间的交易数据一致性的问题，虽然很多成熟的应用集成产品都会提供分布式事务和重试的功能，但是这些功能往往在实际的应用中作用不是很大。主要因为：1.大多数集成接口使用的是基于HTTP的传输协议(Web Service、REST等)，而分布式事务通常只能支持诸如JDBC，EJB，JMS之类的协议；2、大多数集成服务之间的调用异常或是因为网络原因、或是因为数据原因都不可能很快自动恢复，而集成产品所提供的重试一般都是在短时间内的重试，比如30秒重试一次，重试3次等，在很多情况下无法满足需要。

为了保证集成项目实际应用中的交易数据一致性，我们需要在项目实施的过程中构建自己的服务补偿机制。根据需求的不同，服务补偿集成有如下两种：

• 实时冲正

对业务一致性要求高的集成业务，如果其采用的集成接口不支持分布式事务(基于HTTP的接口)，需要采用实时冲正进行服务的补偿

• 需要进行冲正补偿的系统服务，必须提供两个服务接口
  • 正常服务接口：用来进行正常的业务服务调用
  • 冲正服务接口：当集成过程中出现错误，调用冲正服务接口进行回滚操作

• 冲正服务在服务的异常处理分支进行调用，目标系统需要实现业务去重的操

• 批量补偿

对业务一致性要求不是很高(主要是时效性)的业务场景，可采用补偿流程定时重发的方式进行服务补偿

• 集成的过程中出现异常，将集成数据存储到冲正日志
• 补偿流程定时检查冲正日志，发现需要冲正的数据，自动重新调用目标服务进行服务重做进行服务补偿
• 如果多次调用补偿失败，可转为手工补偿

 

欢迎关注我的微信公众号