近40年銀行核心系統變遷歷程及新建設模式

本文詳細介紹了我國銀行核心系統的定義、位置與邊界，發展歷程、更換核心系統的原因，以及新核心建設的五大模式與其特點對比。希望內容能夠幫助銀行科技從業者建立起對銀行核心系統的整體認知，提供一定積極的指導作用與借鑒意義，從而引發思考並促進行業交流與探討，共同為我國的銀行科技蓬勃發展貢獻自己的智慧與經驗。

在這裡，特別要感謝張廣老師，對我國銀行核心系統的發展歷程部分進行了完善和補充，特別是關於目前業內流行的分散式微服務組建模式，學到很多。希望後續有更多的小伙伴來分享自己的見解或想法，一起思維碰撞，探索更多可能……

此文分為以下五部分：

一、銀行核心系統的定義與邊界

二、我國銀行核心系統的發展歷程

三、銀行核心系統更換的原因分析

四、銀行核心系統建設的五類原則

五、銀行核心系統建設的五大模式

一、銀行核心系統的定義與邊界

銀行核心系統（Core Banking System）是以處理銀行最基本的存款、貸款業務為主的IT系統，作為支撐業務營運的關鍵系統和銀行信息化的重要組成部分，被稱作銀行IT系統的“心臟”。我們去銀行網點或線上辦理的存貸款業務都是在銀行核心系統中完成的，除此可能還包含客戶、會計、公共等功能。

銀行核心系統在整個銀行IT系統架構中是其他業務子系統的基礎，也與其他系統保持著密切的關係，作為重要的業務處理系統，在整個銀行IT系統中處於承上啟下的關鍵位置。

核心系統在金融服務能力、處理性能等方面，對銀行日常經營的業務與流程優化、提升客戶體驗度、推動業務改革或創新等方面起著決定性作用。

銀行IT系統功能邊界的定義，對於系統的分析與設計非常重要。需要結合銀行自身發展情況與發展戰略進行整體規劃，當有了明確的邊界就清楚了系統分析和設計的範圍，就有了工作的目標和任務。

因此，邊界的定義是明確責任和控製成本的基礎，有助於精細管理，能避免浪費無效的工作時間和精力。試想要是工作沒有邊界，是一件多麼可怕的事情，可能會違背自己的本意做一些職責範圍之外的事，甚至出現扯皮推諉的情況。

在銀行新核心系統設計時也一樣。

因為銀行核心系統會與幾十個、甚至成百上千個其他關聯繫統有進行交互，所以分析邊界要先梳理核心系統包含哪些內容，不包含哪些內容，然後再結合銀行IT系統的整體規劃，儘量做到只處理最基本的核心業務，即單純的交易處理系統。從而保證核心系統的穩定與高效，這不僅增強了系統的靈活性和擴展性，而且還能適應外圍系統的快速擴展。

在科技飛速發展下，銀行核心系統在不同時期面對的挑戰與機遇各不相同，在調整核心系統的定位並設計最優解的同時，經歷著一代又一代的發展與變革。

二、我國銀行核心系統的發展歷程

在沒有電子電腦的時代，當時銀行叫做儲蓄所，專門給儲戶辦理存取款業務。在櫃臺前，由出納和會計人員負責存取業務的現金收付、以及賬本的登記，常常可以看到一堆摞的高高的賬本，一個墨水瓶，一隻填寫憑證的蘸水筆，一把用來記賬和軋賬的算盤……

儲蓄所職員完全是依靠手工操作辦理業務，無論是客戶業務辦理，還是計息結賬、內部往來對賬、編製報表等都靠人工處理。

比如營業時間的存取款，從收錢、點鈔、登折再到另一個人的覆核、簽字、蓋章、記賬，最快也要二三十分鐘；再如每天營業結束後的“扎賬”，若總賬和明細賬沒有扎平，就必須連夜加班查賬找出原因，直至賬目齊平。

圖1-1 銀行辦理業務場景；儲戶的賬本與賬頁

純手工時代的銀行業務辦理不僅耗費大量人力、效率非常低、資金周轉慢、信息不靈通，例如票據或者紙質憑證的傳遞與交互；而且風險控制也是一大難題，比如手工記賬的誤差在所難免、登記憑證或賬本易丟失與污損，甚至是發生火災等問題。

手工時代只解決了能夠辦理銀行業務的問題，顯然無法滿足中國銀行業發展的需要。隨著電子電腦的出現，銀行業進入了電子化的初期階段，通過簡單的模擬手工操作，主要解決了手工操作和業務處理的效率問題。

手工時代留下了很多的名詞和概念，一直到現在，在系統中都還能看到歷史的痕跡。

例如，“台賬”、“登記簿”在手工時代就有相應台賬的賬本或登記簿去記錄一些事情，在用電腦模擬手工時代的做法時，也就將相關概念都引入到系統了；再如“出納”，手工時代區分出納與會計，因此在系統列印的回單上，有時會出現“出納會計”的字樣；又如“儲蓄天數演算法”，手工時代為每一位儲戶計算利息很不方便，為簡化操作和減輕銀行工作人員的工作量，規定了不管大月、小月都是按30天，一年按360天計算利息的演算法，在目前的系統當中還有使用。

在引入電腦之後，即20世紀80年代前期出現了PC單機時代，也稱為“會計電算化”，就是把一部分櫃員手工記錄的內容，特別是會計賬簿和記賬傳票，使用電腦來實現數據的登記和保存。從而減輕人工登記和處理的負擔，加快業務辦理速度，提高工作效率。

通常每個儲蓄所或營業所會配一個PC單機，櫃臺人員會將手工登記的信息錄入到電腦系統中保存，從而實現銀行每個營業網點單獨一套“電子的賬本”，形成了非紙質記賬的方式。

由於還沒有互聯網，每個網點安裝的電腦設備都沒聯網，擁有各自獨立的系統，各個網點分別處理自己的賬務信息，所以沒有通存通兌功能。基本上都是以網點為單位，在哪裡辦理的開戶，就只能在哪裡辦理業務。跨儲蓄所的交互，還是和手工時代一樣走紙質票據或紙質憑證的傳遞，總的來說，是解放了一部分的手工操作，解除了原先很多在紙質上面的記錄。

