引言

G行以全棧云平臺為基礎，逐步推進云原生技術的應用，探索數字化轉型路徑，為銀行業務快速發展提供有力技術支撐。同時，云原生也帶來了在微服務管理、云安全、健康監測、依賴路徑、韌性要求等多方面的挑戰，具體表現為：

微服務管理：多個微服務有機組合才能構建一個健康的應用程序，本質上許多活動部件需要協同工作才能使系統正常運行。如果一項微服務失敗，則系統需要對其進行檢測并自動修復。隨著自動化部署引入，系統迭代頻繁，應用系統微服務的管理越來越復雜，管理要求越來越高。

云安全：由于云原生環境的易變性，傳統邊界安全模型無法覆蓋所有風險場景。在云原生技術架構下，容器間隔離、微服務全生命周期變化、微服務間網格化依賴、集群資源自動調度等新領域都可能帶來不同層面的安全風險，影響應用系統穩定性。因此，針對云原生的復雜性引入安全管理策略和技術手段進行有效防護和保障，是非常有必要的。

健康監測：Kubernetes是非常復雜的平臺，為了保障基于Kubernetes的業務系統平穩運行，了解Kubernetes的健康狀況至關重要。一些現有技術可以用來收集Kubernetes集群日志、各種指標數據、事件和安全威脅，以幫助監視集群的健康狀況，但單一指標很難系統性的衡量基于Kubernetes的應用系統健康程度。需要一套更加智能、直觀的方式，對各種指標數據進行采集、整合、綜合分析，從而生成可視化的高階視圖。

依賴路徑：在一個由多集群、微服務化的云原生分布式環境中包含大量交互、依賴點，可能出錯的地方數不勝數。硬盤故障、網絡不通、流量激增壓垮某些組件，任何一次故障處理不好就有可能導致業務停滯、性能驟降，或者其他各種無法預料的現象；同時云原生環境中，也難以全面掌握何種故障會導致系統局部崩潰，甚至全面崩潰。需要盡可能地在這些情況發生之前找出系統中的脆弱點。

韌性要求：云原生帶來的業務分散、集群繁多、集群邊界受限等問題對云平臺也提出了新挑戰，需要平臺提供可靠的韌性能力以保障業務穩定運行。業務分散體現在應用在各集群的差異化配置、業務跨云訪問、集群間應用同步等；集群繁多體現在繁瑣重復的集群配置、云廠商集群管理差異、碎片化API訪問入口，如何讓集群對上層用戶透明等問題；集群邊界限制體現在資源調度受限于集群、應用可用性受限于集群、彈性伸縮受限于集群。如何讓應用可以面向多集群進行部署分發，如何提供整體跨集群自動伸縮能力也是未來面臨的挑戰。

針對上述挑戰，我們進行了一些探索和實踐，以提高平臺韌性，提升業務運行穩定性。

云原生業務韌性的探索與實踐

1.實踐內容

為了提升云上業務感知、保護和主動優化能力，進一步應對上文描述的一系列挑戰，G行全棧云初步完成了云原生業務韌性能力建設，實現了部分應用系統跨集群調度、故障演練、多中心互備等功能，探索提升業務韌性，實現業務連續性與災備管理。下圖是云原生業務韌性平臺架構，基于云原生技術實現應用的跨集群配置備份和數據備份。

云原生業務韌性平臺功能涵蓋多集群管理、云原生應用系統數據備份與恢復、跨集群資源及演練調度等核心模塊，具體內容如下：

