中臺的概念說了好多年了，起源就是芬蘭的遊戲公司supercell，之後阿里就提出了大中臺小前臺的戰略，然後和瘋狗一樣侵蝕了中國。
很多小公司為了顯得牛逼，管他呢，幹他，就要硬懟箇中臺出來，反正有個名字叫出來就顯得很叼的樣子。
其實然並卵，中臺的目的還是為了更快的能承接業務的需求，釋放開發的重複勞動。
這些年也經歷了從交易到金融中臺的體驗，對中臺也算是有個比較粗略的理解，這些年的中臺真的有沒有那麼好，甚至於現在想到什麼業務就想搞中臺，想做什麼就想往中臺遷移，好像中臺就是萬能的，沒有中臺既不能顯示自己的能力，又不能突出自己的水平。
今天，我就談談中臺，先談談交易中臺吧。
中臺架構
任何一個新生事物的誕生，隨之而來都會引發一系列的問題。
就拿中臺來說，最開始的探索我想無非就是沉澱、抽象通用的業務能力，達到快速交付的目的，而後隨著架構的調整，又會衍生出對應的組織中臺、技術中臺、資料中臺等等。
通常，我們平時最多說的中臺能力就是業務中臺，比如使用者中臺、商品中臺、交易中臺、庫存中臺、營銷中臺、金融中臺等等，這些通用的能力無論對於哪個公司的業務來說都應該是不可或缺的一部分。
對於前臺來說，存在一點改變，比如BFF（backend for frontend）的概念，也叫做面向前端的後端。
通常，對於C端APP、PC、H5、開放平臺等這些不同的前臺對於資料的要求是不太一樣的，為了適應這些變化，針對每個端都整一個BFF作為資料的聚合、裁剪，也可以承載鑑權、限流等一些通用的能力。
這樣的架構方式就把傳統的一些閘道器的能力和BFF放在了一起，當然也可以剝離開，更優的解法我想還是通過中介軟體的能力配置方式就能達到資料聚合、裁剪的能力，同時可以兼有路由、鑑權、限流等等。
中臺沉澱的是通用和抽象能力，原本雜糅在一起的業務邏輯和能力就有了清晰的界定，一些傳統的業務能力將會被劃分到業務後臺的概念中，比如一些CRM系統，財務管理系統，使用者管理這些。
架構就是類似這樣，接下來說具體的交易中臺的建設。
交易中臺
交易中臺核心的3個部分就是正向交易、逆向交易、履約，無論做哪些抽象的能力，都離不開這3個模組。
一般在團隊規模不大的時候，這3個能力都可以放在一起維護，完全沒有什麼問題，主要服務本身可以承載不用業務線的需求，能夠對外輸出通用的3個能力即可。
當然，更加具體的業務應該由業務本身來決定是什麼，這裡只會描述最基礎應該具有的能力。
而當業務的體量上升之後，就會面臨更多的拆分的必要，比如訂單查詢、下單、支付、逆向取消退款、履約拆分形式。
正向交易
讓我從提單頁、訂單確認頁開始說起，一般來說，提單頁的資訊非常多，我們要顯示購買的商品資訊、還有使用者的等級、積分、能用的優惠券、價格、剩餘的庫存、支付方式等等，有的還有一些搭售的商品，具體還有怎麼選擇最優的組合方式，搭售商品的展示邏輯等等。
提單頁涉及到的介面可謂是複雜的變態，而且QPS還高，通常這個介面的邏輯會由專門的導購服務來做聚合，當然也有的是讓交易本身做這個聚合的邏輯，不過我認為由導購的服務來聚合更為合理一點。
其他的變化都比較好說，單純的呼叫其他服務的介面應該就可以滿足，由於這個介面的QPS會非常高，所以要做好熔斷降級的措施，對於非主鏈路的服務在高併發的時候該降級的就一定要降級，絕對不能拖累到主鏈路的下單流程。
這裡搭售單其實是一個比較複雜的部分，這個實現方式一般是用子訂單的形式來實現，也有的實現方式是一個獨立的平行訂單，還有的是獨立到另外一個服務，具體實現方式不做評價，但是複雜是真的複雜，幾個訂單交雜在一起，要保證最終下單一致性，必須都下單成功，而且對於支付來說合並支付、逆向退款也是非常複雜的一件事情。
提單頁之後，就進入到真正的下單支付環節，下單的流程對於不同的業務來說可能不太一致，能力支援到位的話藉助流程編排可能稍微輕鬆一點，反之為了相容多種不同的業務必然需要抽象出足夠通用的邏輯，但是這樣也會使得簡單的業務變得更加複雜。
而如果為了圖簡單，全部都是if else的話，也能快速搭起來架子，但是後續承載更多不同業務場景將會變得無比被動。
所以中臺的能力應該是對現有的業務足夠清晰之後再做的抽象，而不是啥也沒有上來就要幹塔喵的中臺。
逆向交易
通常的考量肯定是要閉環的，這個詞倒是很好，包括我們平時做設計方案的時候肯定也是如此，光進不出的那是貔貅，眾所周知，貔貅是沒有菊花的，難受。
訂單的取消、退款更多的時候和支付的互動，對於複雜的業務邏輯，存在各種優惠券、紅包、積分、會員權益扣減一大堆的就會讓支付變得非常複雜。
支付的時候很爽，反正傳參就完了，真正到了退款的時候，對於各種不同型別的權益使用、分潤規則將會導致退款非常難，對於支付來說這一部分的能力並不好抽象，更多的計算的邏輯還是會被交易承載。
履約
履約一般而言非同步的形式會比較更好一點，下單後發放積分、優惠券、紅包屬於履約，之後安排配送、發貨、簽收也都屬於履約。
通常的形式是監聽下單或者支付成功的訊息，消費之後呼叫下游服務的介面，只要呼叫成功就代表履約成功，履約的最終成功應該由下游服務來保證。
當然，對於比如複雜的履約流程，涉及到物流配送等，那就不是這麼簡單了。
