转自揭秘：蚂蚁金服 SOFA 分布式架构演进之路

SOFA 是蚂蚁金服自研的一套金融级分布式中间件，包含了应用容器，RPC，消息，数据中间件，分布式事务，限流，熔断，分布式链路追中等等框架。

在 SOFA 里面，通过一个 TCC （Try-Confirm-Cancel）的框架来解决了分布式事务的问题，也就是现在的 SOFA DT X ，在 TCC 模型下，会有一个事务的发起方，这个一般上是一个业务系统，它会现在业务系统中去启动一个本地事务，然后调用所有的事务参与方的 Try 接口，如果 Try 通过之后，再调用所有的事务的参与方的 Commit 接口进行事务提交。如果 Try 失败，则调用所有的事务参与方的 Cancel 接口进行事务回滚。在 TCC 中，一旦一阶段 Try 通过之后，二阶段就 Commit 就必须成功，但是现实情况中，总会因为各种各样的问题，会有 Commit 失败的情况发生。所以，在 SOFA 的 DTX 中，还有一个单独的服务，专门用于重试二阶段，让这些事务最终能够成功。

当然，在 SOFA 里面，除了对分布式事务做同步的服务的事务支持之外，针对异步的消息，也提供了事务消息的支持，SOFA 里面的事务消息的支持可以看如下这张图：

在事务消息里面，发起方会在一个本地事务中去发送一个消息，SOFA 的消息中心接收到这个消息之后，会落到消息中心的存储里面，但是这个时候，消息中心并不会向订阅方投递消息；等到发起方的本地事务结束，会自动给消息中心一个通知，告诉消息中心本地事务已经提交或者回滚，如果消息中心从发起方得到的通知是事务已经提交，就会将消息发送给消息的订阅方，如果消息中心从发起方得到的通知是事务已经回滚，那么消息中心就会从存储中将消息删除掉。当然，发起方给消息中心的通知在中间也可能会因为各种各样的问题到丢失，所以，一般上事务的发起方还需要实现一个消息回查的接口，当消息中心在一段时间内没有收到事务的发起方的通知的时候，消息中心会主动回查发起方，主动咨询发起方对应的事务的状态，根据主动拿到的状态来决定消息是要发送还是删除。

分布式事务和事务型消息作为 SOFA 在事务上的解决方案都在被广泛地使用，其中分布式事务一般上用在强同步的场景，比如转账的场景，而事务型的消息一般上被用在异步的场景，比如消息记录的生成等等。