很多金融機構在考慮「上雲」與否的時候，並不清楚自己能得到什麼。
其實他們最在意的，是希望技術保證核心穩定運行，是整體完全自主掌控，是最後達到每單筆交易/每個賬户成本下降的目標，是在業務穩定性、連續性不降低的前提下，支撐業務敏捷。
抽絲剝繭數個實踐合作案例後，我們可以看到，金融機構的訴求，或許可以分為三環：
最難解決的是“1環”問題，分佈式事務怎麼實現？各種模式應用在哪些場景？有何利弊？異地多活情況下，數據庫怎麼保證良好的支撐？
到了“2環”，重點落在領域化建模，機構們要參考最佳實踐，思考底層模型框架如何處理，他們也在關心集中化架構——分佈式架構——雲化架構，有沒有一些特殊的差異？
上升到“3環”，訴求就會涵蓋整個雲化環境下的運維保障體系、devOps體系、整體的部署架構體系……
2020年被認為是雲原生核心的元年，更多金融機構逐漸從混沌中醒來，與科技公司聯手摸索出核心系統的“病灶”所在，對症下藥。
陳威是阿里雲新金融事業部金融核心部負責人，曾從事企業級信息技術產業十餘年，具備豐富的應用架構與設計，數據智能，雲平台，互聯網等領域的理論與大型複雜項目實踐，尤其在金融行業具有多年的交叉實踐經驗，服務於近百家大型機構與客户。
在雷鋒網《AI金融評論》與阿里雲聯合主辦“銀行系統雲化升級”實戰體驗營中，陳威就從阿里雲服務金融機構的過往經驗中提取精華，詳盡深入地討論了他們在金融核心系統轉型方面的探索和實踐。
欲獲得所有講者視頻，可關注公眾號“AI金融評論”（ID: aijinrongpinglun），進羣獲取回放鏈接。
以下為陳威演講內容，雷鋒網做了不改變原意的編輯和整理：
今天的主題是《金融核心雲原生轉型的探索與實踐》。
在整個金融業，尤其在銀行領域，核心系統是IT整體支出佔比最大，最為複雜，對於技術要求最高的一塊。這也是我們認為，整個金融行業包括銀行，在朝着雲化轉型的理念裏，最後最難的一部分。
今天的內容首先會講到銀行核心系統雲化轉型的訴求，簡單來講就是客户和我們為什麼要做這件事？其次是核心雲原生轉型的挑戰與應對。
銀行核心系統雲化轉型的訴求可能在座的聽眾有所瞭解，金融核心實際上經過了好幾代，存在代際的差異。
最早是傳統綜合業務系統這部分，然後到第一代基於主機的單體式核心系統。比如錢存在國有大行那裏，都是在主機系統Mainframe（大型機）上。
大量的農商農信體系是在AS400上；還有一部分在Power小型機系列。
第二代就是我們通常看到銀行會走到瘦核心的階段，從原來的核心繫統進行拆分，尤其是面向敏態的部分，通常會建設一個叫互聯網核心的系統。
第一代的技術架構的改造或者升級，通常的做法，基於從單體下移到基於ESB的SOA架構。近幾年有些開發商會基於開源Spring Cloud把這部分SOA架構升級到微服務的架構。
從技術架構路線來講，這是從ESB向微服務框架的體系改進，這就是我們經常聽到的分佈式核心的實際的現狀。
從應用架構路線來看，技術層面雖然有一些升級，但是它底層模型和應用架構，其實沒有太大變化。
第二代核心的典型特徵就是以ESB為核心和微服務架構，但有個問題沒有解決：底層對業務敏捷的支撐是心有餘而力不足。支撐一些新的產品，服務或者功能上線需要大量的人力定製化開發，業務並不夠敏捷。
隨着雲計算技術的不斷髮展和成熟，雲化的潮流勢不可擋，不論是傳統企業還是金融系統，有意願和動力升級到雲上核心，這就是所謂的第三代，也叫雲原生核心，基於容器雲原生或者基於PaaS等技術。
它跟我們通常理解的分佈式核心，實際上有較大差異。第三代是完全走向IaaS/PaaS化，但在底層應用架構方面，其實也有相應的變更，類似於大家聽到的中台化、領域設計，這些關鍵字都會在第三代核心中有所體現。
- 第三代金融核心關鍵性標準
我們試圖總結一下第三代核心的一些關鍵詞，經過長時間的調研與歸納，形成了這麼一些標籤，雲原生，異地多活，中台化，數字化。
雲原生和異地多活，偏向技術架構和基礎設施；中台化和數字化，偏向於業務和應用。
雲原生：金融核心實際上也是應用系統，本質上和其他業務系統沒有特別大的差異，但是它比較複雜，對業務連續性和一致性的保障會比較高。
同時，它本質上是一個應用，所以雲原生應用該具備的特徵，它實際上也具備。比如容器化部署模式，PaaS的資源供給應用需要的能力，這都屬於雲原生範疇。
異地多活：大部分新建的銀行要做的核心，基本上會有異地多活。它不光是同城容災或者異地容災，是能夠做到多地多活的模式，可以做到城市級的容災。對於傳統金融機構而言，異地多活也是比較大的挑戰。
中台化：原來的集中式架構，就是傳統一個大的單體化應用，牽一髮而動全身。
當需要定製化或創新金融產品服務，尤其是疫情常態化之後，未來有很多不見面的流程服務，包括基於互聯網或者視頻的新渠道形態，原來的架構不能複用。
這時希望打造一個堅實的業務中台能力，能夠支撐未來多變的挑戰。中台化最終是為了提高面向創新的效率，這也是建中台的初心，這是支撐業務敏捷非常重要的手段。
數字化：能夠以數字化模式，展現裏面所有運營相關內容，有了數字化運營的基礎和能力，智能自動化運維才有空間，這是核心未來發展的重要方向。
其次，因為核心系統的生命週期非常長，可能會要支撐全行的業務支撐十年八年的的時間。如果遇上比如數字貨幣這種國家大力推行的方向，它對於核心有怎樣的挑戰？所以架構上的設計，一定要把這個（時間跨度）也考量進去，具備很強的擴展能力。
第三代金融核心的重要意義
自主創新：首先它是自主創新的一個標杆。但從我們的觀察來看，2020年是雲原生核心的元年，諸多傳統金融機構在逐步的進行嘗試。
行業標準：在第三代核心，或者全分佈式、雲原生、多活核心架構領域，還沒有公認的標準。金融機構非常想去打造行業的先鋒標杆，沉澱的卓越實踐參考。
實施工藝：核心是一個龐大的項目羣，週期很長，可能有不同的開發商，涉及的人員非常多，不可能按照原來的小應用開發模式，必須要有一套統一規範的框架和實施工藝，支撐長生命週期的大型系統開發，能夠在上面開發整個核心系統上百個應用。
能把這三點做好，是我們認為第三代核心在金融機構落地的標誌。
- 第三代金融核心的業務價值
首先是全棧式的自主可控，滿足相關的要求。
多活架構，可以做到RPO=0，甚至是城市級的容災，RPO=0，有問題的話恢復時間＜1分鐘。如果大家對於基礎設施比較瞭解，就會了解要達到這樣一個指標會有多麼巨大的挑戰，只有達到城市級別的RPO=0，RTO分鐘級，才能夠真正的保證業務的連續性。
彈性擴展，基於分佈式架構的擴展性，一定比集中式架構要好，所以它完全能夠滿足業務的特殊要求或者線性增長，支撐傳統金融機構做類似於雙十一這樣的大促銷，金融爆款產品的秒殺，或者是一些高併發的場景金融。
業務敏捷，產品團隊能很快在該框架的核心上，實現新的金融產品和服務。在傳統的集中式架構下，上線新的大一些的功能就可能需要大量改動核心內部、關聯繫統，造成業務上架用時較長。基於微服務或分佈式架構的，可以通過devops模式縮短業務交付時間。
運維成本，雲原生架構基於相對低廉的x86服務器構建，同等處理能力下，分佈式架構的單位運行成本大幅降低，分佈式架構的年均運行維護成本是大型機的17%。
- 金融機構們的訴求是什麼？
在一個分佈式的雲化環境中，要保證核心穩定運行，其實有三個非常關鍵的標誌。
整體完全自主掌控。
從財務的角度看，最後達到每單筆交易/每個賬户成本的下降。
業務穩定性、連續性不降低的前提下，支撐業務敏捷。
這三點衍生出金融機構對供應商/合作伙伴的訴求，大體分為4個方向。
諮詢與設計：架構諮詢指導，技術，開發規範等，配套的組織體系架構等。
服務交付：服務的長期交付過程，一般來講建設週期在2~3年，所以整體的人員投入，開發實施交付規範等。
運維保障：後續的長期運維保障，出問題怎麼監控、解決，怎麼更自動化；
產品與方案：最底層的是產品方案的支撐，包括整體規劃路線圖，產品的延續性、一致性、無縫升級維護，還有產品計劃的發佈策略、相應的生態豐富度。
客户的訴求可以分為三環，最難解決的是“1環”問題：
業務一致性，怎麼實現分佈式事務？各種各樣的模式，到底用在哪些場景？各種模式的利弊是什麼？
數據一致性，尤其是異地多活這種情況下，數據庫怎麼保證良好的支撐，尤其在異地之後的數據容災等問題，都是基礎架構部門非常關心的“1環”內容，通常很難靠金融機構自己解決，一般需要外部供應商來做。
“2環”重點是怎麼領域化建模，有沒有一些最佳實踐？底層模型框架怎麼處理？集中化架構到分佈式架構，再到雲化架構，有沒有一些特殊的差異？
“3環” 涵蓋整個雲化環境下的運維保障體系，devOps體系，整體的部署架構體系，比如怎麼做單元化架構等。
雲原生轉型的挑戰和應對從哪些框架/思路，去解決轉型訴求帶來的挑戰？
可能原來大家理解的，主要是在業務和數據建模，以及底層的技術軟件支撐。但在大量調研之後，發現其實中間還缺兩層，就是架構集成、開發運維部分，這也是要攻克的難點。
之前講到，第一代、第二代（金融核心）裏這塊業務流程不會有太大調整，但在第三代，一定要真正讓它敏捷，對業務流程清晰梳理，同時要能轉化為類似中台的模式。
上半部分屬於企業級架構建模的範疇，下半部分是建模之後怎樣在雲上落地。
- 我們怎麼做敏捷的架構設計？
做敏捷的架構設計，首先要考慮中台化領域設計。
相對傳統的服務集成架構是渠道層+整合層+核心系統，但中台化分層就會拆成渠道層、開放層、產品服務層、中台能力層、基礎服務層等。
其中，渠道層，包括各個電子化渠道，開放互聯網渠道，線下的渠道等。
像產品服務層，其實不是產品真正執行代碼的地方，實際是業務能力編排的領域。例如存貸款這些業務，也是經過一個流程編碼，調用不同的引擎賬户和中台能力，去支撐完成業務鏈。
其次是思考雲原生應用框架的搭建。
為什麼要考慮框架？我們在客户項目中經常遇到一個客户的問題，感嘆懂業務的不懂雲原生分佈式；懂雲原生分佈式的，對業務理解可能也沒有那麼深。
現在更先進的底層技術，比如雲原生分佈式數據庫，學習使用和運維的難度可能比原來要高，這樣會極大影響技術的可獲得性，就是好不好用的問題。
這需要一套框架整合起來，在業務組件技術層面封裝，降低開發難度，最後讓普通的應用開發人員，能夠像普通單體架構一樣開發業務應用，而不用關心這後面到底是在什麼樣的環境裏部署的。
再就是底層基礎設施部分。
因為開發週期非常長，難免中間有老的核心繫統，怎麼統一完成服務調度治理，怎麼在儘量不改代碼的情況下，更平滑地接入和交互？
其實我們講的mesh技術，就比較好解決這個問題。我們也發現很多客户不由自主地運用mesh來支撐集成的架構核心。
使用mesh，下一代的微服務技術，結合分佈式網關，能夠跟ESB對接，支撐傳統業務調用——這也是服務網格目標。這部分與現在經常講到的low code低代碼、低侵入，都具備相近似的模式。
如果想用mesh的模式實現異構架構集成等？這就尤為需要關注雲化分佈式改造方面的新進展。
以往來講，spring cloud這套體系，如果你要寫一個比較健壯的核心應用，一定要在體系裏把所有代碼和編排都放進去，實際上每個真正的業務代碼量佔整體比較少，會有大量業務無關的邏輯。
這部分如果通過mesh技術，直接用sidecar處理，對於原來的業務應用不會有大量的侵入。因為走的是網絡層所有監控，所以能夠把整個架構的鏈路全部清晰表達出來。這對全方位監控也是很重要的內容。
- 如何保證質量安全與穩定性？
客户無論是大機下移還是雲化轉型，都有一個非常重要的前提：保證自身業務連續性；保證整體業務安全情況下，能支撐業務敏捷。
在質量安全與穩定性方面，我們有一整套可回滾可灰度可監控的防控體系，分為三層質量網。
未來一旦微服務化、雲化，它會有大量的容器應用，不大可能靠人力定位最終的問題，一定要靠自動化、智能化的方式解決傳統的巡檢監控問題。總的來説，會有配套機制保障終端客户不出問題，設施是不可靠的，要從應用、軟件、機制規範、工具體系支撐。
另外就是異地多活架構。
這部分實際是支付寶能去支持雙十一的底層核心架構，是三地五中心的多活架構。在互聯網上，我們一般採用客户ID號尾號分片的方式，最後拆到100個單元，能夠在不同機房之間精細調撥流量。
所以任何一個機房或城市出現問題，我們都能把流量瞬間調撥過去，同時業務應用能承擔起來，機房級或城市級容災都能做到RPO=0。這裏面非常核心的，就是底層分佈數據庫，真正能夠支持異地容災的分佈式結架構。
比如在異地機房，整個單元從端到端升級到一個新的架構，現在可以做到機房級的邏輯單元架構更新，或者應用版本大規模升級，這些都可以通過單元化方式實現。
無論在哪個級別，RPO都能做到等於0，但由於網絡或者物理限制，無法做到RTO=0。
陳威在本場演講中，還談到了金融核心轉型的實踐路徑和案例分析，並回答了銀行大機下移、數字貨幣對金融核心的挑戰等提問。欲獲得本場演講回放，可關注公眾號“AI金融評論”（ID: aijinrongpinglun），回覆關鍵詞“參會”，進羣獲取回放鏈接。
雷鋒網