支付“清結算”體系的設計方法

我們知道，每一筆支付最終都要進行結算，一般會有眾多參與者或利益方，在完成之後，算清相關的利益關係，完成利益分配。本文作者對完成利益分配的“清算系統”進行了詳細的闡述分析，一起來看一下吧。

支付完成以後進行履約，履約完成以後就需要清算各方利益並最終進行結算，清結算體系與支付體系並行是支付範疇另一個非常龐大的體系。

一、清算系統設計

我們都知道一筆支付最終都是要進行清算的，業務一般都會有眾多參與者或者利益方，事做完以後，算清楚相關的利益關係，完成利益分配。今天我們就來講一講這個算清楚賬完成利益分配的系統“清算系統”。

1. 清算系統概述

我們先看下清算的定義以及銀聯的清算的含義。

《支付清算組織管理辦法》規定：

支付清算：支付指令的交換和計算

支付指令：參與者以紙質、磁介質或電子形式發出的，辦理確定金額的資金轉賬命令

支付指令的交換：提供專用的支付指令傳輸路徑，用於支付指令的接收、清分和傳送

支付指令的計算：對支付指令進行彙總和軋差

參與者：接受支付清算組織章程制約，可以傳送、接收支付指令的金融機構及其他機構

銀聯的支付清算包括淸分和資金劃撥兩個環節：

1）淸分

對交易日誌中記錄的成功交易，逐筆計算交易本金及交易費用（手續費、分潤等），然後按清算物件彙總軋差形成應收或應付金額。簡言之，就是搞清楚今天應該向誰要多少錢？應該給誰多少錢？

2）資金劃撥

透過特定的渠道和方式，完成應收應付資金的轉移。簡言之，就是明確透過何種渠道，拿回應收款、付出應付款。

從上面的定義可以看出，清算最核心的其實就是清分這個過程，也就是算清楚各方應收應付的這個過程。今天我們重點講的就是這個過程，以及記賬的過程。而承載這個過程的系統，我們稱為清算系統。

2. 清算系統的位置

我們在一張支付小票這篇文章裡提出過“311架構模型”，在這裡我們可以看到清算系統的位置，在交易系統之後；這樣的話我們可以理解為，清算系統在訂單，交易，支付之後。上述三者都有可能基於本身的業務來請求清算，比如基於訂單清算商家結算款，基於交易計算卡券營銷等成本，基於支付計算通道成本等，如圖1所示：

圖1 結算系統所處位置

3. 清算業務架構

清算系統整個結構由以下幾部分組成。之前在O2O清結算實戰中我們詳細講過一次，主要包括上游請求系統、商家模型子系統、計算核心、計費子系統、賬務前置模組。後面會詳細講解每一個模組的職能以及設計關鍵點，如圖2所示：

圖2 清算系統架構

4. 上游請求系統

簡而言之，有清分需求的業務系統都可以稱為清算系統的上游，向清算系統發起清算請求，比如訂單、交易、支付。上述三者都有可能基於本身的業務來請求清算，比如基於訂單清算商家結算款，基於交易計算卡券營銷等成本，基於支付計算通道成本等。

5. 物件模型

物件模型就是你算出來的應收應付的債權物件，以及物件之間的關係。比如外賣平臺的一個訂單，可能會涉及到眾多的利益物件，比如外賣平臺要抽傭，提供飯餐的商家要餐費，騎士小哥要快遞服務費，騎士小哥的保險費，這些需要完成訂單的分賬；而外賣平臺還可能有很多渠道或者合夥人，需要給渠道和合夥人進行分潤等。

分賬就是將一款項分成多份給多方；而分潤其實就是平臺將計算所得例如分給多個分潤方。

一個公司的業務可能不同的業務會有不同的物件模型，比如單一的商家，有合夥人的商家，有渠道商的商家，還有服務商平臺商的商家。所以每一類訂單會有不同的商戶模型，進行計算時，計算的維度會有不同。

那麼我們抽象出常見的集中物件關係模型，如圖3所示：

圖3 常見物件關係模型

