中台的概念说了好多年了，起源就是芬兰的游戏公司supercell，以后阿里就提出了大中台小前台的战略，而后和疯狗同样侵蚀了中国。前端
不少小公司为了显得牛逼，管他呢，干他，就要硬怼个中台出来，反正有个名字叫出来就显得很叼的样子。面试
其实然并卵，中台的目的仍是为了更快的能承接业务的需求，释放开发的重复劳动。后端
这些年也经历了从交易到金融中台的体验，对中台也算是有个比较粗略的理解，这些年的中台真的有没有那么好，甚至于如今想到什么业务就想搞中台，想作什么就想往中台迁移，好像中台就是万能的，没有中台既不能显示本身的能力，又不能突出本身的水平。markdown
今天，我就谈谈中台，先谈谈交易中台吧。架构
中台架构
任何一个新生事物的诞生，随之而来都会引起一系列的问题。并发
就拿中台来讲，最开始的探索我想无非就是沉淀、抽象通用的业务能力，达到快速交付的目的，然后随着架构的调整，又会衍生出对应的组织中台、技术中台、数据中台等等。frontend
一般，咱们平时最多说的中台能力就是业务中台，好比用户中台、商品中台、交易中台、库存中台、营销中台、金融中台等等，这些通用的能力不管对于哪一个公司的业务来讲都应该是不可或缺的一部分。异步
对于前台来讲，存在一点改变，好比BFF（backend for frontend）的概念，也叫作面向前端的后端。高并发
一般，对于C端APP、PC、H五、开放平台等这些不一样的前台对于数据的要求是不太同样的，为了适应这些变化，针对每一个端都整一个BFF做为数据的聚合、裁剪，也能够承载鉴权、限流等一些通用的能力。s
pa
这样的架构方式就把传统的一些网关的能力和BFF放在了一块儿，固然也能够剥离开，更优的解法我想仍是经过中间件的能力配置方式就能达到数据聚合、裁剪的能力，同时能够兼有路由、鉴权、限流等等。
中台沉淀的是通用和抽象能力，本来杂糅在一块儿的业务逻辑和能力就有了清晰的界定，一些传统的业务能力将会被划分到业务后台的概念中，好比一些CRM系统，财务管理系统，用户管理这些。
架构就是相似这样，接下来讲具体的交易中台的建设。
交易中台
交易中台核心的3个部分就是正向交易、逆向交易、履约，不管作哪些抽象的能力，都离不开这3个模块。
通常在团队规模不大的时候，这3个能力均可以放在一块儿维护，彻底没有什么问题，主要服务自己能够承载不用业务线的需求，可以对外输出通用的3个能力便可。
固然，更加具体的业务应该由业务自己来决定是什么，这里只会描述最基础应该具备的能力。
而当业务的体量上升以后，就会面临更多的拆分的必要，好比订单查询、下单、支付、逆向取消退款、履约拆分形式。
正向交易
让我从提单页、订单确认页开始提及，通常来讲，提单页的信息很是多，咱们要显示购买的商品信息、还有用户的等级、积分、能用的优惠券、价格、剩余的库存、支付方式等等，有的还有一些搭售的商品，具体还有怎么选择最优的组合方式，搭售商品的展现逻辑等等。
提单页涉及到的接口可谓是复杂的变态，并且QPS还高，一般这个界面的逻辑会由专门的导购服务来作聚合，固然也有的是让交易自己作这个聚合的逻辑，不过我认为由导购的服务来聚合更为合理一点。
其余的变化都比较好说，单纯的调用其余服务的接口应该就能够知足，因为这个界面的QPS会很是高，因此要作好熔断降级的措施，对于非主链路的服务在高并发的时候该降级的就必定要降级，绝对不能拖累到主链路的下单流程。
这里搭售单实际上是一个比较复杂的部分，这个实现方式通常是用子订单的形式来实现，也有的实现方式是一个独立的平行订单，还有的是独立到另一个服务，具体实现方式不作评价，可是复杂是真的复杂，几个订单交杂在一块儿，要保证最终下单一致性，必须都下单成功，并且对于支付来讲合并支付、逆向退款也是很是复杂的一件事情。
提单页以后，就进入到真正的下单支付环节，下单的流程对于不一样的业务来讲可能不太一致，能力支持到位的话借助流程编排可能稍微轻松一点，反之为了兼容多种不一样的业务必然须要抽象出足够通用的逻辑，可是这样也会使得简单的业务变得更加复杂。
而若是为了图简单，所有都是if else的话，也能快速搭起来架子，可是后续承载更多不一样业务场景将会变得无比被动。
因此中台的能力应该是对现有的业务足够清晰以后再作的抽象，而不是啥也没有上来就要干塔喵的中台。
逆向交易
一般的考量确定是要闭环的，这个词却是很好，包括咱们平时作设计方案的时候确定也是如此，光进不出的那是貔貅，众所周知，貔貅是没有菊花的，难受。
订单的取消、退款更多的时候和支付的交互，对于复杂的业务逻辑，存在各类优惠券、红包、积分、会员权益扣减一大堆的就会让支付变得很是复杂。
支付的时候很爽，反正传参就完了，真正到了退款的时候，对于各类不一样类型的权益使用、分润规则将会致使退款很是难，对于支付来讲这一部分的能力并很差抽象，更多的计算的逻辑仍是会被交易承载。
履约
履约通常而言异步的形式会比较更好一点，下单后发放积分、优惠券、红包属于履约，以后安排配送、发货、签收也都属于履约。
一般的形式是监听下单或者支付成功的消息，消费以后调用下游服务的接口，只要调用成功就表明履约成功，履约的最终成功应该由下游服务来保证。
固然，对于好比复杂的履约流程，涉及到物流配送等，那就不是这么简单了。
若有收获，就点个赞吧
0 人点赞
