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

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

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

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

​

对于一个业务规模很小，业务也比较单一，该架构也是最高效的方式，一到两个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号

联系邮箱：public@space-explore.com

(未经赞成，请勿转载)