在商家註冊時，或者入駐時，在物件模型子系統生成他的物件模型，以及模型對應的物件關係。比如你通過了好友的邀請註冊了一個網站，那麼好友就成了你的合夥人了，那麼你的物件模型就是“合夥人-使用者模型”，當你有了消費時，會去計算給你好友作為你的合夥人的分成。

6. 計費規則子系統

計費子系統核心職能就是維護計費規則，基於算賬服務的請求返回計費模式以及引數值。比如單商家模型需要計算平臺的資訊服務費，那麼透過基礎引數請求計費子系統獲得資訊服務費的計費模式（按比例，固定金額，按單筆階梯還是累計階梯），拿到計費規則以後便可以計算出資訊服務費數值。

所有最核心的就是要基於業務特點抽象出計費規則的模型。

一個是匹配的模式，就是你要用什麼方法去到規則池裡找到規則，比如條件法，就是一組引數去匹配到規則，這個也是最常用的，那麼你就需要為不同的計費型別設定不同的匹配條件組，比如例子中透過“類目+城市”去找規則，這樣的話再匹配條件裡可以設定靈活的條件組。

然後就是規則的設定，一條規則應該有哪些維度組成，這樣我們將每一個費用的計算認為是一個函式。

分成費用=f(x)=g{ j(a) , k(b,c) , l[y,z, p(e,r,u) ] }

那你規則就需要能夠使這個符合函式得到f（x）的值。

分成模式：固定金額，固定比例，按單筆階梯，按累計階梯，遞減等。

下面是在選擇了模式以後要配置的規則引數：

頻率：就是在遞減時，遞減的頻率是按月還是按日還是按年

首月：我們設定一個首月的數值，也就是遞減的期初值

遞減金額：每次減多少

最低金額：減到多少就固定下來了

看一個計費規則配置的示例，如圖4所示：

圖4 合夥人分成計費規則配置

基於上面的一個配置器，我們可以配置出非常多的規則，那麼基於不同的費用的配置模板我們就可以配置出無窮個計費的規則了，如圖5所示：

如圖5 合夥人分成計費規則列表

7. 算賬服務

一個清算請求來了以後，不同的清算型別我們的計算任務是不一樣，計算的模式也是不一樣的，計算的結果也會不一樣。所以算賬模型我們同樣需要設計抽象出來，比如首先是透過清算型別確定清算的模板，基於清算模板我們就知道了應該計算哪些費用以及做什麼任務，然後逐個去計算每一個費用即可，對於整個計算流程裡如果需要做一些處理的進行處理即可。

關於分潤和分賬，基於不同的物件模型，我們可以知道哪些是要算分潤，哪些是要算分賬，我們用下面的這個代理商，商家，分賬方來看，如圖6所示：

圖6 分賬與分潤

8. 清分結果

我們在一張小票看透支付清結算架構中講了清分計費的結果是什麼樣的了，比如下面，我們算出來這筆外賣單的相關應收應付以及所屬主體物件，如表1所示：

表1 清分明細

這是清分明細，那麼是不是需要彙總軋差，這個看業務需要，一般情況下我們可以選擇單筆入賬的，也就是算出一筆入一筆。

9. 記賬服務

清分完成以後，我們就需要做入賬處理了，這個我們在賬戶系統設計從入門到精通講得比較清楚，大家可以複習一下。

二、結算系統設計

每個月公司要給員工結算工資：陳老師在京東開了一個店鋪，定期京東需要給我結算貨款；你請了一個保姆，每個月要給阿姨結算服務費…。等等，結算場景我們並不陌生，但是怎麼設計一個結算系統，你知道麼！今天我們就好好聊一聊（最後有原型頁面）。

1. 什麼是結算

定義：將平臺的代收款支付給平臺商家的資金轉移過程。

展開來講就是現在有很多平臺比如滴滴，貨拉拉，京東商城，作為一個服務平臺上面有很多商家（我們將滴滴司機也成為商家），使用者在平臺購買商品或者服務，服務完成後，平臺需要按照協議約定將服務款抽取一定費用後的剩餘部分結算到商家的平臺結算賬戶中或者直接付款支商家銀行賬戶的資金劃轉過程。

