文 / 中國銀行軟體中心張國柱

近年來，隨著銀行業務品種增長和經營規模擴張，支撐業務發展的核心銀行系統同樣經歷了大量的改造，逐漸變得功能交錯、程式碼臃腫。尤其在金融個性化需求激增、網際網路公司跨界競爭的大背景下，核心銀行系統老邁的單體架構嚴重掣肘著IT系統對業務需求的快速響應，而將核心銀行系統遷移到微服務架構也成為銀行重塑市場競爭力的重要選項。本文結合筆者在基於微服務架構的核心銀行系統開發中的實踐和思考，從服務拆分策略、公共處理機制設計、引數管理機制設計等三個方面，分享核心銀行系統向微服務架構遷移的實踐經驗，並提出針對核心銀行系統微服務架構設計的一些建議。

一、服務拆分策略

核心銀行系統的應用邊界往往不清晰，採用“事務指令碼”模式開發的應用程式的處理邏輯可以隨意堆砌，資料訪問也不規範。同時，經過多年沉積的核心銀行系統普遍面臨功能繁雜、資料混亂等問題，而將其拆分成邊界清晰的服務正是對症之藥方。微服務架構中經常用到的服務擴充套件立方體模型如圖1所示，其中Y軸縱向拆分是按功能解耦成為微服務;Z軸橫向拆分是將服務按資料拆分，目的是突破單庫資料處理能力;X軸則是透過多節點部署，達到消除單點和提高處理能力的目的。

對於核心銀行系統，Y軸縱向拆分是指按功能維度拆分為微服務，主要可分為客戶、存款、貸款、支付、借記卡、現金、匯率兌換、稅費、櫃員管理等。其中，客戶、存款、貸款、支付、借記卡直接對客戶提供業務價值，可歸類為對客服務;現金、匯率、稅費提供業務支援能力，可歸類為公共服務;櫃員、機構和內部賬是銀行內部管理所需，可歸類為管理服務。一般而言，服務間的呼叫形成強依賴關係，其特點為“依賴性，場景統一性”。如圖2(左)所示，貸款服務對存款服務的依賴是強依賴，在所有放款和還款場景，貸款都需要跨服務邊界訪問存款，產生全域性事務一致性問題。

圖2 服務依賴特點分析

Z軸橫向拆分是指將資料按特定的屬性取值拆分為多個子集，每個資料子集和在上面執行的服務構成的自包含集合稱為業務單元。不同業務單元間存在弱依賴關係，其特點為“偶然性，場景差異性”。如圖2(右)所示，存款按賬號號段可拆分為多個業務單元，僅在交易資料不能在一個業務單元封閉管理時，才需要跨單元服務邊界進行訪問，產生全域性事務一致性問題。

因核心銀行系統支援的業務通常均涉及資金往來，業務場景要求資金在交易賬戶間強一致性體現。由於核心銀行系統承載著極為重要的業務功能，因此在服務和單元拆分策略上也需要進行統一規劃，避免模組各自為政。

1.縱橫無規劃拆分

如果沒有預先制定服務和單元的拆分規則，而是任由各模組獨立進行服務和單元的拆分，則會在總體上形成縱橫交錯的服務呼叫局面。如圖3(左)所示，縱向拆分出來的存款和貸款服務各自進行橫向單元拆分，形成了蛛網狀的服務呼叫關係，這不僅會對應用開發造成極大困擾，後期運維也將困難重重。

圖3 服務關係

2.以橫向拆分為主

經分析發現，核心銀行系統的多數交易都發生在同一個客戶的賬戶之間，因此可以採用以橫向為主的拆分規則，以儘可能將全域性事務一致性場景降到最低。如圖3(中)所示，針對客戶、存款、貸款、支付和借記卡等對客服務，如均按相同的客戶號段橫向進行業務單元拆分，並將同一個客戶號段的多個服務部署在一起，可使服務在執行態組成單體的單元服務，大部分交易將能在同一業務單元的內部完成。由於業務單元依賴具有“偶然性，場景差異性”的特點，因此在開發階段還需要梳理出涉及跨業務單元訪問的交易，並針對交易制定分佈事務一致性解決方案。

需要注意的是，橫向拆分為主並不意味著回到單體應用的老路上，同樣包括透過縱向拆分識別出高內聚、低耦合的服務，以保證服務的邊界清晰。在此模式下，服務間的依賴體現在數量可控的方法(服務)呼叫上，由於服務間依賴具有“必然性，場景統一性”的特點，該方法旨在透過服務呼叫的統一處理達到揚長避短的效果。具體實現方法上，服務提供方需要提供遠端呼叫和本地呼叫兩套介面，在呼叫前增加是否有本地呼叫例項的判斷，如果有本地呼叫例項，則進行本地呼叫;如果無本地呼叫例項，則進行遠端服務呼叫。透過上述處理，可以兼得微服務開發獨立和單體事務一致性的優點。在設計階段，由於未形成程式穩定版本，工作重點是微服務功能獨立開發和功能性測試，在開發環境將服務分開部署，達到服務能夠獨立進行開發和測試的目的。而在使用者測試和生產環境，由於形成了程式的穩定版本，透過對服務進行單體部署，將可最大程度減少跨業務單元呼叫。

