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

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

一、清算系統設計

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

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種模式：

1. 結算到銀行卡：直接将結算款項直接付款到商家簽約的結算銀行卡賬戶中
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 協議

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部