結算名詞解釋，如表2所示：

表2 結算常見名詞解釋

2. 結算的模式

結算我們常見的有2種模式：

結算到銀行卡：直接將結算款項直接付款到商家簽約的結算銀行卡賬戶中

結算到虛擬戶：將虛擬結算款結算入賬到商家在平臺開通的結算戶中，後續可以商家自主提現

像微信支付寶在開通支付產品時都會獲得一個商戶號，每個商戶號會有一套賬戶用於收款和結算，並且簽約繫結一張結算卡，次日會將上一日的結算款先結算之虛擬戶在一筆結算之繫結的對公戶。當然結算到對公戶的比例可以自己設定，可以全額結算也可以部分結算，將一部分資金留在虛擬戶裡，用於次日的退款或者其他付款需求。

3. 關於結算產品

結算產品其實就是指支撐不同型別結算模式的結算能力：

T1結算：工作日結算，當天的服務款，在下一個工作日結算

D1結算：日然日結算，當天的服務款，在下一個自然日結算

D0結算：日然日結算，當天的服務款，在當天結算

S0結算：交易完成後即可結算，按照訂單號逐筆進行結算，像借貸的還款，一般逐筆

結算功能，使用者可以選擇系統自動結算，也可以選自主發起結算。

自動：系統按照結算協議，在約定時間自動將服務款支付給結算卡

自助：商家需要自主的在服務平臺完成可結算週期內的款項的結算申請

結算簽約，商家入駐平臺時會進行資質認證以及簽約一款適合自己的結算產品。

4. 結算場景

上面還是比較抽象，我們列舉幾個容易理解的結算場景：

支付公司將收單款結算給商戶

電商平臺將交易款結算給商家

滴滴平臺將打車錢結算給司機

電影院將票房結算給各方

公司將工資結算給員工

所以，簡而言之，結算就是將屬於別人的錢給到別人。

5. 如何評價結算產品的好壞

評價結算系統的好和壞一個是站在公司角度，另一個是站在使用者角度。

站在公司角度：準確率高，資金安全，能容使用者滿意，投訴少

站在使用者角度：支援銀行多，服務好就是後臺好用，到賬快，成本低

6. 結算的業務架構

業務完成後，到了結算節點，賬務系統按照結算週期將已經入賬待結算資料打包後推送給結算系統，結算系統對結算資料進行處理加工後生成結算記錄和結算明細；然後請求賬務系統進行結算打款，賬務系統請求賬戶中心扣款之後呼叫打款中心進行打款申請，如圖7所示：

圖7結算的業務流程

7. 結算系統系統架構

結算系統的產品架構如圖8所示：

圖8 結算系統的產品架構

對於不同結算產品，需要定時任務的管理去推動結算的進行。

商戶後臺：商家自主發起結算，查詢結算資訊，變更資訊的後臺

運營後臺：公司內部運營的操作檯

賬務系統：為結算系統提供結算資料，接受打款申請以及反饋出款通知

墊資系統：針對D0，S0的結算請求申請墊資的受理方

計費系統：計算結算時商家需要支付的費用，比如一筆2元

商家系統：用於查詢商家的相關結算需要的資訊

8. 結算系統業務實體結構

從更小的顆粒度審視結算各資訊記錄之間的關係以及每個資訊單元所記錄的內容，便於對結算系統有個更精細的認知。

結算請求：一次同時結算所有可以結算的商家，記錄多少個商家

結算記錄：一個商家生成一條結算記錄，本次結算多少錢，以及打款狀態

結算明細：按照商家結算的支付產品型別記錄每個支付產品結算多少筆，多少錢

結算資訊：記錄這個商家簽約了什麼結算產品，結算的時間管理等

比如某一日一共結算了100個商家（一次結算請求），其中A商家結算了1000塊錢（一條結算記錄），其中A商家的快捷支付結算了100筆500塊錢，閘道器支付結算了600筆500塊錢（結算明細），如圖9所示：

圖9 結算單據之間的關係

9. 業務流程

結算業務的處理流程如圖10所示：

圖10 結算業務處理流程

10. 系統互動時序圖

結算系統處理時序如圖11所示：

