中台的概念说了好多年了，起源就是芬兰的游戏公司supercell，之后阿里就提出了大中台小前台的策略，而后和疯狗一样侵蚀了中国。

很多小公司为了显得牛逼，管他呢，干他，就要硬怼个中台进去，反正有个名字叫进去就显得很叼的样子。

其实然并卵，中台的目标还是为了更快的能承接业务的需要，开释开发的重复劳动。

这些年也经验了从交易到金融中台的体验，对中台也算是有个比拟粗略的了解，这些年的中台真的有没有那么好，甚至于当初想到什么业务就想搞中台，想做什么就想往中台迁徙，如同中台就是万能的，没有中台既不能显示本人的能力，又不能突出本人的程度。

明天，我就谈谈中台，先谈谈交易中台吧。

中台架构

任何一个新生事物的诞生，随之而来都会引发一系列的问题。

就拿中台来说，最开始的摸索我想无非就是积淀、形象通用的业务能力，达到疾速交付的目标，而后随着架构的调整，又会衍生出对应的组织中台、技术中台、数据中台等等。

通常，咱们平时最多说的中台能力就是业务中台，比方用户中台、商品中台、交易中台、库存中台、营销中台、金融中台等等，这些通用的能力无论对于哪个公司的业务来说都应该是不可或缺的一部分。

对于前台来说，存在一点扭转，比方 BFF（backend for frontend）的概念，也叫做面向前端的后端。

通常，对于 C 端 APP、PC、H5、开放平台等这些不同的前台对于数据的要求是不太一样的，为了适应这些变动，针对每个端都整一个 BFF 作为数据的聚合、裁剪，也能够承载鉴权、限流等一些通用的能力。

这样的架构形式就把传统的一些网关的能力和 BFF 放在了一起，当然也能够剥来到，更优的解法我想还是通过中间件的能力配置形式就能达到数据聚合、裁剪的能力，同时能够兼有路由、鉴权、限流等等。

中台积淀的是通用和形象能力，本来杂糅在一起的业务逻辑和能力就有了清晰的界定，一些传统的业务能力将会被划分到 业务后盾 的概念中，比方一些 CRM 零碎，财务管理系统，用户治理这些。

架构就是相似这样，接下来说具体的交易中台的建设。

交易中台

交易中台外围的 3 个局部就是 正向交易 、 逆向交易 、 履约，无论做哪些形象的能力，都离不开这 3 个模块。

个别在团队规模不大的时候，这 3 个能力都能够放在一起保护，齐全没有什么问题，次要服务自身能够承载不必业务线的需要，可能对外输入通用的 3 个能力即可。

当然，更加具体的业务应该由业务自身来决定是什么，这里只会形容最根底应该具备的能力。

而当业务的体量回升之后，就会面临更多的拆分的必要，比方订单查问、下单、领取、逆向勾销退款、履约拆分模式。

正向交易

让我从提单页、订单确认页开始说起，一般来说，提单页的信息十分多，咱们要显示购买的商品信息、还有用户的等级、积分、能用的优惠券、价格、残余的库存、领取形式等等，有的还有一些搭售的商品，具体还有怎么抉择最优的组合形式，搭售商品的展现逻辑等等。

提单页波及到的接口堪称是简单的变态，而且 QPS 还高，通常这个界面的逻辑会由专门的 导购服务 来做聚合，当然也有的是让交易自身做这个聚合的逻辑，不过我认为由导购的服务来聚合更为正当一点。

其余的变动都比拟好说，单纯的调用其余服务的接口应该就能够满足，因为这个界面的 QPS 会十分高，所以要做好熔断降级的措施，对于非主链路的服务在高并发的时候该降级的就肯定要降级，相对不能连累到主链路的下单流程。

这里搭售单其实是一个比较复杂的局部，这个实现形式个别是用子订单的模式来实现，也有的实现形式是一个独立的平行订单，还有的是独立到另外一个服务，具体实现形式不做评估，然而简单是真的简单，几个订单交杂在一起，要保障最终下单一致性，必须都下单胜利，而且对于领取来说合并领取、逆向退款也是非常复杂的一件事件。

提单页之后，就进入到真正的下单领取环节，下单的流程对于不同的业务来说可能不太统一，能力反对到位的话借助流程编排可能略微轻松一点，反之为了兼容多种不同的业务必然须要形象出足够通用的逻辑，然而这样也会使得简略的业务变得更加简单。

而如果为了图简略，全部都是 if else 的话，也能疾速搭起来架子，然而后续承载更多不同业务场景将会变得无比被动。

所以中台的能力应该是对现有的业务足够清晰之后再做的形象，而不是啥也没有上来就要干塔喵的中台。

逆向交易

通常的考量必定是要闭环的，这个词倒是很好，包含咱们平时做设计方案的时候必定也是如此，光进不出的那是貔貅，家喻户晓，貔貅是没有菊花的，好受。

订单的勾销、退款更多的时候和领取的交互，对于简单的业务逻辑，存在各种优惠券、红包、积分、会员权利扣减一大堆的就会让领取变得非常复杂。

领取的时候很爽，反正传参就完了，真正到了退款的时候，对于各种不同类型的权利应用、分润规定将会导致退款十分难，对于领取来说这一部分的能力并不好形象，更多的计算的逻辑还是会被交易承载。

履约

履约一般而言异步的模式会比拟更好一点，下单后发放积分、优惠券、红包属于履约，之后安顿配送、发货、签收也都属于履约。

通常的模式是监听下单或者领取胜利的音讯，生产之后调用上游服务的接口，只有调用胜利就代表履约胜利，履约的最终胜利应该由上游服务来保障。

当然，对于比方简单的履约流程，波及到物流配送等，那就不是这么简略了。