圖1-2 銀行儲蓄宣傳&櫃員桌上配置了電腦

其實在這一階段已經出現核心系統的雛形，簡單說就是一個後臺會計的登記系統，主要功能有賬務的處理、數據的記錄，以及配套的櫃員操作頁面（即字元終端）與主機連接在一起，沒有計算能力，只是一個顯示屏幕，通過鍵盤傳送輸入要素並顯示輸出。

核心的主要設計思想是以“賬戶為中心”的金融服務體系，就是以賬本為分戶賬來作為整個系統的一個中心或面對的一個對象，因此，賬戶在核心系統當中是唯一的關聯標識，是將所有業務操作和記錄串接在一起的關鍵要素。

由於每個儲蓄所或網點都是單機，所以每個系統都是一個個信息孤島，互相之間不能互聯互通。

比如一個人在同一家銀行有5個賬戶，5個賬戶可能是不同網點辦理的，那銀行的各網點就不能夠總攬地瞭解客戶，無法針對客戶的財務狀況和實際需求提供有針對性的服務。但同時，也為大規模引入全國聯網的系統和業務流程再造打下了基礎。

之後，國內開始建設網路基礎設施，將各網點連起來實現業務聯網區域的通存通兌，甚至發展到以省市級主機為中心，向省外網路連接實現省級互聯互通……這就引出了下一個發展階段——聯網聯機的時代。

存貸匯是銀行的基本業務，跨網點通存通兌最常見，此前跨網點辦理業務會用到票據（如本票、匯票），需要等待銀行之間的票據交換，若幹天後才能完成業務的辦理，對客戶來說時效性和安全性比較差，當引入電腦網路後提升了數據實時傳送的能力。

基於該背景下建設了電腦網路，各個銀行之間不再需要使用紙質的傳遞方式，就能夠通過網路將不同的網點和不同的系統，藉助通信設備和線路建立連接，實現了各地區、各部門、各應用系統之間的數據實時傳輸、交換、資源共用，實現了聯機業務處理和異地跨行通兌。

比如2小時匯款到賬、甚至實時匯款到賬，極大地提升了客戶體驗。在發展到後期，有些地市藉助網路更進一步，產生了區域性數據集中一種做法。

相當於網路建立起來後在某個地區設置一個區域性主機，讓區域性主機提供統一的核心系統後臺服務，網點僅保留櫃面操作的模式，因此順勢出現了核心系統和櫃面系統的分離。

圖1-3 那時的ATM界面；新版電腦

與此同時，自動櫃員機（ATM）開始大量出現，主要用於辦理存入、支取或查詢交易的業務。在國家的指導下，成立了以電腦、通信等現代科技為基礎和銀行卡等為介質的“金卡工程”並開始實施，通過電腦網路系統，用電子信息轉賬的形式實現貨幣流通。金卡工程首批12個試點省、市全部實現了同城跨行ATM/POS聯網運行和信用卡業務聯營，自93年金卡工程發起到97年底，已發行了5萬多張卡。

對銀行來說，主要是出現了一種叫銀行卡的交易介質，不僅針對某一家銀行可以使用，而是能全國通用。這一轉變將銀行服務網點做了很大的拓寬，原先的儲蓄所變化為在人流量較多的地段設ATM機，甚至借用其他銀行的ATM機也可以提供相應的服務。

由此，銀行開始陸續出現除櫃面之外的電子渠道，銀行核心系統的設計理念也發生了變化。在銀行業飛速發展的進程中，隨著我國經濟建設發展、改革開放的不斷深入和即將加入的世貿組織，進一步加快了商業銀行電子化建設的步伐。

為迎接加入世貿組織的挑戰與機遇，提升數據和技術力量的分散、業務處理缺乏標準規範、軟硬體資源不共用、管理水平不平衡等問題導致的負面影響；加上電腦的硬體設備能力在不斷提高、網路質量越來越好、網速越來越快等原因，數據大集中應運而生。

簡單的說就是原先區域性的數據集中，但對客戶來說，同一家銀行是一個整體，任意網點都應享受同樣的金融服務；對銀行來說，將客戶在各網點的信息彙總起來用於風險評估或評級，不僅能節省銀行的管理成本，而且有利於對客戶有更全面的瞭解後提供更好的金融服務。

數據大集中是各銀行根據自身情況對數據和業務進行不同程度的集中處理。例如，將分散的省級數據中心的數據和業務集中到國家級的數據中心，實現系統基礎架構、物理伺服器、數據和應用建設的集中。

數據大集中使總行能夠集中全部研發力量，從而避免低水平的重覆開發，節約系統管理、軟體維護及升級的費用；使總行能夠得到準確、實時的數據，全面地瞭解到各分行的工作進展情況，以免增加不必要的後繼溝通成本；使總行能夠通過分析交易數據與交易行為，提升整體服務水平，減少因信息不對稱而導致的銀行風險管理失控或業務機遇喪失。

因此，國內商業銀行開始重視規模化經營，掀起了一場以數據大集中為主線的技術革命和業務變革。同時也造成核心系統的數據量呈指數級增長，原先是一個地區或單網點的數據，經全國大集中之後數據量翻了10倍，甚至100倍併在一個系統中承擔，而且系統可能要使用十年左右時間，對當時的系統設計來說是一個極大的挑戰。

故各家銀行引入IOE（IBM、 Oracle、EMC）模式，以總行業務集中化、流程規範化為目標持續改進。儘可能多地將業務納入核心系統的統一管控並兼顧各地方特色，同時綜合櫃員制被普遍採用，打破了記賬到出納的原有業務辦理模式。

圖1-4 營業廳實行高櫃與低櫃；電腦在普遍使用

1999年9月1日，工商銀行提出了以“9991”工程命名的大集中工程，用了3年時間將全國各地36個計算中心合併，建立了兩大數據中心，即在北京上海建立了兩大互相備份的數據中心，是我國數據大集中的里程碑工程。

