引言

隨著金融業務轉型步伐加快，業務連續性要求趨嚴，對金融業信息系統運行穩定性要求日益提升。依據《銀行、證券跨行業信息系統突發事件應急處置工作指引》的通知（銀監發（2008）50號），影響銀證系統日間業務時間超過5分鐘（含），不足30分鐘的突發事件屬于Ⅲ級事件（一般事件），對三方存管系統的業務連續性提出更高要求。

    G行三方存管系統用于承載銀行方三方存管銀證業務，遵循“券商管證券，銀行管資金”原則，將投資者的證券賬戶與證券保證金賬戶嚴格進行分離管理。本文以G行三方存管系統云原生改造為切入點，從業務上云方案設計、業務上云風險評估、業務上云問題發現、業務上云帶來的收益四個方面進行總結。

image.png

一、業務上云方案設計--云原生架構打基礎

在金融行業蓬勃發展和技術高速迭代的大背景下，傳統集中式架構暴露出的短板愈發突出：1）擴展性不足，難以靈活應對業務規模的快速擴張；2）容錯能力欠佳，一旦關鍵節點出現故障，易引發系統性風險；3）代碼耦合度過高，使得系統維護與功能升級變得異常復雜。

為緊跟技術發展潮流，積極賦能業務創新，自 2019 年起，G 行啟動新一代三方存管系統上云項目建設，該項目實現了容器化微服務改造和國產化分布式改造。下面從上云應用架構設計與上云業務遷移兩大核心維度展開，全面推動系統的升級轉型。

1.1  上云應用架構設計

應用上云的關鍵在于全面合理地架構拆分，為后續業務遷移打好基礎。架構拆分不能只追求數量，要結合系統實際業務場景和業務量變化綜合考量。G行三方存管系統架構拆分時，先按交易方向將網關層分為銀行方和證券方，保證交易獨立，減少干擾，提升穩定性和效率；再根據交易重要程度，拆分銀行方與證券方的金融交易，實現資源分配和業務保障的差異化管理，保障關鍵交易；最后依據業務運行特點，對查詢、簽約等業務針對性拆分。其中，簽約業務因占比較低，基于 “非必要不拆分”原則，不做交易方向拆分，避免復雜性和成本增加，體現拆分策略的合理性。

1.2  上云業務遷移

    為確保云上業務平穩遷移，G行在三方存管系統業務遷移過程中采取一系列謹慎有序的遷移策略。首先按照應用業務遷移，設計新老系統并行場景，優先將銀行端全部查詢業務遷移至新系統，讓新系統同時對接新、老數據庫，實現最小風險下對查詢業務的最大化接入。待新系統穩定后，再以合作機構為業務對象，分批遷移重要業務。由于銀證業務合作機構較多，一次性整體遷移風險較高，因此按照券商簽約客戶量維度，遵循先少后多的原則，逐步對接新系統，完成云上容器化業務遷移。在國產化分布式架構改造階段，基于前期容器化微服務底座，通過控制云上流量進行業務遷移，可謂水到渠成。在保證業務平穩運行的前提下，按照5%、20%、50%、100%精控流量比例，最終實現無感化云上業務流量遷移。

二、業務上云風險評估--風險評估保平穩

系統上云過程中風險貫穿始終，核心目標是確保系統上云安全平穩運行。從架構設計到上線，需全程做好風險評估，降低運行隱患。以下是G行在上云過程中遇到的突出風險點及應對方法：

批量并行運行風險：新老系統并行期的批量運行風險控制依據架構特性進行優化。傳統架構向容器微服務化遷移時，為保障合作機構清算準確唯一，避免資金風險與數據混亂，各合作機構清算任務必須相互獨立、彼此隔離。從容器化向國產化分布式遷移時，為合理利用資源、確保任務有序，批量僅在一套環境運行，通過為每個任務生成唯一標識來監控批量狀態，防止重復執行，避免數據不一致和資源浪費。

