作者：劉偉光，阿里雲智能新金融&互聯網行業總裁、中國金融四十人論壇常務理事，畢業於清華大學電子工程系
01 前言
2015年雲原生理念提出的時候，彼時全球金融百年發展形成的信息化到數字化的背後，金融級的技術服務水準經過長時間的打磨已經形成行業共識的標準。8年前的雲原生經典理念是聚焦在容器化、DevOps、持續開發持續集成、微服務架構這些軟件開發層面的新範式。而金融級要求諸如高可用、高性能、業務連續性、系統安全穩定等等這些要求跟雲原生架構的理念彷彿處在兩個相距遙遠的範疇。隨着技術層面的不斷演進，在新型的應用系統的開發方面，金融機構開始逐步引入容器化等雲原生部署架構，但是始終發現聚焦在開發態層面的雲原生能力是不能觸達金融的系統建設的各個層面。雲計算技術日新月異的變化反過來推動了雲原生的發展從狹義到廣義，今天的雲已經變成了更爲普適性的標準基礎設施，更是新技術新業務創新的平臺；因此諸如雲原生大數據，和雲原生存儲以及雲原生網絡技術等技術讓雲的原生能力從軟件開發走向數據平臺進而延展到底層物理部署架構。今天的雲計算無論是公共雲還是專有云，其技術體系帶來的先進性以及對開源的擁抱和支持確實在改變着行業面向未來的規劃。
經過長時間的探索實踐，我們提出一個全新的概念：金融級雲原生，其核心思想就是讓雲原生從狹義變成廣義，讓雲原生的先進思想從只覆蓋應用開發擴展到系統物理部署架構這樣的完整技術鏈路，從單純的開發態轉向設計態+研發態+運行態+運維態+容災態，同時在每個範疇中都結合金融級的高可用、高性能、業務連續性等特徵，總結和定義成金融級的全棧式的雲原生架構的範式。這樣的架構範式將把最先進的技術架構理念和最嚴苛的金融級SLA高度結合，旨在刻畫出一套全棧雲原生能力升級的技術體系，完整替換傳統架構，在數字金融高速發展的今天，在人工智能的雲時代中能夠提供最強有力的支撐。
02 金融 IT 架構的發展
如果銀行是鋼鐵俠，那IT系統就是他的戰衣。
在過去40多年裏，隨着以銀行爲代表的金融行業的業務發展和轉型，IT系統整體架構也同樣經歷過多輪的迭代演化，銀行的信息化發展進程可概括爲四個主要階段：單機時代、聯網聯機時代、數據大集中時代、分佈式雲原生時代。
1）單機時代：以計算機取代手工，但沒有信息互聯，每個網點即一個單獨的“電子賬本”，成爲信息孤島。
2）聯網聯機時代：依託網絡基礎設施的完備，銀行依託區域中型城市，以省市級主機爲中心，將各網點業務聯繫起來，實現省市級互聯。
3）數據大集中時代：各銀行依據自身發展，不同程度的集中處理數據和業務，實現系統基礎架構、物理服務器、數據和應用的大集中。
在數據大集中時代，也是銀行IT信息化發展最快、對業務推動最大一個時期，其中整個IT系統建設的重中之重是“核心系統”。核心系統：Core Banking System，其中CORE是Centralized Online Real-time Exchange的意思，也就是“集中式在線實時交易”的縮寫，並非字面的“核心”這麼簡單，突出一個“實時在線”信息交互，以轉賬支付爲例，從原來最早的半個月縮短到“實時秒到”，正是通過數據大集中和核心繫統的實時在線交易能力的建設，讓中國金融服務大幅提升了服務能力和交易效率。銀行的業務豐富度、業務交易量、數據量等也在不斷屢創新高，與此同時，作爲銀行基石作用的核心繫統對IT系統的處理性能、穩定性、安全性提出了極高的挑戰和要求。而彼時的國內IT企業仍然無法承擔起這樣極高的要求，銀行IT架構的唯一選擇就是集中式架構。
4）分佈式雲原生時代：隨着金融業務形態的不斷擴充，集中式架構的擴展性不足、互聯網式高併發應對能力不足、成本高、自主研發要求等缺陷不斷凸顯出來，同時分佈式雲原生技術也正在從銀行的互聯網服務平臺逐漸走向核心系統的技術架構，逐漸成爲銀行新一代全行級主流技術架構。
集中式架構的特點： 集中式架構也指由IBM、Oracle、EMC三家廠商主導的系統架構範式，IBM的大/小型機、Oracle的數據庫、EMC的存儲器一直都是國產供應的短板，高度依賴集中式架構爲核心的架構體系。集中式架構最大的特點就是部署結構簡單，底層硬件一般採用從IBM、HP、Oracle等廠商購買到的昂貴的主機、小型機、一體機等，無需考慮如何對服務進行多節點的部署，也不用考慮各節點之間的“分佈式協作問題”。一般採用“縱向垂直擴展”的方式，通過增加單機的資源配置來提升系統的處理能力，並通過增加硬件設備和基礎軟件的集羣機制來提升系統的可用性。
分佈式架構的特點： 系統由多個部署在不同的網絡計算機上的模塊構成，彼此之間通過網絡進行消息傳遞進行通信和協調的系統。分佈式系統採用“橫向水平擴展”的方式，通過增加服務器的數量來提升系統的運行能力，理論上可以無限擴張運行能力。分佈式系統採用集羣化部署，集羣中每個節點都是一個獨立的運行單元，可以根據任務的大小隨時增加或減小節點的數量。單個節點失效時也不會影響整體的可用性。
03 金融企業擁抱雲原生的問題與衝突
“設計不是爲了讓東西變得漂亮，而是爲了讓東西更好地工作” 。同樣雲原生不是爲了時髦，而是要解決問題。
阿里巴巴在2009年提出去集中式架構，在2013年基本完成去集中式架構。
硬件上，用標準化的X86服務器替代IBM的小型機和EMC的存儲設備，解決性能擴張的壓力。
軟件上，用開源的OceanBase、MySQL替代Oracle數據庫。
系統上，運用分佈式雲原生架構思路構建了新的體系。
阿里在去集中式架構過程中，不但通過用廉價、相對可控的PC服務器解決海量規模的計算問題，也推動雲原生技術的成熟和廣泛應用。隨着金融行業的業務與技術不斷迭代與發展，分佈式雲原生技術不但要解決高性能、高可靠、高彈性、高標準的要求，同時還需要圍繞安全、風險、效能、容量成本等多個方面進行全公司級的架構設計考量，也就不得不面對如下8大問題。
問題1：何爲雲原生？何爲金融級雲原生？
CNCF最初對雲原生定義是一個狹義的理念，更多是聚焦在軟件開發層面的新的範式，定義爲容器化部署+微服務架構+持續開發持續集成+DevOps這四大特徵的“狹義雲原生”，核心是面向應用開發者層面。但是隨着雲計算的不斷演進，雲原生存儲、雲原生網絡、雲原生數據庫、雲原生大數據、雲原生AI、雲原生業務中臺等等都走向雲原生的統一範疇，所以概念逐漸擴大化，說明“狹義雲原生”還是聚焦在開發層面，還是不能完全解決客戶的整體架構升級問題，所以形成了“廣義雲原生”。
而面對金融行業更加嚴苛的要求，需要解決不止是開發敏捷的問題，還需要解決架構先進性，將金融對安全合規、交易強一致性、單元化擴展、容災多活、全鏈路業務風險管理、運維管理等各方面行業要求與雲原生技術進行深度融合，實現對傳統集中架構的整體架構升級，發展爲一套既符合金融行業標準和要求、同時兼具原生技術架構優勢，形成了“金融級雲原生架構”。
問題2：雲原生對IT運維管理的變化何在？
“車同軌、書同文、行同倫”
從IT架構演進來看，傳統集中式架構雖然部署簡單，但存在縱向煙囪割裂、橫向管理分散的情況，每個層面和每個技術產品都獨立分散管理運維。在虛擬化技術成熟後，實現了從底層服務器、存儲、網絡、虛擬機等層面的集中式統一管理，大幅提升了運維人員的管理半徑。而云原生的核心理念是一切資源技術都以池化和服務的方式提供，不再是傳統割裂煙囪式的資源供給關係。雲原生架構更進一步實現了對IaaS資源、PaaS資源、分佈式數據庫、分佈式中間件、容器、研發工藝等各類技術服務的標準化和統一管理，真正實現了科技層的“車同軌、書同文”，大幅降低了運維複雜性，提高了人均管理對象規模化。
問題3：雲原生體系如何進行開源治理？
以前金融企業想使用雲原生的技術或產品，需要花費大量的精力研究一些開源項目，自己做運維和管理，還需要考慮集成、穩定性保障等問題，這樣才能建立一個雲原生平臺。金融機構開始意識到開源軟件只能解決水面之上的、顯性的、功能性的需求，大量的水面之下的、隱性的、非功能性的需求，開源軟件並不具備，但卻是金融機構在構建雲原生應用時真正需要考慮的。
爲了方便開發人員、運維人員更容易地使用雲原生技術產品，越來越多的金融機構建立起了一套企業級雲原生技術中臺和技術標準，從產品集成、運行、監控、運維等多維度進行產品和架構治理，實現有SLA保障、有成熟案例、有技術規範、可灰度的雲原生技術適配落地。
問題4：雲原生如何與信息技術應用創新結合，實現1+1>2？
自頂向下的完整雲原生技術棧代表着今天最先進的技術體系，因此在“信息技術應用創新”的技術方案選擇中不能只是單純的硬件思路或者單純的點對點替換思路，更多應該是用最先進的雲原生技術架構利用“信息技術應用創新”改造的機會實現全面能力的升級。
“信息技術應用創新”成爲金融機構IT體系建設中不可忽略的重要因素，在構建雲原生體系時，需要考慮這些方面的需求帶來的挑戰，例如“信息技術應用創新”軟硬件供應鏈穩定性和國產芯片可靠性問題。
“信息技術應用創新”勢必會導致金融機構面臨不同芯片服務器的“碎片化問題”（造成管理複雜性增加、成本增加），如果將每一種類型的芯片集羣都單獨建雲管理，這種多雲的資源池割裂和分化，很難被雲原生應用進行統一資源調度和使用，無法充分地利用到不同業務的峯值和低谷來進行彈性。除此之外，多朵雲還會導致運維複雜，包括部署、升級和擴容等需要單獨管理，運維管理成本高，操作體驗差。
所以，“一雲多芯+雲原生” 成爲了碎片化問題的最優解，“一雲多芯”從根本上解決不同類型芯片共存所帶來的多雲管理問題（碎片化統一管理，將“多芯”的差異轉變爲“一雲”的標準化服務）、雲原生解決了資源整合問題（碎片化資源的小合大）。最大限度利用雲上資源池的強大算力，實現多個芯片集羣能力的算力資源整合，真正形成1+1>2的一朵雲。
問題5：雲原生架構對業務安全生產如何應對？
根據“墨菲定律”——“懷疑一切、任何節點失敗都會發生！” （“Anything that can go wrong will go wrong”）。雲原生應用架構設計原則是，將影響安全生產的潛在“黑天鵝”風險作爲“常態”。
雲原生架構的建議是：允許失敗發生，確保每個服務器，每個組件都能夠在不影響系統的情況下發生故障並且具備自愈和可替代能力。立即失效（Fail fast and Fail small）是雲原生系統一個重要的設計原則，它背後的哲學是既然故障無法避免，問題越及早暴露、應用越容易恢復，進入生產環境的問題就越少。Fail small 的本質在於控制故障的影響範圍——爆炸半徑，關注點將從如何窮盡系統中的問題轉移到如何快速地發現和優雅處理失敗。
金融級雲原生架構來說技術風險亦是重中之重。 任何一筆交易處理的差錯背後都有可能導致不可預計的資金損失。需要建立一套專業的技術風險體系（SRE，Site Risk Engineering），確保從系統架構平臺到風險文化機制，在架構設計、產品開發、變更上線、穩定性評估到故障定位恢復等等環節，都能全生命週期地確保風險質量控制，對任何系統變更作兜底保障。
問題6：雲原生架構對業務連續性如何保證？
對金融機構而言，當業務上線後，最不能接受的就是業務不可用。
雲原生的韌性能力代表了當系統所依賴的軟硬件組件出現各種異常時，整個系統表現出來的抵禦能力，這些異常通常包括硬件故障、硬件資源瓶頸（如 CPU/網卡帶寬耗盡）、業務流量超出軟件設計能力、影響機房工作的故障和災難、軟件bug、黑客攻擊等對業務不可用帶來致命影響的因素。韌性從多個維度詮釋了系統持續提供業務服務的能力，核心是從雲原生架構設計上，整體提升系統的業務連續性，提升系統韌性。金融級雲原生的韌性能力包括：服務異步化能力、重試/限流/降級/熔斷/反壓、主從模式、集羣模式、AZ內的高可用、單元化、跨Region容災、異地多活容災等。
問題7：雲原生架構對交易一致性如何應對？
人們希望像使用單機系統一樣使用分佈式系統，因此不可避免的需要面對 “分佈式一致性” 問題。
雲原生中微服務中“微”代表了服務顆粒度變小，而金融交易的複雜性又相對較大。 所以在雲原生系統的數據一致性是一個相對複雜的問題，不同微服務中獨立的數據存儲，使得維護數據的一致性變得困難。由於分佈式微服務系統中的網絡錯誤不可避免，基於CAP定理，當出現網絡分區時，就需要雲原生架構能夠在一致性和可用性之間進行平衡。
所以金融級雲原生架構規劃時，也會遇到金融業務對一致性的挑戰，這種一致性不僅體現在業務邏輯上（TCC、SAGA、XA事務、消息隊列等），也更多地需要在數據層面上一致性保障（多節點一致性、多中心一致性）。
問題8：雲原生架構與應用設計與研發有哪些挑戰？
使人疲憊的不是遠方的高山，而是鞋裏的一粒沙子。
雖然雲原生技術有諸多好處，金融機構往往擁有大量的存量系統，這些存量系統的技術體系往往與雲原生技術存在差異，如何對存量系統與新的雲原生應用進行集成、治理？微服務的拆分策略如何制定，如何衡量拆分的維度、拆分的標準和拆分的顆粒度？如何建立雲原生的可觀測體系，實施有效的監控、日誌管理和告警，實時監控應用性能、資源使用情況，問題發生時快速定位並解決問題？
這些問題挑戰深層次解決，很多金融機構意識到需要雲原生技術中臺在設計態、研發態、運行態、運維態、容災態這5態進行統一技術規範，能夠實現標準貫穿和設計前置，將運維、容災、安全等後端能力和要求，在設計和研發階段就進行考慮、設計、前置，用雲原生技術來解決後端人力工作量和管理複雜性。
04 金融級雲原生的“新標準和新藍圖”
金融級雲原生的發展過程
Kevin Kelly在《失控：全人類的最終命運和結局》中對現代科技預言的準確性，讓作者成爲諸多科技從業者心中的預言帝，本書亦成爲聖典。書中描述中強調了兩個關鍵點：
1、複雜系統由大量獨立自治的簡單系統分層組合而成。
2、複雜動作是簡單動作組裝而成，不是修改而成。
整個體系由不同層次的多個職責單一的“微系統”構成（微服務），並且系統本身具備容錯性和迭代自由度，可在整體上達到一個動態容錯能力。最重要的是，整個體系中沒有 “集中式的上帝之手”的存在。這與雲原生所倡導的系統架構設計不謀而合，甚至雲原生誕生也受此啓發。
正所謂 “一鯨落、萬物生”，隨着傳統集中式架構的衰落和退潮，雲原生技術正在全面成長和湧現。
雲原生，本質上就是因雲而生的軟件、硬件、架構。雲原生也是不斷髮展演進的過程，雲原生（Cloud Native）概念在2015年被提出，後經CNCF進一步發展和提煉形成了包括容器、持續交付、持續集成、服務網格、微服務、不可變基礎設施和聲明式API的“狹義雲原生”概念。
今天，當我們討論“數字化”時候 ，事實上有兩個概念 ，一個叫原生、一個叫轉型。 狹義雲原生技術主要面對的是互聯網類的“數字化原生”企業的敏捷創新新型要求，多以互聯網類的無狀態的應用爲主，對數據一致性要求以最終一致性爲主。而對傳統金融類“數字化轉型”企業的已有的技術標準和技術資產（包袱）往往有較大的阻礙。
隨着雲計算技術的不斷深化普及，越來越多的新技術 “因雲而生” ，這些 “ 生於雲、長於雲” 的產品、技術、軟件、硬件、架構都逐漸成熟，並構成了“廣義雲原”生概念。未來“生於雲、長於雲”的“雲原生”型產品將會不斷湧現：新一代數據庫、人工智能、存儲、芯片、網絡和健康碼。雲原生極致的彈性、服務自治、大規模可複製等能力，更容易實現異構資源標準化、加速數字生產力釋放、加快業務應用的迭代速度、推動業務創新。它是數字化時代中衆多不確定性中“最大的確定性”，它強大的包容性代表了未來數字化企業的整體技術架構方向。廣義雲原生技術除了對“數字化原生企業”的技術架構敏捷創新要求之外，也兼顧了傳統“數字轉型化企業”的技術標準和架構兼容需求，所以具備更加廣泛的技術架構適用度、更好的企業級服務能力。
今天，隨着雲原生逐漸從社區走向金融機構、越來越深入人心，金融機構開始研究如何結合金融場景要求的雲原生落地 -- 將金融對安全合規、交易強一致性、單元化擴展、容災多活、全鏈路業務風險管理、運維管理等各方面行業要求與雲原生技術進行深度融合，發展爲一套既符合金融行業標準和要求、又具備雲原生技術優勢的“金融級雲原生架構”。能夠更好地滿足金融級對IT環境嚴苛地挑戰和要求，爲金融機構的傳統“穩態應用”（數字化轉型）和 “敏態應用” （數字化原生）應用提供統一的技術架構支持。
如果把過去金融的集中式架構（中央大腦）的統一控制作爲“左”，完全的開源式的分佈式雲原生作爲“右”。在金融雲原生架構下，金融機構所需要的技術架構就是在左和右之間尋求一個平衡點，做到：既具備金融級的安全、強一致性、可靠性，又具備容錯、擴展和快速響應的能力。提出“強局部自治、弱中心控制”架構來並屏蔽應用複雜性（例如：GRC架構，G-Global全局系統、R-Region 區域系統、C-City 局部系統)，僅將需要綜合多方因素判斷的複雜邏輯交由全局系統（中央大腦）完成，減輕中心繫統的負擔，而對於大量的日常簡單判斷和執行動作放在局部系統內閉環完成，提升容錯能力，進而提高整體系統的魯棒。
定義金融雲原生的10大新要素
雲原生架構是基於雲原生技術的一組架構原則和設計模式的集合，旨在將雲應用中的非業務代碼部分進行最大化剝離，從而讓雲設施接管應用中原有的大量非功能特性(如彈性、韌性、安全性、可觀測性、灰度等)，在沒有非功能性業務中斷困擾的同時，使業務具備輕量、敏捷、高度自動化的特點。在傳統架構中，應用層有較多的非業務代碼；而在雲原生架構下，理想情況是不再有非功能性代碼在應用代碼邏輯中體現，而讓其下沉到基礎設施中去，業務運維人員也只需專注於與業務代碼相關的部分。我們將金融級雲原生的核心總結爲如下10大架構要素。
要素1：平臺工程 & 不可變基礎設施
面對雲原生技術大規模使用，降低金融機構在研發和運維層面的複雜性，是制約雲原生技術落地的一個很大阻礙。目前從研發管理和運維管理角度， “平臺工程”和“不可變基礎設施”是兩個可以大幅降低複雜性的雲原生關鍵能力。
DevOps理念是“誰構建，誰運行”，開發人員應該能夠端到端地開發、部署和運行他們的應用。但對於大多數金融機構而言，這實際上並不容易實現。而原來被證明有效的勞動分工（Ops 和 Dev）對人才要求相對更低，但隨着DevOps範式的推崇，研發人員必須對所有事情都瞭如指掌，大大增加了“認知負擔”。這對金融機構的研發團隊提出了很高的要求，不利於普適型人才建設，也會很大程度地阻礙金融機構在雲原生應用的全面引入。如果說改進最可能的一個方向，那麼非平臺工程（Platform Engineering）莫屬了，平臺工程是DevOps和業務程序員之間橋樑。讓開發人員更快更好交付業務軟件的自助服務平臺。通過簡單頁面化的操作，就能完成這個環節的串聯配置，讓研發無需關注諸多運維工具的細節，專注在應用功能研發上即可。Gartner對平臺工程的描述 “平臺彙集的工具、能力和流程均由領域專家精心挑選，並經過封裝，以方便端用戶使用。其最終的目標，是打造無摩擦的自助服務體驗，爲用戶提供正確的能力，幫助其以最少的成本完成重要工作，提高終端用戶的生產力，並減少他們的認知負擔。”
傳統的可變基礎設施是指應用服務基於物理機或虛擬服務器進行部署，運行環境的構建依賴很多變量，諸如一些服務器上的配置、基礎軟件等，在不同環境之間可以通過動態配置下發或實時訪問外部服務更新應用的狀態，整個應用服務所依賴的基礎設施一直處於變化之中，當出現需要進行應急回滾的場景時，運維人員處理流程往往會比較複雜，容易出錯。
雲原生不可變基礎設施是指基於雲原生的鏡像化方案將應用依賴的基礎設施（操作系統、安全腳本、運維 Agent 、開發框架、運行環境等）打包成不可變的鏡像，應用發佈時只需依賴鏡像將容器拉起即可，極大地降低了應用的部署和運維成本，使得應用部署及運維變得更簡單、更可預測，同時應用運行環境也獲得了更高的一致性和可靠性。此外，基於鏡像還可以實現自動輪轉替換、自動回滾等運維功能，大幅提升了應用運維的自動化水平。一方面通過鏡像分層可以提升鏡像的管理水平，另一方面根據容器加載鏡像的原理鏡像分層可以一定程度上提升鏡像加載效率，從而提升應用啓動速度。
要素2：彈性混合雲
隨着雲架構成爲金融機構的平臺和基礎設施主流，按照業務單元具備按需彈性伸縮的能力，在面臨流量高峯時可以快速彈性擴展以提升資源和應用處理能力，當應用流量高峯過後可以快速釋放資源，以達到最大程度的資源利用率，因此需要構建一個靈活、可低成本複製的彈性架構。彈性架構本質是單元化架構的擴展，提供了一種以單元化架構中業務單元爲最小粒度進行彈性伸縮的能力，主要包含彈出和彈回兩個動作。彈出是以業務單元爲基礎的計算資源、網絡、應用、數據層面的全面彈出，是一個從底層資源到上層流量的整體彈性手段，彈出的單元稱之爲彈性業務單元。區別於普通業務單元，彈性業務單元具備以下幾個特徵：
局部性： 常規模式下擴展出的每個業務單元需要包含全量應用和全量數據，而彈性架構下彈出的彈性業務單元只需要包含單元內的部分應用和部分數據即可，通常是高流量鏈路涉及的相關應用。
臨時性： 區別於普通業務單元生命週期較長的特點，彈性業務單元的生命週期比較短，在支持“雙十一”等大促支付高峯後，彈性業務單元的業務請求會彈回到常規業務單元，隨後會對彈性業務單元進行釋放，以節省成本。
跨雲： 彈性業務單元通常會處於另外一朵或幾朵雲之中，彈性架構運用的場景所面對的流量峯值是日常的數倍，日常所在的雲計算底座很難提供充足的資源，這時就需要其他雲計算底座提供大量的資源支持。
彈性架構充分發揮了混合雲的優勢，海量的雲資源讓應用可以無限擴展以應對極高的流量峯值，在達到流量峯值後可以進行資源的快速釋放，真正做到資源按需彈性伸縮。
要素3：資源混合部署
在日常生產中，在線服務應用爲了確保較高的服務質量，往往會長期運行並且獨佔CPU資源，但CPU利用率卻很低;而離線計算任務正好相反，通常是短生命週期且對資源服務質量要求不高，但運行期CPU利用率很高。隨着業務規模的擴大，在線業務集羣和離線集羣資源池逐步變大，由於存在業務低峯期，會遇到資源利用率的問題，一個比較明顯的現象就是集羣的資源分配率很高但是實際利用率偏低。
金融機構在雲原生架構建設過程中進行在線和離線集羣混合部署，除了通過CPU彈性共享和優先級搶佔、離/在線應用錯峯編排、應用QoS等級劃分、內存分級管理等核心能力，以資源隔離和動態調整爲基礎，將不同屬性類型的在線服務和離線計算類服務進行精確組合，解決資源錯峯高效利用的問題外。對應到金融級的複雜性，需要建設如下混部能力標準：
大規模化、多場景的混部，將混部技術打造爲業務運行的基礎設施及環境，完善混部技術能力輸出，便於推廣到其他資源環境；
打通混部管控與運維體系一致性。統一資源接入流程，確保基礎軟件、配等置全局一致性維護與管理；
資源調度的靈活、高效、精細流程，在線-離線業務快速資源切換、一體化資源調度；
混部穩定性，達到和非混部同等量級的穩定性指標。依賴精細化地服務度量制定，以及資源隔離與業務運行適配度提升；
混部監控體系，提高運行時監控、異常發現與診斷能力；
混部異常應急機制，針對穩定性風險提前識別場景，並制定流程化應急機制，打造異常快速恢復能力。
要素4：多技術棧異構集成
服務網格可看作基礎設施層，用於處理服務間的通信。現代雲原生應用有着複雜的服務拓撲，服務網格負責在這些拓撲中實現請求的可靠傳遞。實踐中，服務網格通常是一組輕量級網絡代理，與應用程序部署在一起，可以將其比作應用程序或微服務間的TCP/IP，負責服務之間的網絡調用、限流、熔斷和監控。
在服務網格技術應用之前，微服務體系的實現方式往往由中間件團隊爲業務應用提供一個SDK，在SDK中會集成各種服務治理能力，如服務發現、負載均衡、熔斷限流、服務路由等。在運行時，SDK和業務應用的代碼混合在一個進程中運行，耦合度非常高，這就帶來了一系列問題：
一升級成本高。每次升級SDK都需要業務應用修改SDK版本號，再重新發布應用。在業務快速發展的時候，這類升級會影響到研發效率。
二是版本碎片化嚴重。由於SDK升級成本高，且中間件不斷向前發展，久而久之，就會導致SDK版本各不統一、能力參差不齊等問題，給統一治理帶來巨大的工作量。
三是中間件演進困難。由於SDK版本碎片化嚴重，導致中間件向前演進時需要在代碼中兼容各種各樣的老版本邏輯，如同戴着枷鎖前行，無法實現快速迭代。
金融機構的服務網格把原來通過SDK集成的一些網絡通信能力下沉到Sidecar中，包括基本的RPC、消息、DB訪問能力，以及在此基礎上的服務發現、熔斷、限流、流量管控、數據庫分庫分表的能力，以此給業務系統帶來較爲透明的通信基礎設施，將基礎設施的迭代演進與業務系統解耦，讓業務研發專注於業務邏輯，減輕業務系統的負擔，提升業務系統及基礎設施的迭代效率。
要素5：基礎架構連續性（公專一體）
當越來越多的核心繫統也在走向全面雲原生化，大規模資源的調度編排對於金融基礎架構連續性成爲必不可少的能力。如何爲金融機構內不同業務部門成千上萬個應用提供服務，如何讓不同應用使用好雲，滿足不同應用對資源訴求的差異並充分利用好雲的能力支撐業務增長，基礎架構連續性需要具備像公共雲一樣的統一資源的管理能力，這不僅僅包括傳統的泛交易類和數據類場景，也包括以GPU爲代表的新型異構計算硬件在大規模計算中的採用比例越來越高，如分佈式深度學習訓練任務，在線推理任務，流媒體編解碼任務等，所需要的更豐富的資源計算場景。
統一的基礎架構連續性進行底層資源的統一運營與管理，可以從供應鏈、容量預測、容量規劃、資源池彈性等多個維度，通過雲原生的豐富技術手段來優化成本提升效率，針對租戶Quota的管控能夠做到實時且準確，底層資源實現零泄露，以扁平易管理，靈活可配置，彈性可借調的方式同時支持所有的場景。
要素6：全鏈路技術風險防控
金融業務系統生產故障有較多都源於變更，變更管控對技術風險防控而言至關重要。特別是在微服務分佈式架構下，服務規模巨大，變更來源廣泛，如變更沒有很強的管控、追蹤能力，一旦線上發生問題，依賴人工追根溯源很難第一時間快速找到對應的變更，變更本身的質量也很難有效控制，這就需要有一套基於雲原生架構的“技術風險防控體系”，來進行全鏈路的風險和變更管控。
技術風險防控的核心指導原則是“變更三板斧”：可觀測、可灰度、可應急。任何變更都需要在執行前部署好可觀測能力，用於評判預期內的效果，識別預期外的問題，用於指導進一步擴大變更範圍和決策應急處置動作。“可灰度”強調的是變更需要逐步擴大範圍，從地域、數據中心、環境、服務器、用戶、時間等多個維度去設計灰度過程。“可應急”強調的是變更方案要優先保障可回退能力，一些變更由於情況特殊，不一定具備可回退能力或者回退代價無法接受，這就需要通過追加其他變更來處置，比如數據訂正、新版本上線等。“變更三板斧”也是金融雲原生架構下變更風控的核心能力，金融級雲原生架構需要在變更流程設計和運維平臺執行過程中強制約束了可“灰度”的落地，同時通過可觀測能力的整合，在變更過程中建設一些熔斷、自愈能力。
“全鏈路風險防控體系”的核心職責是通過整合所有變更信息，使變更可見、更可追溯。同時，提供變更編排、變更灰度檢查、變更預檢、變更結果監控預警等能力，當出現問題時通過提供變更關聯來加快線上問題處理速度。
此外，全鏈路風險防控體系還需要能夠產出資損風險點分析，制訂防控措施，明確預案細節；在質量測試分析階段要進行資金驗證的測試分析。發佈前要再次評估風險，檢查資損防控措施是否實施完成，包括實時覈對、 T + M 分鐘級覈對、 T + H 小時級覈對、 T +1隔日覈對等多維度佈防，並“責任到人”訂閱覈對預警，同時業務方對資金流要進行完整的驗收。通過證證、證賬、賬賬、賬實等覈對模式進行資金流操作。
要素7：雲原生安全可信
當前，互聯網環境下的外部威脅趨於多樣化、新型化，傳統的防禦手段對於已知的漏洞利用和威脅攻擊手法具有較好的應對效果，但是無法很好地應對APT攻擊、0Day漏洞攻擊等新型威脅。然而，這些已知的和新型的威脅存在着共同的特點：均是業務預期外的行爲。基於此特點，雲原生技術需要對所有的服務請求及資源加載行爲進行可信度量，建立起基於可信行爲的安全縱深防禦體系，確保只有預期內的行爲可以訪問執行成功，對預期外的行爲進行阻斷攔截來達到抵禦已知和未知威脅的效果。
同時，金融行業爲保障業務主體之間的安全隔離，基礎設施等技術服務也要從業務主體中構建隔離的環境，具備獨立隔離的網絡環境和更高等級的安全保障。雲原生平臺技術服務按照可信原生服務標準進行相關的多租戶隔離、統一管控、可信通道收斂等相關改造，升級爲可信原生服務。針對應用運行時所處的環境，雲原生安全可信架構在基礎設施中內置身份、認證、鑑權、全鏈路訪問控制、全鏈路加密等安全可信能力，並儘可能實現基礎設施與應用的解耦，以可信原生的方式減少對業務的打擾，提供可信的應用運行環境。
要素8：金融級一致性
雲原生應用以分佈式系統爲主，應用會被切分到多個分佈式的微服務系統下，拆分一般分爲水平拆分和垂直拆分，這並不僅僅單指對數據庫或者緩存的拆分，主要是表達一種分而治之的思想和邏輯。
分佈式系統的底層無法逃離 “CAP的不可能三角” （C: Consistency，一致性；A: Availability，可用性；P: Partition tolerance，分區容忍性）。CAP原理證明，任何分佈式系統只可同時滿足以上兩點，無法三者兼顧。而分佈式的服務化系統都需要滿足分區容忍性，那麼必須在一致性和可用性之間進行權衡。 如果網絡發生異常情況，導致分佈式系統中部分節點之間的網絡延遲不斷增大，可能會導致分佈式系統出現網絡分區。複製操作可能會被延後，如果這時我們的使用方等待複製完成再返回，則可能導致在有限時間內無法返回，就失去了可用性；而如果使用方不等待複製完成，而在主分片寫完後直接返回，則具有了可用性，但是失去了一致性。
對金融機構而言，架構層面的高可用和業務層面的強一致性，幾乎同樣重要。這就需要金融級雲原生能夠很好地平衡“CAP的不可能三角”，需要儘可能兼顧業務強一致與系統高可用。
但是“一致性挑戰”在分佈式系統中絕不僅僅是一個數據庫問題，而是一個大的話題，涵蓋分佈式系統的各個層面：事務一致性、節點一致性、系統間業務一致性、消息冪等一致性、緩存一致性、跨IDC一致性等等。所以也需要雲原生架構有一系列技術能夠應對金融級對一致性的嚴苛挑戰。
事務級： 需要根據不同的金融場景選擇合適的分佈式事務模式，在平衡成本和性能後，SAGA和TCC是目前金融機構比較常用的兩種分佈式事務模式。SAGA模式對應用實現侵入性更小，但基於補償事務來保障一致性的設計、前後步驟執行過程中不保證事務隔離性；而TCC模式能做到比較好的事務隔離性，但需要應用層感知更多的複雜度。對於事務流程中部分不需要同步返回結果的節點，爲提高執行效率可採用異步消息隊列實現，對於一些事務流程較長的場景可明顯降低事務實現複雜度、削峯填谷。典型場景如客戶購買理財場景簡化分爲存款賬戶扣款和理財賬戶入賬兩個步驟，如選用SAGA模式，存款賬戶成功扣款後、理財賬戶入賬失敗，客戶會看到“錢已付、貨沒到”的中間異常狀態，需要系統進行衝正存款賬戶扣款來保障事務一致性。若選用TCC模式，先後完成存款賬戶扣款、理財賬戶入賬的邏輯處理，各自需要存款系統和理財系統記錄邏輯處理的狀態，二者均成功後再發起統一提交。
數據庫級： 金融場景下對於數據不丟有着極致的要求，一方面需要在同城、異地多個機房保存多個副本，另一方面需要在多個副本之間實現數據同步，保障同城RPO爲零、異地RPO接近零。Paxos算法是基於消息傳遞的實現分佈式系統數據一致性的算法，是至今爲止公認的實現一致性的最有效的算法之一，分佈式數據庫通過對Paxos的支持來實現跨多服務器，甚至跨多中心的數據一致性保證。
機房級： 跨機房的路由能力、異常事務的跨機房恢復能力。發生機房故障時，數據庫需要能夠切到同城/異地的副本、並保障RPO爲零，配合應用層的交易路由切換，完成機房級容災切換、恢復業務。期間因機房故障導致的部分交易事務流程中斷，分佈式事務組件需要具備自動恢復能力，重新啓動中斷的事務流程按事先設定的業務規則向前完成或向後衝正。
要素9：單元化多地多活
隨着數字金融業務的快速發展，傳統集中式生產環境已經很難滿足需求。當前演化方向是“異地多活”的單元化架構，以單元化機房（後面簡稱爲LDC）爲基礎運行單元，以滿足快速發展的數字金融業務對基礎設施擴展和容災的高時效性、金融級安全性要求。
金融機構普遍採用的“兩地三中心”架構有幾個典型的不足，一是該架構要求同城雙中心具備接近的機房容量以滿足全量切換，二是該架構模式下異地容災系統平時一般是“冷”的，並不真正承載業務流量，且災難發生時很難接管全量業務。隨着新建數據中心普遍集中在內蒙、貴州等遠離傳統數據中心的地域，新老數據中心容量配比很不均衡等客觀條件限制下，要求金融機構在運行架構上突破“兩地三中心”的傳統模式，向N+1“多活”的災備方案演進，進一步提升故障恢復的體系性能力。
“異地多活架構”是指基於LDC單元化架構的擴展能力，在不同地域的IDC中部署LDC單元，並且每個LDC單元都是“活”的，是真正承接線上真實業務流量的，在發生故障時，可以進行LDC單元之間的快速切換。 異地多活單元化架構解決了以下四個關鍵問題：
由於儘量減少了跨單元交互和使用異步化，使得異地部署成爲可能。整個系統的水平可伸縮性大大提高，不再依賴同城IDC；
可以實現N+1的異地災備策略，大大縮減災備成本，同時確保災備設施真實可用；
整個系統已無單點存在，大大提升了整體的高可用性；同城和異地部署的多個單元可用作互備的容災設施，通過運維管控平臺進行快速切換，有機會實現100%的持續可用率；
該架構下業務級別的流量入口和出口形成了統一的可管控、可路由的控制點，整體系統的可管控能力得到很大提升。基於該架構，線上壓測、流量管控、灰度發佈等以前難以實現的運維管控模式，現在能夠十分輕鬆地實現。
要素10：業務連續性和數智化運維
在雲原生環境下需要對多個容器、多個虛擬機、多個主機、多個可用區、甚至多個地域上的信息進行關聯，纔可能回答清楚服務爲什麼宕機、爲什麼沒有實現定義的SLO、故障影響了哪些用戶和業務等這一系列問題，纔可能基於運維數據和AI智能實現高效的“監控、變更、應急、容量、容災、演練”數智化運維管理。
雲原生數智化運維主要包括七方面能力：
監控發現能力：指標、日誌、鏈路全方位可觀測性，全面覆蓋業務、中間件和基礎設施，並且可層層下鑽。
故障應急處置能力：異常全面發現，快速定位和恢復的能力，確保業務SLA。
變更風險防控能力：業務全方位變更管控，嚴守“可灰度、可觀測，可回滾”三板斧。
容量管理能力：從業務到基礎設施提供全鏈路容量精準評估和風險提前識別能力，達到穩定與成本的平衡。
容災管理能力：平臺化可編排容災，支撐機房容災，單元化容災等場景，覆蓋演練，切換和大屏等能力。
演練評測能力：通過混沌工程、紅藍攻防等方式，對業務風險保障能力進行探測和檢驗。
資金安全保障能力：基於資金安全覈對規則，通過離線、實時、文件等方式對業務系統的資金流進行監測。
雲原生數智化運維主要具備三方面特徵：
高效 : 通過運維工作的平臺化來提高運維效率。如系統監控平臺、變更管控平臺、動態資源管控平臺、調度中心、註冊中心等。
安全：基於自動業務驗證平臺和大數據運算規則，保障系統運行的穩定性與正確性。如數據覈對中心、依賴管控平臺、容量檢測管控平臺等。
智能：基於大數據的分析和規則計算，進行智能化的運維管控。如自動故障分析處理系統、容量自動探測擴容系統等。
構建金融雲原生的新藍圖
金融級雲原生應用架構
《架構即未來》一書提出了分佈式應用設計的十四條基本原則，而這正是最爲重要的雲原生應用架構的核心要素。
N+1設計：要確保任何你所開發的系統在發生故障時，至少有一個冗餘的實例。回滾設計：確保系統可以回滾到以前發佈過的任何版本。
開關禁用設計：能夠關閉任何發佈的功能。監控設計：在設計階段就必須要考慮監控，而不是在實施完成之後補充。
設計多活數據中心：設計時就考慮多活部署，不要被一個數據中心的解決方案把自己限制住。
異步設計：異步適合併發，只有在絕對必要的時候才進行同步調用。
無狀態系統：無狀態的系統更利於擴展，更利於做負載均衡。只有當業務確實需要的時候，才使用狀態。
水平擴展非垂直升級：永遠不要依賴更大、更快的系統。微服務核心思想是水平擴展，不要把所有的功能都集中在一個系統裏面。必要的時候把需求分爲多個系統，而不是升級原有的系統。
設計的前瞻性：提前考慮影響下一階段系統擴展性問題的方案，不斷提煉公共共享服務，以減少重構的次數。
非核心則購買：如果不是你最擅長的，也提供不了差異化的競爭優勢則直接購買。數據庫、雲服務這種的就購買好了。
小構建，小發布，快試錯：全部研發要小構建，不斷迭代，讓系統不斷地成長。小版本的失敗率較低，因爲失敗率與解決方案中的變更數量直接相關。
隔離故障：實現隔離故障設計，通過斷路保護避免故障傳播和交叉影響。避免多系統之間的互相影響，這個很重要。
自動化：“自動化是智慧之源”，在雲原生架構中，快速部署和自動化管理是核心。設計開始就需要儘可能通過架構和設計實現自動化的過程。如果機器可以做，就不要依賴於人。
使用成熟的技術：如果某技術故障率比較高，就絕不能使用。
金融級雲原生平臺架構
金融雲原生平臺架構整體可分爲：設計域、研發域、運行域、運維域、災備域 5大領域。
設計態：採用領域驅動設計等與微服務架構體系天然親和的設計方法，並在設計過程中，關注數據一致性、服務顆粒度等問題，貫徹分佈式架構設計的設計原則和規範。
研發態：面向研發人員，提供一站式的研發生產力工具，屏蔽分佈式技術的複雜性，提升研發人員體驗和生產率。達成廣泛共識的工程模板，降低組織認知成本。
運行態：面向應用，分佈式應用運行的基礎設施，覆蓋應用全生命週期，包括創建、部署、監控、變配，支持多種形態的應用交互方式和數據存儲形態。底層支持多種形態的計算方式以及其上的調度方式。
運維態：面向運維人員，解決分佈式架構的先天覆雜性，廣泛使用工程手段，保證系統整體可用性水平。
災備態：面向災難，提供對節點級、機房級、城市級災難的容忍能力。
金融級雲原生數據架構
雲原生框架天生具備快速交付、彈性伸縮、標準化、自動化、隔離性等諸多優勢，與新一代數據技術不斷融合，形成了具備如下幾個特點的雲原生數據架構體系。
1、可擴展的多種計算模式融合
雲原生數據架構可統一支持批、流、交互式、多模、圖等不同計算模式的融合，例如：湖倉一體、流批一體、流式機器學習，使多種計算系統進行深度整合，在功能、生態上形成互補，用戶能夠在一套系統內完成更多種類型計算,提升平臺運行效率，降低使用成本。
2、多層智能化的分佈式存儲層
存儲計算分離會在兩三年內成爲標準，數據平臺向託管化和雲原生的方向發展。存儲內部精細化的分層成爲平衡性能和成本的關鍵手段，基於分佈式存儲系統上的多層存儲(熱存儲/標準存儲/冷存儲等)與存儲利用相結合實現存儲降本。AI在分層算法上將發揮更大的作用，編碼和壓縮在通用處理器上的優化空間有限的情況下，未來更大的突破和技術換代將取決於軟硬一體化的技術發展及應用情況。
3、統一調度和彈性伸縮的資源池管理
隨着數據湖存算分離不斷深入, 圍繞基於雲原生架構下來建立統一容器化資源調度系統成爲數據湖存算分離發展的必要組件，爲大數據與AI一體化架構提供統一資源池化與在離線混部的基礎支撐；通過統一算力資源池實現資源統籌調度，優化資源細粒度的管理與調度，可以將離線計算與其它在線計算任務進行資源混部達到峯谷互補的效果，有助於提升服務器資源利用率；同時，也可以根據業務優先級分配計算任務資源，確保資源調度期間不發生爭搶，實現在業務高峯期，以彈性擴縮容模式調用算力資源，充分發揮資源算力，提升響應效率。
4、大數據SRE智能運維能力
大數據技術多樣性和數據平臺架構的複雜性，爲大數據平臺的運維帶來挑戰。新一代大數據平臺可支持在線滾動升級，縮短升級時長；提供統一運行各類異構工作負載流程，統一管理作業生命週期，統一調度任務工作流，爲任務的規模和性能提供保證；通過作業日誌，性能指標，資源利用率等數據，結合歷史記錄和實時負載情況，使用機器學習方式進行分析、檢測和調優，在查詢計劃、數據模型、資源管理自適應，以及系統異常檢測和自愈等方面不斷優化，形成大規模數據平臺的智能化運維能力。
金融級雲原生基礎架構
金融級雲原生基礎設施需要滿足5大總體要求和13項管理要求。
（一） 5大總體要求爲：
一是採用成熟雲平臺產品，打造IaaS、PaaS一體化雲計算平臺，實現租戶端和運維端的完整服務目錄，與軟件開發體系和生產運維體系無縫對接；
二是實現全公司級基礎資源彈性供給，按照分佈式技術框架，支撐全公司業務系統實現高可用容災架構，滿足安全生產要求；
三是全面滿足信息技術應用創新要求，從雲平臺底座到軟件服務具有全鏈路信息技術應用創新運行的能力，同時保障分佈式應用高性能穩定運行；
四是具備提供大規模應用上雲的基礎，提供完善的應用框架，對應用系統提供穩定、持續、高性能的支撐；
五是雲平臺產品有成熟生態圈，與業界公有云技術發展保持基本同步，適配最新開源技術演進。
（二） 13項管理能力要求爲：
統一資源管理：採用統一的物理資源類型和架構實現基礎硬件資源的統一管理，如服務器、交換機、操作系統等；雲管平臺通過統一管理方式（控制檯、API等）實現兩地三中心的計算、存儲、網絡等雲資源進行管理，降低開發和運維使用複雜度。
統一數據管理：對同城雙活、異地多活架構通過數據存儲、遷移、同步等方式，保障分佈式雲節點數據一致性，提供一體化容災及聯動切換能力，最大限度滿足業務連續性要求。如提供統一的鏡像方案、對象存儲的容災、數據庫跨地域備份和同步等。
統一服務管理：支持兩地三中心節點通過統一的API、SDK、控制檯等管理雲服務，如統一控制面進行服務的部署、更新等，大幅降低雲服務管理複雜度，提升用雲效率。
統一運維管理：通過雲管實現對兩地三中心不同節點採用相同的運維體系進行管理，提供一致的運營、監控、可靠性SLA等服務，減少運維管理人員工作量，提升運維效率，大幅降低系統故障，縮短故障時間。
統一安全管理：一方面通過物理基礎設施、網絡安全、數據面/控制面隔離等實現平臺側安全，另一方面通過主機安全、訪問控制、防火牆、態勢感知等實現安全服務，保障一體化安全。
統一資源調度：通過雲管實現對兩地三中心算力資源的統一調度，提供多種調度策略支持。基於位置調度滿足對時延和帶寬敏感的業務（如手機銀行音視頻應用）；基於算力需求調度滿足對AI、大數據等大計算量的業務（如潮汐調度、混部等場景）；基於工作負載調度滿足多維異構的場景（如理財搶購、積分兌換、雙11等應用場景）。
統一監控管理：完成雲上和雲下各類型監控指標的接入和統一展現；完成雲上和雲下分佈式鏈路追蹤能力，實現從業務監控、到應用服務監控、到資源監控的逐層下鑽和多維分析，完善故障定位分析能力；通過統一告警中心的對接和優化完成動態閾值，提升業務整體事件感知能力、快速定位能力和智能化分析決策能力。
支撐多元算力：雲資源池兼容CPU、GPU等多種算力，爲人工智能、深度學習、科學計算等多領域場景的金融科技類新應用產品提供高效的雲算力服務。
支撐全棧信息技術應用創新：通過一套體系兼容多產品服務能力，支撐一雲多芯、全棧XC雲平臺服務能力，推動信息技術應用創新戰略落地。
支撐精細化管理：通過平臺的計量計費能力以及與行內各系統打通，實現計算、存儲、網絡、安全等多類資源的計量計費能力。逐步實現IT成本精細化管理，實現業務IT投入與業務產出可度量、可評價，實現成本與效率的兼顧，實現IT資源的高效利用。
支撐裸機管理：滿足裸金屬交付從服務器上架、自動化裝機、系統設置和軟件編排的流程自動化和批量化，提升交付效率，降低人工工作量；滿足裸金屬統一納管要求，實現裸機的統一監控和告警。
支撐服務質量：通過自服務能力提升，基礎設施管理平臺的建設將能夠提供高效穩定運行精細化管理提供更好的服務，根據平臺對於數據的收集及分析，將有效的改進管理方向和內容，能有效增強服務品質。
支撐架構發展：採用行業領先的專有云架構，搭建與公有云同源、滿足金融行業容災要求的雲平臺，通過一套體系支撐所有產品，支撐全行線上線下一體化運維體系建設，通過有機統一的體系結構設計，滿足未來全棧雲平臺能力建設。
05 金融級雲原生實現路徑
金融級雲原生能力評估
“投資未來的最好方法是改善現在”。
金融級雲原生極大的釋放了數字化時代的紅利，雲原生充分繼承雲的設計思想，未來應用將更多基於雲上進行應用開發，即雲原生應用更加適合雲的架構，而云計算也爲雲原生應用提供較好的基礎支撐，如資源隔離機制、分佈式部署、高可用架構等方面，通過新的架構、技術保障應用系統變得更加健壯，可以說雲原生最大程度發揮了雲的優勢。
某銀行基於IaaS/PaaS 一體化雲平臺，運用分佈式微服務框架、雲中間件、容器、DevOps 等雲原生技術，搭建了可提供橫向擴展、秒級伸縮、智能運維、適應快速開發持續交付的 PaaS 級雲平臺，推動該銀行從傳統架構向互聯網架構演進。該平臺基於容器進行應用部署、運行、調度資源，利用容器的輕量級特性，在服務數量激增的情況下節省更多應用部署和運行資源，可以輕鬆應對波動的業務流量。同時，應用的鏡像交付形式實現了“一次構建，多次部署”，避免傳統部署過程帶來的操作複雜度與操作風險。通過該平臺，應用交付週期縮短了 80%，業務需求響應速度提高 50%。
然而，在金融機構開始大量採購採納雲原生技術時，卻存在雲原生技術產品體系過於龐雜、開源生態缺乏治理、產品之間兼容適配困難等諸多問題。局部技術特性往往給金融機構選擇造成很大幹擾，併產生較高的試錯成本。
“拋開整體來看局部細節都是耍流氓”。
越是平臺型技術，越需要從整體角度來考量。所以，迫切需要一套結合行業特性的統一標準，爲金融機構提供一個能力參照模型，以便金融機構定位自身雲原生技術轉型的發展階段，對比分析發現雲原生能力建設的不足，制定未來技術和能力建設方向。我們結合一些金融行業實踐，爲金融機構採納雲原生技術提供一套完整的技術能力框架，和九大維度的成熟度評估模型，可以參考如下指標進行展開：
微服務架構程度、應用雲化程度、可觀測性、高可用管理、配置自動化、DevOps、雲平臺能力、雲原生安全、容器及K8s能力。
金融級雲原生演進路徑
好的架構是進化來的，我們既需要一套完整的架構規劃，來確保完整性和建設規範，但也需要架構能夠持續演進，確保整體穩妥可控，所以我們歸納總結了兩種雲原生架構演進路徑作爲參考。
參考路徑一：全局宏觀尺度來看（從上向下），根據雲原生能力評估來尋找技術短板和演進路徑。 如下示例是一個雲原生架構三階段演進路徑，幫助金融機構逐步實現應用架構從單體微服務改造，走向單元化，實現同城雙活再到異地多活的變遷。尋求最平衡的架構發展路徑以滿足業務發展和嚴苛場景考驗。
參考路徑二：從問題出發（從下向上），架構演進的目的一定是解決某一類問題。 不妨從“問題”的角度出發，來設計整體雲原生架構演進。如下示例使一個以解決技術問題來不斷進行雲原生架構演進的實踐。
步驟1：爲了讓整個應用架構有“更好的底層支撐”，將應用架構運行在雲平臺上
步驟2：爲了解決單體架構“複雜度問題”，使用微服務架構
步驟3：爲了解決微服務間“通訊異常問題”，使用治理框架 + 監控
步驟4：爲了解決微服務架構下大量應用“部署問題”，使用容器
步驟5：爲了解決容器的“編排和調度問題”，使用 Kubernetes
步驟6：爲了解決微服務框架的“侵入性問題”，使用 Service Mesh
06 結語
本文將廣義雲原生的技術理念和金融級的技術標準進行了映射和結合，定義了金融級雲原生的藍圖和十大要素，旨在讓雲原生的先進技術理念能夠擴展到企業機構全方位技術棧，給金融行業的面向信息技術應用創新的架構規劃提出了全新的參考架構，讓我們一起堅持探索和實踐，爲金融級的架構創新提速。
作者簡介：
劉偉光，阿里雲智能新金融&互聯網行業總裁、中國金融四十人論壇常務理事，畢業於清華大學電子工程系。 加入阿里雲之前，在螞蟻金服負責金融科技的商業推廣和生態建設工作以及螞蟻區塊鏈的商業拓展工作；在企業軟件市場深耕多年，曾經創建Pivotal軟件大中華區分公司，開創了企業級大數據以及企業級雲計算PaaS平臺的市場先河。在創建Pivotal中國軟件公司之前，劉偉光曾經擔任EMC大中國區數據計算事業部總經理，並在甲骨文中國公司工作多年，曾經創建了Exadata大中國區的產品事業部並擔任事業部總監。