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

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

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

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

对于一个业务规模很小，业务也比较单一，该架构也是最高效的方式，一到两个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原则，可以建模抽象出基础能力层

交易是很多契约的组合体，基础能力服务是最原子性的，还需要将这些通过流程编排组合成有业务价值的交易产品来统一对外输出和管理，这就是交易平台产品层的职责，解决共性和差异性的问题。

 

此外交易系统需要依赖会员，商品，店铺，库存，优惠，支付和物流等这样的业务服务才能完成一个真正的交易，加上这些我们基本可以确定交易的业务中台架构图，如下：

有了整体的全局大图，接下来我们将会按照如下的框架来详细介绍每个部分。

 

总体设计：

  核心业务领域模型：

领域模型的设计，还是遵守DDD的原则，这块做的好坏，关键是对这块业务的理解和未来一段时间的预判，加上抽象归纳。

 

 

 

核心类图：

从总体设计的角度看，总体的类图应当是关注业务模型本身，按照之前约定，我们先看BA层的业务模型

 

这个类图，只画了宏观和重要的业务域类，其他用来支撑的类图，将在BA层做展示，目前帮助理解交易这些类图足够说明问题，太多反而没有重点。

PA层是对外开放的服务层，按照惯例设计，会有与其DO对应的DTO类，此外考虑到购车更多的是承担前台层的功能，BA层不会引入购车，而将其放到了PA层。

PA层的业务对象类图，除了dto 类型外，还增加了消息事件对象，用来将交易的业务变化通过事件消息通知给对其感兴趣的订阅方，要说明的一点是BA层的DO对象，PA层是完全可以使用的。

核心服务设计：

服务接入层更多的是前后端交互restful service的设计，交易的PA层实质上已经做了对外开放的微服务设计（使用dubbo框架），服务接入层的restful service几乎是对微服务进行包装参数转换的处理，就没有必要单独说明restful

service，直接看PA 最重要的几个服务。

 

核心链路时序设计：

通过最常规的下单购买和支付流程来说明交易的核心调用链路是怎么样的过程，为了简化说明下面的时序图简化了异常链路的处理过程和人为减少了依赖的业务系统。进行核心链路依赖的设计，是为了在设计阶段更好的去评估依赖的合理性，确保交易的性能，安全性和容灾处理方面的要求。有了核心调用链路图，你才能在设计阶段确定哪些调用是可以减少的，哪些地方可以异步处理，哪些地方可以使用前置缓存，哪些地方需要异步重试，哪些地方不能超时，哪些地方要确保最终一致性，哪些要做幂等处理等等，此外也对下游系统更好的评估自己的流量和响应时间提供了参考依据。

交易这块的技术设计点非常多，分布式高并发系统遇到的经典技术问题，几乎都在着有出现，限于篇幅，将通过接下来的一篇专题文章专门介绍。

对这块有兴趣的欢迎交流技术方案和产品玩法。

更多文章欢迎访问 http://www.apexyun.com/

公众号:银河系1号

联系邮箱：[email protected]

(未经同意，请勿转载)