云上業務引流風險：在國產化分布式業務遷移階段，云上業務引流風險不容小覷，其中關鍵在于保證流量精準控制。為達成這一目標，在架構設計階段進行埋點，對網關層實施精簡化和去狀態化處理，實現通過連接云上實例數比例精確控制接入流量，有效降低引流風險，保障業務遷移的平穩進行。

流量回切風險：流量回切的高效性是業務遷移無影響的最后一道防線。遷移前要充分考慮異常場景，制定快速回切策略。三方存管系統以快速恢復業務為原則，將回切流程拆分為關鍵和非關鍵步驟，優化每步執行邏輯，借助自動化技術實現流程精簡化、自動化，確保業務異常時能迅速回切流量，減少業務中斷時間，降低對用戶和業務的影響。

系統容量風險：系統容量風險涵蓋業務容量風險以及應用與平臺支撐能力風險。新系統上線前評估需貼近生產實際，例如在新、老系統并行期，新系統訪問老系統數據庫時，老系統數據庫連接實例數的容量風險易被忽略。因此，非功能測試階段要克隆生產環境，保證一致性。同時管理員要長期積累容量風險識別經驗，上線前逐項評估系統容量風險。

數據遷移風險：在分批業務轉移過程中，因新舊數據庫間的異構性差異，面臨著顯著的風險挑戰。這些風險主要體現在以下三個方面：

1. 數據一致性與完整性風險：遷移前后可能出現數據丟失、字段內容被截斷、字符集與編碼方式轉換引發的數值偏差、表結構變動以及索引丟失等問題。為有效應對此類風險，關鍵在于構建詳盡的數據與表結構遷移前后的比對及校驗機制，并開發或采用專業的校驗比對工具來確保數據的精確無誤。  

2. 性能與穩定性風險：異構數據庫間在性能和穩定性方面存在顯著差異，且數據存儲與使用規則也各不相同。針對這一風險，核心策略是在遷移前進行廣泛而深入的測試，充分考慮各種可能的使用場景，以確保遷移后的系統能夠滿足性能需求并保持高度穩定。  

3. 臟數據風險：在遷移過程中，若未對遷移數據進行全面深入的分析，而盲目采用全量遷移的方式，可能會將非必要數據一并帶入新系統，從而為后續系統運行埋下隱患。為規避此類風險，在制定數據遷移方案時，必須對數據進行全面系統的分析，嚴格遵循最小化遷移數據原則，并在遷移后仔細核查遷移數據的內容，確保數據的純凈與有效性。

三、業務上云問題發現 --監控靈敏排隱患

為保障三方存管業務上云后平穩運行，在容器微服務化云上業務遷移初期，通過細化監控指標，利用智能監控技術，提升監控靈敏度，及時捕捉潛在風險隱患。發現風險隱患后，迅速組織研發、運維等各領域專家組成攻堅組，通過數據分析、日志回溯、網絡抓包和模擬測試等手段排查問題原因，制定有效解決方案，并建立長效風險預警和應對預案，為后續業務平穩遷移及運行筑牢基礎。

3.1  聯機交易響應耗時長

程序代碼處理機制引起交易偶發停頓：通過細化監控策略，增設聯機交易響應時間最大閾值策略，并將敏感度提高到單筆報警，發現存在偶發聯機交易響應超時。經排查各階段交易耗時，問題鎖定在網關層接收網絡報文到開始處理之間。經深入分析和測試環境復現，確定網關層反向解析請求報文源地址時，存在異常等待超時，致使聯機交易偶發卡頓。

外圍系統引起應用短時暫停：通過優化聯機交易響應時間基線波動率監控策略，成功捕捉到偶發響應時間偏離場景。針對告警時間段內的交易情況展開全面排查與細致分析，發現存在交易異常暫停現象。為深挖問題根源，進一步擴展了排查范圍，發現輔助運營監控平臺在進行信息采集時，引發應用線程短時暫停，停止信息采集任務后，交易異常暫停現象消失。

3.2  系統資源消耗異常

外圍系統引起pod內存消耗異常：通過對運行服務巡檢發現，某類對內存要求高的服務pod存在內存異常緩慢增長。對內存使用情況分析發現輔助運營的平臺進行信息采集時存在內存占用不釋放現象。

