引言

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

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

image.png

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

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

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

1.1  上云應用架構設計

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

1.2  上云業(yè)務遷移

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

二、業(yè)務上云風險評估--風險評估保平穩(wěn)

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

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

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

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

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

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

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

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

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

三、業(yè)務上云問題發(fā)現(xiàn) --監(jiān)控靈敏排隱患

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

3.1  聯(lián)機交易響應耗時長

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

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

3.2  系統(tǒng)資源消耗異常

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

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

四、業(yè)務上云帶來的收益

    相較于傳統(tǒng)單體架構應用系統(tǒng)，云上系統(tǒng)在業(yè)務連續(xù)性、應用變更復雜度、生產環(huán)境一致性等方面展現(xiàn)出顯著優(yōu)勢。

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

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

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

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

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

4.1  上云應用架構設計

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

4.2  上云業(yè)務遷移

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

五、總結

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

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

作者：郭紅斌

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