2004年9月25日，工商銀行通過數據中心整合工程的實施，將北京數據中心主機生產系統順利遷移至上海，全行業務集中到上海數據中心處理。還完成了澳門、新加坡、東京、漢城、香港等亞洲地區省外分支機構數據的集中處理。

2002年7月1日，建設銀行啟動了為期3年的數據集中工程（DCC）項目，按期完成全行38個一級分行和總行營業部的全面上線，併在業務發展方面統一了全行會計核算和櫃面業務應用版本，提高了跨區域交易和清算的服務質量，加速了全行的頭寸管理和資金調度，實現了支持後臺集中運行的業務模式。

截至“十一五”末，各大商業銀行、全國性股份制銀行、省級農信等經過了大約十年的時間，全國性的各家銀行幾乎都完成了省級集中或是全國數據大集中，將分散於各分行的業務數據集中至數據處理中心。

隨後，銀行業開始高速擴張物理網點和開始新一代渠道的建設，在代銷基金、保險、代收代繳等業務開拓方面加大投入力度。特別是網路銀行、電話銀行、自助銀行、移動銀行等方面形成了新突破，不再是以各渠道相對獨立的思想來建設。

隨著渠道多樣化的發展，市場對銀行業務辦理支持7*24小時不間斷處理提出了更高的要求，因此7*24小時在當時的系統設計中是一個熱點。

同時數據集中化在不斷發展，客戶信息都集中到了總行，系統中可以看到客戶的全貌，並對客戶進行數據分析，所以“以客戶為中心”的新概念伴隨著業務轉型而陸續出現。

經過全國大集中的建設，伴隨著系統長期運行，逐漸暴露了一些問題。主要是核心系統越來越龐大，因為全國大集中後，核心系統納入了各地區的共有功能之外，還包含了每地區的特色功能，導致系統耦合嚴重，形成了所謂的“胖核心”。

不僅限制了業務發展，還增加了建設和運營成本，每次修改都感覺牽一發而動全身，而且開發新功能時會發現改動與評估內容很多，開發耗時越來越長，無法做到快速的響應業務變化。

例如，無法快速推出有特色的產品響應市場需求來吸引客戶；再如，因系統內部改動較大而無法給優質客戶提供個性化利率；又如，因營改增的業務需求而導致記賬規則的調整，需要在核心系統內部做手術，不僅需要投入大量的人力物力，而且風險很大，如果賬務核算是一個相對獨立的系統，那麼就不會帶來核心系統巨大的改動量，也不必為此承擔大的風險。

究其根源，該階段的銀行核心系統其實也叫“綜合業務系統”，不管是什麼業務，都放在這系統中實現，只是將渠道端單獨分隔開，但後臺的處理功能全部綜合在一起，用一個系統去完成銀行的各種業務，這就必然導致成為大而全的系統，難以維護。

為瞭解決系統龐大耦合的問題，業內一致開展了核心系統瘦身的運動，喊出了“瘦核心、大外圍”的口號，驅動了將核心系統的輔助功能都剝離到外圍系統。

圖1-5 叫號系統被廣泛使用；智能設備遍佈網點

從系統結構上來說，首先從核心系統中拆分的有管理類功能，建立各類管理系統。比如信貸管理系統、財務管理系統、櫃員管理系統、額度系統，將辦理業務前需要做的評級與審批類的管理性工作，拆離核心作為管理功能，也就是在完成各種管理性質的動作並通過後才說明能夠辦理該業務。所以可以拆離核心，只留下一個小而精的核心系統來處理核心業務、內容單一，核心系統通過介面與各管理系統連接，傳遞信息或進行相應的管理控制。

其次，從核心系統中拆分的有統計分析類功能，建立數據倉庫。因為系統對數據進行分析與加工很消耗系統資源，而且也並非交易過程中急需使用的內容，可以在交易結束、獲取數據之後再進行分析，通過數倉去解決耗資源的問題，不要讓其影響整個業務系統的運轉。例如，通過數據分析給客戶打標簽，標記普通客戶、優質客戶、VIP客戶等。

還有，需從核心系統中拆分出報表功能。數據經過統計分析之後，需要給監管報送或給行內出具各種報表，既然統計分析類功能已剝離核心，那對於報表也要建立單獨的報表系統進行加工與報送。

最後，還有第三方對接類的功能也要從核心系統中剝離。早期銀行只會辦理自身支持的業務，但隨著網路的發展，銀行與第三方的連接或是與第三方實時交互的功能越來越多，比如代繳水電費。

為提升系統間的交互效率，就出現了連接第三方的各類前置系統，以及專門做中間業務拓展的中間業務系統，使得行內能建立統一的交互管理標準。例如，建立了ESB服務匯流排、建立了ECIF全行級客戶信息系統實現行內客戶信息統一共用等。

甚至一些激進的銀行，將核心系統中的賬務內容也相應分開，比如建立貸款系統、存款系統、或是互聯網核心系統等，並配套總賬系統來彙總處理各賬務系統的會計流水。因此，在核心系統瘦身階段後期，逐漸出現了“大總賬”的概念。

除功能瘦身外，核心系統的整體設計理念也全面轉向“以客戶為中心”。例如，指定編碼規則生成系統唯一的客戶號，再通過客戶號管理同一客戶下的所有賬號，建立統一的客戶信息視圖，打破原有客戶群各自封閉的情況。並將客戶之間的關係進行歸集（比如針對集團客戶可歸集其下轄各子公司的賬戶），實現客戶與賬戶的多層級管理，掌握客戶每筆交易的資金動態和流向等。

以客戶為中心（複雜的關聯關係），如下表：

圖1-6 複雜的關聯關係

除了“以客戶為中心”之外，還引入了產品工廠、定價模型等參數化、配置化的設計思想，大大提升了銀行核心系統的靈活程度與健壯性。