圖11 結算系統處理時序圖

11. 詳細流程圖

每個處理階段的詳細邏輯流程圖，篇幅有限，為了更加易讀，簡化了流程圖，僅繪製了核心的節點，如果有不明白的地方可以加入產品學習群，深度交流。

資料準備過程如圖12所示：

圖12 結算過程中的資料準備

結算處理過程如圖13所示（以T1結算為例）：

圖13 結算處理

打款處理如圖14所示：

圖14 打款處理

結算狀態流轉如圖15所示：

圖15 結算狀態流轉

12. 結算賬單

平臺按照結算明細，以不同的維度生成結算賬單，商戶可以在後臺下載結算賬單，或者透過介面獲取賬單，這個大家可以調研一下微信或者支付寶後臺，這裡不再詳述。

拓展閱讀1：“詐金花”中的清算思維

很多人在團建或者日常休閒娛樂時都會選擇玩一些紙牌遊戲；比如我們今天的主人公“詐金花”，它就是一款這樣的多人紙牌遊戲。遊戲過程中需要考驗玩家的膽略和智慧，每人三張牌，張張有玄機。三張牌會組成一下情況，相較之下定輸贏，

從上到下每類越來越小，同類之下再比：

較豹子（AAA最大，222最小）

同花順（AKQ最大，A23最小）

同花（AKQ最大，352最小）

順子（AKQ最大，A23最小）

對子（AAK最大，223最小）

單張（AKJ最大，352最小）

當然這是一個博弈的過程，因為全程大家不知道對方是什麼牌，就跟斗地主一樣，開始先在桌面投遞基礎籌碼，然後過程中需要不斷地迴圈下注，以致桌面的籌碼越來越多，最終勝者的收益也會越來越誘人。

但是遊戲過程中會有人因為擔心更大風險選擇“不跟”而退出，這個過程可能牌小詐走牌大，是實力、勇氣和智謀的較量，是冒險家的遊戲；最後勝者通吃，拿走桌面所有的籌碼……

不過今天我們不玩遊戲，而是玩點不一樣的支付，解密一下這個遊戲中隱藏的“支付清算思維”。

1. 陳老師的“金花局中局”

元旦期間陳老師約了4位朋友一起炸金花，組成了一個“5人金花局”，在我拿出紙牌即將開始的一瞬間，突然眼前一道白光，大腦一陣眩暈，待我清醒後，我竟然到了一個大大的房間裡，站在一個白板前，下面做了很多大佬，喬布斯、張小龍、俞軍、梁寧等，他們都直勾勾地盯著我……

只見後面顯示屏上有一行大字“陳天宇宙‘支付奧妙’全球演講巡演-深圳站”。

我是見過大世面的，調整懵逼神態以後，在白板上寫下了一行字“為詐金花設計一套清算體系”，然後就開始了我的演講。

2. 清算賬戶設定

一共有5個人參與遊戲，為每個人設定一個遊戲清算賬戶，並且設定一箇中間待清算賬戶，如圖16：

圖16 清算賬戶設定

3. 清算貨幣設定

玩遊戲我們可以選擇一些物件作為代理貨幣，比如花生或者紙牌等，然後約定這些物品短期的貨幣信用，僅在遊戲中有效。並且約定遊戲代理貨幣和真實貨幣之間的匯率，比如1：10，如圖17所示：

圖17 遊戲幣與真實貨幣匯率

4. 發行和分配遊戲貨幣

遊戲期初陳老師作為央行角色決定發行100個花生作為遊戲的全量貨幣，並且每人發放20個花生作為遊戲基礎籌碼，如圖18所示：

圖18初始化賬戶餘額

這樣我們就為遊戲設定了一個桌面的清算系統，該清算系統採用實時多邊淨額清算模式。

我們下注，追加砝碼往桌子上扔花生的過程就是以花生為支付貨幣，支付籌碼並且請求實時清算的過程，經過桌面清算以後我們可以實時看到桌面籌碼總數量的變化，這個總數量就是本局當前的待清算總額，遊戲每個場景的清算過程如下。

5. 開局下注清算

