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