通過系統參數的靈活配置實現產品特色化，通過對客戶需求的聚焦，進而對指定客戶群或是個別優質的客戶提供有針對性的服務，比如提供利率、費率及匯率的差異化定價，在吸引新客戶和留住老客戶的同時，也為今後業務的發展奠定了堅實的基礎。

此時的銀行核心系統仍處於全國大集中的階段，在2015年後，業內才逐漸進入了分散式微服務時代，採用了新的互聯網思路去構建銀行核心系統。

2015年作為民營銀行元年，網商銀行於2015年6月、微眾銀行於2015年9月正式開業。擁有互聯網基因的民營銀行，與原先以大型主機為主的全國大集中時的系統建設模式不同，採用了去IOE的分散式微服務架構來建設核心系統，給行業提供了一種新的設計思路，同時對傳統銀行也產生了較大的觸動。

其次是近年來，在監管要求和鼓勵國產化的大力推進下，如2017年中國人民銀行發佈了《中國金融業信息技術“十三五”發展規劃》，明確提出“以安全、可靠、高效、彈性為重點目標實施架構轉型，探索分散式架構和成熟開源技術應用，逐步減少或擺脫對單一技術產品的依賴”，因為國產化在大型主機為主的方向上有所缺乏，所以在尋求新的建設方向上多了一個選擇，分散式核心系統出鏡率越來越高。

圖1-7 網商銀行；微眾銀行

分散式核心系統與集中式核心系統是相對的，有好幾種組建模式，接下來逐一闡述，還包括分散式微服務的核心與以往傳統核心系統的區別。特別值得註意的是，分散式和微服務兩個詞經常是同時出現，但卻是兩個不同的概念，不能混為一談。

分散式是指核心系統對存儲數據使用多機進行分片（即資料庫的處理）,原先的單機系統或上一代的核心系統，對於數據來說是存儲在一個資料庫上，單機系統的存儲空間受限於硬碟或上限，若要支持海量存儲則價格非常昂貴且存儲性能也有一定上限。

其次，CUP和IO也受限於單機系統本身的資源限制，若是用多機分片就可以將單機器的工作分散在多台機器上，那就可以根據數據量的規模做橫向的擴展，使用計算能力稍微差一點的機器通過拼數量的方式做到海量數據的及時處理；還需避免單點故障，或者說機器突然之間變成不可用，那會影響整個系統的所有用戶、客戶及賬戶等。

因此，分散式目的有兩個：一是突破單機系統的數據存儲和數據處理能力上限，使得數據量規模可以橫向擴展；二是分片後減小單台機器設備突發故障的影響面，使得一個故障隻影響一個分片的機器，而其他分片可以照常處理。這樣就不算系統整體中斷服務。

分散式銀行核心的功能主要是針對於數據存儲，提高了銀行系統運轉的健壯性或可用性。而微服務是另一個著眼點，抽象地說是指核心系統應用程式的一個部署與拆分的模式。

具體的說是指核心系統按照功能模塊進行服務拆分，原先可能是將各個模塊的所有程式全部打包在一起，作為一個整體去運轉，再按照微服務拆分之後，只需要按模塊進行相應的服務拆分，拆成一塊塊小的包，然後對每一塊做單獨的打包並部署在不同機器上，目的是解決模塊間的耦合問題，用來降低系統修改時的影響範圍和難度。

從銀行核心系統的資料庫方面看，分散式的發展經歷了以下幾個模式：

1）應用資料庫一體化模式

應用資料庫一體化是核心系統最早期的模式，如PC單機和最早期大集中階段，核心系統的應用程式作為一個整體部署和運行，與數據存儲（即主機的文件系統或開放平臺的資料庫）合在一臺高性能機器上。

因為應用和資料庫在同一臺機上運行，所以應用模塊之間的調用，屬於程式內的函數調用，應用進行資料庫操作屬於本機訪問。

在該模式下，本地調用消耗最少、單筆交易的處理耗時也非常短、交易響應速度很快，當然，對高性能機器的壓力也相當大，既要處理資料庫文件也要處理應用程式的邏輯計算，若是在機器性能不太夠的情況下或交易量提升後，容易形成資源爭搶。

IBM大型主機即此類模式，優點是應用與數據文件一體化，應用直接操作底層的數據文件，數據隔離層數越少那麼訪問效率越高，因此單機處理可以達到很高的性能。

圖1-8 應用資料庫一體化模式

2）應用集群、資料庫集中模式

基於模式一資源受限的背景下，誕生出了應用集群、資料庫集中的新模式。簡單的說，就是應用與資料庫分離成不同機器部署，資料庫仍用一臺高性能的機器，應用程式作為一個整體在其他機器部署運行。

由於應用程式不帶有任何狀態，因此可以一模一樣的複製多台機器，儘管應用程式有可能會併發量很大，但可以堆小的機器來實現負載均衡。因為對於一筆交易來說，不管路由到哪台機器上執行應用程式，最後都會落到資料庫上，最終交易的執行效果都一樣。

此模式下，由於將資料庫與應用分離，降低了資料庫機器資源的爭搶，從而提升了單機處理資料庫的能力；而應用集群部署，提升了應用的橫向擴展接入能力，解決了應用的單點故障，因為一臺應用程式的機器出現故障，會路由到其他應用程式上繼續執行交易，所以對整體系統來說沒什麼影響。

但由於應用程式跟資料庫拆分之後，會使得應用每一次訪問資料庫都會變成一次跨機器的網路訪問，那麼單個交易訪問資料庫次數越多，耗時延長狀況就會越嚴重。

對一筆普通的賬務交易而言，確實存在操作幾十上百次資料庫，所以彙總起來的消耗相當大，在業內通用的處理方式是：儘可能在銀行內建設萬兆網路，用高速的網路減少網路的消耗，其次是儘可能地想辦法減少應用程式訪問數據的次數，比如在應用程式端引入緩存，那對於相同的數據就無需多次訪問資料庫獲取數據了。

圖1-9 應用集群、資料庫集中模式

接下來我們繼續看下一個模式：應用集群、分散式資料庫的模式，這時出現了分散式資料庫。

3）應用集群、分散式資料庫模式