好了這是一個新的開局，每人獲得了三張牌，牌的點數如圖，並且往桌子上投遞1個花生做為期初籌碼，此時經過桌面清算系統的實時清算我們可以看到當前待清算籌碼總量為5個花生，也就是50元人民幣，大家都垂涎欲滴摩拳擦掌，如餓狼一般盯著這筆象徵著“一次呷哺呷哺單人套餐還可以加一個雞腿”的巨大的財富，如圖19所示：

圖19開局下注後的賬戶變化

這時桌面每個清算賬戶放一起我們可以理解為是詐金花遊戲的資金池，該資金池總貨幣體量是100個頭寸，而每次花生在不同清算賬戶之間的流轉我們可以理解為是資金的流動性，流動性實現了不同清算賬戶之間資金的劃撥，但並不改變整個資金池的貨幣體量。

而每次資金的流動也就是支付，我們可以認為是一次支付清算，而每個人的用來投遞花生以及數手裡或者桌面花生的手可以認為是支付系統。

6. 追加砝碼清算

在這個過程中，大家可以選擇追加砝碼看不看別人的牌，下一位就需要追加不下於前者的砝碼，並且選擇看還是不看。如果看牌的話牌小者就會出局，那麼本局已經投遞的砝碼就打水漂了。這個遊戲的過程大家可以認為就是我們的經濟活動中的交易場景，經過一陣廝殺較量以後籌碼分佈成了如下局面，但沒到最終輸贏難分，戰事非常膠著，如圖20所示：

圖20遊戲過程中追加砝碼

以上過程我們可以稱為單局“局中”實時清算過程。

7. 個體間的拆借清算

這時候經過一陣廝殺，王八手裡沒有花生了，也就是沒有籌碼了，但是此時他戰至正酣，不忍退出，就向在座的手裡有花生的發起了拆借訴求。最終以60元人民幣購買了陳老師6個花生，完成了資產拆借，如圖21所示：

圖21成員間的拆借

8. 單局“局末”多邊淨清算

到了陳老師喊牌了，陳老師不忍心讓大家都傾家蕩產，追加了5砝碼後選擇開牌，如圖22所示：

圖22開牌

這時本局以陳老師豹子牌點最大而獲勝，獲得了桌面全部籌碼，不好意思桌面的所有牌都歸我了，如圖23所示：

圖23結束後的桌面清算

9. 全域性多邊淨額清算

天色已晚，大家都困了，這時候協商不玩了，改日再戰，這時候開始進行多邊清算了，以每個人手裡的花生基數為清算依據，每個人需要支付人民幣購買他人的花生以獲得20枚期初的花生數量，或者賣出手裡的花生獲得人民幣以實現期初的20枚花生，清算後大家手裡的花生又回到了期初的20，只不過這次清算是需要進行人民幣進行清償推動的，如圖24所示：

圖24全域性多邊淨額清算

以上的清算過程存在一些小的錯誤，感興趣的可以找出，並在留言處回覆討論，這個過程就是對賬的過程，那麼就需要對賬系統來實現了。

10. 遊戲總結

清算系統模型，如果要設計一套支付清算系統，那麼從上面我們可以看出至少需要有如下的子系統和元素組成，清算賬戶、支付系統、交易系統，貨幣體系，交易場景等。

清算基礎：我們可以從上面看出清算的基礎就是清算賬戶賬戶，對整個過程提供賬戶資金頭寸管理以及實現資金的支付清算。

清算模式：上面我們用到了實時多邊淨額清算模式，除此之外還有實時全額清算模式，實時雙邊清算模式。

11. 如夢清醒會心一笑

此時天塌地陷紫金錘，游龍出海驚天變，一陣天動地搖之後，有一道白光……這時候陳老師一個琅蹌差點打翻了牌桌上的茶杯……說時遲那時快之間張三上來扶住了我說到“陳老師怎麼了，是不是又起早寫文章有點低血糖啊”。

此時我稍作鎮定，會心一笑“哈哈 哈哈 沒事 今日必定大勝 開牌……”新年的鐘聲敲響了，屋外已經飄起片片雪花，投眼望去依然燈火通明，每一個窗戶透出的燈光裡白霧下可能都是我們對2022年幸福的期許……

