本文已收錄在Github，關注我，緊跟本系列專欄文章，咱們下篇再續！

• 🚀 魔都架構師 | 全網30W技術追隨者
• 🔧 大廠分佈式系統/數據中台實戰專家
• 🏆 主導交易系統百萬級流量調優 & 車聯網平台架構
• 🧠 AIGC應用開發先行者 | 區塊鏈落地實踐者
• 🌍 以技術驅動創新，我們的征途是改變世界！
• 👉 實戰乾貨：編程嚴選網

聚焦銀行業務中最核心、最考驗系統功力的領域之一：司庫管理系統（TMS）。

面試一個頂級銀行或金融科技公司，面試官問：“你如何設計一個高可用的司庫系統？” 如果你只會説“搞個微服務”，那肯定涼涼。

本文剖析 TMS 的核心業務流，並手把手教你如何應用最新的微服務分佈式設計模式來解決其中的痛點。

1 TMS的核心定位與挑戰

1.1 核心業務：“管理銀行的錢和風險”

司庫系統的核心職能，用大白話講，就是管理銀行自身的流動性（現金）和市場風險。它像銀行的“中央大腦”，處理高價值、高頻率的金融交易。

主要業務類型

資金調撥、頭寸管理（現金預測）、外匯交易（FX）、貨幣市場交易（Money Market）、衍生品交易等。

挑戰（痛點）

1. 高價值/高風險： 任何一筆交易都是鉅額資金，對數據一致性和安全性要求極高。
2. 實時性/併發性： 市場行情變化快，交易決策和執行必須實時，在市場高峯期併發量巨大。
3. 複雜性： 一筆交易可能涉及多個內部系統（核心賬務、風控、清結算）。

2 核心業務流拆解：資金調撥與頭寸管理

以最基礎也是最核心的業務——跨部門資金調撥和實時頭寸管理為例進行微服務拆解。

2.1 業務場景：資金調撥

A賬户 B賬户。典型的分佈式事務場景。

步驟	業務操作	關鍵挑戰	理論落地
1. 交易錄入	交易員在前端錄入調撥指令。	數據校驗與暫存。	API Gateway & Anti-Corruption Layer (ACL)
2. 資金扣減	從調出賬户 A 扣減資金。	必須成功，否則需回滾。	事務性發件箱 (Transactional Outbox)
3. 資金增加	向調入賬户 B 增加資金。	必須與步驟 2 保持一致。	Saga 模式（編排或協調）
4. 賬務登記	登記到總賬系統。	最終一致性即可。	事件驅動架構 (EDA) + 最終一致性

2.2 架構落地

2.2.1 分佈式事務

用 XA 嗎？不，生產環境不用 XA！它性能差、鎖粒度大。最佳實踐：Saga 模式。

拆分服務：

• TradeService (交易服務)
• AccountService (賬户服務 - 負責扣減和增加)
• JournalService (總賬服務)

實現方式：編排 (Choreography) 或 協調 (Orchestration)。以 **AccountService **為例：

1. TradeService 收到調撥請求，先將指令寫入自己的數據庫，同時利用 事務性發件箱 模式（Outbox 表），確保業務數據和事件消息的原子性。
2. TradeService 向MQ發送 FUNDS_TRANSFER_REQUESTED
3. AccountService 消費事件，嘗試從 A 賬户扣減（事務 ）。

• 成功： 發送 FUNDS_DEDUCTED
• 失敗： 發送 FUNDS_DEDUCTION_FAILED 事件，觸發 TradeService 的補償事務（將請求標記為失敗）。

4. AccountService 消費 FUNDS_DEDUCTED 事件，嘗試向 B 賬户增加（事務 ）。

Saga 模式通過一系列本地事務和補償事務，實現了最終一致性，完美避開分佈式事務的性能瓶頸。

2.2.2 實時頭寸計算（Liquidity）

頭寸（Liquidity Position），銀行某時刻可用的資金餘額。需實時聚合來自所有交易（調撥、外匯、存款等）的變動。

最佳實踐：事件驅動架構 (EDA) + CQRS。

• TransactionService (交易服務)： 負責處理交易並生成事實 (Facts)，即資金變動事件（FUNDS_TRANSFERRED, FX_DEAL_EXECUTED）。
• PositionService (頭寸服務)： 訂閲所有資金變動事件，維護一個只讀的、優化的 Position 數據庫。

• 寫入 (Command)： 交易服務執行。
• 讀取 (Query)： 頭寸服務負責，專門針對快速查詢設計（如使用 Redis 或 MongoDB 預聚合數據）。

理論點亮：

• EDA： 將業務解耦，交易是命令，頭寸是結果。交易服務只關心執行，頭寸服務只關心計算。
• CQRS (Command-Query Responsibility Segregation)： 隔離讀寫模型。交易模型是複雜的寫模型，頭寸模型是簡單的讀模型，讀寫互不影響，保證查詢的低延遲。

3 關鍵理論概念與業務落地詞彙表

理論概念	通俗講解（比喻）	TMS 業務落地	面試官金句
Saga 模式	一系列環環相扣的本地事務，一個失敗了就啓動退貨（補償）流程。	跨服務（如Trade到Account）的資金調撥，確保兩邊資金變動要麼都成功，要麼都退回。	“我們採用 Saga 協調模式 確保跨賬户資金調撥的最終一致性，避免使用 XA 犧牲性能。”
最終一致性	“遲早會到的信件”：數據不會丟，但可能需要幾秒甚至更久才能在所有地方體現。	總賬登記、實時報表生成。交易完成了，但報表可能延遲幾秒刷新。	“對於風控報表等非核心實時查詢，我們接受最終一致性，通過 EDA 異步刷新。”
事務性發件箱	“把快遞單貼在包裹上一起打包”：確保數據庫記錄和消息發送要麼都成功，要麼都失敗。	交易服務成功寫入調撥記錄的同時，必須確保對應的 Kafka 消息 也被髮出。	“我們利用 Transactional Outbox 模式 確保交易記錄和資金變動事件的原子性，避免了數據丟失或重複。”
冪等性 (Idempotency)	“重複點多次，結果還是一樣”。	交易系統收到重複的資金增加/扣減消息時，必須確保賬户只被操作一次。	“所有對賬務系統的操作都通過 全局唯一 ID 保證冪等性，防止因消息重發導致的重複入賬。”
CQRS	“前台負責點單，後廚負責出菜”：將修改和查詢使用不同的數據模型。	交易執行（高寫入）使用關係型數據庫，頭寸查詢（高讀取）使用內存緩存/NoSQL。	“在頭寸管理中，我們應用 CQRS，使用 Redis 維護實時頭寸快照，實現了毫秒級的查詢響應。”

4 總結

架構師的 TMS 核心能力展現：

• 業務理解力： 清楚 TMS 是高價值、高併發、高一致性的系統。
• 分佈式事務處理： 拒絕 XA，擁抱 Saga 和 最終一致性。
• 高可用/實時性： 利用 EDA + Kafka 實現系統解耦和數據流實時化。
• 性能優化： 熟練使用 Transactional Outbox 保證原子性，使用 CQRS 優化讀寫性能。