[[394931]]

中臺(tái)的概念說了好多年了，起源就是芬蘭的游戲公司supercell，之后阿里就提出了大中臺(tái)小前臺(tái)的戰(zhàn)略，然后和瘋狗一樣侵蝕了中國。

很多小公司為了顯得牛逼，管他呢，干他，就要硬懟個(gè)中臺(tái)出來，反正有個(gè)名字叫出來就顯得很叼的樣子。

其實(shí)然并卵，中臺(tái)的目的還是為了更快的能承接業(yè)務(wù)的需求，釋放開發(fā)的重復(fù)勞動(dòng)。

這些年也經(jīng)歷了從交易到金融中臺(tái)的體驗(yàn)，對(duì)中臺(tái)也算是有個(gè)比較粗略的理解，這些年的中臺(tái)真的有沒有那么好，甚至于現(xiàn)在想到什么業(yè)務(wù)就想搞中臺(tái)，想做什么就想往中臺(tái)遷移，好像中臺(tái)就是萬能的，沒有中臺(tái)既不能顯示自己的能力，又不能突出自己的水平。

今天，我就談?wù)勚信_(tái)，先談?wù)劷灰字信_(tái)吧。

中臺(tái)架構(gòu)

任何一個(gè)新生事物的誕生，隨之而來都會(huì)引發(fā)一系列的問題。

就拿中臺(tái)來說，最開始的探索我想無非就是沉淀、抽象通用的業(yè)務(wù)能力，達(dá)到快速交付的目的，而后隨著架構(gòu)的調(diào)整，又會(huì)衍生出對(duì)應(yīng)的組織中臺(tái)、技術(shù)中臺(tái)、數(shù)據(jù)中臺(tái)等等。

通常，我們平時(shí)最多說的中臺(tái)能力就是業(yè)務(wù)中臺(tái)，比如用戶中臺(tái)、商品中臺(tái)、交易中臺(tái)、庫存中臺(tái)、營(yíng)銷中臺(tái)、金融中臺(tái)等等，這些通用的能力無論對(duì)于哪個(gè)公司的業(yè)務(wù)來說都應(yīng)該是不可或缺的一部分。

對(duì)于前臺(tái)來說，存在一點(diǎn)改變，比如BFF(backend for frontend)的概念，也叫做面向前端的后端。

通常，對(duì)于C端APP、PC、H5、開放平臺(tái)等這些不同的前臺(tái)對(duì)于數(shù)據(jù)的要求是不太一樣的，為了適應(yīng)這些變化，針對(duì)每個(gè)端都整一個(gè)BFF作為數(shù)據(jù)的聚合、裁剪，也可以承載鑒權(quán)、限流等一些通用的能力。

這樣的架構(gòu)方式就把傳統(tǒng)的一些網(wǎng)關(guān)的能力和BFF放在了一起，當(dāng)然也可以剝離開，更優(yōu)的解法我想還是通過中間件的能力配置方式就能達(dá)到數(shù)據(jù)聚合、裁剪的能力，同時(shí)可以兼有路由、鑒權(quán)、限流等等。

中臺(tái)沉淀的是通用和抽象能力，原本雜糅在一起的業(yè)務(wù)邏輯和能力就有了清晰的界定，一些傳統(tǒng)的業(yè)務(wù)能力將會(huì)被劃分到業(yè)務(wù)后臺(tái)的概念中，比如一些CRM系統(tǒng)，財(cái)務(wù)管理系統(tǒng)，用戶管理這些。

架構(gòu)就是類似這樣，接下來說具體的交易中臺(tái)的建設(shè)。

交易中臺(tái)

交易中臺(tái)核心的3個(gè)部分就是正向交易、逆向交易、履約，無論做哪些抽象的能力，都離不開這3個(gè)模塊。

一般在團(tuán)隊(duì)規(guī)模不大的時(shí)候，這3個(gè)能力都可以放在一起維護(hù)，完全沒有什么問題，主要服務(wù)本身可以承載不用業(yè)務(wù)線的需求，能夠?qū)ν廨敵鐾ㄓ玫?個(gè)能力即可。

當(dāng)然，更加具體的業(yè)務(wù)應(yīng)該由業(yè)務(wù)本身來決定是什么，這里只會(huì)描述最基礎(chǔ)應(yīng)該具有的能力。

而當(dāng)業(yè)務(wù)的體量上升之后，就會(huì)面臨更多的拆分的必要，比如訂單查詢、下單、支付、逆向取消退款、履約拆分形式。

正向交易