拓展閱讀2：工資結算可以這麼做

現在很多平臺都有個人商家或者說是服務者，就像外賣平臺的騎手，貨運平臺的司機，家政平臺的阿姨，這些個人勞動者在平臺提供服務，平臺進行收入的結算。雖然有很多靈活就業平臺都有成熟的解決方案，或是使用標準的清結算平臺完成這部分的服務收入結算，這篇文章將介紹可能不常見的設計方法，但是裡面的一些設計思路可能會有一些啟發。

1. 結算資訊

我們假定為一個貨運平臺設計司機的收入結算，每個司機按照不同的週期進行結算，特級司機按日進行結算，高階司機按周進行結算，普通司機按月進行結算；結算方式是按照約定週期主動打款給司機簽約的銀行卡當中，所以我們要有一個基礎的結算資訊資料，如表3所示：

表3 結算物件資訊管理

2. 結算單

該結算單跟我們之前講的賬戶有點區別，這個單據更像一個工資條，但是其中有些欄位具備賬戶的部分屬性，該結算單的資訊更加多，而且每個司機每個結算週期會建立一個本週期的結算單據。該結算單據包含一些統計類的欄位，用於記錄一些金額，就像我們工資條中的公積金，養老保險，稅，應付工資等，例如我們篩選出王五近半年結算單據，如表4所示：

表4 結算單記錄

實發收入不能為負，但是實際情況肯定有場景出現本期純負收入的場景，為了保證這個欄位不為負，我們設定另外2個欄位，一個是本期欠款，來記錄本期總實發的負額部分；上期欠款則是結轉上期的欠款金額，本期的上期欠款等於上期的“本期欠款+上期欠款”。

3. 結算資訊建立

司機簽約認證以後由司機crm來申請建立該司機的結算賬戶，也就是我們上面的結算資訊，並且為其建立第一條結算單據。

4. 結算單據的生成

按照司機的結算週期定期的建立本週期的結算單據，並且實時的根據清分結果更新結算單據的相關資料清分司機在完成一單收入時，由訂單系統推送訂單到清分系統，完成該單據相應費用的計算，比如本單平臺佣金，稅等，然後計算本單的司機所得，基於計算結果去更新該司機的結算單據；獎金和罰款同理。

5. 期末賬務處理

因為借宿那單據中有幾個欄位需要在本期完結以後才能進行統一處理，比如欠款的處理。所以在一個結算週期結束的第二天凌晨，打款之前，我們要完成期末賬務的處理，比如彙總生成本期欠款，彙總生成本期實發等等。

6.打款

到了結算週期結束的第二天凌晨基於結算單據的“實發收入”生成打款訂單，請求打款系統進行打款。

7. 學習會越來越有效率

我想前面我們有大量的介紹清結算賬戶等相關的內容，大家現在應該很容易理解任何一種結算手段和方式，學習肯定是越來越輕鬆，接收內容的效率越來越高。

就像我最近看很多支付類書籍，速度越來越快，因為你單單看到標題，然後掃描一下正文中的關鍵字眼基本就知道他在講什麼，已經瞭解的東西，就一掃而過，快速地掃描一下，大腦提取一次同類知識點，補充書中的新內容即可。所以說學習的越多，後面的升級效率越快……量變終會引起質變。

最舒服的工作，可能不是工作本身，而是你對工作的把控力；如果任何一次需求、任何一次溝通，只要對方說出某幾個關鍵字，你已經有了最好的答案，我想這就是最舒服的工作，因為你從不會因為“難度”而痛苦，加油，讓自己面對的一切都變得簡單，即使在別人眼裡，它是巨大的挑戰！

拓展閱讀3：“三層式”清結算中臺

我們都知道清結算，因為課堂剛剛完結了這個專欄的20節課；我想我們很多人也都知道中臺，因為這個概念活了很長時間。那麼什麼是“清結算中臺”呢？我想也很容易理解，無非就是用“中臺的理念”建設“清結算體系”。

