为什么dtm

现实问题

dtm项目起源于实际项目中的问题。我们在公司内部，涉及订单支付的服务，会将所有业务相关逻辑放到一个大的本地事务，这会导致大量耦合，复杂度大幅提升。

我们在进行go语言的微服务化过程中，需要将原先的事务拆分成分布式事务。我们调研了一遍市场上面的开源项目，只有java有成熟的分布式事务解决方案，golang没有，其他语言也没有。因此我们的选择有两个：

• 第一种方式是全部转用java开发，使用Java中应用最广泛的seata方案。这种方案代价非常高，需要将原有大量的业务使用Java重写
• 第二种方式是自己开发一套分布式事务管理器，现有的业务还保留当前语言，渐进式微服务化

dtm能带来什么

我们细致的评估完第二种方案后，发现我们计划自主开发的分布式事务管理器dtm大大优于第一种，有以下几点：

• 可以提供非常简单易用的接口，拆分具体业务接入分布式事务，普通几年开发经验的工程师就能够胜任
• 我们可以对多语言栈进行了支持，这个特性对于小公司切换语言栈，以及大公司采用多语言栈，具有重大意义
• 我们有一项核心技术子事务屏障，可以大大降低开发者处理子事务乱序的处理难度，在seata上进行该技术的开发，难度很高，而自己的方案则简单很多

开源

综合下来，简单易用性、多语言支持、减轻业务负担三个重要方面，我们的方案dtm都非常优秀，相较于我们调研看到的其他开源方案，亮点突出，因此我们决定自己开发。dtm与seata的比较，可以看这里DTM vs SEATA

因为我们的实践表明dtm确实非常优秀，能够极大的降低分布式事务的使用门槛，能够解决当前市面上许多无法解决的问题，因此我们将它开源，反哺开源社区。