前兩種模式的資料庫都是單機的，那麼資源會存在上限，為瞭解決資料庫資源上限的問題，就需要將資料庫拆成多個機器來處理，那就出現了分散式資料庫。

接下來繼續看第三模式：應用集群、分散式資料庫，即資料庫與應用分離成不同機器部署。就是說採用分散式資料庫，應用程式搭建集群在其他機器部署運行。

圖1-10 應用集群、分散式資料庫模式

如上圖，分散式資料庫可以對資料庫劃分若幹分片、內部是由多台機器組成的，但對應用程式而言（即對外展示）是一個整體，表現和單個資料庫一樣。因此分散式資料庫作為一個資料庫軟體來說，自身保證了內部的事務的一致性和可見性，且作為一個整體，也做到了資料庫內部的整體備份和恢復。

在此模式下，使用分散式資料庫解決了模式2的資料庫橫向擴展和單點故障問題，對應用程式來說，與模式2相同，改動也是相對來說比較小的一種模式。

截至目前，國內銀行核心系統當中採用分散式資料庫，已經有些實際的案例了。早期在項目實施過程中比較擔心的就是分散式資料庫概念太新，能否運用在實際工作中，或是到底好用不好用等。

銀行核心系統使用國產資料庫案例，如下：

圖1-11 銀行核心系統使用國產資料庫案例

作為分散式資料庫的方案來說，也有一個成熟的過程，在使用的越來越多、解決問題也會越來越多的情況下，會逐漸逐漸的變得更加成熟起來。因此該模式從理論上來看，確實是一個可選方案，也是一個相對來說比較好的方案。

4）單元化模式

在上一模式中介紹的分散式資料庫模式，是由分散式資料庫內部做切片，而單元化模式的資料庫與應用分離成不同機器部署，是從系統規划上入手，採用普通資料庫按照hash或者range切片的方式將資料庫切分成表結構完全相同的若幹份，每一份都是一個普通的資料庫，那應用程式要和資料庫分片做相應的綁定。

也就是說，每一份都有應用集群與之對應，可以理解為都是一個完整的核心系統，只是資料庫分散的是一部分數據。

圖1-12 單元化模式

如果一筆交易當中要處理多個分片的數據怎麼辦？

那這時就要採用跨機器的網路外調方式，在應用程式之間進行相應的交易或程式的調度，同時對應用系統提出了更高的要求，需要應用層要實現分散式事務的管理，達到一致性的要求。

原先是一個資料庫連接裡面所有的操作都是由資料庫保證它的一致性，但在單元化的模式下資料庫無法實現一致性的要求，因為有很多個跨應用程式的調用，所以只能應用層實現。

另外，在該模式下無法做到像原先單機資料庫一樣指定時間點對所有的數據（含已完成或已提交的交易）做完整的備份或恢復，因為單元化模式下每個切片都是一個相互獨立的資料庫，所以做不到整個核心系統數據同一時點的一致性備份和恢復。

下麵就進入微服務部分，微服務的概念是互聯網公司提出併發展起來的。互聯網和銀行早期一樣，初期規模較小時，業務單一就一個系統，隨著逐漸發展，業務越來越多，因此系統就發展成類似銀行綜合業務系統一樣大而全的系統，也同樣遇到了銀行數據大集中時期相同的問題。但互聯網有一個特點，就是IT系統都是自主開發，沒有外購。

於是，綜合業務系統的拆分，就形成了微服務的框架模式，即使用相同的技術棧，去建設一個個獨立的子系統，運行於同一套框架體系內。這樣更有利於公司內部人員的復用、以及基礎平臺的復用。

而銀行瘦核心，其實做也是做的同樣的事情，只不過銀行選的路線是從各個廠商外購成熟產品再進行客戶化開發，因此也就很難以一套應用框架去要求各家廠商，因此銀行形成的是SOA系統互聯的體系。

接下來就從核心系統的應用部署的角度看，微服務的結構經歷了以下幾個模式：

5）應用整體打包模式

首先介紹最早期的核心系統應用整體打包模式，如下圖可以看到核心系統的應用程式，雖然分了很多模塊，但是最終編譯打包成一個可執行程式運行。

啟動應用程式時，所有程式就都啟動了，當一筆交易當中發生跨模塊調用時，都是在可執行程式內發生函數調用去執行的，因此模塊之間沒有任何邊界，可以直接調用。

圖1-13 應用整體打包模式

在此模式下，模塊邊界比較模糊，程式跨模塊使用也沒有阻礙，特別是維護階段時間長了，非常容易逐漸形成系統耦合。

6）應用模塊打包整體運行模式

為減少應用模塊之間的耦合，從而做到模塊間邊界清晰，因此產生了新的模式，要求各模塊分開編譯打包，不允許跨模塊直接調用，若要跨模塊訪問必須使用外部函數介面聲明的方式明確程式功能的所屬模塊，也更容易梳理各模塊的內部功能與對外需提供的服務，及程式之間的調用關係和定位；

其次是通過模塊分別打包編譯的強約束，來解決這個耦合性的問題。

圖1-14 應用模塊打包整體運行模式

在該模式下，模塊邊界清晰，代碼不可能混入其他模塊，模塊間調用需要使用外部函數介面聲明。通常編譯時是打成一個個不同的包或一個個不同的庫，但最終在一個主框架內載入所有模塊運行，模塊間調用仍屬於進程內部調用，因此調用效率很高，可以讓資料庫連接、分散式事務等全局部分在各模塊共用使用。

7）應用微服務模式

最後一種是業內最近常見的應用微服務模式，可以理解為是將銀行核心系統的應用程式按照模塊分別編譯、打包，打包成這種可執行程式然後每個模塊分別部署運行。

需要註意的是，資料庫與應用程式一一對應，各模塊分別部署時所訪問的資料庫也會相應地拆分出來。

圖1-15 應用微服務模式