那這樣的話，要想做好中臺，首先就要理解什麼是中臺，中臺的核心是什麼？清結算的相關係統如何向中臺靠攏，做成中臺的樣子…。。這是這篇文章要介紹的內容。

可以說我們在創造一種事物或者系統建設的理念和方法，那麼抽取這個理念和方法首先就需要挖掘其最核心最突出的特徵。清結算業務或者相關係統本身跟商品系統、購物車、訂單、服務履約等系統，除了功能模組不同以外本質沒有實質性差別，都是基於某項業務將功能集成了一個系統。

所以說在系統本身沒有最突出的特徵，最突出的特徵就必然從“中臺”這個系統建設理念上去挖掘。

什麼是中臺呢，中臺又有什麼最核心的特徵？我們常說的抽象通用能力，規避重複建設等這些是中臺的目的。而我們分析中臺的核心特徵可以概括為這樣一個模型：三層式。

如果將清結算體系規範成“三層式”去建設，那麼就是“清結算中臺”，這三層如圖25所示：

圖25三層式結算清結算中臺架構

1）業務層

清結算中臺要關注業務場景，為業務場景提供系統服務，多業務線、複雜的業務場景中的清結算業務是清結算中臺服務的物件，所以說清結算不再是獨立的一個個後臺系統，而是一個服務叢集，我們要基於“服務”去建設系統。

2）服務層

服務層是基於服務物件抽象出來的服務單元，就像我們去銀行辦事，大廳的接待員會接待你。傳統上來說她是個接待員，但是站在服務的角度，她提供了“接待服務”，雖然她還是她，雖然接待還是接待，但是已經大不同。基於接待服務去思考，我們會更關注服務本身，而不是她這個接待員。

所以清結算中臺，我們不再關注清結算體系內單獨的系統本身，而是去關注這套系統能向外提供的服務，以服務論影響。既然是“服務層”，那麼我們就需要去抽象這些服務，定義這些服務，以及設計這些服務的准入標準、流程、規範，以及這些服務的提供方式，API，MQ，SQL還是……

3）基礎層

這一側就如“接待員”一樣，是我們對外提供服務的能力基礎，所以我們可以稱之為“能力基礎層”，這一層是以系統能力為建設物件，比如清算計費的能力、賬務記錄的能力、賬戶凍結的能力。這些能力簡單的說就是我們曾經的叫“功能”的另一個說法，為了顯得我們是一個專業的中臺，我們對外宣稱，我們這不是簡單的功能，而是能力叢集。

這三層之間的關係，我們不如用一段描述來定義。公司的業務複雜，為了規避重複建設，搭建通用的系統，可以多業務線複用，未來新業務可以複用；我們基於業務場景進行抽象，抽象出原子化的服務單元；這些服務單元需要一系列的系統功能來支撐，而這些系統功能抽象出通用的系統服務能力，將這些服務能力進行封裝，構建成了一個能力叢集，所以說清結算中臺的未來要關注三個東西，如圖26所示：

圖26清結算中臺三個目標

基於業務場景構建基礎能力，反過來將基礎能力封裝出標準服務，去覆蓋更多的業務場景；那麼清結算中臺其實就是做下面的三件事，如圖27所示；

圖27清結算中臺三重點

對清結算中臺的能力叢集進行更簡潔的表達，將多個能力進行分組，對每一組從業務視角闡述，我們就可以得到清結算中臺的幾大服務叢集，如圖28所示：

圖28清結算中臺服務叢集

所以如果大家要做清結算系統，那麼就做好系統的架構和功能；如果要做清結算中臺，那麼就做好“三層式”，定義好每一層以及每一層之間的協同。然後在每一層內做好更細顆粒度的規劃和抽象，至少你會是一個合格的“清結算中臺”的樣子……

思維模型只不過是翻山越嶺滄海桑田以後對這段路途最刻骨銘心的歸納和抽象！

專欄作家

陳天宇宙，微信公眾號：陳天宇宙，人人都是產品經理專欄作家。多平臺支付領域專欄作者，十年資深產品；專注為10萬支付產品經理和支付機構以及企業提供深度支付內容和服務！

題圖來自 Unsplash，基於 CC0 協議

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。