• 多集群管理：集群管理包括應用管理、備份管理、策略管理、沙盤管理、活動監控、監控告警、容量管理等子功能模塊。同時保障納管集群標簽、資源、節點、服務、狀態等數據的有效管理。
• 云原生應用系統數據備份與恢復：根據不同業務應用條線的重要程度制定不同備份策略。核心業務、關鍵業務提供分鐘級甚至秒級備份，普通業務、非關鍵業務可按周或按月備份并能夠按照備份時間點進行快速恢復。
• 跨集群資源及演練調度：實現Kubernetes集群之間的資源調度，滿足業務高峰時的資源需求，其中包括調度策略的制定、調度組、歷史記錄及報告等；支持云上虛擬機與容器應用的切換演練調度，應對突發事件的切換調度，其中包括演練計劃、演練方案、演練報告、場景管理、流程庫、步驟庫、階段庫等。

2.應用成效

目前全棧云韌性平臺已完成多個Kubernetes集群以及集群內部分應用系統納管，實現應用災備無縫切換，并基于平臺能力實現如下能力探索：

• 靈活備份策略：有效的縮短備份時間，靈活的備份頻度，提高RTO；避免備份冗余數據，提高資源利用率。
• 穩敏雙態災備：基于不同語言的回調，實現統一納管及調度；優化切換效率，顯著提升RTO。
• 多云遷移：支持不同云廠商切換過渡，實現平臺級災備能力；順應國產化信創要求，雙棧并舉，防范系統性風險。

后續改進

云原生技術帶來了更高層次的基礎設施抽象，讓應用開發人員的關注點從基礎設施進一步分離，聚焦上層業務邏輯實現。全棧云在實踐韌性能力建設過程中，也面對與應用系統結合的一系列問題，包括：

• 應用定制多：每個應用系統都有自己的架構特性，在技術上無法實現應用的一鍵災備納管，只能針對每個應用剝繭抽絲，一一定制。
• 配置梳理繁：不管是純云原生應用，還是穩敏雙態應用，都有平臺級、系統級、服務級等各種復雜配置，災備端納管起來容易錯一漏萬，嚴重時甚至影響到主端應用的正常運行。
• 業務驗證難：針對應用系統完成的容災備份，與主端應用的業務對等性無法得到完全、充分的驗證。
• 主備同步弱：云原生應用系統迭代快，業務更新頻繁，備端應用無法滿足一次納管，同步迭代。備端需要針對主端應用系統的每次迭代進行主動同步，以確保主備服務的一致性。
• 為解決上述問題，在以“API+云服務”的形式構建服務生態鏈的潮流下，我們也在探索技術手段和管理機制互相融合可行方案，具體包括：
• 災備前移：管理上將應用系統上云改造與云上災備管理融合，技術上針對不同應用系統制定不同容災規范，確保完成上云即完成容災建設。
• 平戰結合：平時完善BCP和DRP，確保其準確性、有效性，演練驗證；戰時快速響應、快速決策、快速處置；平戰結合，打造來之能戰、戰之能勝的業務連續性體系。
• 穩敏雙態共存：業務線條貫穿敏態和穩態，信息系統本地應急和異地災備能力需穩敏同時構建；穩敏技術架構遵從BCM體系構建支撐能力；風險聯動業務和IT部門，構建穩敏兼顧的雙態組織和應急體系。
• 高低頻事件聯動：依托低頻事件，構建BCM體系業務和IT的最后一道防線；面對高頻事件，實現日常運維和組件切換的聯動；高低頻事件聯動，切實實現資源共享，提升災備投資ROI。

下圖是全棧云韌性平臺可行的優化流程，從指標制定、策略制定、能力建設、應急演練、應急切換、優化改進以及影響分析報告等形成的一套業務系統的優化閉環，每一個步驟均通過相關的技術手段以達到預期目標。在后續工作中我們將深入探索技術與管理的融合方案，服務于應用系統業務連續性。

未來，G行將從IaaS、PaaS、SaaS、DevOps等方向進一步完善云原生系統的管理、調度、觀測和容災演練能力，全方位構建完整生態云體系，為云上業務韌性保駕護航。同時基于云原生架構規劃推進業務系統建設，繼續深耕金融科技領域，提高服務成本的透明度與可信度，期望通過自己的云原生架構落地實踐為業界提供數字化轉型經驗。