0
核心系統轉型，相當于給正在跳動的心臟，做一場不停擺的換心手術。
不少核心系統采用的傳統集中式架構，已經不止是一種技術架構模式，而成為一種根深蒂固的思維習慣和設計理念。當它成為潛規則而影響了創新時，我們往往身在此山中而不為所知。
在阿里巴巴集團副總裁、阿里云新金融&互聯網事業部總經理劉偉光看來，不少機構在做核心系統轉型時，極易陷入窘境：
選擇應用平遷、不做架構大變化，最簡單和快捷。有的銀行正因如此，開發力量80%以上的時間是在做代碼的性能優化，難以承接新功能、新業務的開發。
先從簡單系統著手進行架構轉型，再推導到核心轉型。結果非核心領域的轉型實踐對于核心領域的參考借鑒意義有限。
核心系統按照功能模塊切分，再眾包給不同的開發商來完成，避免被一家綁定。
選擇各個領域的最佳“供應商”，完成各自擅長的工作任務（咨詢建模、架構、設計、應用、基礎軟硬件），大家只熟悉自己這部分的“最佳實踐”。
追求技術架構完成解耦，碎片化供應商。實際上項目實施過程中IaaS/PaaS層適配雖然功能大體能夠適配，但在非功能性領域的磨合總出現莫名其妙的問題，產生大量溝通與適配成本。
業務應用是業務應用開發商的事情，技術平臺是技術平臺供應商的事情，兩者沒有關系。
……
這次，劉偉光將全面探討金融行業，尤其是銀行業，在進行核心系統轉型、升級過程中遇到的方方面面的問題與挑戰。本文從醞釀到成文歷經四年，期間他與團隊拜訪過近千家金融機構，沉淀出3.5萬字長文。
當中包括：目前核心領域分布式架構轉型、金融級云原生分布式轉型的21個困惑與解答，新業態對舊核心的挑戰，雙核心并行與在線遷移的大致方案，以及第三代核心的標準與定義等。
此前《AI金融評論》也曾發布《阿里云劉偉光：2萬字解剖「保險科技」，管理者怎樣做「正確的事」？》，點擊鏈接即可查看全文。
作者 | 劉偉光
阿里巴巴集團副總裁
阿里云新金融&互聯網事業部總經理
“核”聚變 1
序言 4
引言 6
1.金融核心分布式轉型的行業變革 7
1.1金融核心從業者的困惑 7
1.2核心轉型成功的標志 8
1.3面對誤區的破局思維 10
1.4新思路新出路 12
2. 金融業務新方向呼喚技術的“供給側改革” 14
2.1開放金融體系需要可標準化的構件式核心 14
2.1.1不能變成新“豎井”的場景金融 14
2.1.2必須實現生態化的產業金融 15
2.2普惠金融體系需要可靈活組裝的核心系統 16
2.3綠色金融體系需要可泛化設計的核心系統 17
3. 金融核心轉型的能力要求與建設體系 17
3.1 何為“金融級云原生” 18
3.2銀行核心系統轉型能力需求 19
3.3 支撐核心轉型的五層十二大能力體系 22
3.3.1業務領域建模 22
3.3.2應用架構集成 24
3.3.3應用系統建設 26
3.3.4基礎軟件設施 29
3.3.5基礎資源設施 36
3.4基于能力體系打造的金融級云原生工場 38
4. 實施路徑與建設模式 394.1四階段五層模式 40
4.2多種實施路徑 40
4.2.1重構模式 40
4.2.1.1業務重構 41
4.2.1.2技術重構 43
4.2.2平行遷移模式 45
4.2.3 SaaS化批量模式 46
4.3 在線遷移與雙核心并行 46
4.3.1 面臨的并行挑戰 46
4.3.2 云原生分布式核心推薦遷移策略 47
4.3.3遷移平臺能力建設 47
5.核心云原生分布式轉型的價值與經驗教訓總結 48
5.1 第三代云原生分布式核心的價值體現 48
5.2 第三代云原生分布式核心的關鍵標準 50
5.3 核心相關系統建設的經驗教訓總結 51
創作這篇文章的想法已經醞釀了有四年多時間，時光如白駒過隙，我們仍初心不改，在這期間我和我的團隊跨越大江南北，拜訪了近千家金融機構，見證了數字金融這幾年在中國的高速躍遷，在擁抱移動互聯網和金融科技新技術的大潮中，中國金融的服務能力有了大幅度提升和客戶體驗的飛躍，開啟了技術驅動數字金融的新時代。
回顧技術在金融行業的發展，金融科技的變革與時代共舞，國外的基礎技術平臺和最佳實踐支撐了過去幾十年的金融行業的發展，直到今天我們也必須承認，這些國外的基礎技術平臺在很多單項技術能力方面仍然是具備非常強的競爭力。但是今天我們面臨的時代，是一個高速發展，具備一定的業務發展不確定性和互聯網特征，并且需要與移動互聯網和音視頻能力的高度結合，同時讓數據變成以資產方式無處不在的數智時代。不是過去的技術不先進，而是它們限制了我們對未來全面數字化金融的想象力，我們需要的是一套新的技術體系以實現金融機構真正的業務和技術的轉型。
以銀行為例，核心系統就是IT建設中皇冠上的明珠，是一家銀行的心臟，在我們與諸多銀行溝通交流的過程中，從那些無數次碰撞的火花中，腦海中關于未來核心系統建設的影子已經從一個模糊的亮光逐漸清晰。它不再是銀行科技部門按部就班按照周期建設的系統，它不再是一個固化的標準存貸匯功能堆積的能力集合，它不應該是不斷修修補補加外掛的平臺，它不再是和數據平臺和數據服務能力割裂的系統，它不再是一個牽一發動全身的架構體系。首先它必須是銀行數字化轉型中最重要的一把手工程，是一個能夠讓內部員工和外部客戶都能感受到數字化能力無處不在的平臺；它是一個能夠快速生成新流程，快速創建和發布新業務新產品，能力單元高度復用的平臺；它是一個能夠具備移動化數據化智能化特征的平臺；它是一個分布式基礎架構技術支撐的平臺，能夠以彈性能力應對互聯網類業務的峰值；它是一個融合云計算中的先進技術能力去應對開放銀行和生態銀行時代所有業務的一棧式平臺，這就是我們腦海中那個未來的樣子。今天我們已經看到有些銀行已經在這個路上去積極的探索，這些探索的背后我相信就是未來引領行業，全新的最佳實踐。
我們在內部和外部不斷的探索與實踐中，逐漸提煉和總結了一些系統性的思考，也就是如何構造具備核心競爭力的核心系統，打造真正“硬核的內核”，逐漸優化和改變目前建設的工程化體系，同時在基礎技術平臺和應用系統的耦合度上深入的進行研究探索，對于系統物理和邏輯部署形態上做了創新的實踐，同時融合了云計算體系當中最先進的云原生技術理念。
希望此文能夠給從業者帶來一些新的思考，從更大的視角去構建智能化內核能力無處不在的新平臺，重塑數字金融時代的商業價值。
此刻我和團隊就在某銀行數據中心現場參與主機應用遷移到分布式云原生架構平臺的過程，能親身見證這些推動金融行業發展變革的歷程，是我們這一代從業者的榮耀，也是我們的責任！
劉偉光
阿里巴巴集團副總裁
阿里云新金融&互聯網事業部總經理
中國金融四十人論壇（CF40）理事
2022.01.08 上海
本書分為五個章節，比較完整的涵蓋了金融行業，尤其是銀行行業的核心領域在進行轉型、升級過程中遇到的方方面面的問題與挑戰?？梢哉f，在數字化成為現代企業轉型發展的標配下，金融行業、尤其是銀行行業，其問題、思考與實踐具有相當的代表意義。作為這個過程的親身觀察者，參與者，直到推動者的過程當中，我們如實的記錄下來了從業者的艱難實踐，以及結合我們內部的和外部的實踐總結，希望能夠為這一偉大的歷程做出自己的一些貢獻，為從業者提供一些中肯的建議，少走一些彎路，多一些從容與信心。
第一章綜合的介紹了目前核心領域分布式架構轉型，云原生分布式轉型的21個問題與困惑，這是歷經兩年多的實地走訪與調研的100%真實的問題。同時不光有問題，也有我們總結歸納并交叉驗證過的核心轉型成功的三大標志，這是本文一切努力服務的三大目標。同時根據一些有代表性的實踐，我們列舉了核心從業者的實際的窘境，并引出了六大斷言。綜合這些問題，窘境與斷言，我們總結歸納出六個新的思路方向來解決這個世紀的難題。
第二章從不確定性時代的金融業務挑戰出發，主要從業務方向的角度分析了當下相對較新的金融業務形態對于傳統金融核心的挑戰與要求，主要是開放金融體系對于標準構件的要求，普惠金融體系對于靈活組裝核心的需求，綠色金融體系對于核心可泛化性的要求。當下的核心阻礙業務敏捷的障礙，這些新業務對于敏捷的要求，一一為您呈現
第三章從銀行核心系統的轉型能力需求的方面，主要從技術方向的角度分析了轉型的能力要求，回答了不少第一章行業和核心從業者的困惑。提煉了五層十二大能力體系，這些是新一代云原生分布式核心建設的最佳參考模型。涵蓋業務建模領域，應用架構集成領域，應用系統開發建設領域，基礎軟件設施領域，以及基礎資源設施領域。
第四章在第二章業務角度和第三章技術角度的基礎之上，分析了不同細分銀行行業的大致模式，經過提煉總結成為實施與建設的四階段五層的實施路徑。同時介紹了三種不同的建設模式，重構模式，平行遷移模式以及SaaS化批量模式。供不同規模的銀行機構參考。并且按照相關的國家指引，給銀行提供了雙核心并行與在線遷移的大致方案。
第五章最后進行了全篇的總結，從實際的數據出發，給出了核心云原生分布式轉型的價值，給出了第三代核心，也就是云原生分布式核心的一些建議標準與定義，同時再次總結了一些建設過程中的經驗教訓，幫助金融企業，銀行機構早日實現核心轉型的重要價值。
曾幾何時，銀行業務系統、特別是銀行核心系統都與“云技術”沒有任何聯系，云原生的種種技術和架構優勢（微服務解耦、敏捷開發、自動化測試與發布、不可變基礎設施、去中心化的服務治理、聲明式API、Serverless無服務器化等）對銀行核心而言都是“別人家的孩子”。
但隨著銀行以消費互聯網、產業互聯網、開放銀行生態為核心的數字化業務快速增長，銀行核心對敏捷交付、高并發、彈性伸縮等不確定性問題的應對，成為新一代銀行核心建設必須面對的“底線要求”。從云計算技術發展中鑄就的云原生和分布式技術在這樣的“時代要求”下必然成為銀行的主流技術，銀行核心也成為“云原生分布式架構”攻克的“最后的堡壘”。
在銀行信息系統中，核心系統承載了銀行存款、貸款、銀行卡、清算核算等核心業務，被稱為“銀行業跳動的心臟”、“銀行IT皇冠上的明珠”，其重要性不言而喻。回顧銀行信息化30多年歷程，核心系統經歷了從“胖核心”到“瘦核心”的演變過程?！芭趾诵摹币訧BM大型機為代表，而“瘦核心”則以典型的IOE技術架構為代表。然而，全方位數字化金融時代的到來使得集中式架構的問題日益凸顯，比如：系統部署無法及時響應業務需求；系統彈性能力差，導致資源過度規劃和冗余浪費；使用成本高等。雖然集中式架構仍然具備很強的競爭力和高度的穩定性，但是在擁抱中國數字金融高速迭代的浪潮中，業務驅動架構變革已成為今天的主題。
隨著集中式架構的六邊形能力（高并發、線性擴展、敏捷開發、按需彈性、精細化治理、多活可靠）已經達到極限，我們認為銀行核心系統的云原生重塑也來到了“時代拐點”。
1.1金融核心從業者的困惑
舊的答案分崩離析，新的答案還沒有著落。
當金融服務進入到“連接一切”、“微粒式服務”、“永遠在線”、“毛細血管”的數字金融時代，業務對金融核心提出了全新的挑戰。雖然我們都知道，延續了幾十年的集中式架構已經越來越難以滿足現在和未來的業務要求。但是，支撐我們的不只是詩和遠方，更有身邊的日常。我們仍然需要面對當下具體的挑戰和問題。
金融核心到底該如何轉型？云原生分布式是否是金融核心的未來？金融核心云原生分布式轉型究竟帶來哪些價值？云原生在解決原有問題的同時帶來了什么新問題、如何應對？帶著這些靈魂拷問，我們調研了數十家金融機構，收集到了這么一份沉甸甸的問題清單，這充分代表了行業在面臨挑戰中普遍感到困惑的地方。
問題：價值呈現[為什么要轉型]
1.為什么核心要轉型、要下移，云原生分布式架構轉型帶來哪些價值?
2.核心云原生分布式轉型與銀行數字化轉型的關系?
3.核心分布式轉型，與云及中臺有什么關系?
4.不同類型/規模的銀行核心云原生分布式轉型的價值差異在什么地方?
5.現在懂C，RPG這些的人越來越少，開發生態已經沒了，領導讓我招會騎馬的騎士，現在都是駕校學車的人了，我招不到人怎么辦？
問題：價值落地[如何轉型]
1.核心下移云原生分布式轉型工程龐大環節眾多，沒有一家公司能夠全方位覆蓋，如果還采取傳統項目的多家供應商集成工作模式，如何保證真正實現云原生分布式核心而不是新瓶裝舊酒？
2.傳統廠商懂業務應用但是不懂云原生和分布式，懂云原生分布式的不懂銀行業務，如何推進？
3.核心云原生分布式轉型需要管理上組織上如何配套？
4.要啟動核心云原生分布式轉型的工作該如何準備，如何著手，需要考慮哪些方面的內容？
5.不同類型/規模銀行在核心云原生分布式轉型的策略上存在什么差異？
6.目前同業在核心云原生分布式轉型實踐上有那些成功經驗可借鑒？
7.核心云原生分布式轉型的實施路徑有那些, 采用什么樣的步驟會比較好？
8.我現在已經有云，分布式數據庫等基礎設施了，我該怎么開展核心云原生分布式轉型？
問題：關鍵挑戰[用什么來轉型]
1.核心云原生分布式轉型的技術難點或者挑戰主要有哪些?
2.如何確保核心安全可靠的下移及云原生分布式轉型？
3.核心下移及云原生分布式轉型目前的生態是什么樣子，有足夠的服務和支持能力嗎？
4.核心云原生分布式轉型對于分布式數據庫的考慮有哪些，尤其是對分布式事務處理？
5.核心云原生分布式轉型，傳統主機或虛機與云之間的關系，二種模式的混合運維給生產中心帶來哪些挑戰？
6.核心云原生分布式轉型一定是一個過程，在這個過程中如何快速集成由不同技術體系構建的應用系統？
7.金融級云原生分布式核心系統是什么？包含哪些內容？有哪些特點？
8.分布式架構框架，微服務框架，應用開發框架這些我都有，別的廠商也都說能做，你們有什么獨特的價值？
9.從上面代表性問題反映出核心系統的重塑是一場浩大且復雜的工程，這些問題涉及范圍非常廣，目前也沒有統一的標準答案。
初心之外，還要用心。我們經過上百次的面對面交流和討論后，決定用心地完成這篇萬字文章，目的是一起來探索，希望各位讀者能夠或多或少地找到部分答案。
1.2核心轉型成功的標志
橋梁越大，內部結構就越重要。
在實踐和探索的過程中，我們通過不斷分析歸納總結，得到了下列這張大圖，這是志同道合的客戶和我們共同的認知與成果，在這個領域，我們必須要心懷敬畏。因為在傳統銀行核心下移分布式云原生改造的領域，這是一條無人之路，大家都在不斷探索和學習。
這張圖展現的就是核心轉型的初心，以及金融機構對合作伙伴的要求。也是考慮迎接核心轉型這個挑戰“以終為始”的出發點。整體而言，分為兩個部分。
1.成功的標志
核心轉型最后必須是金融客戶要能夠成功，并且要能夠實在的給客戶帶來巨大的價值，而不僅僅是買來一堆高科技產品堆在開發和數據中心。從這一點出發，行業認為核心轉型的成功標志是
1）安全自研可控
自研可控有多重維度，第一種維度是技術架構的安全可控，可以對系統架構和關鍵技術進行整體把握。主要涉及自產自研、關鍵技術產品代碼的擁有、知識產權的可控性等。
第二種維度是業務層的解耦，對于核心系統的功能能夠自主的按照業務發展進行研發迭代，而不是高度耦合、牽一發動全身。
2）財務成本，單交易/賬戶成本下降
上一代集中式架構，尤其是主機體系，綜合的TCO成本相對較高，不僅僅是購置成本，包括長達10多年的運營維護成本，擴容成本，這些都還只是顯性成本，反而更容易忽略的是人員成本，擁有相關主機技能的人才越來越少，越來越難培養相關技術人才。
3）業務穩定性連續性不降低前提下支撐業務敏捷
天下武功，唯快不破，業務敏捷是面對不確定性的制勝法寶。這也是核心轉型的最大動因之一。例如對于新業務的快速功能性支撐，對于老業務的快速升級迭代等等。但是核心光敏捷是不行的，前提是保證可靠性和穩定性，沒有穩定，就沒有金融安全，沒有金融安全一切都是空中樓閣。
2.對于合作伙伴的訴求
金融機構和行業認識到，要完成這個壯舉，必須是整個產業鏈條和整個生態的大協作才有可能，這不是一兩家技術公司的事情。從這個角度出發，我們識別出來以下4個大的方向，是保證客戶，整個行業成功的要素。它們環環相扣，缺一不可。
1.咨詢與設計中關于云原生分布式的架構設計，遷移方案，并行方案，實施路徑等
2. 項目實施和組織陣型的提前規劃設計，基礎平臺和應用開發的組織陣型規劃
3. 運維保障中快速解決核心故障問題和機制保障；白盒化，更自動的監控和運維工具的支撐
4. 產品與方案層面，產品與方案是整個核心遷移和云原生分布式轉型的基礎支撐，因此產品的長期規劃和產品的延續性，基礎產品的發布更新和生命周期這些都是尤為重要。
但無論怎樣艱難，業界已經形成一種共識，新的時代已經到來，從集中式到分布式，從分布式到云原生分布式架構的轉型，是一條必經之路。
1.3面對誤區的破局思維
核心轉型需要“站在整體看局部、站在結果來看過程”。
2021年諾貝爾物理學獎頒給了“復雜性系統”的研究，金融核心轉型就是金融業的“復雜性系統”，其中涉及了業務、技術、產品、組織、人員能力、流程、生態、協同和管理等諸多方面的問題和挑戰。如何解決這些問題本身是個開放命題。
同時我們也看到很多機構在核心轉型實踐中存在的一些誤區。面對這些誤區，需要具有破局思維、打破“簡單型系統”的思維禁錮，同時需要“站在整體看局部、站在結果來看過程”，這樣才能明確地站在“終局”來看，什么肯定是不對、不合適的，才能一步步逼近成功。
下面我們從核心轉型成功的3個角度出發分析一些核心轉型領域的常見誤區和我們思考斷言，希望能夠給大家帶來一些啟發和幫助。
誤區1：先從簡單系統著手進行架構轉型，再推導到核心轉型。
某銀行由于自研可控要求，只考慮了OA相關系統，核心系統不考慮。但是核心領域被卡脖子的問題依然存在，并且OA系統的自研可控成果對于核心領域而言，是無法借鑒的，這是完全兩個不同領域的應用，架構完全不一樣。導致未來核心應用轉型仍然需要大量的探索和工作要做，總體支出會更大。
斷言1：“從儉入奢易、從奢入儉難”。非核心領域的轉型實踐對于核心領域參考和借鑒意義有限，需要在核心領域架構體系上及早納入自研可控等架構級別考量，避免2次遷移成本和時間成本。
誤區2：追求技術架構完成解耦，碎片化供應商，不被綁定。某銀行B在核心云原生分布式轉型的過程中，對于核心技術平臺要求能夠完全的分層分模塊解耦，例如在IaaS/PaaS/SaaS/核心數據庫這些關鍵領域，在任何一層出現問題的時候都能夠隨時的切換到可替代的平臺，不綁定任何一家技術平臺供應商。但是實際上項目實施過程中IaaS/PaaS層適配雖然功能大體能夠適配，但是在不同廠家的磨合方面，穩定性和性能等非功能性領域出現莫名其妙的問題，并且協調兩家廠商的產品研發對接需要大量的溝通與適配成本。
斷言2：“基礎不牢、地動山搖”，底層架構的高效穩定是第一目標。底層架構在起步階段從“統一架構”更加容易走穩，再逐步進行局部優化和解耦。
誤區3：核心系統按照功能模塊切分，再眾包給不同的開發商來完成，避免被一家綁定。某銀行C整個核心進行分布式改造的項目群極其龐大，平臺技術部與各家核心應用開發商進行了充分的交流，然后選定各家較為擅長的領域來實施建設。這種眾包方式的確沒有綁定任何一家供應商，但帶來的問題在日后實際核心下移開發中日漸突出。眾包給眾多核心應用開發商之后，由于開發商都只熟悉自己那一部分業務和技術框架，無法做到全局的架構管控和統一技術標準打通。例如：全鏈路跟蹤與壓測、業務染色、單元化、異地多活等。
斷言3：核心架構中“非功能性需求”考慮要大于“功能性需求”。“非功功能性需求”應由技術架構來承載。業務模塊可以解耦設計和分包，技術架構要統一規劃和統一標準，實現核心領域的“統、分結合”。
誤區4：業務應用是業務應用開發商的事情，技術平臺是技術平臺供應商的事情，兩者沒有關系。傳統集中式環境下技術平臺經過了經年累月的標準化以及適配，對于應用的普適性相對更強，所以應用開發不需要太多考慮底層架構的差異性，只需要當黑盒子來使用即可。但是在云原生架構時代，需要考慮分布式CAP原則的調整，適配與折中的設計?？紤]分布式事務，分布式數據一致性，異地多活等難題對于業務模式，業務流程，業務底層數據模型的特殊影響與特殊設計，如熱點賬戶，業務服務跟蹤治理，全局業務序列號等專題。而這部分的專題設計，是傳統上層應用與傳統底層技術平臺之間的灰色地帶與結合帶，它往往決定了整體系統的整體表現，尤其在極端情況下的非功能性表現。
斷言4：傳統集中式架構下的核心建設模式在云原生架構下大多數情況下并不適用，需要引入額外的框架、機制與設計來保障核心系統的整體表現。
誤區5：選擇應用平遷、不做架構大變化，更最簡單和快捷。某銀行D由于核心相關系統規模太大，應用數量眾多，原來大量應用是在集中架構的封閉系統中，采用rpg，cobol等語言編寫，行方為了想盡快將系統從封閉系統下移至開放平臺，為了快速和簡單起見，使用了一種并不成熟的代碼翻譯工具，將整個rpg語言翻譯至java語言并部署在開放平臺，底層使用分布式數據庫承載數據。整體應用架構沒有做太多的調整，基本上還是屬于集中式架構的范疇。在后期的運行過程中發現較多的性能問題與可用性問題，以及集中式應用與分布式數據庫的配合適配問題，只能讓龐大的開發團隊進行每個程序的代碼的手工性能優化，導致開發力量80%以上的時間是在做代碼的性能優化，根本無法承接新的功能或者業務的開發，拖累業務應用建設的整體進度。
斷言5：核心轉型最佳路徑是追求“P/PC平衡”-- 產出和產能平衡。不僅僅是完成 “產出”任務（應用遷移），更為重要的是升級“產能”（技術架構能力）。“產能”（技術架構）升級后會推動更大的“產出”（業務價值），成為全行數字化轉型的助推引擎。
誤區6：選擇各個領域的最佳“供應商”,完成各自擅長的工作任務（咨詢建模、架構、設計、應用、基礎軟硬件）。某銀行E找了專業咨詢團隊進行業務梳理與業務建模，然后這些資產大部分停留在紙面，并沒有相關后繼的指導和形成標準規范。導致核心研發團隊依舊不太清楚如何開展后繼的大規模開發。后繼根據各個業務板塊進行應用開發商的招采，選擇各個領域最佳供應商。在實際過程中，還是仰賴于應用開發商的經驗，沒有辦法參考前期業務咨詢和建模的資產，例如某應用開發商A負責客戶模塊，某應用開發商B負責產品模塊，大家都只熟悉自己這部分“最佳實踐”。如何遵照前期的業務建模的成果，如何在整個核心項目群內形成端到端的業務流程落地是沒有參考和總控的，導致沒有達到最初的規劃和設計目標。
斷言6：核心轉型相比選擇“供應商”而言，更為重要的是選擇具備“端到端落地實踐”的。從理念、方法論、設計規劃、平臺架構、標準規范都能夠戰略性長期投入和總體把控的“合作伙伴”才能真正落地實現業務敏捷和推動數字化轉型，而不是為一堆冠名“數字化轉型”的文檔買單。
這些結合客戶常見現狀、誤區和思考斷言，也是未來在核心轉型中可以借鑒和參考的要素。流水可能會繞路，但絕不會回頭。
1.4新思路新出路
面對復雜性，需要的不僅僅是一套“方案”，而是一套應對的“原則”。
針對以上常見的困惑，窘境和挑戰，要達成核心云原生分布式轉型的成功，我們需要的不僅僅是一套技術方案，更需要一套能夠指引行動的“原則”。正如雷-達里奧在《原則》一書中提到：原則猶如指引行動的“燈塔”，它連接著我們的目標與行動。解決不確定性靠敏捷、解決復雜性靠原則，越是復雜的系統越需要一套原則來保證。
我們將金融核心轉型所需要的原則總結為一個全新“六邊形”原則。
1）業務技術閉環原則：整個體系需要支持“業務-技術”閉環敏捷模式，讓業務敏捷從一句口號到真正能夠快速開發落地上線（從有業務想法，到建模，到領域設計，到服務設計，到數據模型，到應用開發，到應用部署，到應用治理，到應用運維的）
2）自動化生產線原則：云原生分布式轉型提供端到端的工具鏈，必要的基礎構件以及先進的實施工藝，形成完備的、端到端的、自動化的、高效的、簡便的且可落地、可運營、可治理的完整體系。比如可以將業務流程數字化為可呈現可復用的資產，并能自動化轉換成為應用系統編排流程。比如可以將業務的服務模型定義自動化轉換成為應用和微服務模塊的代碼框架，并且可以選擇裝配對于云原生分布式環境下事務與數據一致性的支持，選擇裝配從業務角度端到端監控的能力，類似的能力數不勝數。
3）開放可插拔原則：這個體系是開放，可集成的生態體系，能夠以相對標準化，規?；姆绞綐嫿ǔ鲈圃鷳谩?/p>
4）可組裝構造原則：依賴這種體系，可高效支持新的金融業務形態，如綠色金融，普惠金融，數字金融，碳金融，開放金融等等。因為這些紛繁復雜模式的標準化構件通過生產線能夠快速制造并復制出來，只需要疊加和裝配差異性的部分。
5）普適性兼容性原則：這種體系徹底的改變了目前核心領域手工作坊的人力堆積模式。如果最復雜且對于技術要求最高的核心領域都可以采用這種模式來實現，那么該體系更可以使用在面向未來云原生模式的更廣泛的業務應用開發領域。
6）易用透明化原則：金融機構和合作伙伴可以利用該體系進行自研可控的業務應用的高效開發而不用關注云原生應用的特殊細節與技巧，因為這些復雜的分布式與云原生裝配與銜接工藝流程已經通過自動化流水線自包含實現了。
我們將這套原則沉淀為一套全新的方法論，工具平臺體系和工作模式，它涵蓋了業務模型與流程建設的最前端，以及系統與業務在云原生環境下的運維和運營，同時這個體系定義了比較明確的工序和生產階段，具備高度的自動化能力，能從一個工序自動化的銜接到下一個工序，只有這樣規?；?、自動化、高效率的工廠化生產模式，才能實現真正的落地業務敏捷，實現應用與云原生分布式技術的可靠融合。這種新的核心系統云原生分布式轉型的建設模式以及配套的自動化生產線工具體系，我們稱之為“金融級云原生工場”模式。
迪士尼有一句話反復被提及：“藝術挑戰技術，技術啟發藝術 ”。
新時代是一個數字時代，數字時代的金融是以數據為關鍵生產要素、以場景和用戶價值為中心的服務模式，主要服務手段依靠對各類數字化技術的綜合運用，其重要載體便是通過網絡送達的軟件服務，是以線上便捷服務為主、線下人工服務為輔，融合數據智能和人類溫情，注重用戶體驗和風控原則的服務模式，金融服務將是開放、普惠、綠色的，嵌入式且靈活多變。而這樣的“泛在化”金融服務必然對賬戶、交易、結算等核心能力提出了“泛在化”、“全時在線”的要求。
2.1開放金融體系需要可標準化的構件式核心
規模是問題（業務）的解藥，規模也是問題（系統）的根源。
如今，開放銀行的理念已經成為銀行業的發展共識，最基本要求是銀行服務通過API、SDK的方式將銀行賬戶、支付、結算能力提供給合作方，以實現把銀行的服務融入到各行各業中。做為開放銀行戰略的升級，場景金融、產業鏈金融正在描繪更大的開放格局，形成一個“泛在化”“毛細血管”式的金融服務。這些業務需要規模來解決泛在化的場景和需求，但這樣的規模也是核心系統問題根源所在。
2.1.1不能變成新“豎井”的場景金融
場景金融是基于各類金融或者非金融場景順暢地融入金融服務。從銀行的角度看，最初的場景金融主要是與平臺類公司接入合作，在消費者眼中，場景金融則是便捷的支付、貸款等金融服務的獲得。
隨著場景金融的演進，其場景正在擴展到人們生活、學習、工作的各個方面，一些銀行已經共建、自建了大量的場景金融業務。但基于場景的用戶轉化需要一套完整的業務系統進行支持，包括大量標準化、模塊化的能力，業務能力方面包括用戶中心、產品中心、合約中心、賬戶中心、權益中心等，數據能力方面包括用戶畫像、推薦模型、聯邦計算等數據。
此外，隨著數字人民幣試點領域的擴大，金融場景正在越來越豐富，僅數字人民幣的應用場景就已經超過350萬個。場景的價值日益受到重視，銀行都在努力構造更多的場景，這也導致了場景的碎片化以及對場景構建的敏捷性要求。我們建議銀行需要及早認識到如何讓場景不成為新一輪的“豎井式開發”，而業務的中臺化、標準化、構件化正是解決這一問題的出路，越來越多的銀行正在為其業務設計結構化的業務模型，并探索將其與應用設計緊密連接起來。
2.1.2必須實現生態化的產業金融
從理論上來講，供應鏈金融是金融業務從核心企業向周邊企業拓展的最好方式，也是推動產業金融發展的理想模式。但是，供應鏈金融的發展往往需要依靠核心企業的意愿、平臺的服務水平、周邊企業的實際收益等諸多關鍵因素的綜合作用，因此，盡管很多研究機構將供應鏈金融視為十萬億級別以上的大市場，但其總體發展一直不是很順利。
如果只為供應鏈金融單獨去建設平臺，那之前存在的建設成本、相關方收益等問題，恐怕依然難以解決。只有通過超越供應鏈視角的大型商業平臺承載供應鏈服務，才有可能解決單一用途平臺面臨的問題。國家倡導建設的行業云，可以承載這樣類型的商業平臺，現有商業平臺也可以進一步擴大互聯，使任何一家企業可以加入平臺即加入供應鏈，在平臺中也可以自由加入任何供應鏈，這樣的平臺模式，才可能突破傳統供應鏈平臺高封閉、重成本、低收益的困境，這一模式也符合國家要求大型企業開源、開放的政策基調。
多功能的大型商業互聯平臺不僅承載供應鏈，也是各類型企業建立自身應用的“標準化構件庫”，企業可以根據自身需要選擇云原生的標準化構件組裝自己的業務，這是“產業數字化”的一大推手。當然，這需要高度的業務標準化，所幸，國家標準化發展政策正在推動這一趨勢的形成，未來銀行也會融入到這一宏大的數字化商業生態中，這將催生金融機構新一代面向數字生態的構件化核心系統。
2.2普惠金融體系需要可靈活組裝的核心系統
普惠金融是致力于持續提高金融服務金融服務公平性、可獲得性的金融服務體系，是通過更有社會責任感的經營理念、更有效率的風控手段、更低的運營成本來使更大范圍的客戶群體可以獲得優質金融服務，在普惠金融的發展過程中，數字化技術將扮演越來越重要的角色。
普惠金融的發展需要做好以下三個方面的工作：
1.靈活的管理：在額度管理、計價定價、風險計量等體系中需要更靈活的能夠支撐不同策略調整，適應不同區域、不同時期、不同行業、不同客戶分層的普惠的要求；
2.經濟的管理：降低單賬戶/單交易成本，降低整體的綜合財務成本；
3.彈性的管理：業務系統可擴展支撐更大數量的中長尾市場。
普惠的客群對象和業務特點決定了其產品碎片化、上線周期短、業務變化頻繁，要求能夠像積木塊一樣解構業務和技術能力，靈活配置、實現業務需要，金融機構的核心系統只有變得像一個可組裝的流水化工場才能應對環境的快速變化，而對長尾客戶群體的支持，更需要一套易擴展的核心系統架構。
2.3綠色金融體系需要可泛化設計的核心系統
發展綠色金融是不僅是金融行業的商業機會，更是金融行業的社會責任。綠色金融包括兩個部分，一是面向客戶的“雙碳”要求觸發的業務變革，一是金融機構自身要完成“雙碳”目標。
按照“雙碳”要求，金融機構要控制信貸資金流向，逐步減少高排放用戶的信貸支持，未來也可能會逐筆核算信貸資金的“碳排放量”，控制信用業務的“碳”風險。這需要社會數據的支持，而不僅僅是來自用戶的數據，需要更多的外部數據源、權威數據支持金融機構計算“碳”風險。通過構建綠色金融賬戶，完善綠色金融產品，提升綠色金融智能化評估，金融機構可以更好地支持綠色生態鏈上下游體系的開放性融合，打通綠色循環。綠色金融將推動對金融賬戶應用模式的泛化，從而影響核心系統的設計理念。
全生態鏈綠色金融模式設計
“重大問題的解決方案，永遠不可能在產生這個問題的維度上出現。”--愛因斯坦
數字韌性被越來越多的金融機構所提及，什么是數字化韌性？當應對外界環境變化，或者客戶需求變更時，軟件產品需要有彈性和韌性，要有反應足夠快的數字化體系。當集中式架構在面臨“數字韌性”而“力不從心”的時候，我們認為很難用“舊時代的方法”去解決新時代的問題。云原生似乎成為一個數字化企業的“標準答案”了。
3.1何為“金融級云原生”
何為云原生呢？為什么現在云原生這么火了？
云原生架構是基于云原生技術的一組架構原則和設計模式的集合，旨在將應用中的非業務代碼部分進行最大化的剝離，從而讓云設施接管應用中原有的大量非功能特性（如彈性、韌性、安全、可觀測性、灰度等），使業務不再有非功能性業務中斷困擾的同時，具備輕量、敏捷、高度自動化的特點。
云原生技術主要以容器、DevOps、微服務、分布式中間件、分布式數據庫、Serverless、服務網格、不可變基礎設施、聲明式API、開放應用模型（OAM）等技術為核心，能夠幫助我們實現業務應用與基礎設施的解耦，因此被認為新一代云計算的“操作系統”。如下是一些云原生的核心架構思想（而無關于產品）：
分布式微服務：微服務的核心就是將大的單體應用拆分為更小的組件服務（微服務）。能夠做到從底層IT基礎設施、到數據庫、到中間件、到應用部署包等全部環境都能夠獨立部署。這樣實現從需求設計、開發、打包、部署全部都能夠獨立完成。實現各個微服務之間徹底的松耦合。同時微服務之間又能夠通過輕量的接口進行交互。
DevOps：核心就是敏捷研發、持續集成和持續交付。需要將軟件生命周期過程中的需求、設計、開發、編譯、構建、打包、部署，從測試環境、到生產環境整個過程能夠實現全部自動化。將敏捷研發、自動化測試進行集成和協同。
服務網格：去中心化的服務集成和治理框架。原來架構一般采用集中式ESB總線/API網關來做接口、API的服務治理和管控，將API接口注冊到API網關。由于ESB/API網關是一個中心化的架構，所有的請求和流量通過API網關，所以中心化的API網關可以對流量進行安全、日志、限流熔斷、監控等各方面的管控和治理能力。當在去中心化的架構下，沒有中心化的EBS/API網關情況下，所有流量下沉到了各個微服務中去了，需要在為服務端增加一個邊車代理，通過邊車代理來做流量的攔截，同時實現對流量的管控和服務治理。
不可變基礎設施：當傳統環境部署中，當有各類變更（應用程序、數據庫、中間件、基礎設施等）發生時，往往可以直接修改配置來實現。但云原生強調任何應用當你部署到生產環境中形成一個實例（容器/虛機）后，這個實例不能發生任何變更。當發生了變更修改時，應該基于鏡像生成一個新的實例，同時銷毀舊的實例。
聲明式API：與命令式API操作相對應的概念。傳統環境的后端操作（比如創建一個容器實例）會去執行命令行，來完成操作動作（這種方式對小規模應用而言比較有效，但大規模和自動化而言，就非常低效）。而對于聲明式API而言，需要通過定義聲明配置文件（比如：YAML文件），來聲明清楚所要做的動作、以及做完后需要達到的狀態。只需要完成這個聲明式的配置文件，底層平臺再去解釋這個聲明式API配置文件的內容，再去做后端的操作，同時把各個底層的技術組件協調到需要的狀態。聲明式API下面，任何對生產環境、對軟件的修改都不是直接去操作一個命令來完成，都是先要寫聲明、寫配置，這個配置文件可以納入配置管理中集中去做管控和管理的。這樣既可以大規模、自動化去執行變更和管理任務，也可以當生產環境出問題時，可以快速去追溯對生產環境做過什么樣的操作，方便做相關的回退和回滾操作。
金融機構采用云原生技術，并不是將應用上公有云，而是將金融對安全合規、交易強一致性、單元化擴展、容災多活、全鏈路業務風險管理、運維管理等各方面行業要求與云原生技術進行深度融合，發展為一套既符合金融行業標準和要求、又具備云原生技術優勢的“金融級云原生架構”。
金融級云原生能將過去在應用架構層做的大量工作，尤其是彈性與韌性、可靠性、自動化等，下沉到技術架構去實現，讓應用只需要關注業務邏輯本身。所以，我們有理由相信，銀行的主流技術架構將從以IOE為核心的集中式架構向金融級云原生架構演進。未來金融機構基于云原生的應用，將天然具備彈性與韌性。
3.2銀行核心系統轉型能力需求
“總有人問我未來十年，會有什么樣的變化，但很少人問我，未來十年，什么事不變的。我認為第二個問題比第一個問題更重要。因為你要把戰略建立在不變的事物上?！?-- 杰夫-貝索斯
通過前文的分析，不論未來金融的服務形態如何演變，我們看到，對“靈活性、易擴展、高并發、標準化組件、低成本、可靠的在線服務”的追求是金融核心的“不變”所在。所以需要將核心戰略聚焦在這個“不變”上面。我們從業務、工程和技術的角度，總結了云原生分布式核心應該具備“不變”的能力需求；針對每一項能力需求，進行詳細拆解為十二項支撐能力；對十二項支撐能力進行歸納分層，形成建議的云原生分布式核心建設過程中的五層十二大能力體系，如下圖所示：
針對核心系統建設過中的困惑、業務轉型對核心系統的要求，本節從業務、工程和技術能力三個方面分別進行回答。
3.2.1業務能力
業務敏捷
Q：如何提供滿足金融業務新方向的核心系統？
A：可標準化的構件式核心系統、可靈活組裝的核心系統和可泛化設計的核心系統，需要核心系統擁有完備的業務組件，可以通過快速配置滿足不同類型客戶、不同場景的業務需求。
Q：核心下移云原生分布式轉型工程龐大環節眾多，沒有一家公司能夠全方面覆蓋，還采取傳統項目的多家供應商集成工作模式，如何保證真正實現云原生分布式核心而不是新瓶裝舊酒，換湯不換藥？
A：云原生分布式核心建設不僅僅是通過云原生技術對核心系統進行重寫，滿足自研可控和容量性能的需求；更重要的是從業務價值的角度對核心系統進行重新規劃，形成全行企業級可復用的業務中臺能力和快速創新能力，支持業務敏捷。
3.2.2工程能力
質量、工期、風險可控
Q：如何確保核心安全可靠的完成云原生分布式轉型？
A：從項目組織管理的角度來看：建議核心系統建設工程是一把手工程，不僅是技術創新突破，還可以通過業務架構和應用架構變革帶來組織架構的變化；所以，整個核心系統建設需要業務部門充分參與而非科技部門自嗨。從工程過程的角度來看：研發過程中，各廠商應基于行內統一的技術體系和應用組件、標準的實施工藝，開發核心系統涉及的眾多應用；在系統遷移切換時，可采用不停機在線遷移模式，實現新老核心的平穩、有序過渡。
Q：傳統廠商懂業務應用但是不懂云原生和分布式，懂云原生分布式的不懂銀行業務，如何推進？
A：建議在云原生分布式核心系統建設初期，通過一個輕量級咨詢項目，借助一批有云原生分布式核心落地經驗的專家，結合金融機構自身業務特點，繪制核心系統藍圖；并基于選定的技術架構和應用架構，選擇典型交易場景進行原型驗證，確保架構層面滿足核心系統需求。
持續治理
Q：核心云原生分布式轉型一定是一個過程，在這個過程中如何快速集成不同技術體系構建的應用系統？
A：核心系統云原生分布式轉型過程中，會涉及到多種類型系統的集成：云原生分布式核心與老核心、已有其他系統（渠道等）的集成；同時，從我們在多家行的實踐來看，與云原生分布式核心集成的系統通常存在多種技術棧（Spring Cloud、Dubbo等）。建議使用服務網格(ServiceMesh)進行系統間集成，在充分發揮其多技術棧集成能力的同時，還能享受服務治理的紅利。
3.2.3技術能力
Q：核心云原生分布式轉型的技術難點或者挑戰主要有那些?
A：核心云原生分布式轉型過程中，技術難點通常集中在非功能需求方面，例如分布式架構下大量微服務調用帶來的性能問題、分布式事務帶來的一致性問題、硬件采用PC機帶來的穩定性問題等，以及大規模分布式集群下如何進行系統運維的問題。因此，需要有一套經過磨合驗證、滿足核心系統研發和運行時需求的IaaS和PaaS平臺，結合云原生分布式核心設計、研發過程中的最佳實踐，才能從容應對轉型過程中的各種挑戰。
高性能、無限容量
Q：核心云原生分布式轉型對于分布式數據庫的考慮有那些，尤其是對分布式事務處理？
A：分布式數據庫應具備以下幾方面的能力，降低核心系統研發和運維的復雜度：內置分布式事務引擎、透明可擴展、極致的高可用、同城容災RPO為零。
安全穩定運行
Q：核心云原生分布式轉型，傳統主機或虛機與云之間的關系，二種模式的混合運維給生產中心帶來哪些挑戰？
A：建議通過統一管理及自動化運維能力，使用單一平臺對多種云資源（包括傳統主機、虛擬機）進行靈活的管理、編排與部署。同時，針對云原生分布式核心系統的運維，面臨著應用集群規模龐大、交易鏈路節點變多、PC服務器穩定性等多方面的挑戰，可參考互聯網企業在高可用運維和容災等方面的經驗，建設面向風險管理的SRE運維體系。
自研可控
Q：將云原生分布式核心納入自研可控體系，如何做到風險可控？
A：建議采用自研可控單元化架構，在單元化架構下設置一個獨立的自研可控單元（采用符合自研可控要求的軟硬件）；基于單元化流量調撥能力，先小流量驗證自研可控單元能力后，再逐步增加流量到自研可控單元，穩步實現自研可控轉型，做到風險可控。
3.3支撐核心轉型的五層十二大能力體系
上一節回答了云原生分布式核心建設過程中需具備的能力，本節將針對提出的五層十二大能力體系進行詳細的闡述。
3.3.1業務領域建模
為了使IT系統完整的承接業務需求，云原生領域建模是運用領域建模思想，充分考慮云原生應用的特點，使用領域建模及管理平臺，把建模變得簡單、敏捷、易落地，并通過平臺實現建模資產的保鮮。具體來說，云原生領域建模通過抓住建模本質，簡化建模過程；采用建模平臺，管理模型資產；運用低代碼技術，落地模型資產。
業務領域建模應關注以下幾個方面：
基于銀行同業已有建模實踐成果敏捷建模，而非投入大量資源且周期長的建模過程；
通過建模平臺實現成果保鮮，持續為業務迭代和創新服務，而非核心系統建設完成之后束之高閣，逐步與系統演進結果脫節；
建模成果能夠借助建模平臺、結合云原生技術快速落地。
3.3.1.1業務建模與技術建模
業務領域建模包括業務建模和技術建模，整體建模流程圖如下：
1.業務建模包括業務流程建模和業務對象建模：
業務流程建模：通過對業務流程現狀分析，結合目標核心系統建設能力要求，參考行業建模成果，形成結構化的業務流程模型；
業務對象建模：基于信息模型資產，結合對業務流程提取的業務實體，進一步分析實體間關系，獲得業務對象模型和業務行為模型。
2.技術建模是為了對業務模型進行落地實現，把上述業務模型轉換為技術模型。通過技術建模，實現三個模型的轉換：
業務流程模型到服務流程組合的轉換；
業務對象模型到邏輯/物理數據模型的轉化；
對象行為模型到API接口/原子服務的轉換。
3.3.1.2建模平臺
建模工具是支持業務領域建模的平臺，包括對領域模型、數據模型、中臺能力模型等的管理，提升建模設計效率并有效沉淀最佳實踐。
在建模平臺中，業務模型包含領域架構、業務模型、業務流程、交易模型、信息模型五層，五層概念逐層縮?。?/p>
領域架構作為系統的整體架構，包含系統中所有的業務模型，把系統中的業務模型按架構圖的方式編排起來；
業務模型是由業務流程組成，是多條業務流程的集合；
業務流程串聯交易模型，形成業務流程圖；
交易模型中定義交易行為、交易的屬性及交易行為的輸入輸出；
信息模型主用于定義九大信息要素：參與者、產品、合約、賬戶、事件、條件、地理位置、資源項、渠道，理論上任何交易模型都是由九大信息要素構成，在不能滿足時也支持添加新的信息要素。
在建模平臺中，技術模型包含：微服務模型、流程模型、實體模型、數據模型。
微服務模型是利用云原生特性，把業務流程中的步驟進行聚類分析，獲得相應的微服務模型；
流程模型承接業務建模中的業務流程，通過對業務流程中的功能進行細化分析，獲得實現業務功能的一個或多個具體接口，明確每個接口的輸入輸出字段，分析出實現業務功能所需的實體及實體間關系，獲得實體模型；
需要持久化的實體模型，按數據庫設計的相關要求轉換為數據模型，通常情況下實體模型與數據模型是一對一或一對多關系。
通過上述步驟，最終得到技術模型中的微服務模型、流程模型、實體模型和數據模型。
3.3.2應用架構集成
應用架構集成層承接業務領域建模成果，將核心系統按照業務領域建模體系進行整體規劃，形成可供全行IT系統復用的業務中臺能力，提供生產各業務系統必須的業務組件；通過服務治理與組合的低代碼能力，快速支撐業務創新；服務網格為傳統應用、遷移到云原生分布式架構下的應用互通提供技術保障。
應用架構層面，云原生分布式核心與傳統瘦核心或分布式核心重大區別是：
不是：簡單的將核心系統按照業務條線劃分為客戶、存款、貸款等應用，采用分布式技術重新實現一遍，很多公共的能力（例如產品管理、合約管理等）都需要各個應用重復建設，數據層面不互通；
而是：將核心系統按照業務領域建模體系進行整體規劃設計，形成可供全行IT系統復用的業務中臺能力，提供業務構件；通過服務運營與編排，使用業務構件快速進行業務創新。
3.3.2.1應用架構中臺化
1.云原生分布式核心中臺化應用架構
通過多年自身金融業務實踐和實際參與銀行客戶核心系統轉型項目，基于標準化業務建模和技術建模成果，建議將用戶、產品、合約、額度、交易、賬戶、計價等金融服務的核心商業要素數字化、中臺化，構建出全行級中臺能力地圖，從而支持前臺業務的快速迭代。
云原生分布式核心中臺化應用架構，可參考下圖：
2.強大、穩定的中臺組件
每一個中臺組件的設計，都承接自業務領域建模成果，具備豐富的業務功能。為確保中臺組件集能支撐業務敏捷創新，中臺組件應具備如下能力：
功能豐富：經過核心系統實際使用驗證、具備能夠支撐產品系統的必備業務功能；
迭代穩定：作為企業級能力共享組件，被大量產品系統復用，需要能夠保持穩定、清晰的迭代升級路徑；
非功能特性卓越：具備優秀的性能和可用性，為整個產品系統的性能和業務連續性提供保障。
3.3.2.2服務治理與組合
金融行業通常采用了分層、分域的IT架構，每一個層、每個域都提供了大量的服務。
架構轉型的過程中，通過服務統一治理和運營，在技術層面支撐研發過程、確保安全生產運行；在業務層面通過金融業務中臺提供服務復用能力，高效進行流程組裝，支持業務敏捷、快速響應市場需求。
1.服務治理保障生產穩定運行
通過架構分層、能力域、系統、應用、服務等多級領域模型，全面梳理軟件資產，建立服務目錄，提升服務復用率；提供服務的全生命周期管理，覆蓋事前、事中、事后環節，支持服務保鮮，建立服務反饋和優化閉環。
2.服務運營編排，支撐業務敏捷、快速創新
服務組合方面，通過業務中臺提供的可復用原子金融服務使用可視化服務編排能力，實現低代碼快速開發業務場景，縮減研發周期，提高產研效率，降低投產風險。
服務編排平臺內置流程模型驅動業務開發，通過編排、執行兩大核心能力取代研發過程中部分枯燥而重復的工作；同時，我們認為平臺應該深度集成中間件，提供一個完整的金融級服務編排解決方案。服務編排能力大圖如下：
3.3.2.3異構應用集成
1.傳統微服務、ServiceMesh和傳統單體應用集成需求
在向云原生架構轉型的過程中，傳統單體應用也面臨著遷移云原生分布式轉型的挑戰；同時，兩種微服務架構（傳統SDK微服務和Sidecar模式）并存已經是一個不可回避的現實問題。如何打通諸多異構應用系統，實現全面云原生分布式轉型，需要有一套強大的技術支撐體系。
2. 基于服務網格(ServiceMesh)實現異構系統集成
在云原生架構下，服務網格可以輕松應對異構系統集成的問題。通過服務網格平臺，提供與平臺無關、語言無關、輕量無侵入的云原生架構集成與治理能力：兼容 Kubernetes和 Istio生態、支持傳統SDK模式微服務框架的服務治理；支持物理機、虛擬機場景，兼容過渡階段的容器化和虛擬化混合部署的場景，滿足傳統單體應用向Service Mesh轉型的需求。
3.3.3應用系統建設
應用系統建設層提供標準化生產線，屏蔽復雜的云原生技術細節，規范云原生應用開發標準。
應用系統建設層面，應重點考慮以下幾方面：
統一ISV（獨立軟件開發供應商）開發技術棧，避免技術管理失控，降低系統運行風險；
統一、易用的開發平臺與框架，簡化和規范化應用開發；
全流程覆蓋的DevOps體系，涵蓋需求結構化管理、代碼版本與分支管理、質量管控與度量，自動化編譯打包與部署等方方面面。
3.3.3.1統一開發體系
1.復雜的云原生技術細節和難以管理的ISV（獨立軟件開發供應商）多技術棧應用
在云原生體系下，應用開發所采用的技術架構，涉及到數量龐大、使用復雜的技術組件，如何讓技術服務于應用開發而不是成為障礙和故障點，是一個必須回答的問題；同時，采購了大量獨立軟件供應商（ISV）的應用，不同ISV使用了不同微服務框架、注冊中心、消息中間件、事務中間件等中間件，實際造成行里的開發技術棧不統一，提高了開發人員的學習成本，同時也增大了系統的運維難度。
2.簡化、標準化和規范化應用開發
通過云原生應用開發框架，提供從金融級應用、組件到工具類包等多層次的開發支持，從而提升研發效能、保障研發質量。這里面應該主要包括：
通過腳手架，快速創建規范化、標準化、金融級的應用開發工程；
通過組件模板，生成符合不同金融場景的組件使用模板代碼，確保使用的正確性和規范性；
在工具類包層面，提供全面的金融級工具類，避免安全隱患。
在應用層面，通過腳手架可以快速創建規范化、標準化、金融級的應用開發工程。工程基于應用模板（靈活可定制）創建，目錄結構和應用分層標準化，集成金融級中間件和架構規范（日志、錯誤碼等規范）；
在組件層面，可生成符合不同金融場景的組件使用模板代碼，確保使用的正確性和規范性。以金融IT開發中備受關注的分布式事務組件為例，可以基于不同業務場景選擇合適的事務模型，生成標準化代碼模板，開發人員只需要關注業務邏輯實現即可；
在工具類包層面，提供全面的金融級工具類（例如金融日期操作類、金額操作類等），避免安全隱患。
3.3.3.2開發運維一體化
1.云原生分布式核心對研發、運維發布的挑戰
從傳統核心到云原生分布式核心，不僅僅是系統本身的架構進行了重塑與變化，更是在團隊、度量、流程、規范、質量、工具、時效等層面都提出了更高的要求。有以下幾方面的挑戰需要去應對：
需求結構化與變更管理：業務需求條目化之后存儲，需求變更影響分析、代碼修改與測試用例變更整個過程形成閉環管理；
代碼版本、分支的管理策略：面對不同上線周期的需求，如何設定代碼分支、如何進行合并管理，需要有成熟的指引與配套工具；
代碼質量管控與度量：面對不同合作伙伴、不同能力層級的開發人員產出的代碼，需要做到代碼質量可度量并得到有效的管控；
自動化編譯、打包與部署：眾多微服務應用、多環境和大規模部署集群，手工構建與發布已經完全不具備可行性，必須有配套的工具支撐。
2.開發運維一體化支撐高效研發與運維發布
開發運維一體化平臺，覆蓋從項目協同、代碼管理到持續集成、持續發布等階段全流程管理，避免多入口和流程割裂，實現規范、標準的快速落地，提供從研發到發布的全鏈路數字化管理，確保核心系統的研發效能和高效可靠發布。
開發運維一體化平臺我們認為應該具備以下幾方面的能力：
項目協同：提供對需求、迭代、缺陷等各個維度的協同管理以及相關的統計報告，讓研發團隊高效協作；
代碼管理：提供代碼托管、評審和掃描、質量檢測等功能，保護企業代碼資產，實現安全、穩定高效的研發生產；
測試管理：標準化管理測試用例，快速搭建一體化（開發、測試、反饋）流程，有效提升交付效率和治理；
持續集成、發布流水線：提供靈活可用的持續集成、持續驗證、持續發布功能，幫助企業高質量、高效率的交付業務；
制品倉庫：提供多種軟件包管理工具的企業級私有倉庫服務，支撐企業級依賴托管。
知識庫：通過可協作的結構化文檔，將知識沉淀下來，并在團隊中有效流動，提升企業創造力。
3.3.4基礎軟件設施
基礎軟件設施層面，提供在苛刻的金融場景中久經考驗的基礎軟件設施和架構體系，涵蓋從運行時和運維時所需要的各項能力，包括異地多活單元化架構能力、分布式服務能力、分布式數據庫、高可用運維能力。
基礎軟件設施層面，應關注以下幾點：
采用充分磨合與驗證、功能完備（如單元化支持）的中間件體系，而非在應用系統開發階段還需要不斷修修補補、甚至進行架構妥協的中間件體系；
滿足自研可控與容災需求的分布式數據庫，容災情況能夠真正做到可切換、敢切換；
異地多活單元化能力，不只是架構設計，還需要中間件、數據庫和運維體系都具備必需的單元化支撐能力。
3.3.4.1分布式服務能力
作為支撐云原生分布式核心應用分布式、微服務化的基礎能力，分布式服務能力應該涵蓋：同步調用的雙模微服務、異步解耦的消息隊列服務、支撐批量作業的任務調度和API網關。
1.高性能的雙模微服務體系，滿足聯機交易場景需求
雙模微服務體系，支持傳統SDK服務框架和ServiceMesh兩種模式的微服務體系。核心系統對雙模微服務體系，有以下具體的能力需求：
高性能：核心的一個交易可能涉及到多次服務調用，服務框架必須高性能以避免提高服務響應時間；
可擴展：擴展性包括多個方面，例如：每家銀行內部通訊協議各有不同，強大的擴展性是服務框架適配行內需求的重要考量；
企業級的服務注冊中心：具備支撐海量服務注冊發現的能力，從而實現銀行內部真正服務打通；
服務治理能力：在具備限流、熔斷、服務訪問控制等動態服務質量治理能力的同時，具備與靜態服務治理打通的能力，從而形成服務動靜結合、全生命周期的管理；
高性能的服務鏈路跟蹤：支持抽樣的高性能跟蹤能力，為分布式環境下的問題排查提供必需的基礎能力。
2.高可靠的消息隊列服務，滿足異步解耦需求，提升交易響應時間
云原生分布式核心系統中，通過消息隊列可以將很多業務功能從聯機交易中解耦，在提升聯機交易性能的同時，也為業務的擴展性提供了可能。
例如：存款賬戶余額變動通知，可以通過異步消息發送給不同的系統進行消費，從而實現多種類型的業務功能（短信/微信通知、頭寸實時計算等）；交易核算分離也可以通過異步消息做到準實時的核算。
云原生分布式核心系統中，消息隊列應做到消息不丟、確保能夠被消費成功。
同時，事務消息機制是消息隊列應該提供的能力；無需核心應用再建立一套消息發送表，來實現消息的可靠發送。
3.高性能、高可用的調度框架，支撐核心系統大量的批處理作業
核心系統有大量的批處理作業，包括基于文件的批處理（如代發工資）和周期性執行的批處理（如存款結息、計提等）。
在分布式架構下，批處理調度框架具備兩個層面的能力，提升處理性能：
應用分布式架構的調度、協同：統一調度、協調分布式下的批處理應用集群，充分利用分布式算力、提升批處理執行效率、降低處理時間，為日終作業鏈加速，留出更充分的時間給大數據處理等系統；
數據分布式架構的作業拆分與事務控制：數據分布式存儲之后，一個作業中的數據按照合理的規則進行數據分包，以數據包為單位并發處理以提升執行效率，同時，要考慮分包策略對數據庫事務的影響。
同時，調度框架的高可用性也非常重要，完善的重試、斷點續作等自動化異常處理機制，可以大大降低運維人員的人工介入，在提升效率的同時避免人工干預帶來新的風險。
4.多種模式、高性能和保障一致性的分布式事務組件
核心應用服務的分布式化和數據分布式存儲，必然會引入分布式事務。分布式事務組件具有以下能力：
多種事務模式：支持TCC、SAGA等多種分布式事務實現模式；支持跨服務、跨數據庫的分布式事務需求；
異常處理能力：支持空回滾、防懸掛等能力，完善的異常處理機制，包括掛起事務、異常事務的重試、監控與告警等處理。
5.高性能、多協議且具備靈活路由規則的API網關
在部分銀行的實踐中，云原生分布式核心在銀行整體IT架構中對外還是一個完整的系統。在這種架構下，核心系統可以通過API網關作為對外服務門戶，實現服務治理、協議轉換等統一的處理；同時，在單元化架構下，基于API網關進行服務路由分發，是單元化必備的能力。
對于API網關，需要具備如下幾方面的特點：
高性能：作為每個對外服務都經過的鏈路節點，高性能是API網關最基礎的要求；
支持多協議和協議轉換：支持常見RPC協議（Dubbo、HTTP等）和行內特色通訊協議的自動轉換能力；
靈活的路由規則配置：支持自定義擴展路由策略，從而可以快捷的實現單元化路由功能；
服務治理能力：在網關層提供熔斷、限流、降級、訪問控制等治理能力。
3.3.4.2分布式數據能力
分布式數據能力有三種不同的架構模式：分布式數據庫、傳統關系型數據庫+分布式數據中間件體系、分布式數據庫+分布式數據訪問中間件。
這三種模式中，推薦采用“分布式數據庫+分布式數據訪問中間件”模式配合單元化架構，在充分發揮分布式數據相關優勢（容災、自研可控、彈性）的同時，又能享受單元化架構帶來的紅利。
1.分布式數據庫
應用于金融核心系統的分布式數據庫，必須在核心金融場景中穩定運行、經過嚴格的驗證。分布式數據庫應具備以下幾方面的能力，降低核心系統研發和運維難度：
分布式事務引擎：內置成熟的分布式事務引擎，嚴格支持事務的ACID屬性；
透明可擴展：支持對應用透明的在線平滑擴縮容，提供不受限的數據容量和處理能力；
極致的高可用：作為核心系統數據庫，需要有完備的高可用架構和高可用等級；
同城容災RPO為零：確保同城容災可切換、敢切換；
滿足自研可控需求：國內自主知識產權的數據庫，安全可控。
2.傳統關系型數據庫+分布式數據中間件體系
基于傳統關系型數據庫和分布式數據中間件，也可以實現數據分布式存儲與訪問能力。該模式下，分布式數據中間件體系需要包含以下組件：
分布式數據訪問組件：支持對應用代碼透明的分庫分表、讀寫分離和全表掃描，能夠生成全局唯一序列號，可以實現平滑擴容；
數據同步組件：實現數據變更的準實時處理。通常用于數據多副本同步、分庫分表數據匯聚、分布式緩存更新等場景。
3.分布式數據庫+分布式數據訪問中間件
在單元化架構下，通常采用這種模式。分布式數據庫基于業務數據某個維度切分為多個集群部署，每個集群相互獨立；數據訪問中間件提供對應用透明的集群選擇能力。
3.3.4.3高可用運維能力
1.核心系統轉型中帶來的運維挑戰
核心系統在云原生分布式轉型過程中，運維同樣也面臨了一系列新的挑戰，其中最為主要的幾個挑戰有：
隨著核心系統進行微服務應用拆分，原有運維管理的應用從個位數增長為數十甚至上百個；
核心應用微服務拆分后，交易鏈路需要跨多個微服務應用完成，對業務監控和定位提出了挑戰；
以往核心系統主要采用被動運維方式，即出現故障然后定位故障和處置故障，而隨著業務的不斷發展，核心系統也面臨互聯網流量、業務快速上線等沖擊，為應對多方沖擊需要從被動運維轉向主動運維；
技術的進步也驅動了核心系統容災的升級，同城容災切換RPO=0也成為新核心建設的目標，既滿足合規要求，也極大的減少了業務損失；
此外還有諸如混沌工程，AIOps等智能化運維工具的優勢也在逐步應用到核心系統運維中。
2.四位一體的高可用運維保障體系
核心在云原生分布式轉型的同時，構建與之對應的高可用運維保障體系顯得尤為必要?？傮w來說，高可用運維保障體系需包括系統安全、資金安全、高可用能力以及成本容量管理四大部分，如下圖所示：
資金安全：發現資金損失的風險。通過執行核對規則，以小時為頻率、準實時等多種時效策略，發現資金類數據問題，向用戶告警；用戶可以第一時間收到告警，根據異常數據排查問題，分析原因，進而解決問題；
系統安全：通過IaaS層安全系統和安全攻防演練，確?；A設施層面的安全；基于應用安全體系、數據隔離和安全掃碼，確保應用層面的安全；
高可用能力：高可用能力包括風險預防能力和應急處置能力。一是通過高可用巡檢能力和應急演練能力建設加強高可用風險預防能力；二是通過監控能力，故障定位能力，應急預案能力建設和打通加強應急處置能力；
成本容量管理：通過全鏈路壓測來提升系統和業務真實水位測試能力，以此為基礎去打通資源管理平臺和容量管理平臺。在保障業務容量穩定的前提下實現容量管理自動化，快速進行容量調撥。
3.3.4.4異地多活單元化
異地多活是分布式系統的一種高可用部署架構，可以滿足金融機構城市級容災的需求。實現異地多活架構的關鍵問題是如何處理跨地域的網絡延遲影響，而單元化架構為異地多活架構的實現提供了可行路徑。
所謂單元，是指一個能完成所有業務操作的自包含集合，在這個集合中包含了所有業務所需的所有服務，以及分配給這個單元的數據。
單元化架構就是把單元作為部署的基本單位，在所有機房中部署數個單元，每個機房里的單元數目不定，每一個單元都部署了系統所需的所有應用，數據則是全量數據按照某種維度劃分后的一部分。
通過采用單元化架構，在容災、彈性、資源利用率和灰度發布方面都將有顯著收益：
容災與業務連續性：支持同城和異地容災模式，RPO=0，RTO很短；單元化多活，縮小故障影響范圍；借助自動化容災平臺，可支持容災預案和便捷的容災演練；
彈性：異地多活提升擴展性，理論上無限擴展；按照單元靈活部署，提升擴容效率；
資源利用率：相對傳統兩地三中心部署架構，單元化架構能夠充分利用各個數據中心資源，顯著提升資源利用率；
灰度：靈活的流量調撥能力，支持單元級灰度發布；新老單元調用隔離，避免交叉訪問兼容性，提升發布效率。
單元化架構的核心原則是單元內流量封閉，這樣將同一筆業務處理的上下游鏈路均在同一個單元內完成，避免了中間跨地域調用的網絡延遲。為了實現單元化架構，需要圍繞兩個方面來設計系統能力，一方面是數據分區，另一方面是交易路由：
數據分區：對于數據的存儲至少需要具備兩項能力。其一是數據分區拆分，即是把數據按照某一個維度水平劃分開來；其二就是系統業務數據分區所用的拆分維度和拆分規則都保持一樣，確保同一條交易在整個鏈路中各個業務系統的數據分區是一致的，避免出現因拆分規則不一致導致的跨單元訪問；
交易路由：一筆交易鏈路中能夠按照預先設計的單元流量規則進行流量的路由和轉發。
1.經典單元化
采用中間件來實現單元化的方案，在頭部互聯網公司和一些大中型金融機構獲得了廣泛實踐，并且獲得了廣泛的技術收益，我們稱之為“經典單元化”架構。
經典單元化架構對中間件、數據分區和運維體系都提出了相應的能力要求：
中間件能力要求：各中間件（API網關、服務框架、消息隊列等）集成單元化路由能力，并且能夠通過全局的動態配置中心實時修改并準確推送路由規則到各中間件，實現單元化的切流。例如：API網關能夠根據路由規則選擇合適的單元進行調用分發；服務框架能夠根據路由規則進行服務提供者路由、消息隊列能夠根據路由規則進行消息跨單元投遞
數據分區能力要求：數據按同一維度水平拆分；數據分片按地域部署，各數據分片在同城和異地均有副本，數據庫分片主備副本可隨時切換；非容錯場景各機房應用只訪問本單元數據分片，容災場景可直接訪問同城的數據分片；
運維體系能力要求：支持單元化架構下的監控、容災切換、應急預案等能力。
2.動態單元化
經典單元化架構中，對應用數據分區和中間件能力建設提出了很高的要求，系統建設成本較高、實施周期較長。
伴隨技術的演進，分布式數據庫、服務網格技術逐步成熟，并已在頭部互聯網企業獲得了廣泛應用，這些新技術應用也為單元化架構的實現帶來了新的思路。
仍然從單元化架構落地需要具備的兩項能力出發，數據分區和交易路由：
分布式數據在線分區調整與擴容能力：傳統實現數據分區的方式是數據結構上增強拆分鍵用于分庫分表后的數據訪問路由。這種方式一旦投產后數據拆分規則就不能隨意進行調整，如迫不得已必須調整，則要進行數據拆分的重新分布遷移，對業務連續性會有較大的影響。分布式數據庫依靠自身的分區技術可以實現對應用相對透明的數據擴展能力；支持在線分區調整的能力則對單元化架構下實現數據分區的在線調整提供了可行性；
服務網格統一管理路由規則能力：服務網格技術是將中間件等能力下沉，實現原有各中間件的功能。同樣，對于單元化的路由，也可以下沉到服務網格統一處理，減少單元化架構落地實施時對各中間件的能力需求。
通過服務網格加分布式數據庫的單元化方案，因為可以根據業務需求而動態的調整分區和路由規則，所以我們稱之為“動態單元化”方案。
3.3.5基礎資源設施
基礎設施層具有高度開放性和彈性擴展能力，可以靈活適配、穩定管理不同類型的基礎設施，為核心系統的自主掌控和降本增效提供無限可能。
云原生架構下的基礎資源設施層面，應重點考慮以下幾方面：
IaaS層能夠真正做到按需快速交付，避免復雜又漫長的申請、審批和采購流程；
安全、穩妥的推進自研可控能力建設，確保核心系統的業務連續性。
3.3.5.1彈性擴展能力
采用云原生架構的IaaS層，實現云原生分布式核心系統按需獲得IT資源、保持業務持續性的需求。
通過基礎設施云化，實現資源打通，通過彈性擴容，使得成本、性能及穩定性達到最優。
IaaS層應具備以下幾方面的特征：
軟件定義平臺，屏蔽底層硬件差異，資源可根據需求進行橫向或縱向的擴展，對上層應用無感知；
生產級的可靠性及安全合規，保證金融機構數據的連續性和安全性；
統一管理入口，對不同人員的角色進行權限隔離，便于用戶運維管里。
3.3.5.2自研可控能力
核心系統作為銀行最關鍵的業務系統，逐步落地自研可控的信息技術體系成為必然的發展方向。然而，在落地層面存在以下幾方面的難點：
1.核心系統的自研可控涉及技術面較廣，包括應用、中間件、數據庫、云軟件/虛擬化軟件、各類硬件設施；
2.核心系統在落地自研可控的同時仍需保障高標準的可用性，不能因單個或部分替代導致技術水平降級；
3.不僅是中大型銀行，小型銀行也需要在科技人員規模較小的情況下對核心系統的開發和維護實現自研可控。
而通過多云管理與一云多芯能力、自研可控單元化架構體系，可以滿足銀行核心系統在自主掌控方面的需求。
1.多云管理與一云多芯
多云管理和一云多芯是解決基礎資源可管理、可替代的重要基礎。多云管理使用單一控制器對多種云資源（也可包括虛擬化環境）進行靈活的管理、編排、部署。一云多芯則通過適配多種類型服務器和服務器芯片，屏蔽底層硬件的差異，實現統一的云資源納管。
2. 自研可控單元化架構
單元化架構本身具備單元內應用封閉、業務自閉環、流量可調撥、可快速容災切換等良好的架構特性。特別適合使用到核心系統這種跨多層技術棧的自研可控場景，可通過分別構建傳統軟硬設施的單元和可替換軟硬設施的單元，并合理分配業務流量，當某個單元出現故障時也可快速把流量切換到另外一個單元，既可逐步落地自研可控，又滿足了業務連續性和技術水平不降級的要求。
3.4基于能力體系打造的金融級云原生工場
基于上節對五層十二大能力的分析，我們認為需要一整套端到端的能力體系，能夠覆蓋從業務建模、架構設計到系統建設，再到系統運行和運維的全流程；同時，這套能力體系應具備明確的實施工藝和高度的自動化能力，從而形成可標準化、規?；c高效的工場化生產模式。
基于這套能力體系打造的核心系統云原生分布式轉型與建設模式，我們稱之為“金融級云原生工場”模式。其中“云原生分布式核心輕咨詢”與 “雙核心并行與不停機遷移”作為系統實施路徑的兩個階段，在下一章中進行闡述。
從生產過程與運行的視角來看，金融級云原生工場整體上包含了以下幾方面的內容：
設計車間：業務領域建模是將業務需求轉化為IT能力的關鍵設計環節，充分考慮云原生應用的特點，使用領域建模及管理平臺，把建模過程變得簡單、敏捷，建模成果易落地并持續保鮮；
原材料（功能完備的組件與連接器）：核心引擎通過中臺化能力中心，承接業務領域建模成果，為生產業務系統提供功能完備的業務組件；服務治理與集成作為連接器，集成各業務組件進行服務組合，支撐業務快速創新；服務網格作為連接器集成多種技術棧的新老系統，為應用互聯互通提供保障能力；
標準化生產線：通過企業級應用開發和架構治理平臺、企業級一站式DevOps平臺，屏蔽復雜的云原生技術細節，提供低代碼編排生產能力，助力金融機構和合作伙伴（ISV）高效開發業務應用；
運行底座：堅實的技術底座，涵蓋充分磨合的PaaS、IaaS、單元化架構和高可用運維體系，為云原生分布式核心的穩定運行奠定堅實的基礎；基于單元化架構和一云多芯的自研可控能力，滿足金融機構自研可控需求。
經過對國內一些金融機構的核心下移與改造的實施路徑和建設模式分析，可以基本上分為兩種建設模式：
1）核心自主重構模式
路線特點：
1.自主研發新核心系統，非采購ISV（獨立軟件開發供應商）核心系統產品，強調自研可控
2.大多數原有核心采用AS400或大機的銀行希望采用重構的方式完成核心下移
3.建設目標包括業務建模、領域架構重構
4.絕大多數銀行構建了全新的核心應用技術平臺
5.部分銀行選擇基于云平臺進行核心系統重構
6.部分銀行在核心重構過程中包含自研可控規劃
7.核心開發實施過程會采購ISV（獨立軟件開發供應商）的人力資源
采用該路線的銀行范圍：國有大行、股份制、大農信、部分中大城商/農商
2）采購核心產品套件模式
路線特點：
1.采購ISV的核心系統產品，并主要基于ISV的人力資源完成核心實施交付
2.主要訴求為替代原有第一代的老舊核心
3.基于ISV核心產品的業務模型和架構建設
4.基于ISV核心產品自帶的應用技術平臺
5.部分銀行要求ISV產品簡單部署在云平臺上
自研可控方面，部分銀行僅能夠要求ISV產品集成國產數據庫
采用該路線的銀行范圍：部分中小城商/農商、民營銀行、外資銀行
4.1四階段五層模式
通過結合國內金融行業核心相關領域的實踐以及核心領域對于技術的云原生分布式轉型的業務能力，工程能力，技術能力要求，橫縱結合形成4階段5層的建設模式和路徑：
通過這張圖我們可以清晰的認識到核心下移云原生分布式轉型的路徑的全貌以及自身所處的不同階段。上圖中任務顏色的深淺代表在不同階段中任務的關鍵程度和優先級，顏色更深的優先級更高。且每一個階段的產出是下一個階段的輸入。從而形成一個系統化的完整的核心下移的頂層工作任務與路徑階段安排。
例如部分銀行采用重構模式，即業務架構和技術架構并行改造，以金融業的領域模型重構核心業務的同時配以主流的分布式架構支撐系統；也有部分銀行采用平遷模式，保持原有系統業務邏輯和流程不變，僅通過選用分布式數據庫來滿足底層海量數據要求。
4.2多種實施路徑
4.2.1重構模式
銀行核心系統的重構之旅，不僅僅只是互聯網技術改造，更是自身服務模式和服務思維的再造。從流程銀行轉向數字銀行，從產品為中心到客戶為中心，從做功能轉向做場景，從做渠道轉向做平臺。整體的實施路徑會從業務重構及核心應用技術平臺搭建兩大方向入手,進而實現核心銀行業務數字化轉型。
4.2.1.1業務重構
回顧“面對誤區的破局思維”的斷言6
斷言6：核心轉型相比選擇“供應商”而言，更為重要的是選擇具備“端到端落地實踐”的。從理念、方法論、設計規劃、平臺架構、標準規范都能夠戰略性長期投入和總體把控的“合作伙伴”才能真正落地實現業務敏捷和推動數字化轉型，而不是為一堆冠名“數字化轉型”的文檔買單。
業務重構主要是根據業界領先的理論和最佳實踐建立企業級業務模型，進而基于模型逐層細化業務規劃并向產品參數化設計轉變。整個改造過程會以現狀業務流程、數據和產品實踐為基礎，以待實現的業務需求為輸入，以領域驅動設計思想為指導，形成具備模型驅動的核心業務架構體系。
傳統的建模方式注重在企業級架構規范的范疇，能夠以結構化的方式將戰略，業務連接起來，但是從實際的落地來說，并不是傳統建模方式關注的。以產品為例，結合領域分層的理念，下圖能夠比較清晰的表明企業級建模與系統架構設計兩者之前的差異。
同時傳統的領域建模需要耗費大量的人力和資源，通常周期比較長，并不是所有的金融企業都能夠參考建行的模式。往往全行級建?；ㄙM了數年的時間之后，整個格局，環境，戰略又發生了變化，導致與時代的錯配。在這個背景之下，敏捷，中臺化，領域化建模的理念開始逐步進入大家的視野。
核心系統領域化架構設計的原則
1.把核心系統打開，對原有核心的業務能力重新進行領域劃分
2.把核心系統中的領域實體構建成微服務應用，實現核心服務能力的對外暴露，以及業務的松耦合
核心系統領域架構設計的進一步描述
1.將核心系統的通用領域提升到中臺能力層次：客戶中心、產品中心、合約中心
2.將核心系統的基礎功能放入基礎服務層，并構建成為對應的微服務應用：賬戶域、定價計價域，核算清算域、公共域、財務域等。
3.將核心系統中的各個業務產品放入產品服務層，各個業務產品的微服務包含了對中臺能力服務和基礎服務的流程編排組裝。
經過中臺化的重構之后，原有的業務流程建模和邏輯也會發生相應的改變，以定期支取為例，在經過中臺化的建模改造之后的流程變成如下的模式
4.2.1.2技術重構
回顧“面對誤區的破局思維”的斷言2、3、5
斷言2：“基礎不牢、地動山搖”，底層架構的高效穩定是第一目標。底層架構在起步階段從“統一架構”更加容易走穩，再逐步進行局部優化和解耦。
斷言3：核心架構中“非功能性需求”考慮要大于“功能性需求”。“非功功能性需求”應由技術架構來承載。業務模塊可以解耦設計和分包，技術架構要統一規劃和統一標準，實現核心領域的“統、分結合”。
斷言5：核心轉型最佳路徑是追求“P/PC平衡”-- 產出和產能平衡。不僅僅是完成 “產出”任務（應用遷移），更為重要的是升級“產能”（技術架構能力）?！爱a能”（技術架構）升級后會推動更大的“產出”（業務價值），成為全行數字化轉型的助推引擎。
從這三個重要的判斷可以看到，核心云原生分布式轉型需要一整套具備可伸縮、高可用的分布式金融技術平臺作為支撐，核心應用技術平臺的搭建整體包括DevOps平臺、分布式中間件平臺以及運維保障平臺三部分。其中DevOps平臺能提高核心應用開發上線的效率，主要包括有項目協作、代碼托管、持續集成持續交付等；分布式中間件平臺提供核心應用分布式能力層，提供了兼備應用分布式和數據分布式能力；運維保障平臺主要承載核心業務系統高可用應急管理功能，提供支持容量管理、壓測管理及容災管理。
同時，技術重構由于涉及的方面太多，我們進一步的進行層次化的拆解與明確，定義了五層十二大能力體系，幫助金融機構進行相應的落地設計。
企業自身可能不太具備這樣的技術能力和相應匹配的團隊，需要借助大量的外部資源與伙伴來完成整個理想中的藍圖。整體的價值，優勢的可獲得性相對比較低。我們建議在建設過程中配套匹配的工場，流水線，實施工藝等模式，降低整體的設計，開發，部署，運營，運維的難度。讓這些先進的技術真正可以落地，可以自主的掌控。建議增加中間框架體系與流水線體系，進一步降低落地難度，增加技術的可獲得性，讓終端的開發、運維等技術人員更容易上手，更容易使用。
4.2.2平行遷移模式
平遷模式實施的原則和前提是對業務不產生影響。業務流程不變、業務功能不變、應用處理邏輯不變、與外圍系統接口不變以及數據邏輯模型不變。
在這種模式下，主要解決的是國家一些指引的要求，同時解決集中式架構的非功能層面帶來的一些挑戰，例如性能、擴展性這些阻礙業務發展和損害客戶體驗的障礙。但從助力業務發展的視角來看，平遷模式是一個過渡性的中間狀態，從長遠來說，最終還是要解決業務敏捷帶來的挑戰。
從目前行業目前的實踐來看，目前具體有這么幾種平行遷移形式
1）數據不動，應用下移
數據架構不動，應用按照一個一個模塊進行下移和分布式改造，在過程中建立起全局的注冊中心，基礎微服務框架體系，同時引入分布式中間件相關技術來支持交易路由、交易熔斷降級、安全中心、統一配置中心等功能。此外，為更好應對核心下移，運維體系需要相關改造完成相應日志監控、鏈路追蹤和監控報警等功能。
這種模式的利：
數據體系和架構一般與業務和應用關聯度比較高，尤其經過長期的運行之后，數據體系非常復雜，牽一發可能會動全身，回歸測試等成本也會非常高。所以不動數據的模式相對比較簡單，業務人員的參與程度非常低?；旧霞夹g可控，在過程中鍛煉了技術人員的分布式，云原生能力，鍛煉了團隊。
這種模式的弊端：
沒有新的業務價值的過多體現，并且整體架構沒有太多變更，轉型不徹底，尤其是數據架構容易造成各種瓶頸，無論是對業務敏捷而言，還是性能角度而言。并且代碼的自動化翻譯工具等體系無法很好的應對領域建模等中臺化要求，翻譯代碼需要大量的性能優化與調整，采取這種模式的開發人員通常需要花費70%的經歷在代碼的性能結構優化上，無暇應對新業務應用的開發。
2）應用不動，數據下移
為了靈活應對海量交易和超量數據的沖擊，需要使用分布式數據技術來解決數據一致性問題。這種核心下移和分布式改造模式多輔以少量人工完成主機核心應用程序改造，或者自身已經在x86虛擬機等集中式架構下。通過接口改造與適配等來對接分布式數據庫體系。這種模式對于底層的分布式，云原生數據庫的技術要求非常高。
這種模式的利：
底層的交易瓶頸比較容易解除，并且實現了分布式情況下的最大挑戰之一的數據一致性挑戰。
這種模式的弊端：
對于分布式數據庫的技術要求，成熟度要求太高，可供選擇的供應商不太多。同時從業務角度而言，沒有新的價值體現，也無法做到業務敏捷。
4.2.3 SaaS化批量模式
相比傳統集中式架構，云原生分布式核心建設對技術積累、人員能力的要求也更高，相比有自研能力的大中型銀行，中小銀行新建核心除了依賴廠商的支持，也存在另一條新的路線，即金融核心SaaS。
基于云原生架構研發的金融核心，經過實地落地驗證后逐步完善、標準化，最終走上SaaS化。對于銀行、尤其中小銀行研發資源有限的情況下，避免投入大量時間、資源做核心的下移或重構，利用SaaS產品提供的標準化組件、OpenAPI，采用低代碼、服務編排快速實現業務敏捷，通過服務網格、Serverless等技術將非功能的需求下移，保障系統的高可用、可擴展、可灰度、可觀測。
選擇SaaS化的金融核心開拓了核心下移之旅的“批量模式”，也是面向云原生未來的架構。
4.3 在線遷移與雙核心并行
4.3.1 面臨的并行挑戰
云原生分布式核心建設一個關鍵必經之路就是如何在保障安全可控的基礎上完成新老核心的切換，金融機構出于人員、成本、風險等因素考慮，針對賬務核心部分往往會采用按模塊、按機構分批遷移的策略，云原生分布式核心建設進入到投產期將會存在雙核心并行。傳統方案中遷移動作需要在停業期間進行，對銀行提供服務的連續性造成影響。
金融機構對自身分布式技術平臺、運維體系以及核心應用的成熟度存在擔憂，傳統做法是在投產之前進行大量的功能測試、遷移演練、旁路驗證等，但這些均不能完全呈現生產環境實際運行情況。
另外，對核心實施人員來說項目周期長、壓力大，核心下移是持久戰、要打硬仗，但也需要有階段性成果進行激勵、給團隊信心。
4.3.2 云原生分布式核心推薦遷移策略
在按模塊、按機構分批次遷移的基礎上，將遷移顆粒度進一步縮小到按單客戶、單賬戶進行遷移，把遷移的風險控制在可接受的程度。同時，整個遷移過程全部實時在線完成，包括從舊核心的數據遷出、新核心的數據遷入、并保障數據一致性。整個核心遷移期間銀行不間斷對外提供服務、客戶無感知。
具體實施中遷移批次可以按照先內后外（銀行內部客戶到外部客戶）、先簡單后復雜（基于大數據分析客戶交易習慣）等策略進行安排。
4.3.3遷移平臺能力建設
要達到雙核心并行以及在線平滑遷移的效果，云原生平臺需要具備如下關鍵能力：
1.全局路由模塊實現新老核心數據識別和路由轉發，新核心采用單元化架構的要同步考慮單元路由；
2.遷移管控平臺對數據遷出、轉換、遷入等遷移步驟進行統一調度，并且保障數據遷移一致性；
3.新老核心并行期對外提供服務保持一致，減少系統間集成的影響。
只有具備以上的能力要求才能到達客戶無感、不停機在線遷移和雙核心并行方案，支持核心系統從集中式架構平穩、有序過渡到云原生架構。
基于該方案，金融架構將獲得兩方面的收益：
1.降低遷移實施風險：按客戶分批次遷移、試點，逐步驗證、排查與解決風險，最終完成新老核心切換。
2.提高業務連續性：在線遷移對客戶正常進行業務操作沒有影響；同時，技術上可以實現遷移不涉及到停業。
愛它的人，總會讓它一次次重生，并賦予它更大的意義。
經過上述的探討，我們歸結出來核心轉型的一些價值，一些共識和通用的標準，結論如下，可以作為行業機構設計和實施的參考。
5.1 第三代云原生分布式核心的價值體現
核心的云原生分布式轉型，成為第三代云原生分布式核心，有如下的一些價值方向:
1.自研可控，100%滿足相關的國家要求
2.運維成本降低400%
云原生架構基于相對廉價的PC服務器構建，在同等處理能力下，分布式架構的單位運行成本大幅度降低，分布式架構的年均運行維護成本是大型機的17%
3.業務敏捷，縮短40%以上的落地時間
云原生，中臺化的模式降低業務模塊間的強耦合性，業務交付更加敏捷，平均需求交付周期可以縮短40%左右，在進一步提升效率之后，可以達到數量級的效率提升
4.彈性擴展，完全線性
云原生架構具備良好的橫向彈性擴展能力，較好的滿足中國特有的“春節高峰”時段的特殊要求以及每年超過20%以上的業務增長量的需求，同時在底層資源充足的情況下，能夠做到即時的線性擴容。
5.下一代的異地多活架構，RPO=0，RTO<1分鐘
基于云原生的單元化異地多活架構，以及分布式中間件，分布式數據庫，云原生分布式框架，可以構建超過三地五中心全活多活架構，具備城市級別災備能力，城市級別RPO=0，RTO分鐘級別RTO<1分鐘。
5.2 第三代云原生分布式核心的關鍵標準
通過全篇的介紹，我們最后嘗試提出云原生第三代核心的一些關鍵標準，這也是行業從業者的一些共識。而為了達成這些標準，我們必須轉換思路，打造能實現這些標準的自動化流水線工廠。
1.云原生
云原生是應用架構演進，整體降本增效的必然趨勢和要求
2.異地多活單元化
單元化是架構灰度，進行架構在線升級的關鍵企業級架構設計
3.中臺化
中臺化是實現業務敏捷，業務彈性，應對未知挑戰的關鍵要素
4.數字化
數字化是實現面向未來金融基礎設施的關鍵設計
5.自研可控
自研可控是實現金融安全的必要保障
而云原生工場模式，是將這些標準與規范融入至整個的標準化制造與加工流水線以及實施工藝的端到端體系化模式，助力金融機構的核心云原生分布式轉型。
5.3 核心相關系統建設的經驗教訓總結
1.分離采購與建設模式的折扣
核心的下移不簡單是從主機等集中式環境換一個云原生和分布式的平臺，傳統的應用是應用開發商去建設，技術平臺是技術平臺供應商去建設的分離模式從最終預期要達到的效果和價值來說，并不會很好。因為應用開發商對于云原生底層技術平臺并沒有很深的了解，很多特性和優勢用不上，只能當虛擬機或者普通的數據庫來使用，基本上無法發揮出云原生的真正的價值。最終實現的業務價值會大打折扣。所以建議在整體建設之前，需要通過一個輕咨詢或者咨詢項目設計出整體的模式，架構，規劃，周期，預算等，為后期的建設做好統籌的設計，而不要盲目的開展建設項目。
2.承上啟下的困難與挑戰
核心等關鍵業務系統的云原生分布式轉型，需要對于核心業務以及對于底層云原生平臺都非常了解，才能夠真正實現高價值的核心云原生分布式轉型。應用架構和數據架構，數據模型等關鍵要素需要匹配分布式的環境做適應性的改造和優化設計才能保證最終的效果。例如在云化分布式環境下的賬戶與賬務數據模型的設計，例如在兩地三中心多活架構下的業務應用分域，以及客戶中心，產品合約的部署設計，例如在單元化模式下的單元區分規則，數不勝數。而這一點，往往很多傳統核心從業人員不太理解，認為應用業務與技術平臺無關，業務是業務，應用是應用，技術平臺是技術平臺。這三者的之間的隔閡，導致的業務無法敏捷，應用無法擴展。而我們急需的，便是運用工場流水線模式將這兩個鴻溝進行聯通，運用業務建模數字化平臺和工序將業務與應用有機貫穿以及同步，達成業務敏捷，運用架構治理與腳手架數字化平臺和工序，將應用和最終的開發運營運維體系有機貫穿與同步，達成應用敏捷以及安全可靠。實現最終的業務端到端敏捷。
3.性能等非功能性的忽視
從集中式架構的CA取向向云原生平臺的擴展性取向進行下移和建設的時候，由于增加了很多的網絡，RPC，分布式存儲等傳統集中式架構沒有的底層開銷，性能層面通常在早期的設計中沒有很好的考量和設計，而到最后的整體端到端性能壓力測試等時候才會爆發出來，無法滿足基本的并發與時延標準，達不到上線標準，然后重新進行各種調整，這個時候大的體系基本上已經建設完畢，無法做整體性優化，無法達到最優的效果。所以，建議在架構設計以及開發的早期，就要引入全鏈路測試與容量規劃的工具，早期識別關鍵鏈路以及關鍵設計的缺陷，為后期大規模應用建設排雷以及打好框架基礎。
4.技術風險與運營的挑戰
傳統集中式架構的運維保障通常由廠商和傳統的服務生態來保障，而到了云原生分布式體系下，整體需要運維的技術棧和平臺的數量，整體架構的復雜程度遠超以前，此時需要更多的將運維保障的任務交給自動化的，體系化的技術風險防控體系來處理，這部分的設計和建設的經驗傳統廠商基本上比較難以具備，也沒有實際落地的經驗。這對于整體系統的可用性，穩定性等帶來很大的隱患和風險，這部分的提前的考量，設計與建設也需要在早期同步開展，因為SRE體系對于架構，應用開發等有一定的規范和要求，遵從這些最佳實踐，才能給最后的運維提供必要的支持，便利和保障，確保整體性的運維管控能夠做到實效，給生產系統穩定高效運行提供真正的高效保障。
5.系統建設實施的巴別塔
系統架構即組織架構，這里的組織架構從傳統意義上大家理解是系統建設成之后，整體的內部開發，運維，管控的組織結構，權責邊界以及溝通交流等體系。但是從實際情況來看，新一代核心的建設周期往往都比較長，通常比較大型的金融機構建設周期都會在20個月以上，參與方眾多，大家往往會忽視這個長周期項目建設團隊自身的組織形式與管理模式。在云原生分布式，中臺化，業務敏捷驅動的這種新的核心架構方式之上，整個核心項目組的組織形式，具體工作任務劃分的方式和邊界，溝通交流方式這些也會有變化。這部分目前如果還按照以前集中式架構的項目組織和開展形式來運作的話，可能會有比較大的信息不對稱以及摩擦，影響整體的工程效率和最后落地的實際效果。因此我們也建議整個項目工程管理和溝通模式需要采用新的組織理念，采用數字化的工具體系來進行組織協調，更高效更高質量的完成實際落地交付上線。
最后，如果需要用幾句話來進行總結的話，那就是
“集中式架構，已經不止是一種技術架構模式，而成為一種根深蒂固的思維習慣和設計理念。當它成為潛規則而影響了創新時，我們往往身在此山中而不為所知。朝著云原生分布式轉型的過程中，打破這種集中式架構的思維慣性和習慣（設計、開發、運維），這些才是最難改變的”
“從金融行業的角度而言，要實現核心的云原生分布式轉型的關鍵在于打造一套新的云原生數字化流水生產線、配套設計工藝以及穩固的云原生分布式基礎設施，嘗試用綜合的視角去改變那些最難改變的部分”。
本文希望能夠給各位讀者帶來一些思考和收獲，能夠帶來一定的借鑒。如果未來一定會發生，那就先進入那個未來！
雷峰網(公眾號：雷峰網)
雷峰網版權文章，未經授權禁止轉載。詳情見轉載須知。