如上圖，黃框代表一個一個單元或微服務的機器，每個框都是一個整體，比如應用模塊1對應著模塊1資料庫、應用模塊2對應著模塊2資料庫。若一筆交易通常會涉及到多個微服務調用時，那就需要在微服務框架內進行跨模塊的遠程調用，並由應用實現分散式事務來保證一致性，與單元化類似。同樣，也做不到整個核心系統數據同一時點的一致性備份和恢復。

值得註意的是，微服務的分散式事務一致性，目前在業內通常使用的有SAGA回沖模式和TCC回沖模式。

SAGA回沖模式是指挨個模塊逐一調用，若調用有問題或失敗則調用沖正，比如先調第一個、再調第二個、再調第三個...如果第3個出現問題或調用失敗時，則反向回沖，即調用第二個沖正、再調第一個沖正等。TCC回沖模式是指不是將整個交易做完，而是先做預處理，先做模塊1的預處理、再做模塊2的預處理、再做模塊3的預處理...如果全部都成功後，再依次做模塊三的確認、模塊二的確認、模塊一的確認，如果當中出現問題或失敗，則做模塊三的取消、模塊二的取消、模塊一的取消等。

SAGA和TCC兩種回沖模式均為最終一致性，即整個業務處理完成後才能保證整個是一致的。對資料庫事務而言，每一步的事務都會先做提交，等到後面出現異常再做回沖或取消，那多個併發時，可能出現讀取到其他併發才處理了一半，最終不一定成功的數據。

比如說執行流程有步驟1、步驟2和步驟3，當系統執行到步驟2，此時步驟1已提交。但是其他併發讀數據時會發現，讀到的是步驟1處理過的數據，但實際上，前面的步驟1最終的結果不一定是成功的，因為還有後續步驟未執行完，如果後續步驟失敗之後則被回衝掉。所以併發讀到的是一個不准確的數據。該場景在早前的單機資料庫中叫讀未提交，就是還未提交最終提交的數據會被讀到，在銀行核心系統中是不允許出現的，因為會造成業務邏輯判斷的失誤。

因此使用此種模式要小心，需編排交易流程步驟，在交易層調度各微服務，並精心組織調用順序，以保障銀行業務安全的順序執行。

比如先做對銀行安全的步驟再做對銀行不安全的步驟，要儘可能讓別人讀到的是對銀行安全的數據，就好比原先支付系統跟核心系統的交互，通過先核心記賬再付款的方式。

另外，要特別避免帶事務的深層次嵌套微服務調用。

三、銀行核心系統更換的原因分析

介紹完我國銀行核心系統的發展歷程，銀行可以結合現有系統的使用情況以及產品和服務革新需求、轉型急迫性等方面，全面掌握自身所處的狀況並結合當前基礎設施、市場動態、客戶需求和組織能力等方面，決定銀行核心系統的實施路徑。

例如，觀望（不作為）、升級（涉及較小的應用程式功能或技術變更）、重構（主機下移或轉Java等提升系統的現代化）、增強（部署一個並行的核心系統運行一系列的差異化服務）、更換（以現代化的解決方案替換現有核心系統，即建設新一代核心系統）。

圖1-16 我國銀行新核心建設情況（2017-2021年）

針對更換核心系統的原因，站在銀行的角度進行分析，主要從以下維度進行思考：

• 功能：系統技術非市場主流，與主流技術對接產生障礙；因為銀行的合併，現存的任何一個核心系統無法對應不同文化的銀行多樣應用系統整合的需求；

• 風險：每一代的銀行面對的社會經濟活動不同，對系統的架構與應用要求產生結構性的影響，必須以重建的思維從根本解決；業務規模（業務量、經營範圍）擴大，舊系統無法應對；

• 運維：舊系統廠商退出市場（硬體、軟體）；因為希望合併迅速整合完成，急急忙忙地系統整合，導致舊系統降低服務水平，縮短原系統壽命；核心系統生命周期，因為科技與社會經濟活動改變而逐漸縮短；

• 成本：舊系統的應用系統時間久了打滿補丁，新的需求開發費時費力；舊核心系統成本貢獻比逐漸升高，特別是主機型系統用戶；

• 收益：核心系統經營管理模式隨著科技與應用的改變，產生多樣的核心系統經營方式可供銀行依據自身條件（規模、人力、成本、效益）選擇（自建、購買、托管）；

• 組織：舊系統開發、維護人才逐漸凋零，藉著新系統的開發培養下一代的接班技術人才。

四、銀行核心系統建設的五類原則

銀行的金融交易涉及到客戶資金運轉，在國民經濟發展中處於特殊重要地位。所以銀行的業務特性決定了銀行對交易和數據的及時性與一致性要求非常高，必須準確、不可丟失，安全性、可用性、可追溯，更是互聯網金融企業無法比擬的。

例如，對於外匯業務，利率的實施變化決定了相關業務要實時相應，如果時效性、準確性達不到要求，就會給客戶或銀行帶來損失。再如，在證券行情實時變化時，銀證轉賬如果不能滿足要求，可能會給客戶帶來巨額損失；一些大額的轉賬或匯兌如無法滿足時效性及一致性，可能給客戶的資金使用帶來風險。當然，互聯網企業的優勢（如海量服務能力、註重客戶體驗、大數據服務能力等）也是傳統商業銀行轉型必須具備的。

及時性是指要及時響應客戶的交易行為，避免可能帶來的損失。因為銀行系統的處理能力與銀行規模和科技投入有關，所以主要從銀行核心系統的幾個關鍵指標來瞭解自身發展情況和目標，如響應時長、每秒事務處理數、每秒請求數等。

• 響應時長（RT）：從發出請求到得到響應的耗時，即從前端界面按交易提交鍵、到處理結果並反顯全部信息到前端界面之間的時間間隔。一般可以採用毫秒單位來表示，而對一些RT比較敏感的業務場景下，可以使用精度更高的微秒來表示。

• 每秒事務處理數（TPS）：每秒能夠處理的事務數，其中T(Transactions)可以定義不同的含義，它可以是完整的一筆業務，也可以是單個的介面請求。

• 每秒請求數（RPS）：也可以叫做QPS，但它與TPS有所不同，前者註重請求能力，後者註重處理能力。不過，若所有請求都在得到響應後再次發起，那麼RPS基本等於TPS。

