[[394931]]

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

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

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

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

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

中臺架構(gòu)

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

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

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

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

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

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

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

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

交易中臺

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

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

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

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

正向交易

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

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

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

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

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

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

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

逆向交易

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

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

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

履約

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

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

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

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

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

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

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