中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

一、清算系統設計

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

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最?。?/li>
• 同花順（AKQ最大，A23最小）
• 同花（AKQ最大，352最?。?/li>
• 順子（AKQ最大，A23最?。?/li>
• 對子（AAK最大，223最?。?/li>
• 單張（AKJ最大，352最?。?/li>

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

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

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

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清結算中臺服務集群

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

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