• 資料庫性能：指的是有關資料庫的指標，比如資源超時、資源死鎖、資料庫連接、記憶體泄漏等。

在分散式銀行核心系統中，一致性是指數據在多個副本之間能否保持一致的特性。在一致性的需求下，當一個系統在數據一致性的狀態下執行更新操作後，應保證系統的數據仍然處於一致。提到一致性就離不開分散式事務、緩存等，就不逐一展開了。

安全性是指通過信息安全建設和管理，有效控制和防範信息安全風險，確保企業與客戶的信息及資金安全。主要包括機房、網路、數據、系統、制度等安全方面進行保障。

高可用是指系統提供的服務必須一直處於可用的狀態，所有處理環節避免單點故障，當故障發生時可以快速恢復，如果在故障發生時具備故障隔離或備災備容錯能力，如多活並行處理、兩地三中心等，RPO（Recovery Point Objective，恢復點目標）、RTO（Recovery Time Objective，恢復時間目標）等指標無限趨近於零。

如下表：

圖1-17 不同災難恢復能力等級下的RPO和RTO

圖1-18 可用性及衡量標準

可用水平（%），通常都包含了信息系統計劃停機的時間，即為了系統維護、新版本投產等原因，人為主動的讓系統停止對外提供服務。因此，要提高可用水平，需要減少系統的計劃停機時間。

可追溯是指金融交易的所有業務操作都要保留日誌數據，做到信息流的可查、可追溯、可審計，也是監管的要求。

五、銀行核心系統建設的五大模式

在銀行IT系統中，銀行核心系統建設是整體支出占比最大、最為複雜，對於技術要求最高的工程，需要持續投入非常多的資金與人力資源，而且還涉及到全行各關聯繫統的配合或同步改造，項目建設周期往往少則一年，多則兩三年。

採取什麼樣的模式來建設新核心系統，如何在本行能夠承受的前提下投入財力和人力，使系統建設既能對標同業又要符合實際發展情況，並能夠滿足未來銀行業務快速發展的需要，一直是一個困擾許多銀行決策層的難點問題。

銀行新核心系統的建設模式大致可分為五種，分別是外購或外包產品、完全自主研發、主導研發、項目研發外包和應用系統托管。對於採取哪種研發模式，需要綜合考慮諸多因素擇優選擇，切不能一概而論。在規劃中要提前明確和定位建設模式、合作伙伴以及維護方式等。

通常是銀行自身IT有強大的技術能力的大行，研發團隊越成熟，越應該走自主研發的道路。反之，中小型銀行的自身IT規劃能力及建設能力不太強，並要支持下一步的業務創新及快速實現業務需求有一定難度，採取外購外包模式，與合作伙伴共同實施核心系統建設是一個更好的選擇。不僅銀行可以用更低的成本獲得更好的技術和服務，並可以使自身在人員缺乏的情況下，將更多精力集中在需求分析設計、項目規劃與服務監控上，從而更好地推進核心項目的建設。

另外，銀行核心系統產品從縱向解剖，自底而上通常可以分解為基礎設施、技術平臺、應用模塊三大部分，越是基礎的越能通用，越靠近應用越要定製，否則做出來效果不好，並且結合外包、自主研發多維度統籌考慮。

對於科技力量薄弱、自身研發能力不足，業務規模在一兩年內甚至幾年內預估不會爆發增長的小銀行，採取外購或外包產品的模式更加合適。它們沒有多少IT人員，忙於日常如協助各個部門查數據、列印報表或結單、分析生產問題，或承接以運維類、報表類等低價值開發工作為主，沒有多少剩餘時間進行研發與創新、甚至是學習或吃透其服務商產品的做法或優點。

除了外購產品更成熟或先進之外，銀行核心系統上線或更換速度更快，比如偏互聯網銀行基本保持在半年內，主要還是相關項目由於是新做，沒有負擔，所以周期短。

還見過銀行直接外購整個銀行IT系統，拆除科技部，直接將信息科技的運維都外包給相關的機構，也是一種更經濟的可選擇的方式，或者一種過渡的方式。

當然，有利必有弊，該模式需認真分析以下三點：

1）是否適合國情、行情

銀行核心系統是一家銀行的引擎、發動機，也是一家銀行科技實力的重要體現，同時也服務於銀行的戰略、業務和組織架構、以及監管政策和法律法規。而不同國家、不同銀行有非常不同的目標、形式和歷史原因。例如，國內外的核心系統差異巨大，直接拿來使用可能會水土不服。

2）差異化開發及維護成本

外購的產品通常要適合本行特色業務，從而進行差異化開發或修改，差異化需求越大越多，修改和測試的工作量就越大，可能會影響上線期限。當系統上線進入了維護階段，服務商會有半年到一年的免費維保期，但對新增需求的分析、設計、開發等方面要單獨算費用，因為過渡依賴存在不確定風險，故議價能力很弱。基本上是，維護成本占了系統建設整個生命周期所需費用的大頭。

3）系統間整合

指的是系統之間沒有統一的數據標準，使得銀行的數據信息零亂分佈，既有冗餘又有缺失，或數據更新不同步，數據一致性無保障。比如有些銀行將核心系統進行拆分，單獨外購貸款系統或分散外購，不同的廠商框架或標準不一樣，若沒有統一標準或長遠規劃，不可能提供高質量的信息服務。

該模式適用的銀行範圍有：部分中小城商/農商、民營銀行、外資銀行，而且部分銀行會要求產品能簡單部署在雲平臺上，在自主可控方面陸續要求集成國產資料庫。當然，有相當研發能力的金融機構也不是絕對不能外購。

項目研發外包模式使用較多，是指“外購產品+改造實施”的方式建設新核心，也可稱為項目外包，即在服務商的業務與技術人員入場前，確定好外包範圍和外包金額，銀行方不再太關註外包公司實際投入資源，而是重點關註項目質量和進度。

