微服务架构分布式事务控制解决方案分析

示例业务一

针对注册业务,如果用户与账号信息不一致,则会导致严重问题; 因此改业务对一致性要求较为严格, 即当用户服务和账号服务任意一方出现问题都需要回滚事务。

1.采用可靠消息一致性方案

由于可靠消息一致性要求发消息者一旦发出消息, 事务参与者接收到消息就必须要将事务执行成功,不能回滚,所以不适用。

2.采用最大努力通知方案

最大努力通知表示发起通知方执行完本地事务后将结果通知给事务参与者，几十事务参与者执行业务处理失败，发起通知方不会回滚事务。即发起方只管发，不保证接收方一定能接收到，如果未成功接收，接收方再通过主动查询发起方的记录获取消息内容。实现了发起方与接收方的解耦。所以不能保证一方失败双方回滚。

3.采用Seata实现2PC（两阶段提交）

可在用户中心发起全局事务，统一账户服务为事务参与者，用户中心和统一账户服务只要有一方出现问题则全局事务回滚，符合要求。

实现方法如下：
1、用户中心添加用户信息，开启全局事务
2、统一账号服务添加账号信息，作为事务参与者
3、其中一方执行失败Seata对SQL进行你操作删除用户信息和账号信息,实现回滚。
4、采用Hmily实现TCC
TCC也可以实现用户中心和统一账户服务只要有一方出现问题则全局事务回滚,符合要求。

示例业务二

P2P平台的用户中心与银行存管系统之间属于跨系统交互，银行存管系统属于外部系统，用户中心无法干预银行存管系统，所以用户中心只能在收到银行存管系统的业务处理结果通知后积极处理，开户后的使用情况完全由用户中心来控制。

根据上述需求进行解决方案分析：
1、采用Seata实现2PC
需要侵入银行存管系统的数据库，由于它的外部系统，所以不适用。
2、采用Hmily实现TCC
TCC侵入性更强，所以不适用。
3、基于MQ的可靠消息一致性
如果让银行存管系统监听MQ则不合适，因为它的外部系统。
如果银行存管系统将消息发给MQ用户中心监听MQ是可以的，但是由于相对银行存管系统来说，用户中心属于外部系统，银行存管系统是不会让外部系统监听自己的MQ的，基于MQ的通信协议也不方便外部系统间的交互，所以本方案不合适。
4、最大努力通知方案
银行存管系统内部使用MQ，银行存管系统处理完业务后将处理结果发给MQ，由银行存管的通知程序专门发送通知，并且采用互联网协议（发送http消息）通知给第三方系统（用户中心）。

示例业务三

在借款人标的募集够所有的资金后,P2P运营管理员审批该标的,触发放款,并开启还款流程。

管理员对某标的满标审批通过，交易中心修改标的状态为“还款中”，同时要通知还款服务生成还款计划。