3.以縱向拆分為主

以縱向拆分為主的拆分規則是指在各微服務間形成獨立的產品邊界，核心銀行系統則被弱化成邏輯概念和管理邊界。具體實現方法上，在註冊中心透過“產品邏輯分組”實現服務治理的產品邊界，產品內多個業務單元在註冊中心歸屬於同一個“產品邏輯分組”，服務僅在“產品邏輯分組”內部註冊和發現。跨產品的API服務釋出和API呼叫，需透過API閘道器進行。如圖3(右)所示，拆分出來貸款和存款兩個微服務都設有產品API閘道器。貸款和存款允許根據業務情況制定自身的橫向拆分策略。在這種模式下，服務間依賴體現為基於API閘道器進行呼叫，需要解決全域性事務一致性問題;業務單元依賴則限制在微服務自身資料層面，全域性事務一致性場景分析較為簡單。

二、公共處理建議

在傳統核心銀行系統中，存在許多授權、定價、重空及稅費計算等公共功能，在單體架構下，可以在各模組新增補丁來堆砌公共功能，負面結果是使得單體架構更加鐵板一塊。與之相比，微服務有清晰的邊界，支援各自管轄資料與事務，但怎樣透過公共處理功能進行協作是微服務拆分後必然需要解決的難題。對此，筆者結合微服務架構下跨服務的公共功能實現要點，提出以下幾點建議。

1.從企業級視角進行公共功能重新建模

核心銀行系統通常綜合了多個業務條線和板塊的業務功能，由於功能需求文出多門，有些公共功能並沒有經過全域性論證，是勉強糅合而成。對此，建議將核心系統原有的公共功能提升到企業高度重新建模，避免從核心系統中拆分出來的公共功能承擔過多職責。

以費用定價舉例，該功能需求往往會涉及多個部門，如渠道管理部提出針對渠道營銷的優惠，產品研發部提出針對產品推廣的優惠，公司部提出針對大客戶的優惠等。由於需求零散，費用計算功能每每是透過硬編碼實現，最後甚至連業務專家也很難解析算費規則。針對上述問題，筆者認為根本的解決方法是建立統一的定價模型，在該模型下，長期定價統一由定價中心提供，便於形成長期的價值導向;短期的營銷定價則在營銷中心的發放優惠券功能中達成，力爭在不改變長期價值導向的前提下，起到短期宣傳效果。

再如綜合授權，該功能需要從各模組、各層級進行授權點收集，既有靜態授權點(客戶狀態、賬戶狀態等)，也有動態授權點(餘額檢查、累計金額等)，最後在統一介面由授權櫃員一次性進行授權。在單體架構中，通常可以將授權點檢查程式碼嫁植在正常的業務邏輯中，如果授權櫃員許可權仍然不夠，則將前面的資料庫操作執行回滾即可。但是，在微服務架構下，由於微服務存在邊界，將不能在程序空間進行授權點資訊收集及傳遞，也無法跨服務邊界進行資料庫級別的回滾，這些因素都增加了原有綜合授權功能的難度。對此，筆者建議從企業級高度對授權進行梳理，由各業務領域將風險點控制文件化、模型化。在系統實現上，可以建立授權服務中心微服務，負責記錄交易的授權點資訊，同時基於領域的微服務將靜態的授權點檢查服務開放，交易流程編排先進行各領域靜態授權檢查，收集授權點登記到授權中心，然後由授權櫃員進行授權，最終當授權通過後再執行業務處理。

2.設計跨服務資料的共享機制

在單體架構下，交易在同一個程序空間能夠方便地實現資料共享，而微服務架構下的資料共享則會被服務邊界阻斷，需要重新設計資料共享機制。當前，新的資料共享機制主要包括引數傳遞、全域性快取和共用資料表等三種方式。其中，引數傳遞方式適合在微服務間採用，理由是不同的微服務通常由不同的開發團隊負責，團隊的領域知識差異容易造成對資料理解產生歧義，引數傳遞方式透過服務介面契約能夠保證各方對資料理解的一致性。全域性快取方式適用於在同一微服務的不同業務單元間進行資料共享，由於業務單元一般負責管轄相同領域的業務資料，不存在資料理解障礙，因此適宜將交易期間多業務單元交換的資料暫存在全域性快取，等交易結束時再持久化到資料庫。對於穩定的公共業務流水資料(如日誌、授權資訊等)，建議儲存在各微服務均可訪問的公共庫表中，以便於對流水資料進行彙總管理，如業內常用的MySQL資料庫支援在同一個資料庫例項上建立多個Database，且同一事務能跨多個Database。而對於管理業務資料量不大的服務，適合將多個服務的業務資料儲存在同一資料庫例項的不同Database中，公共資料儲存則在公共Database。