在項目實施過程中，銀行會根據里程碑計劃的執行情況和行內自主掌控要求，選派不同程度的人員參與需求分析和設計及評審或部分開發工作，具體的研發還是以服務商為主。

服務商目標和責任明確，銀行方投入精力小，有利於銀行擁有自主知識產權或者是共有知識產權。缺點是立項採購拉長了項目實施周期、銀行自有研發規範較難落實、項目質量受制於服務商實施團隊的能力，多家外包伙伴時溝通成本較大。

隨著銀行規模增大，可能還會衍生出多家服務商合作外包的方式做項目，降低對單個服務商的依賴，將可能造成的損失降到最低。

在項目前期，通常還會增加咨詢公司對本行的業務進行梳理和優化。銀行對自身業務把握清晰，但對未來發展和業界的領先實踐無法與咨詢公司相提並論，只有通過專業的理念和服務將業務分析透徹，才能很好指導後期的系統設計與開發工作。

其次，核心系統項目建設牽涉到銀行很多部門和組織，難免會有利益衝突與工作的協調配合，藉助第三方專業的視角和可觀的角度能更高效的協調和解決問題。

該模式適用的銀行範圍有：部分中大小城商/農商，其主要訴求是替代掉原有的老舊核心系統，建立起產品的業務模型和架構建設，在自主可控方面部分銀行會要求集成國產資料庫。

對於大型金融機構來說，銀行IT在逐步去外包化，儘管還存在外購系統的情況，但更多的是希望能掌控系統從而解決外購系統的重重束縛，或是完全自主研發代替外購或外包產品。為積極響應國家對金融核心領域技術自主可控的要求，銀行IT走自主研發的道路是必經之路。

不僅能完全使用本行的戰略、業務和組織架構，而且國內金融IT廠商技術力量相對薄弱，很多高水平畢業生不做外包，當行里研發隊伍的規模和素質達到一定程度，系統上線周期會快於外購系統。

算上研發人力費用、固定資產折舊、辦公費用、系統維護成本等，從整個產品生命周期看，自主研發總成本通常要低於外購產品。

該模式適用的銀行範圍有：國有大行、股份制、大農信、部分中大城商/農商行，大多數原有核心採用AS400或大機的銀行希望採用重構的方式完成核心下移，部分銀行會要求基於雲平臺進行核心系統重構，在重構的規劃或過程中強調自主控。

除了大型商業銀行，其他銀行規模相對比較大，研發團隊有較強的研發能力，但不具備完全的自主研發能力。那麼，可以採取介於完全外購外包與自主研發之間的近自主研發的系統建設模式。

主導研發包括自主定義系統的架構、數據標準、介面標準、數據交換規範，以及系統設計、資料庫設計、流程設計等，項目與技術經理要由銀行研發人員擔當，便於日後能主導所有系統維護工作。

銀行進行外包採購的是“人力外包（俗稱買人頭）”。人力外包是以人力勞動時間為主要目標的外包方式。一般以開發工時為結算依據，銀行負責選人、分派任務、結果驗收。

其優點是項目可快速進入實施階段、使用人工靈活，有利於自主掌控，研發規範管理更好，知識傳承和連續性保障較好。缺點是銀行的管理難度高，外包人員流動性較大、缺乏對團隊的歸屬感和認同感。此外，如何客觀評價外包人員的勞動效率也是一個難題。

在人力外包的情況下，衍生出了新的形式用於嚴格規範對人力外包的管理，防止外包人力工作量不飽和。

比如以任務單的形式實施小微型項目外包，便於對人力外包的事前控制，要求從外包資源池中申請外包人力時，必須提出具體的工作內容和預估工作時長，並形成研發任務單。同時，管理難度有增加，需要明確評估每一個任務的工作量。

上述提到的四種核心系統建設模式，基本都是一個銀行擁有一個自己的系統。還有一種模式是“應用系統托管”，可以理解為多法人機構共用的核心系統。

對於中小型金融機構或新成立的銀行，要新建一個僅供自己銀行使用的核心系統併進行日常的運維不容易，所謂麻雀雖小，五臟俱全，總體投入成本較大。

因此，2009年左右出現了銀行間共用合作平臺，各參與行共同建設，從調研論證、項目立項、需求分析、開發、測試到上線後的運維，成員行公共參與並實踐，因此減少了研發過程中的重覆開發，節省掉研發費用後均攤成本，將用戶利益做到最大化，最終為金融機構提供各種所謂金融服務。

隨著涉及金融雲服務的快速發展，雲服務企業已成熟，如山東城商行聯盟、興業銀銀平臺、神碼金融雲等，其應用系統托管的模式幫助中小城商行、民營銀行解決了發展過程中各種各樣的難題。

結語

關於我國銀行核心系統定義、邊界與位置，我國銀行核心系統整個發展歷程、更換核心系統的原因和原則，以及新核心的建設五大模式就介紹完了。

相信對於初學者來說，已經逐漸建立起了對銀行核心系統領域的整體認知、搭建起了屬於自己的第一層級知識樹。對行業同仁來說，對目前銀行核心系統發展到分散式微服務的模式有了更深的理解，當然很多實現的模式所帶來的問題與機會需要繼續思考，也包括業內各大服務商正研發的雲原生核心系統等，都還需要在實踐與使用的過程中不斷研究與探索，從而更好地權衡利弊、更進一步地追尋方案最優解。

參考資料

• 梁禮方.《銀行信息科技》,2015年

• 吳軍.《商業銀行外部研發資源管理探討》,2016年

• 牛新莊.《商業銀行分散式架構實踐》,2019年

• 德勤.《數字化時代下的核心銀行轉型》,2019年

• 網商銀行技術編委會.《金融級IT架構》,2021年

• 雷小寒.《銀行核心系統建設再提速》,2021年

• 阿裡雲.《“核”聚變—核心系統轉型之路》,2022年

作者丨代堂明

本文來自博客園，作者：古道輕風，轉載請註明原文鏈接：https://www.cnblogs.com/88223100/p/The-changing-course-and-new-construction-mode-of-the-core-banking-system-in-the-past-40-years.html