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