服務內存配置不合理：在系統持續運行一段時間后，我們觀察到批量服務出現內存使用率高于閾值的情況。通過深入的內存使用情況分析，并結合該服務功能的特性-批量頻繁讀取文件操作場景。經綜合判斷，確定當前內存的增長屬于正常業務范疇。當內存增長至特定區間時，系統會自動進行動態內存的釋放。由此可見，內存使用率過高是資源初始分配不合理導致。

四、業務上云帶來的收益

    相較于傳統單體架構應用系統，云上系統在業務連續性、應用變更復雜度、生產環境一致性等方面展現出顯著優勢。

業務連續性能力提升：多副本特性降低業務中斷概率，運維關注重點轉向上下游系統可靠性。

投產流程復雜度降低：借助鏡像制品庫，實現標準化拉取與部署，減少人為干預風險。

生產環境一致性提升：容器化部署依靠鏡像版本控制，確保多環境信息一致。

在金融行業蓬勃發展和技術高速迭代的大背景下，傳統集中式架構暴露出的短板愈發突出：1）擴展性不足，難以靈活應對業務規模的快速擴張；2）容錯能力欠佳，一旦關鍵節點出現故障，易引發系統性風險；3）代碼耦合度過高，使得系統維護與功能升級變得異常復雜。

為緊跟技術發展潮流，積極賦能業務創新，自 2019 年起，G 行啟動新一代三方存管系統上云項目建設，該項目實現了容器化微服務改造和國產化分布式改造。下面從上云應用架構設計與上云業務遷移兩大核心維度展開，全面推動系統的升級轉型。

4.1  上云應用架構設計

應用上云的關鍵在于全面合理地架構拆分，為后續業務遷移打好基礎。架構拆分不能只追求數量，要結合系統實際業務場景和業務量變化綜合考量。G 行三方存管系統架構拆分時，先按交易方向將網關層分為銀行方和證券方，保證交易獨立，減少干擾，提升穩定性和效率；再根據交易重要程度，拆分銀行方與證券方的金融交易，實現資源分配和業務保障的差異化管理，保障關鍵交易；最后依據業務運行特點，對查詢、簽約等業務針對性拆分。其中，簽約業務因占比較低，基于 “非必要不拆分”原則，不做交易方向拆分，避免復雜性和成本增加，體現拆分策略的合理性。

4.2  上云業務遷移

    為確保云上業務平穩遷移，G 行在三方存管系統業務遷移過程中采取一系列謹慎有序的遷移策略。首先按照應用業務遷移，設計新老系統并行場景，優先將銀行端全部查詢業務遷移至新系統，讓新系統同時對接新、老數據庫，實現最小風險下對查詢業務的最大化接入。待新系統穩定后，再以合作機構為業務對象，分批遷移重要業務。由于銀證業務合作機構較多，一次性整體遷移風險較高，因此按照券商簽約客戶量維度，遵循先少后多的原則，逐步對接新系統，完成云上容器化業務遷移。在國產化分布式架構改造階段，基于前期容器化微服務底座，通過控制云上流量進行業務遷移，可謂水到渠成。在保證業務平穩運行的前提下，按照5%、20%、50%、100%精控流量比例，最終實現無感化云上業務流量遷移。

五、總結

通過云原生改造極大提升了對業務發展的支撐能力，但也給運維帶來新挑戰。一方面，系統架構變得更復雜，節點連接繁多，運維難度增大，故障排查定位困難；另一方面，單 pod 故障概率高于傳統服務器，在途交易差錯賬處理要求提高，而且運維所涉獵技術領域更廣，對運維人員技術能力要求更高。

未來，我們將著力繼續探索在復雜服務中快速定位故障的方法，加強標準化建設持續提升可觀測水平，不斷提升智能運維能力，保障系統平穩運行，賦能業務快速發展。

作者：郭紅斌

深耕金融科技安全運營領域多年，目前主要負責金融類存管系統的應用運維建設工作。面對萬千技術的更新迭代，打造規范化、可視化、快速響應的安全運營能力，是我們亙古不變的目標。