讓我從提單頁、訂單確認(rèn)頁開始說起，一般來說，提單頁的信息非常多，我們要顯示購買的商品信息、還有用戶的等級(jí)、積分、能用的優(yōu)惠券、價(jià)格、剩余的庫存、支付方式等等，有的還有一些搭售的商品，具體還有怎么選擇最優(yōu)的組合方式，搭售商品的展示邏輯等等。

提單頁涉及到的接口可謂是復(fù)雜的變態(tài)，而且QPS還高，通常這個(gè)界面的邏輯會(huì)由專門的導(dǎo)購服務(wù)來做聚合，當(dāng)然也有的是讓交易本身做這個(gè)聚合的邏輯，不過我認(rèn)為由導(dǎo)購的服務(wù)來聚合更為合理一點(diǎn)。

其他的變化都比較好說，單純的調(diào)用其他服務(wù)的接口應(yīng)該就可以滿足，由于這個(gè)界面的QPS會(huì)非常高，所以要做好熔斷降級(jí)的措施，對(duì)于非主鏈路的服務(wù)在高并發(fā)的時(shí)候該降級(jí)的就一定要降級(jí)，絕對(duì)不能拖累到主鏈路的下單流程。

這里搭售單其實(shí)是一個(gè)比較復(fù)雜的部分，這個(gè)實(shí)現(xiàn)方式一般是用子訂單的形式來實(shí)現(xiàn)，也有的實(shí)現(xiàn)方式是一個(gè)獨(dú)立的平行訂單，還有的是獨(dú)立到另外一個(gè)服務(wù)，具體實(shí)現(xiàn)方式不做評(píng)價(jià)，但是復(fù)雜是真的復(fù)雜，幾個(gè)訂單交雜在一起，要保證最終下單一致性，必須都下單成功，而且對(duì)于支付來說合并支付、逆向退款也是非常復(fù)雜的一件事情。

提單頁之后，就進(jìn)入到真正的下單支付環(huán)節(jié)，下單的流程對(duì)于不同的業(yè)務(wù)來說可能不太一致，能力支持到位的話借助流程編排可能稍微輕松一點(diǎn)，反之為了兼容多種不同的業(yè)務(wù)必然需要抽象出足夠通用的邏輯，但是這樣也會(huì)使得簡(jiǎn)單的業(yè)務(wù)變得更加復(fù)雜。

而如果為了圖簡(jiǎn)單，全部都是if else的話，也能快速搭起來架子，但是后續(xù)承載更多不同業(yè)務(wù)場(chǎng)景將會(huì)變得無比被動(dòng)。

所以中臺(tái)的能力應(yīng)該是對(duì)現(xiàn)有的業(yè)務(wù)足夠清晰之后再做的抽象，而不是啥也沒有上來就要干塔喵的中臺(tái)。

逆向交易

通常的考量肯定是要閉環(huán)的，這個(gè)詞倒是很好，包括我們平時(shí)做設(shè)計(jì)方案的時(shí)候肯定也是如此，光進(jìn)不出的那是貔貅，眾所周知，貔貅是沒有菊花的，難受。

訂單的取消、退款更多的時(shí)候和支付的交互，對(duì)于復(fù)雜的業(yè)務(wù)邏輯，存在各種優(yōu)惠券、紅包、積分、會(huì)員權(quán)益扣減一大堆的就會(huì)讓支付變得非常復(fù)雜。

支付的時(shí)候很爽，反正傳參就完了，真正到了退款的時(shí)候，對(duì)于各種不同類型的權(quán)益使用、分潤(rùn)規(guī)則將會(huì)導(dǎo)致退款非常難，對(duì)于支付來說這一部分的能力并不好抽象，更多的計(jì)算的邏輯還是會(huì)被交易承載。

履約

履約一般而言異步的形式會(huì)比較更好一點(diǎn)，下單后發(fā)放積分、優(yōu)惠券、紅包屬于履約，之后安排配送、發(fā)貨、簽收也都屬于履約。

通常的形式是監(jiān)聽下單或者支付成功的消息，消費(fèi)之后調(diào)用下游服務(wù)的接口，只要調(diào)用成功就代表履約成功，履約的最終成功應(yīng)該由下游服務(wù)來保證。

當(dāng)然，對(duì)于比如復(fù)雜的履約流程，涉及到物流配送等，那就不是這么簡(jiǎn)單了。

很多JVM的底層技術(shù)細(xì)節(jié)你是否只了解表面?

面對(duì)JVM Crash或性能調(diào)優(yōu)方面的問題時(shí)你是否會(huì)束手無策?

面對(duì)上層Java應(yīng)用發(fā)生的偏離預(yù)期的行為是否會(huì)不知所措?

本文轉(zhuǎn)載自微信公眾號(hào)「艾小仙」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系艾小仙公眾號(hào)。