为什么dtm

现实问题

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

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

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

dtm能带来什么

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

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

开源

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

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

Last Updated: