基于大中台架构的电商业务中台最佳实践之二：交易业务中台核心设计

为什么要用业务中台化思想来架构交易系统

上一篇文章已经简要介绍了交易业务中台的设计理念，本篇会详细的来说为何要用中台的思想来架构交易系统。要说明白这个问题，我们必须回看系统的演化路径是怎样随着业务规模的增长进行变化的。

首先来看初创公司/新业务系统是如何演进的；以基于云计算为基础的架构模式，大部分的初创的系统架构图如下

对于一个业务规模很小，业务也比较单一，该架构也是最高效的方式，一到两个web系统，数个微服务业务系统，一到两个前台系统。微服务业务系统将会把会员，商品，类目，店铺，交易，库存，物流这些划分成不同的模块/包放在一到几个系统，这样做的好处是非常明显的，每个人都熟悉所有的代码，代码量不大，开发效率高，这在公司刚起步时，是非常接地气的和最适合的架构。

随着公司业务规模和组织的壮大，会基于上面的架构，迭代演进N次，直到系统不再是制约公司发展的瓶颈，这期间最重要的架构升级是系统和数据库的垂直拆分，异步消息解耦，分布式事务机制，稳定性保障。为了快速说明问题，我们将忽略中间演进版本，直通基于中台的版本。

在介绍业务中台模式之前，先来看看中台概念的产生背景，中台研发模式最早产生于芬兰著名游戏公司supercell. Supercell有员工180人，后被腾讯以100亿美金估值收购，其鼎峰时期全球排名top10的游戏，有5个来自supercell, 其能快速推出高质量的游戏，其大中台功不可没。 阿里借鉴了supercell的“大中台，小前台”的模式，以解决快速创新试错的前端业务和日益沉重的淘宝天猫这些核心系统之间的矛盾，以提升研发效率和跨团队合作。

可以进一步的设想，如果公司业务高速发展，特别是互联网的业务模式，出现10倍增速的发展也很正常，这会面临业务和技术团队规模变大，业务也会越来越复杂，就以交易为例，最初就是简单支撑实物购买场景（消费者付款购买，平台/商家发