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