3.分散式事務一致性模式選擇

服務和單元的拆分將產生分散式事務處理需求，主流的事務一致性解決方案主要有TCC和SAGA兩種。其中，SAGA較之TCC減少了Try階段工作，對應用的改造要求較低，更為適用於相對簡單的業務場景。但是，核心銀行系統不僅涉及資金交易，且交易流水也常常被用作法律憑證，因此筆者建議採用對應更高改造要求的TCC方案。

以客戶轉賬場景為例，當客戶A所在的業務單元完成扣賬操作後，還需呼叫客戶B所在的業務單元入賬，假如在返回時出現通訊故障，則需要補充發起客戶A的衝正交易，將賬戶餘額恢復，並將流水記錄設定為已衝正。在SAGA方案下，交易由確認Confirm處理和回沖Cancel處理組成。SAGA方案的Confirm處理等同於正常流程，如果整體交易失敗，則客戶A會存在一筆非真實業務衝正的流水，如果這筆流水體現在客戶的賬單中，

會對客戶造成很大的困擾。為了保證對客流水的清晰展現，採用SAGA方式後續查詢都需要對流水進行過濾處理。

與之相比，採用TCC方案則可基於Try處理進行金額凍結和記錄技術流水等工作，如果交易失敗，則Cancel處理除了恢復被凍結的金額，也能刪除技術流水，從而保證被技術衝正的流水不會在業務流水中體現。相比之下，TCC方案體現了重要金融業務場景處理邏輯的嚴謹性，而且在後續流水查詢環節也能避免補充額外的過濾處理。

三、引數管理方案

由於突破單庫資料處理能力的需要，當按照Z軸將服務橫向拆分出的多個業務單元時，各業務單元領域服務通常會使用同樣的業務引數，而業務引數如何服務於多個業務單元是單元化設計需要考慮的重點問題。對此，業務單元的引數管理需關注如下兩個設計要點。

1.業務引數維護主體

當業務單元拆分後，引數維護主體存在以下兩個選擇：

一是由業務領域的服務單元維護業務引數，即指定服務的牽頭業務單元負責引數主體的維護工作，而對於非牽頭業務單元則僅允許其對引數進行查詢，由服務閘道器將引數維護請求統一發送給牽頭業務單元。在此方式下，微服務的領域模型保持完整，但由於引數只能在一點維護，因此業務單元的引數維護程式還需要進行差異化處理。

二是由引數中心提供業務引數維護公共服務，即建立引數中心，同時將各領域的引數維護交易剝離到引數中心，業務單元則需要呼叫引數中心的查詢服務獲取引數資料。在此方式下，微服務需要將業務引數的管理職責從領域中剝離出來，微服務的領域模型也將變得不再完整，但換取到業務單元查詢引數方式的一致性。

2.業務引數訪問的模式

如上文所述，業務單元拆分導致業務引數維護和查詢往往不在同一個資料庫中，需要根據情況選擇引數的查詢方式，常用引數訪問方式及特點如下：

一是服務呼叫方式，該方式是指在服務層由業務引數維護主體提供開放的引數查詢服務，使用者可透過服務介面查詢業務引數，該方式實現簡單，但查詢效能較差。

二是資料同步方式，該方式是指在資料層將業務引數主本同步到業務單元的資料庫，以保證服務能在本單元訪問到業務引數，該方式需要設計資料同步機制，但查詢便捷且效能較高。

三是資料來源切換方式，該方式是指在資料層定義業務引數所在庫的資料來源，當服務需要訪問業務引數時，可透過切換資料來源進行訪問，該方式實現複雜程度適中，且效能較好，但主要缺點是應用程式需要管理多個數據源，增加了應用的複雜度。

新形勢下，如何藉助微服務架構讓核心銀行系統這個“笨拙的大象起舞”，是當前大多數銀行都在思考的問題。微服務架構憑藉服務邊界清晰的天然優勢更容易進行彈性伸縮，但同時也帶來如事務一致性難題、公共處理難題、引數管理難題等諸多挑戰，需要充分權衡基於微服務架構的多種設計方案，才能揚長避短，真正發揮新架構帶來的紅利。

來源：《中國金融電腦》2022年第02期