中台。起源是芬兰游戏公司Supercell。之后，阿里提出了大、中、小前台的战略，然后像疯狗一样蚕食着中国。.很多小公司为了牛逼，不得不从中台强行退出，反正有了名字，看起来就很搞笑了。其实不一样，中台的目的是更快的承接业务需求，释放开发的重复劳动。这些年我也经历了从交易到金融中台的经历，对中台有了一个大概的了解。这些年中台真的有那么好吗？现在一想到什么业务我都想搞中台。欲为所欲，欲迁中台。看来中台是无所不能的。没有中泰，既无法展现自己的能力，也无法凸显自己的水平。今天说说中台，先说说交易的中台。中台格局中任何新事物的诞生都会引发一系列问题。以中台为例。我认为初期的探索无非是对通用业务能力进行沉淀和抽象，以达到快速交付的目的。然后随着架构的调整，相应的组织中台、技术中台、数据中心等。通常，我们平时说的最多的中台能力就是业务中台，比如用户中台、商品中台、交易中台、库存中台、营销中台、财务中台等等。这些通用能力无论在哪个公司，都应该是任何业务不可或缺的一部分。对于前端，有一点变化，比如BFF（backendforfrontend）的概念，也称为面向前端的后端。通常，C端APP、PC、H5、开放平台等不同的前台对数据的要求是不同的。为了适应这些变化，每端一个BFF被用作数据聚合和裁剪。承载认证、限流和其他通用能力。这种架构把一些传统的网关能力和BFF放在一起。当然也可以分开。我认为更好的解决方案是通过中间件能力配置来实现数据聚合和裁剪能力。同时可以结合路由、鉴权、限流等。通用和抽象的能力都沉积在中台。原本混在一起的业务逻辑和能力都会被清晰的定义出来。一些传统的业务能力会划分为业务后台的概念，比如一些CRM系统、财务管理系统等，用户管理这些。结构与此类似。接下来说一下交易平台的搭建。交易中心的三个核心部分是正向交易、反向交易和合约履行。无论做什么抽象能力，都离不开这三个模块。一般在团队规模较小的时候，这三种能力一起维护是完全没有问题的。主服务本身可以承载不同业务线的需求，对外输出三种通用能力就足够了。当然，更具体的业务要由业务自己决定，这里只描述最基本的能力。并且当业务量增大时，将面临更多的拆分需求，如订单查询、下单、支付、反向取消退款、合同履约拆分等。对于远期交易，我先从提单页和订单确认页开始。一般来说，提单页有很多信息。我们需要展示购买商品的信息，以及用户的等级、积分、可用的优惠券、价格，剩余库存，付款方式等，还有一些捆绑商品，具体如何选择最优组合方式，捆绑商品的展示逻辑等。提单页面涉及的接口可谓复杂异常，而且QPS还是很高的。通常，这个接口的逻辑会被一个专门的导购服务聚合起来。聚合服务更合理。其他变化更容易说。简单调用其他服务的接口应该就够了。由于该接口的QPS会很高，所以要采取熔断降级的措施。对于非主链路服务，在高并发的时候，应该降级，就必须降级，不能拖累主链路的下单流程。这里的绑定列表其实是一个比较复杂的部分。这种实现方式一般以子订单的形式实现，有的实现方式是一个独立的并行订单，有的是独立于另一个服务。具体实现方法不评价，但是复杂度真的很复杂。几个订单混在一起。要保证最终订单的一致性，必须所有的订单都下单成功，而对于支付来说，合并支付和反向退款也是很复杂的事情。提单页面后，进入真正的订货和付款流程。不同企业的订购流程可能不一致。如果能力支持到位，借助流程编排可能会容易一些。相反，为了兼容很多不同的业务，必须要抽象出足够通用的逻辑，但这也会让简单的业务变得复杂。而如果是ifelse为了简单起见，也可以快速架起架子，但以后要承载更多不同的业务场景，就变得极其被动了。所以，中台的能力应该是在现有业务足够清晰之后的抽象，而不是无所事事的中台。逆向交易的通常考虑必须是闭环。这个词很好，包括我们平时做设计方案的时候。只能进出的是貔貅。众所周知，貔貅没有菊花，让人难受。取消订单和退款通常与付款相互作用。对于复杂的业务逻辑，有大量的优惠券、红包、积分、会员权益抵扣等，会让支付变得非常复杂。支付很爽，反正传完参数就完了。到了退款的时候，因为各种权益和分红规则，很难退款。对于支付，这部分能力不行。抽象，更多的计算逻辑还是会由交易来承载。合约性能一般来说，异步形式更好。下单后发放积分、优惠券、红包是合同的一部分，然后安排发货、送货、签收也是合同的一部分。通常的形式是监听下单或支付成功的消息，消费后调用下游服务的接口。只要调用成功，就意味着合约的履行成功，最终的履行成功应该由下游服务来保证。当然，对于涉及物流配送的复杂合同履行流程，就没有那么简单了。很多JVM的底层技术细节你只了解吗？面对JVMCrash或性能调优问题，你是否束手无策？面对上层Java应用中偏离预期的行为，您是否一头雾水？本文转载自微信公众号“爱小仙”，可通过以下二维码关注。转载本文请联系艾小仙公众号。
