[[394931]]

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

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

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

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

今天，我就談談中臺，先談談交易中臺吧。

中臺架構

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

就拿中臺來說，最開始的探索我想無非就是沉淀、抽象通用的業務能力，達到快速交付的目的，而后隨著架構的調整，又會衍生出對應的組織中臺、技術中臺、數據中臺等等。

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

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

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

這樣的架構方式就把傳統的一些網關的能力和BFF放在了一起，當然也可以剝離開，更優的解法我想還是通過中間件的能力配置方式就能達到數據聚合、裁剪的能力，同時可以兼有路由、鑒權、限流等等。

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

架構就是類似這樣，接下來說具體的交易中臺的建設。

交易中臺

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

一般在團隊規模不大的時候，這3個能力都可以放在一起維護，完全沒有什么問題，主要服務本身可以承載不用業務線的需求，能夠對外輸出通用的3個能力即可。

當然，更加具體的業務應該由業務本身來決定是什么，這里只會描述最基礎應該具有的能力。

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

正向交易

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

提單頁涉及到的接口可謂是復雜的變態，而且QPS還高，通常這個界面的邏輯會由專門的導購服務來做聚合，當然也有的是讓交易本身做這個聚合的邏輯，不過我認為由導購的服務來聚合更為合理一點。

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

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

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

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

所以中臺的能力應該是對現有的業務足夠清晰之后再做的抽象，而不是啥也沒有上來就要干塔喵的中臺。

逆向交易

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

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

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

履約

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

通常的形式是監聽下單或者支付成功的消息，消費之后調用下游服務的接口，只要調用成功就代表履約成功，履約的最終成功應該由下游服務來保證。

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

很多JVM的底層技術細節你是否只了解表面?

面對JVM Crash或性能調優方面的問題時你是否會束手無策?

面對上層Java應用發生的偏離預期的行為是否會不知所措?

本文轉載自微信公眾號「艾小仙」，可以通過以下二維碼關注。轉載本文請聯系艾小仙公眾號。