为什么要用业务中台化思想来架构交易系统
上一篇文章已经简要介绍了交易业务中台的设计理念，本篇会详细的来说为何要用中台的思想来架构交易系统。要说明白这个问题，我们必须回看系统的演化路径是怎样随着业务规模的增长进行变化的。
首先来看初创公司/新业务系统是如何演进的；以基于云计算为基础的架构模式，大部分的初创的系统架构图如下
对于一个业务规模很小，业务也比较单一，该架构也是最高效的方式，一到两个web系统，数个微服务业务系统，一到两个前台系统。微服务业务系统将会把会员，商品，类目，店铺，交易，库存，物流这些划分成不同的模块/包放在一到几个系统，这样做的好处是非常明显的，每个人都熟悉所有的代码，代码量不大，开发效率高，这在公司刚起步时，是非常接地气的和最适合的架构。
随着公司业务规模和组织的壮大，会基于上面的架构，迭代演进N次，直到系统不再是制约公司发展的瓶颈，这期间最重要的架构升级是系统和数据库的垂直拆分，异步消息解耦，分布式事务机制，稳定性保障。为了快速说明问题，我们将忽略中间演进版本，直通基于中台的版本。
在介绍业务中台模式之前，先来看看中台概念的产生背景，中台研发模式最早产生于芬兰著名游戏公司supercell. Supercell有员工180人，后被腾讯以100亿美金估值收购，其鼎峰时期全球排名top10的游戏，有5个来自supercell, 其能快速推出高质量的游戏，其大中台功不可没。 阿里借鉴了supercell的“大中台，小前台”的模式，以解决快速创新试错的前端业务和日益沉重的淘宝天猫这些核心系统之间的矛盾，以提升研发效率和跨团队合作。
可以进一步的设想，如果公司业务高速发展，特别是互联网的业务模式，出现10倍增速的发展也很正常，这会面临业务和技术团队规模变大，业务也会越来越复杂，就以交易为例，最初就是简单支撑实物购买场景（消费者付款购买，平台/商家发货），随着用户和业务的发展，会出现，虚拟商品交易，团购，拼团，拍卖，秒杀，预售等等交易业务模式。
最初就是一个系统单纯的支持一个单一的业务，到了阶段二支持三个业务，你还能勉强活着，到了阶段三如果还是使用之前的架构和开发模式，你会陷入泥潭，在阶段三必然会出现以下问题：
[if !supportLists]1. [endif]业务之间的需求相互影响，修改和测试回归成本非常高，但还是会发生意想不到的线上问题。
[if !supportLists]2. [endif]由于支撑的需求越来越多，没有人能掌控全局，修改无存下手，开发越来越不敢接需求。
[if !supportLists]3. [endif]多个需求并行的开发是场噩梦，团队经常加班，还是满足不了业务需求的开发，团队越来越是瓶颈，经常接到业务方的投诉。
业务中台化也就是解决这些问题的最佳选择，将交易域的核心能力和服务，通过梳理抽象沉淀为稳定外化的服务，通过预留的扩展点，来支持个性化扩展。扩展点的开发完全可以由业务团队的技术来进行，交易中台研发将专注于中台的建设和稳定性，这样讲大大改善开发协作效率，一个业务能不能跑的快，主要依赖于前台，当然业务中台的技术团队需要做好业务隔离和中台本身的稳定高效进化。
了解交易的一般业务流程
本篇是用来讲交易的，结果扯了太多业务中台的东西，现在直奔交易，看看交易的两个业务流程。
交易订单创建流程：
简化的逆向退款流程：
只举例2个业务流程，其他的大同小异，对交易业务的分析和梳理，不难发现，交易涉及的业务域可以归类为以下几个方面：价格，优惠，库存，拆单，支付，限购，交付，订单，超时，售后。
交易业务中台架构
通过对交易业务流程和业务的分析和梳理，采用20/80原则，可以建模抽象出基础能力层
交易是很多契约的组合体，基础能力服务是最原子性的，还需要将这些通过流程编排组合成有业务价值的交易产品来统一对外输出和管理，这就是交易平台产品层的职责，解决共性和差异性的问题。
此外交易系统需要依赖会员，商品，店铺，库存，优惠，支付和物流等这样的业务服务才能完成一个真正的交易，加上这些我们基本可以确定交易的业务中台架构图，如下：
有了整体的全局大图，接下来我们将会按照如下的框架来详细介绍每个部分。
作者：银河1号
链接：https://www.jianshu.com/p/98bc07b1241f
随时随地看视频