銀行核心系統(tǒng)是IT建設(shè)皇冠上的明珠，我們與諸多銀行交流碰撞的火花中，未來核心系統(tǒng)的建設(shè)藍圖逐漸清晰。它不再是銀行科技部門按部就班建設(shè)的系統(tǒng)，不再是標準存貸匯功能的集合，不再是修修補補加外掛的平臺，不再是和數(shù)據(jù)平臺、數(shù)據(jù)服務(wù)能力割裂的架構(gòu)。
要實現(xiàn)金融核心云原生分布式轉(zhuǎn)型，關(guān)鍵在于打造一套新的云原生數(shù)字化生產(chǎn)線、配套設(shè)計工藝以及穩(wěn)固的云原生分布式基礎(chǔ)設(shè)施，用綜合的視角去變革那些最難的部分，從更高的視角去構(gòu)建智能化內(nèi)核能力無處不在的新平臺，重塑數(shù)字金融的商業(yè)價值。
核心系統(tǒng)轉(zhuǎn)型，相當于給正在跳動的心臟，做一場不停擺的換心手術(shù)。
不少金融機構(gòu)核心系統(tǒng)采用的傳統(tǒng)集中式架構(gòu)，成為了根深蒂固的思維慣性和設(shè)計、開發(fā)、運維習慣。當這一習慣開始影響創(chuàng)新時，我們往往因身在此山中難以察覺。
四年多時間，我和團隊拜訪了近千家金融機構(gòu)，在移動互聯(lián)網(wǎng)和金融科技的新技術(shù)大潮中，見證了技術(shù)驅(qū)動數(shù)字金融的新時代。
國外的基礎(chǔ)技術(shù)平臺和最佳實踐支撐了過去幾十年的金融業(yè)發(fā)展，很多單項技術(shù)仍具備極強的競爭力。今天我們面臨一個高速發(fā)展、充滿不確定性的時代，需要與移動互聯(lián)網(wǎng)和音視頻能力結(jié)合。過去的技術(shù)不是不先進了，而是限制我們對未來全面數(shù)字化金融的創(chuàng)造力，急需一套新的技術(shù)體系以實現(xiàn)金融機構(gòu)真正的業(yè)務(wù)和技術(shù)轉(zhuǎn)型。
銀行核心系統(tǒng)是IT建設(shè)皇冠上的明珠，我們與諸多銀行交流碰撞的火花中，未來核心系統(tǒng)的建設(shè)藍圖逐漸清晰。它不再是銀行科技部門按部就班建設(shè)的系統(tǒng)，不再是標準存貸匯功能的集合，不再是修修補補加外掛的平臺，不再是和數(shù)據(jù)平臺、數(shù)據(jù)服務(wù)能力割裂的架構(gòu)。
它必須是銀行數(shù)字化轉(zhuǎn)型中最重要的“一把手”工程，讓內(nèi)部員工、外部客戶都感受到數(shù)字化能力無處不在；是一個能快速生成新流程，發(fā)布新業(yè)務(wù)新產(chǎn)品，能力單元高度復用的平臺；是一個移動化、數(shù)據(jù)化、智能化，以分布式基礎(chǔ)架構(gòu)技術(shù)支撐的平臺，能以彈性能力應(yīng)對業(yè)務(wù)的峰值；是一個融合云計算中先進技術(shù)，應(yīng)對開放銀行和生態(tài)銀行所有業(yè)務(wù)的一棧式平臺。不少銀行已經(jīng)在這條路上積極探索，引領(lǐng)未來行業(yè)的重要實踐。
從實踐中，我們提煉出了一套系統(tǒng)性的思考：如何構(gòu)造具備競爭力的核心系統(tǒng)，優(yōu)化工程化體系，優(yōu)化基礎(chǔ)技術(shù)平臺和應(yīng)用系統(tǒng)的耦合度，對邏輯部署形態(tài)進行創(chuàng)新，并融合云計算中最先進的云原生技術(shù)。
能夠親歷金融行業(yè)的發(fā)展變革，是我們這一代從業(yè)者的榮耀，也是責任。
一、金融核心分布式轉(zhuǎn)型的行業(yè)變革
核心系統(tǒng)承載了銀行存款、貸款、銀行卡、清算核算等核心業(yè)務(wù)，被稱為“銀行業(yè)跳動的心臟”?；仡欍y行信息化30多年歷程，核心系統(tǒng)經(jīng)歷了從“胖核心”到“瘦核心”的演變?！芭趾诵摹币訧BM大型機為代表，“瘦核心”則以典型的IOE（IBM小型機、Oracle數(shù)據(jù)庫、EMC存儲設(shè)備的縮寫）技術(shù)架構(gòu)為代表。
隨著銀行以消費互聯(lián)網(wǎng)、產(chǎn)業(yè)互聯(lián)網(wǎng)、開放銀行生態(tài)為重點的業(yè)務(wù)快速增長，新一代銀行核心建設(shè)面臨“挑戰(zhàn)”。雖然集中式架構(gòu)仍具備很強的競爭力和高度的穩(wěn)定性，但問題也日益凸顯，即高并發(fā)、線性擴展、敏捷開發(fā)、按需彈性、精細化治理、多活可靠能力，已經(jīng)達到極限，系統(tǒng)部署無法及時響應(yīng)業(yè)務(wù)需求，系統(tǒng)彈性能力差，資源過度規(guī)劃和冗余浪費。銀行核心系統(tǒng)的云原生重塑來到了“時代拐點”，云原生的技術(shù)架構(gòu)，如微服務(wù)解耦、敏捷開發(fā)、自動化測試與發(fā)布、去中心化的服務(wù)治理、聲明式API、Serverless等，必然成為銀行的主流技術(shù)。
?。ㄒ唬┖诵霓D(zhuǎn)型的常見誤區(qū)與破局
核心轉(zhuǎn)型要“站在整體看局部，站在結(jié)果看過程”。
實踐中，我們看到很多機構(gòu)在面臨核心系統(tǒng)轉(zhuǎn)型時有一些普遍的困惑：金融核心到底該如何轉(zhuǎn)型？云原生分布式是否是金融核心的未來？金融核心云原生分布式轉(zhuǎn)型究竟帶來哪些價值？云原生在解決原有問題的同時帶來了什么新問題、如何應(yīng)對？
帶著這些靈魂拷問，我們調(diào)研了數(shù)十家金融機構(gòu)，梳理出以下核心轉(zhuǎn)型中的常見誤區(qū)。
誤區(qū)1：先從簡單系統(tǒng)著手進行架構(gòu)轉(zhuǎn)型，再到核心轉(zhuǎn)型。
例如實踐中出于技術(shù)自研要求，只考慮了OA系統(tǒng)的架構(gòu)轉(zhuǎn)型，但是核心領(lǐng)域被卡脖子的問題依然存在。因為OA系統(tǒng)的技術(shù)自研對核心領(lǐng)域沒有借鑒意義，導致未來核心應(yīng)用轉(zhuǎn)型仍需大量的探索。
破局：非核心領(lǐng)域的轉(zhuǎn)型對核心領(lǐng)域的參考借鑒意義有限，需要盡早考量核心架構(gòu)的技術(shù)自研，避免二次遷移的金錢和時間成本。
誤區(qū)2：核心轉(zhuǎn)型全流程選擇各個領(lǐng)域的最佳供應(yīng)商，就能達到好效果。
核心轉(zhuǎn)型全流程涉及咨詢建模、架構(gòu)、設(shè)計、應(yīng)用、基礎(chǔ)軟硬件等，實踐中如果只是找了專業(yè)咨詢團隊進行業(yè)務(wù)咨詢與建模，但大部分停留在紙面上，缺乏實操指導，核心研發(fā)團隊依舊不清楚如何開展大規(guī)模開發(fā)。
后繼各業(yè)務(wù)板塊招采了各領(lǐng)域的最佳供應(yīng)商，仰賴于應(yīng)用開發(fā)商的經(jīng)驗，各開發(fā)商都只熟悉自己這部分，無法落地前期業(yè)務(wù)建模的成果，無法形成端到端總控和業(yè)務(wù)落地。
破局：核心轉(zhuǎn)型選擇具備“端到端落地實踐”的合作伙伴。從理念、方法論、設(shè)計規(guī)劃、平臺架構(gòu)、標準規(guī)范都能夠戰(zhàn)略性長期投入和總體把控，才能真正落地數(shù)字化轉(zhuǎn)型。
誤區(qū)3：追求技術(shù)架構(gòu)解耦，隨時可切換到可替代的技術(shù)供應(yīng)商。
在核心云原生分布式轉(zhuǎn)型過程中，對核心技術(shù)平臺要求能夠完全分層分模塊解耦，不綁定任何一家技術(shù)平臺供應(yīng)商。實際上項目實施中IaaS/PaaS層雖然功能大體能夠適配，但在穩(wěn)定性、性能等“非功能性”領(lǐng)域常出現(xiàn)莫名其妙的問題，協(xié)調(diào)多家廠商的研發(fā)，產(chǎn)生大量溝通與適配成本。供應(yīng)商眾多導致無法做到全局架構(gòu)管控和統(tǒng)一技術(shù)標準打通。
破局：“基礎(chǔ)不牢、地動山搖”，底層架構(gòu)的高效穩(wěn)定是第一位的。從起步階段“統(tǒng)一架構(gòu)”更容易走穩(wěn)，再逐步進行局部優(yōu)化和解耦。業(yè)務(wù)模塊可以解耦設(shè)計和分包，技術(shù)架構(gòu)則要統(tǒng)一規(guī)劃和統(tǒng)一標準，“統(tǒng)分結(jié)合”。
誤區(qū)4：業(yè)務(wù)應(yīng)用是應(yīng)用開發(fā)商的事，技術(shù)平臺是技術(shù)平臺供應(yīng)商的事，兩者沒有關(guān)系。
傳統(tǒng)集中式架構(gòu)下，技術(shù)平臺經(jīng)過了經(jīng)年累月的標準化和適配，應(yīng)用的普適性相對更強，應(yīng)用開發(fā)不需要太多考慮底層架構(gòu)的差異性。但在云原生架構(gòu)時代，需要考慮分布式CAP（Consistency，Availability，Partition tolerance）原則，即一致性、可用性、分區(qū)容錯性三者最多同時實現(xiàn)兩點，不能三者兼顧，對應(yīng)用進行折中的設(shè)計。同時，需要考慮分布式事務(wù)、分布式數(shù)據(jù)一致性、異地多活等難題對于業(yè)務(wù)模式、業(yè)務(wù)流程、業(yè)務(wù)底層數(shù)據(jù)模型的特殊影響。
這部分是傳統(tǒng)上層應(yīng)用與傳統(tǒng)底層技術(shù)平臺之間的灰色地帶，往往決定了系統(tǒng)的整體表現(xiàn)，尤其在極端情況下。
破局：傳統(tǒng)集中式架構(gòu)，在云原生架構(gòu)下，大多數(shù)情況下并不適用，需要引入額外的框架、機制與設(shè)計來保障核心系統(tǒng)的整體表現(xiàn)。
（二）新思路新出路
針對以上核心轉(zhuǎn)型中的常見誤區(qū)與挑戰(zhàn)，要達成核心云原生分布式轉(zhuǎn)型的成功，我們需要一套能夠指引行動的“原則”。我們將金融核心轉(zhuǎn)型所需的行動指導總結(jié)為“六邊形”原則：1、業(yè)務(wù)技術(shù)閉環(huán)原則；2、自動化生產(chǎn)線原則；3、開放可插拔原則；4、可組裝構(gòu)造原則；5、普適性兼容性原則；6、易用透明化原則。
阿里云將這套“六邊形”原則沉淀為一套全新的方法論、工具平臺和工作模式，涵蓋了業(yè)務(wù)模型與流程建設(shè)的最前端，以及在云原生環(huán)境下的運維和運營。同時，明確的工序和生產(chǎn)流程，具備高度的自動化，能從一個工序自動化銜接到下一個工序。我們將這種核心系統(tǒng)云原生分布式轉(zhuǎn)型的建設(shè)模式，以及配套的自動化生產(chǎn)線體系，稱為“金融級云原生工場”模式。
（三）核心轉(zhuǎn)型成功的標志
在實踐和探索的過程中，我們得到了下面這張金融核心轉(zhuǎn)型的落地大圖：
一是客戶成功的三大標志。
首先，安全可控。第一種維度是技術(shù)架構(gòu)安全可控，整體把握系統(tǒng)架構(gòu)和關(guān)鍵技術(shù)，主要涉及自產(chǎn)自研、關(guān)鍵技術(shù)產(chǎn)品代碼自主、知識產(chǎn)權(quán)可控等。第二種維度是業(yè)務(wù)層的解耦，按照業(yè)務(wù)發(fā)展進行自主研發(fā)迭代，而不是高度耦合、牽一發(fā)動全身。
其次，財務(wù)成本、單交易/賬戶成本下降。上一代集中式架構(gòu)，TCO（Total Cost of Ownership）成本相對較高。不僅包括購置成本，還包括長達十多年的運營維護成本、擴容成本、人員成本等，核心轉(zhuǎn)型成功應(yīng)當帶來成本下降。
最后，業(yè)務(wù)穩(wěn)定性、連續(xù)性不降低的前提下，支撐業(yè)務(wù)敏捷。業(yè)務(wù)敏捷是面對不確定性的制勝法寶，例如對新業(yè)務(wù)的快速功能性支撐，對老業(yè)務(wù)的快速升級迭代等。但是前提是保證可靠性和穩(wěn)定性。沒有穩(wěn)定，就沒有金融安全，一切都是空中樓閣。
二是客戶對合作伙伴的訴求。
要完成核心轉(zhuǎn)型是整個產(chǎn)業(yè)鏈和生態(tài)的大協(xié)作，而不是一兩家技術(shù)公司的事，我們總結(jié)出核心轉(zhuǎn)型必備的四大要素，環(huán)環(huán)相扣，缺一不可：首先，咨詢設(shè)計云原生分布式的架構(gòu)設(shè)計、遷移方案、并行方案、實施路徑等；其次，項目實施和組織陣型的提前設(shè)計，包括基礎(chǔ)平臺和應(yīng)用開發(fā)的組織陣型規(guī)劃；第三，運維保障，快速解決核心故障問題，白盒化，更自動的監(jiān)控和運維工具及機制保障；第四，產(chǎn)品與方案層的長期規(guī)劃，產(chǎn)品與方案是整個核心遷移和云原生分布式轉(zhuǎn)型的基礎(chǔ)支撐。
從集中式到分布式，再到云原生分布式架構(gòu)的轉(zhuǎn)型，是一條必經(jīng)之路。
二、呼喚技術(shù)的“供給側(cè)改革”
數(shù)字時代的金融業(yè)以數(shù)據(jù)為關(guān)鍵生產(chǎn)要素、以場景和用戶價值為中心，是以線上便捷服務(wù)為主、線下人工服務(wù)為輔，融合數(shù)據(jù)智能和人的溫情，注重用戶體驗和風控的服務(wù)模式。新興金融體系包括開放金融體系、普惠金融體系、綠色金融體系，滿足嵌入式且靈活多變，對賬戶、交易、結(jié)算等核心能力提出了“泛在化”“全時在線”的要求。
（一）開放金融體系可標準化的構(gòu)件式核心
開放銀行已成為銀行業(yè)的發(fā)展共識，場景金融、產(chǎn)業(yè)鏈金融正形成“泛在化”“毛細血管”式的金融服務(wù)，描繪出更大的開放格局。這些業(yè)務(wù)需要“規(guī)?；眮頋M足泛在化的場景需求，“規(guī)?；狈催^來也對核心系統(tǒng)提出了挑戰(zhàn)。
1.不能變成新“豎井”的場景金融
隨著場景金融的演進，一些銀行共建、自建了大量場景金融業(yè)務(wù)?；诿總€場景都需要一套完整的業(yè)務(wù)系統(tǒng)支持，包括大量標準化、模塊化的能力，如用戶中心、產(chǎn)品中心、合約中心、權(quán)益中心等業(yè)務(wù)能力，用戶畫像、推薦模型、聯(lián)邦計算等數(shù)字化能力。
此外，隨著數(shù)字人民幣試點領(lǐng)域的擴大，金融場景越來越豐富，僅數(shù)字人民幣的應(yīng)用場景就超過350萬個。銀行都在努力構(gòu)造更多的場景，覆蓋生活、學習、工作各個方面，這導致場景的碎片化及對場景構(gòu)建的敏捷性要求。
銀行需要認識到如何不讓場景成為新一輪的“豎井式開發(fā)”。業(yè)務(wù)的中臺化、標準化、構(gòu)件化是解決這一問題的出路，越來越多的銀行正為業(yè)務(wù)設(shè)計結(jié)構(gòu)化的業(yè)務(wù)模型，并探索將其與應(yīng)用設(shè)計緊密連接。
2.必須實現(xiàn)生態(tài)化的產(chǎn)業(yè)金融
供應(yīng)鏈金融是金融業(yè)務(wù)從核心企業(yè)向周邊企業(yè)拓展的最好方式，也是推動產(chǎn)業(yè)金融發(fā)展的理想模式。實踐中，供應(yīng)鏈金融的發(fā)展需要依靠核心企業(yè)意愿、平臺服務(wù)水平、周邊企業(yè)的實際收益等諸多因素，因此，盡管很多研究機構(gòu)將供應(yīng)鏈金融視為十萬億級以上的大市場，其總體發(fā)展一直不是很順利。
如果為供應(yīng)鏈金融單獨建設(shè)平臺，其建設(shè)成本、相關(guān)方收益等難以解決。只有通過超越供應(yīng)鏈視角的大型商業(yè)平臺承載供應(yīng)鏈服務(wù)，才有可能解決單一用途平臺面臨的問題。國家倡導建設(shè)的行業(yè)云，就可以承載這樣的商業(yè)平臺，平臺中可以自由加入任何供應(yīng)鏈；同時，現(xiàn)有商業(yè)平臺也可以進一步擴大互聯(lián)，任何一家企業(yè)加入平臺即加入供應(yīng)鏈。這樣才能突破傳統(tǒng)供應(yīng)鏈平臺高封閉、重成本、低收益的困境，也符合國家要求大型企業(yè)開源、開放的政策基調(diào)。
多功能的大型商業(yè)互聯(lián)平臺不僅承載供應(yīng)鏈，還是各類企業(yè)建立自身應(yīng)用的“標準化構(gòu)件庫”。企業(yè)可以根據(jù)自身需要，選擇云原生的標準化構(gòu)件組裝業(yè)務(wù)，這是“產(chǎn)業(yè)數(shù)字化”的一大推手，需要高度的業(yè)務(wù)標準化。國家標準化發(fā)展政策正在推動這一趨勢，未來銀行也會融入這一數(shù)字化商業(yè)生態(tài)，催生金融機構(gòu)新一代構(gòu)件化核心系統(tǒng)。
（二）普惠金融體系可靈活組裝的核心系統(tǒng)
普惠金融致力于提升金融服務(wù)的公平性、可獲得性，通過更有社會責任感的經(jīng)營理念、更有效率的風控手段、更低的運營成本賦能小微企業(yè)、農(nóng)民、城鎮(zhèn)低收入人群等弱勢群體，讓更廣泛的客戶獲得優(yōu)質(zhì)金融服務(wù)。
普惠金融的客群對象和業(yè)務(wù)特點決定了其產(chǎn)品碎片化、上線周期短、業(yè)務(wù)變化頻繁，需要能像積木一樣解構(gòu)業(yè)務(wù)和技術(shù)的能力，靈活配置、滿足業(yè)務(wù)需要。針對普惠金融，金融機構(gòu)的核心系統(tǒng)只有像可組裝的流水化工場才能應(yīng)對環(huán)境的快速變化，同時對長尾客戶群體的支持，需要的是一套易擴展的核心系統(tǒng)架構(gòu)。
（三）綠色金融體系可泛化設(shè)計的核心系統(tǒng)
發(fā)展綠色金融不僅是金融行業(yè)的商業(yè)機會，更是社會責任。綠色金融包括兩個部分：一是金融機構(gòu)自身要完成“雙碳”目標；二是面向客戶側(cè)，“雙碳”觸發(fā)的業(yè)務(wù)變革。
按照“雙碳”的要求，金融機構(gòu)要控制信貸資金流向，逐步減少高排放用戶的信貸支持，未來可能會逐筆核算信貸資金的“碳排放量”，控制信用業(yè)務(wù)“碳”風險。要實現(xiàn)“碳”風險計算，除了用戶數(shù)據(jù)支持，還需要外部社會數(shù)據(jù)，尤其是權(quán)威數(shù)據(jù)支持。通過構(gòu)建綠色金融賬戶，完善綠色金融產(chǎn)品，提升綠色金融智能化評估，金融機構(gòu)可以更好地支持綠色生態(tài)鏈上下游體系的開放性融合，打通綠色循環(huán)。
綠色金融將推動金融賬戶應(yīng)用模式的泛化，從而影響核心系統(tǒng)的設(shè)計理念。
三、金融核心轉(zhuǎn)型的能力要求與建設(shè)體系
數(shù)字化韌性在當下金融核心轉(zhuǎn)型中格外重要，軟件產(chǎn)品需要有彈性、韌性，以及反應(yīng)足夠快的數(shù)字化體系。當集中式架構(gòu)面臨“數(shù)字化韌性”力不從心時，我們很難用舊時代的方法去解決新時代的問題。
?。ㄒ唬┖螢椤敖鹑诩壴圃?/strong>
云原生架構(gòu)是基于云原生技術(shù)的架構(gòu)原則和設(shè)計模式的集合，能將應(yīng)用中非業(yè)務(wù)代碼最大化的剝離，讓云設(shè)施接管應(yīng)用中原有的大量非功能特性，如彈性、韌性、安全、可觀測性、灰度等，使業(yè)務(wù)不再被非功能性業(yè)務(wù)中斷，同時具備輕量、敏捷、高度自動化的特點。
云原生技術(shù)主要以容器、DevOps、微服務(wù)、分布式中間件、分布式數(shù)據(jù)庫、Serverless、服務(wù)網(wǎng)格、不可變基礎(chǔ)設(shè)施、聲明式API、開放應(yīng)用模型（OAM）等技術(shù)為核心，能夠?qū)崿F(xiàn)業(yè)務(wù)應(yīng)用與基礎(chǔ)設(shè)施的解耦，被認為是新一代云計算的“操作系統(tǒng)”。
金融機構(gòu)采用云原生技術(shù)，并不是將應(yīng)用上公有云，而是將金融對安全合規(guī)、交易強一致性、容災(zāi)多活、全鏈路業(yè)務(wù)風險管理等各方面行業(yè)要求與云原生技術(shù)深度融合，發(fā)展為一套既符合金融行業(yè)標準，又具備云原生技術(shù)優(yōu)勢的“金融級云原生架構(gòu)”。
（二）銀行核心系統(tǒng)轉(zhuǎn)型能力需求
對金融核心來說，不論未來金融服務(wù)的形態(tài)如何演變，對“靈活性、易擴展、高并發(fā)、標準化組件、低成本、可靠在線服務(wù)”的追求是不變的。我們從業(yè)務(wù)、工程和技術(shù)的角度，總結(jié)了云原生分布式核心應(yīng)對“不變”的能力，并針對每項能力拆解出十二項支撐能力，再對這十二項支撐能力歸納分層，形成云原生分布式核心建設(shè)的五層十二大能力體系，如下圖所示：
（三）支撐核心轉(zhuǎn)型的五層十二大能力體系
第一層：業(yè)務(wù)領(lǐng)域建模
充分考慮云原生應(yīng)用的特點，使用領(lǐng)域建模及管理平臺，把建模變得簡單、敏捷、易落地，并通過平臺實現(xiàn)建模資產(chǎn)的保鮮。具體來說，簡化建模過程；采用建模平臺，管理模型資產(chǎn)；運用低代碼技術(shù)，落地模型。
一是基于銀行同業(yè)已有實踐敏捷建模，而非投入大量資源進行長周期建模；二是通過建模平臺實現(xiàn)成果保鮮，持續(xù)為業(yè)務(wù)迭代，而非核心系統(tǒng)建完之后束之高閣，逐步與系統(tǒng)演進結(jié)果脫節(jié)；三是建模成果能夠借助建模平臺、結(jié)合云原生技術(shù)快速落地。
第二層：應(yīng)用架構(gòu)集成
應(yīng)用架構(gòu)集成層承接業(yè)務(wù)領(lǐng)域建模成果，將核心系統(tǒng)按照業(yè)務(wù)領(lǐng)域建模體系整體規(guī)劃，形成可供全行IT系統(tǒng)復用的業(yè)務(wù)中臺能力，生產(chǎn)各業(yè)務(wù)系統(tǒng)必需的業(yè)務(wù)組件；通過服務(wù)治理與組合的低代碼能力，快速支撐業(yè)務(wù)創(chuàng)新；基于服務(wù)網(wǎng)格實現(xiàn)異構(gòu)系統(tǒng)集成，為傳統(tǒng)應(yīng)用、遷移到云原生分布式架構(gòu)下的應(yīng)用互通提供技術(shù)保障。即，應(yīng)用架構(gòu)集成層主要由應(yīng)用架構(gòu)中臺化、服務(wù)治理與組合、異構(gòu)應(yīng)用集成三大能力支撐。
在應(yīng)用架構(gòu)層面，云原生分布式核心與傳統(tǒng)“瘦核心”、分布式核心重大區(qū)別是：一、不是簡單的將核心系統(tǒng)按照業(yè)務(wù)條線劃分為客戶、存款、貸款等應(yīng)用，采用分布式技術(shù)重新實現(xiàn)一遍，導致很多公共能力如產(chǎn)品管理、合約管理等應(yīng)用都需要重復建設(shè)，數(shù)據(jù)層面不互通；二、是將核心系統(tǒng)按照業(yè)務(wù)領(lǐng)域建模體系進行整體規(guī)劃設(shè)計，形成可供全行IT系統(tǒng)復用的業(yè)務(wù)中臺能力，提供業(yè)務(wù)構(gòu)件，并通過服務(wù)運營與編排，使用業(yè)務(wù)構(gòu)件快速進行業(yè)務(wù)創(chuàng)新。
第三層：應(yīng)用系統(tǒng)建設(shè)
提供標準化生產(chǎn)線，屏蔽復雜的云原生技術(shù)細節(jié)，規(guī)范云原生應(yīng)用開發(fā)標準，包括異構(gòu)應(yīng)用集成、統(tǒng)一開發(fā)體系、開發(fā)運維一體化三大支撐能力。
應(yīng)重點考慮以下三方面：一是統(tǒng)一ISV開發(fā)技術(shù)棧，避免技術(shù)管理失控；二是統(tǒng)一、易用的開發(fā)平臺與框架，簡化和規(guī)范化應(yīng)用開發(fā)；三是全流程覆蓋的DevOps體系，涵蓋需求結(jié)構(gòu)化管理、代碼版本與分支管理、質(zhì)量管控與度量、自動化編譯打包與部署等方面。
第四層：基礎(chǔ)軟件設(shè)施
提供在苛刻金融場景中久經(jīng)考驗的基礎(chǔ)軟件設(shè)施和架構(gòu)體系，涵蓋運行時和運維時所需的各項能力，包括異地多活單元化架構(gòu)、分布式服務(wù)、分布式數(shù)據(jù)、高可用運維等能力。
應(yīng)關(guān)注以下三點：一是采用充分磨合與驗證過的中間件體系，不要在應(yīng)用系統(tǒng)開發(fā)階段還需要修修補補；二是采用滿足技術(shù)自研與容災(zāi)需求的分布式數(shù)據(jù)庫，能真正做到可切換、敢切換；三是具有異地多活單元化能力。不只是架構(gòu)設(shè)計，中間件、數(shù)據(jù)庫和運維體系都要有單元化支撐能力。
第五層：基礎(chǔ)資源設(shè)施
具有高度的開放性和彈性擴展能力，靈活適配、穩(wěn)定管理不同類型的基礎(chǔ)設(shè)施，為核心系統(tǒng)的自主掌控和降本增效提供無限可能。
應(yīng)重點考慮以下兩點：一、IaaS層能夠真正做到按需快速交付，避免復雜又漫長的申請、審批和采購流程；二、安全穩(wěn)妥的推進自研技術(shù)能力建設(shè)，確保核心系統(tǒng)的業(yè)務(wù)連續(xù)性。
（四）基于能力體系打造的金融級云原生工場
基于對云原生分布式核心建設(shè)的五層十二大能力分析，我們認為需要一整套端到端的能力體系，覆蓋從業(yè)務(wù)建模、架構(gòu)設(shè)計到系統(tǒng)建設(shè)，再到系統(tǒng)運行和運維的全流程。同時，這套能力體系還需具備明確的實施工藝和高度的自動化能力，從而形成可標準化、規(guī)?；⒏咝У墓龌a(chǎn)模式。我們稱為“金融級云原生工場”模式。
金融級云原生工場整體上包含以下幾部分：一是設(shè)計車間。通過業(yè)務(wù)領(lǐng)域建模將業(yè)務(wù)需求轉(zhuǎn)化為IT能力，并充分考慮云原生應(yīng)用的特點，使用領(lǐng)域建模及管理平臺，把建模過程變得簡單、敏捷，讓建模成果易落地。二是原材料，即功能完備的組件與連接器。具體來說，核心引擎通過中臺化能力中心，承接業(yè)務(wù)領(lǐng)域建模成果，為生產(chǎn)業(yè)務(wù)系統(tǒng)提供完備的業(yè)務(wù)組件。服務(wù)治理與集成作為連接器，集成各業(yè)務(wù)組件進行服務(wù)組合，支撐業(yè)務(wù)快速創(chuàng)新。服務(wù)網(wǎng)格集成多種技術(shù)棧的新老系統(tǒng)，為應(yīng)用互聯(lián)互通提供保障能力。三是標準化生產(chǎn)線。通過企業(yè)級應(yīng)用開發(fā)和架構(gòu)治理平臺、企業(yè)級一站式DevOps平臺，屏蔽復雜的云原生技術(shù)細節(jié)，提供低代碼編排生產(chǎn)能力，助力金融機構(gòu)和ISV高效開發(fā)業(yè)務(wù)應(yīng)用。四是運行底座。堅實的技術(shù)底座，涵蓋充分磨合的PaaS、IaaS、單元化架構(gòu)和高可用運維體系，為云原生分布式核心的穩(wěn)定運行奠定堅實的基礎(chǔ)，并基于單元化架構(gòu)和一云多芯，滿足金融機構(gòu)自研技術(shù)需求。
四、金融核心轉(zhuǎn)型的建設(shè)模式與實施路徑
我們總結(jié)出四階段五層的建設(shè)模式和三條重點實施路徑，并著重介紹在線遷移與雙核心并行方案。
（一）四階段五層建設(shè)模式
綜合國內(nèi)金融行業(yè)核心領(lǐng)域的相關(guān)實踐，分為四個階段，即輕咨詢期、平臺能力建設(shè)期、云原生/分布式設(shè)計驗證期、規(guī)?；貥?gòu)或建設(shè)期；在技術(shù)能力、工程能力、業(yè)務(wù)能力上可以分為五個層次，即基礎(chǔ)資源設(shè)施、基礎(chǔ)軟件設(shè)施、應(yīng)用系統(tǒng)建設(shè)、應(yīng)用架構(gòu)集成、業(yè)務(wù)領(lǐng)域建模，橫縱結(jié)合形成四階段五層建設(shè)模式。
（二）三條重點實施路徑
采用重構(gòu)模式的，多是大型國有銀行、股份制銀行，對業(yè)務(wù)架構(gòu)和技術(shù)架構(gòu)并行改造；一些銀行采用平行遷移模式，保持原有系統(tǒng)業(yè)務(wù)邏輯和流程不變，僅通過選用分布式數(shù)據(jù)庫來滿足底層海量數(shù)據(jù)要求；中小銀行核心建設(shè)，還可以采用SaaS化批量模式。
1.重構(gòu)模式
銀行核心系統(tǒng)的重構(gòu)不僅是互聯(lián)網(wǎng)技術(shù)改造，更是自身服務(wù)模式和服務(wù)思維的再造。從流程銀行轉(zhuǎn)向數(shù)字銀行，從產(chǎn)品為中心到客戶為中心，從做功能轉(zhuǎn)向做場景，從做渠道轉(zhuǎn)向做平臺，包括業(yè)務(wù)重構(gòu)和技術(shù)重構(gòu)兩部分。
業(yè)務(wù)重構(gòu)，根據(jù)業(yè)界領(lǐng)先理論和最佳實踐建立企業(yè)級業(yè)務(wù)模型。改造以已有業(yè)務(wù)流程、數(shù)據(jù)、產(chǎn)品為基礎(chǔ)，納入待實現(xiàn)的業(yè)務(wù)需求，形成模型驅(qū)動的核心業(yè)務(wù)架構(gòu)體系。
傳統(tǒng)的建模方式，需要耗費大量人力和資源，且建設(shè)周期長，往往全行級建模花了數(shù)年時間后，整個格局、環(huán)境、戰(zhàn)略又發(fā)生了變化。敏捷、中臺化、領(lǐng)域化建模的理念進入大家的視野。
技術(shù)重構(gòu)方面，需要一套可伸縮、高可用的分布式金融技術(shù)平臺作為支撐，包括DevOps平臺、分布式中間件平臺、運維保障平臺三部分。DevOps平臺能提高核心應(yīng)用開發(fā)上線的效率；分布式中間件平臺為金融機構(gòu)提供兼?zhèn)鋺?yīng)用分布式和數(shù)據(jù)分布式能力；運維保障平臺主要承載核心業(yè)務(wù)系統(tǒng)高可用應(yīng)急管理功能。
一般來說，企業(yè)需要借助大量外部技術(shù)力量與伙伴一起完成技術(shù)重構(gòu)。我們建議在建設(shè)過程中配套相匹配的工場、流水線、實施工藝等，以降低整體設(shè)計、開發(fā)、部署、運營、運維的難度。
2.平行遷移模式
平行遷移模式實施的原則是對業(yè)務(wù)不產(chǎn)生影響，業(yè)務(wù)流程不變、業(yè)務(wù)功能不變、應(yīng)用處理邏輯不變、與外圍系統(tǒng)接口不變、數(shù)據(jù)邏輯模型不變，可以用較小的技術(shù)成本解決集中式架構(gòu)非功能層面帶來的挑戰(zhàn)。但從業(yè)務(wù)發(fā)展的視角來看，平行遷移模式是一個過渡狀態(tài)，長遠來說，最終還是要解決業(yè)務(wù)敏捷帶來的挑戰(zhàn)。
從目前的行業(yè)實踐來看，有以下兩種：
一是數(shù)據(jù)不動，應(yīng)用下移。即數(shù)據(jù)架構(gòu)不動，上層應(yīng)用按照一個個模塊做下移和分布式改造，同時引入分布式中間件相關(guān)技術(shù)支持交易路由、交易熔斷降級、安全中心、統(tǒng)一配置中心等功能。
好處在于，數(shù)據(jù)體系和架構(gòu)一般與業(yè)務(wù)高度關(guān)聯(lián)，長期運行之后，數(shù)據(jù)體系非常復雜，牽一發(fā)動全身，回歸測試等成本也非常高。不動數(shù)據(jù)的模式就相對簡單了。它的弊端在于，整體架構(gòu)沒有太多變化、轉(zhuǎn)型不徹底，數(shù)據(jù)架構(gòu)容易造成業(yè)務(wù)敏捷、性能上的瓶頸。開發(fā)人員通常需要花費70%的精力在代碼的性能結(jié)構(gòu)優(yōu)化上，無暇應(yīng)對新業(yè)務(wù)應(yīng)用的開發(fā)。
二是應(yīng)用不動，數(shù)據(jù)下移。通過分布式數(shù)據(jù)技術(shù)來解決數(shù)據(jù)一致性問題，輔以少量人工完成主機核心應(yīng)用程序改造，或者本身已經(jīng)在X86虛擬機等集中式架構(gòu)下，通過接口改造、適配來對接分布式數(shù)據(jù)庫體系，對底層的分布式技術(shù)、云原生數(shù)據(jù)庫技術(shù)要求非常高。
好處在于，底層的交易瓶頸比較容易解除，即數(shù)據(jù)一致性挑戰(zhàn)。弊端在于，對分布式數(shù)據(jù)庫的技術(shù)要求、成熟度要求太高，可供選擇的技術(shù)供應(yīng)商不多。同時還無法做到業(yè)務(wù)敏捷。
3.SaaS化批量模式
相比傳統(tǒng)集中式架構(gòu)，云原生分布式核心建設(shè)對技術(shù)積累、人員能力的要求更高。相比有自研能力的大中型銀行，中小銀行在研發(fā)資源有限的情況下，為避免投入大量時間、資源做核心重構(gòu)，還存在另一條路線，即金融核心SaaS化批量模式。
金融核心SaaS基于云原生架構(gòu)研發(fā)，經(jīng)過落地驗證后逐步標準化，最終走上SaaS化。具體來說，SaaS化批量模式指利用SaaS產(chǎn)品提供的標準化組件、OpenAPI開放應(yīng)用程序接口，采用低代碼、服務(wù)編排快速實現(xiàn)業(yè)務(wù)敏捷，通過服務(wù)網(wǎng)格、Serverless等技術(shù)將非功能的需求下移，保障系統(tǒng)的高可用、可擴展、可灰度、可觀測。
選擇SaaS化的金融核心，開拓了核心下移的“批量模式”，也是面向云原生未來的架構(gòu)。
（三）在線遷移與雙核心并行
如何在保障安全可控的基礎(chǔ)上完成新老核心的切換。金融機構(gòu)出于人員、成本、風險等因素考慮，賬務(wù)核心往往會采用按模塊、按機構(gòu)分批遷移的策略。于是，在投產(chǎn)期會存在雙核心并行的情況，會對銀行服務(wù)的連續(xù)性造成影響。
傳統(tǒng)做法是在投產(chǎn)之前做大量的功能測試、遷移演練、旁路驗證等，但這些并不能完全呈現(xiàn)生產(chǎn)環(huán)境的實際運行情況。同時，項目周期長、壓力大。核心下移是持久戰(zhàn)，需要有階段性的成果給團隊激勵。
阿里云提出云原生分布式核心遷移的推薦策略，即在按模塊、按機構(gòu)分批遷移的基礎(chǔ)上，將遷移顆粒度進一步縮小到按單客戶、按單賬戶，把遷移風險控制在可接受的范圍內(nèi)。同時，整個遷移過程全部實時在線完成，包括從舊核心的數(shù)據(jù)遷出、新核心的數(shù)據(jù)遷入，保障數(shù)據(jù)一致性。整個核心遷移期間，銀行不間斷對外提供服務(wù)、客戶對遷移過程無感知。
遷移順序可以按照“先內(nèi)后外”“先簡單后復雜”的策略進行?！跋葍?nèi)后外”指的是先銀行內(nèi)部客戶再外部客戶，“先簡單后復雜”則可以基于大數(shù)據(jù)分析客戶交易習慣先遷移簡單模塊。
要達到雙核心并行以及在線平滑遷移的效果，遷移平臺的能力建設(shè)至關(guān)重要：一是全局路由模塊實現(xiàn)新老核心數(shù)據(jù)識別和路由轉(zhuǎn)發(fā)，新核心采用單元化架構(gòu)，要同步考慮單元路由；二是遷移管控平臺對數(shù)據(jù)遷出、轉(zhuǎn)換、遷入等遷移步驟進行統(tǒng)一調(diào)度，并保障數(shù)據(jù)遷移一致性；三是新老核心并行期對外照常提供服務(wù)，減少系統(tǒng)間集成的影響。讓核心系統(tǒng)從集中式架構(gòu)平穩(wěn)、有序過渡到云原生架構(gòu)。
五、核心云原生分布式轉(zhuǎn)型的經(jīng)驗總結(jié)
我們歸納出金融核心轉(zhuǎn)型的一些共識和通用的標準，供行業(yè)參考：
（一）第三代云原生分布式核心的價值體現(xiàn)
金融核心云原生分布式核心，首先是技術(shù)自研，100%滿足國家相關(guān)要求；其次，運維成本能降低400%。云原生架構(gòu)能基于相對廉價的PC服務(wù)器構(gòu)建，在同等處理能力下，分布式架構(gòu)的單位運行成本大幅度降低，年均運行維護成本是大型機的17%；第三，業(yè)務(wù)敏捷，平均交付周期能縮短40%以上；第四，彈性擴展，完全線性，能滿足中國特有的“春節(jié)高峰”，以及每年20%以上的業(yè)務(wù)增長需求；第五，下一代異地多活架構(gòu)，RPO=0，RTO<1分鐘?；谠圃膯卧惖囟嗷罴軜?gòu)，以及分布式中間件、分布式數(shù)據(jù)庫、云原生分布式框架，可以構(gòu)建超過“三地五中心”的全活多活架構(gòu)，故障恢復后不丟數(shù)據(jù)，故障恢復時間在1分鐘以內(nèi)。
（二）第三代云原生分布式核心的關(guān)鍵標準
云原生第三代核心有一些關(guān)鍵標準，我們打造了云原生工場模式，將這些標準與規(guī)范融入自動化流水線，并采用端到端的實施工藝。
這些關(guān)鍵標準有：1、云原生，是應(yīng)用架構(gòu)演進、降本增效的必然趨勢和要求；2、異地多活單元化，是架構(gòu)在線升級的關(guān)鍵企業(yè)級架構(gòu)；3、中臺化，是實現(xiàn)業(yè)務(wù)敏捷、彈性，應(yīng)對未知挑戰(zhàn)的關(guān)鍵；4、數(shù)字化，是面向未來金融基礎(chǔ)設(shè)施的關(guān)鍵設(shè)計；5、技術(shù)自研，是實現(xiàn)金融安全的必要保障。
（三）核心系統(tǒng)建設(shè)的經(jīng)驗總結(jié)
實踐中，我們總結(jié)出一些經(jīng)驗與教訓：
一是做好整體規(guī)劃與設(shè)計。核心系統(tǒng)下移是個復雜工程，在啟動之前需要通過咨詢，為后期建設(shè)做好統(tǒng)籌，避免盲目建設(shè)。
二是打通技術(shù)與業(yè)務(wù)，讓云原生分布式發(fā)揮真正價值，需要參與者對于業(yè)務(wù)及底層云原生平臺技術(shù)都非常熟悉。傳統(tǒng)上應(yīng)用的歸應(yīng)用開發(fā)商，技術(shù)的歸技術(shù)平臺供應(yīng)商的分離建設(shè)模式，已經(jīng)無法滿足轉(zhuǎn)型的需求。我們通過金融級云原生工場模式聯(lián)通技術(shù)與業(yè)務(wù)的鴻溝。
三是技術(shù)運維的挑戰(zhàn)。傳統(tǒng)集中式架構(gòu)的運維保障通常由廠商和生態(tài)來進行，而云原生分布式體系下，整體需要運維的架構(gòu)復雜度遠超以往，需要更多的將運維保障任務(wù)交給自動化、體系化的技術(shù)風險防控體系。技術(shù)風險防控體系的設(shè)計與建設(shè)，需要在早期同步開展。
四是復雜項目的組織管理模式迭代。核心系統(tǒng)的建設(shè)周期往往比較長，大型金融機構(gòu)會在20個月以上，參與方眾多。加上云原生分布式、中臺化、業(yè)務(wù)敏捷驅(qū)動的新型架構(gòu)，對項目的組織形式、具體工作劃分有不同的要求。整個項目工程管理需要采用新的組織理念，通過數(shù)字化的工具來進行組織協(xié)調(diào)，更高效、高質(zhì)量的完成落地交付。
要實現(xiàn)金融核心云原生分布式轉(zhuǎn)型，關(guān)鍵在于打造一套新的云原生數(shù)字化生產(chǎn)線、配套設(shè)計工藝以及穩(wěn)固的云原生分布式基礎(chǔ)設(shè)施，用綜合的視角去變革那些最難的部分，從更高的視角去構(gòu)建智能化內(nèi)核能力無處不在的新平臺，重塑數(shù)字金融的商業(yè)價值。
本文作者劉偉光系阿里巴巴集團副總裁、阿里云新金融&互聯(lián)網(wǎng)事業(yè)部總經(jīng)理、中國金融四十人論壇理事。文章僅代表作者個人觀點，不代表CF40立場。
未收藏
