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