本文詳細介紹了我國銀行核心系統的定義、位置與邊界，發展歷程、更換核心系統的原因，以及新核心建設的五大模式與其特點對比，希望內容能夠幫助銀行科技從業者建立起對銀行核心系統的整體認知，提供一定積極的指導作用與借鑒意義，從而引發思考并促進行業交流與探討，共同為我國的銀行科技蓬勃發展貢獻自己的智慧與經驗，
在這里，特別要感謝張廣老師，對我國銀行核心系統的發展歷程部分進行了完善和補充，特別是關于目前業內流行的分布式微服務組建模式，學到很多，希望后續有更多的小伙伴來分享自己的見解或想法，一起思維碰撞，探索更多可能……
此文分為以下五部分：
一、銀行核心系統的定義與邊界
二、我國銀行核心系統的發展歷程
三、銀行核心系統更換的原因分析
四、銀行核心系統建設的五類原則
五、銀行核心系統建設的五大模式
一、銀行核心系統的定義與邊界
1、銀行核心系統的定義
銀行核心系統（Core Banking System）是以處理銀行最基本的存款、貸款業務為主的IT系統，作為支撐業務營運的關鍵系統和銀行資訊化的重要組成部分，被稱作銀行IT系統的“心臟”，我們去銀行網點或線上辦理的存貸款業務都是在銀行核心系統中完成的，除此可能還包含客戶、會計、公共等功能，
銀行核心系統在整個銀行IT系統架構中是其他業務子系統的基礎，也與其他系統保持著密切的關系，作為重要的業務處理系統，在整個銀行IT系統中處于承上啟下的關鍵位置，
核心系統在金融服務能力、處理性能等方面，對銀行日常經營的業務與流程優化、提升客戶體驗度、推動業務改革或創新等方面起著決定性作用，
2、銀行核心系統的邊界
銀行IT系統功能邊界的定義，對于系統的分析與設計非常重要，需要結合銀行自身發展情況與發展戰略進行整體規劃，當有了明確的邊界就清楚了系統分析和設計的范圍，就有了作業的目標和任務，
因此，邊界的定義是明確責任和控制成本的基礎，有助于精細管理，能避免浪費無效的作業時間和精力，試想要是作業沒有邊界，是一件多么可怕的事情，可能會違背自己的本意做一些職責范圍之外的事，甚至出現扯皮推諉的情況，
在銀行新核心系統設計時也一樣，
因為銀行核心系統會與幾十個、甚至成百上千個其他關聯系統有進行互動，所以分析邊界要先梳理核心系統包含哪些內容，不包含哪些內容，然后再結合銀行IT系統的整體規劃，盡量做到只處理最基本的核心業務，即單純的交易處理系統，從而保證核心系統的穩定與高效，這不僅增強了系統的靈活性和擴展性，而且還能適應外圍系統的快速擴展，
在科技飛速發展下，銀行核心系統在不同時期面對的挑戰與機遇各不相同，在調整核心系統的定位并設計最優解的同時，經歷著一代又一代的發展與變革，
二、我國銀行核心系統的發展歷程
1、手工時代（20世紀80年代以前）
在沒有電子計算機的時代，當時銀行叫做儲蓄所，專門給儲戶辦理存取款業務，在柜臺前，由出納和會計人員負責存取業務的現金收付、以及賬本的登記，常常可以看到一堆摞的高高的賬本，一個墨水瓶，一只填寫憑證的蘸水筆，一把用來記賬和軋賬的算盤……
儲蓄所職員完全是依靠手工操作辦理業務，無論是客戶業務辦理，還是計息結賬、內部往來對賬、編制報表等都靠人工處理，
比如營業時間的存取款，從收錢、點鈔、登折再到另一個人的復核、簽字、蓋章、記賬，最快也要二三十分鐘；再如每天營業結束后的“扎賬”，若總賬和明細賬沒有扎平，就必須連夜加班查賬找出原因，直至賬目齊平，
圖1-1 銀行辦理業務場景；儲戶的賬本與賬頁
純手工時代的銀行業務辦理不僅耗費大量人力、效率非常低、資金周轉慢、資訊不靈通，例如票據或者紙質憑證的傳遞與互動；而且風險控制也是一大難題，比如手工記賬的誤差在所難免、登記憑證或賬本易丟失與污損，甚至是發生火災等問題，
手工時代只解決了能夠辦理銀行業務的問題，顯然無法滿足中國銀行業發展的需要，隨著電子計算機的出現，銀行業進入了電子化的初期階段，通過簡單的模擬手工操作，主要解決了手工操作和業務處理的效率問題，
手工時代留下了很多的名詞和概念，一直到現在，在系統中都還能看到歷史的痕跡，
例如，“臺賬”、“登記簿”在手工時代就有相應臺賬的賬本或登記簿去記錄一些事情，在用計算機模擬手工時代的做法時，也就將相關概念都引入到系統了；再如“出納”，手工時代區分出納與會計，因此在系統列印的回單上，有時會出現“出納會計”的字樣；又如“儲蓄天數演算法”，手工時代為每一位儲戶計算利息很不方便，為簡化操作和減輕銀行作業人員的作業量，規定了不管大月、小月都是按30天，一年按360天計算利息的演算法，在目前的系統當中還有使用，
2、PC單機（20世紀80年代前期）
在引入計算機之后，即20世紀80年代前期出現了PC單機時代，也稱為“會計電算化”，就是把一部分柜員手工記錄的內容，特別是會計賬簿和記賬傳票，使用計算機來實作資料的登記和保存，從而減輕人工登記和處理的負擔，加快業務辦理速度，提高作業效率，
通常每個儲蓄所或營業所會配一個PC單機，柜臺人員會將手工登記的資訊錄入到計算機系統中保存，從而實作銀行每個營業網點單獨一套“電子的賬本”，形成了非紙質記賬的方式，
由于還沒有互聯網，每個網點安裝的計算機設備都沒聯網，擁有各自獨立的系統，各個網點分別處理自己的賬務資訊，所以沒有通存通兌功能，基本上都是以網點為單位，在哪里辦理的開戶，就只能在哪里辦理業務，跨儲蓄所的互動，還是和手工時代一樣走紙質票據或紙質憑證的傳遞，總的來說，是解放了一部分的手工操作，解除了原先很多在紙質上面的記錄，
圖1-2 銀行儲蓄宣傳&柜員桌上配置了電腦
其實在這一階段已經出現核心系統的雛形，簡單說就是一個后臺會計的登記系統，主要功能有賬務的處理、資料的記錄，以及配套的柜員操作頁面（即字符終端）與主機連接在一起，沒有計算能力，只是一個顯示螢屏，通過鍵盤傳送輸入要素并顯示輸出，
核心的主要設計思想是以“賬戶為中心”的金融服務體系，就是以賬本為分戶賬來作為整個系統的一個中心或面對的一個物件，因此，賬戶在核心系統當中是唯一的關聯標識，是將所有業務操作和記錄串接在一起的關鍵要素，
由于每個儲蓄所或網點都是單機，所以每個系統都是一個個資訊孤島，互相之間不能互聯互通，
比如一個人在同一家銀行有5個賬戶，5個賬戶可能是不同網點辦理的，那銀行的各網點就不能夠總攬地了解客戶，無法針對客戶的財務狀況和實際需求提供有針對性的服務，但同時，也為大規模引入全國聯網的系統和業務流程再造打下了基礎，
之后，國內開始建設網路基礎設施，將各網點連起來實作業務聯網區域的通存通兌，甚至發展到以省市級主機為中心，向省外網路連接實作省級互聯互通……這就引出了下一個發展階段——聯網聯機的時代，
3、聯網聯機（20世紀80年代末至90年代初）
存貸匯是銀行的基本業務，跨網點通存通兌最常見，此前跨網點辦理業務會用到票據（如本票、匯票），需要等待銀行之間的票據交換，若干天后才能完成業務的辦理，對客戶來說時效性和安全性比較差，當引入計算機網路后提升了資料實時傳送的能力，
基于該背景下建設了計算機網路，各個銀行之間不再需要使用紙質的傳遞方式，就能夠通過網路將不同的網點和不同的系統，借助通信設備和線路建立連接，實作了各地區、各部門、各應用系統之間的資料實時傳輸、交換、資源共享，實作了聯機業務處理和異地跨行通兌，
比如2小時匯款到賬、甚至實時匯款到賬，極大地提升了客戶體驗，在發展到后期，有些地市借助網路更進一步，產生了區域性資料集中一種做法，
相當于網路建立起來后在某個地區設定一個區域性主機，讓區域性主機提供統一的核心系統后臺服務，網點僅保留柜面操作的模式，因此順勢出現了核心系統和柜面系統的分離，
圖1-3 那時的ATM界面；新版計算機
與此同時，自動柜員機（ATM）開始大量出現，主要用于辦理存入、支取或查詢交易的業務，在國家的指導下，成立了以計算機、通信等現代科技為基礎和銀行卡等為介質的“金卡工程”并開始實施，通過計算機網路系統，用電子資訊轉賬的形式實作貨幣流通，金卡工程首批12個試點省、市全部實作了同城跨行ATM/POS聯網運行和信用卡業務聯營，自93年金卡工程發起到97年底，已發行了5萬多張卡，
對銀行來說，主要是出現了一種叫銀行卡的交易介質，不僅針對某一家銀行可以使用，而是能全國通用，這一轉變將銀行服務網點做了很大的拓寬，原先的儲蓄所變化為在人流量較多的地段設ATM機，甚至借用其他銀行的ATM機也可以提供相應的服務，
由此，銀行開始陸續出現除柜面之外的電子渠道，銀行核心系統的設計理念也發生了變化，在銀行業飛速發展的行程中，隨著我國經濟建設發展、改革開放的不斷深入和即將加入的世貿組織，進一步加快了商業銀行電子化建設的步伐，
4、全國大集中（20世紀90年代末至2008年左右）
為迎接加入世貿組織的挑戰與機遇，提升資料和技術力量的分散、業務處理缺乏標準規范、軟硬體資源不共享、管理水平不平衡等問題導致的負面影響；加上計算機的硬體設備能力在不斷提高、網路質量越來越好、網速越來越快等原因，資料大集中應運而生，
簡單的說就是原先區域性的資料集中，但對客戶來說，同一家銀行是一個整體，任意網點都應享受同樣的金融服務；對銀行來說，將客戶在各網點的資訊匯總起來用于風險評估或評級，不僅能節省銀行的管理成本，而且有利于對客戶有更全面的了解后提供更好的金融服務，
資料大集中是各銀行根據自身情況對資料和業務進行不同程度的集中處理，例如，將分散的省級資料中心的資料和業務集中到國家級的資料中心，實作系統基礎架構、物理服務器、資料和應用建設的集中，
資料大集中使總行能夠集中全部研發力量，從而避免低水平的重復開發，節約系統管理、軟體維護及升級的費用；使總行能夠得到準確、實時的資料，全面地了解到各分行的作業進展情況，以免增加不必要的后繼溝通成本；使總行能夠通過分析交易資料與交易行為，提升整體服務水平，減少因資訊不對稱而導致的銀行風險管理失控或業務機遇喪失，
因此，國內商業銀行開始重視規模化經營，掀起了一場以資料大集中為主線的技術革命和業務變革，同時也造成核心系統的資料量呈指數級增長，原先是一個地區或單網點的資料，經全國大集中之后資料量翻了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小時在當時的系統設計中是一個熱點，
同時資料集中化在不斷發展，客戶資訊都集中到了總行，系統中可以看到客戶的全貌，并對客戶進行資料分析，所以“以客戶為中心”的新概念伴隨著業務轉型而陸續出現，
5、瘦核心（2008年至2015年）
經過全國大集中的建設，伴隨著系統長期運行，逐漸暴露了一些問題，主要是核心系統越來越龐大，因為全國大集中后，核心系統納入了各地區的共有功能之外，還包含了每地區的特色功能，導致系統耦合嚴重，形成了所謂的“胖核心”，
不僅限制了業務發展，還增加了建設和運營成本，每次修改都感覺牽一發而動全身，而且開發新功能時會發現改動與評估內容很多，開發耗時越來越長，無法做到快速的回應業務變化，
例如，無法快速推出有特色的產品回應市場需求來吸引客戶；再如，因系統內部改動較大而無法給優質客戶提供個性化利率；又如，因營改增的業務需求而導致記賬規則的調整，需要在核心系統內部做手術，不僅需要投入大量的人力物力，而且風險很大，如果賬務核算是一個相對獨立的系統，那么就不會帶來核心系統巨大的改動量，也不必為此承擔大的風險，
究其根源，該階段的銀行核心系統其實也叫“綜合業務系統”，不管是什么業務，都放在這系統中實作，只是將渠道端單獨分隔開，但后臺的處理功能全部綜合在一起，用一個系統去完成銀行的各種業務，這就必然導致成為大而全的系統，難以維護，
為了解決系統龐大耦合的問題，業內一致開展了核心系統瘦身的運動，喊出了“瘦核心、大外圍”的口號，驅動了將核心系統的輔助功能都剝離到外圍系統，
圖1-5 叫號系統被廣泛使用；智能設備遍布網點
從系統結構上來說，首先從核心系統中拆分的有管理類功能，建立各類管理系統，比如信貸管理系統、財務管理系統、柜員管理系統、額度系統，將辦理業務前需要做的評級與審批類的管理性作業，拆離核心作為管理功能，也就是在完成各種管理性質的動作并通過后才說明能夠辦理該業務，所以可以拆離核心，只留下一個小而精的核心系統來處理核心業務、內容單一，核心系統通過介面與各管理系統連接，傳遞資訊或進行相應的管理控制，
其次，從核心系統中拆分的有統計分析類功能，建立資料倉庫，因為系統對資料進行分析與加工很消耗系統資源，而且也并非交易程序中急需使用的內容，可以在交易結束、獲取資料之后再進行分析，通過數倉去解決耗資源的問題，不要讓其影響整個業務系統的運轉，例如，通過資料分析給客戶打標簽，標記普通客戶、優質客戶、VIP客戶等，
還有，需從核心系統中拆分出報表功能，資料經過統計分析之后，需要給監管報送或給行內出具各種報表，既然統計分析類功能已剝離核心，那對于報表也要建立單獨的報表系統進行加工與報送，
最后，還有第三方對接類的功能也要從核心系統中剝離，早期銀行只會辦理自身支持的業務，但隨著網路的發展，銀行與第三方的連接或是與第三方實時互動的功能越來越多，比如代繳水電費，
為提升系統間的互動效率，就出現了連接第三方的各類前置系統，以及專門做中間業務拓展的中間業務系統，使得行內能建立統一的互動管理標準，例如，建立了ESB服務總線、建立了ECIF全行級客戶資訊系統實作行內客戶資訊統一共享等，
甚至一些激進的銀行，將核心系統中的賬務內容也相應分開，比如建立貸款系統、存款系統、或是互聯網核心系統等，并配套總賬系統來匯總處理各賬務系統的會計流水，因此，在核心系統瘦身階段后期，逐漸出現了“大總賬”的概念，
除功能瘦身外，核心系統的整體設計理念也全面轉向“以客戶為中心”，例如，指定編碼規則生成系統唯一的客戶號，再通過客戶號管理同一客戶下的所有賬號，建立統一的客戶資訊視圖，打破原有客戶群各自封閉的情況，并將客戶之間的關系進行歸集（比如針對集團客戶可歸集其下轄各子公司的賬戶），實作客戶與賬戶的多層級管理，掌握客戶每筆交易的資金動態和流向等，
以客戶為中心（復雜的關聯關系），如下表：
圖1-6 復雜的關聯關系
除了“以客戶為中心”之外，還引入了產品工廠、定價模型等引數化、配置化的設計思想，大大提升了銀行核心系統的靈活程度與健壯性，
通過系統引數的靈活配置實作產品特色化，通過對客戶需求的聚焦，進而對指定客戶群或是個別優質的客戶提供有針對性的服務，比如提供利率、費率及匯率的差異化定價，在吸引新客戶和留住老客戶的同時，也為今后業務的發展奠定了堅實的基礎，
此時的銀行核心系統仍處于全國大集中的階段，在2015年后，業內才逐漸進入了分布式微服務時代，采用了新的互聯網思路去構建銀行核心系統，
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年）
針對更換核心系統的原因，站在銀行的角度進行分析，主要從以下維度進行思考：
-
功能：系統技術非市場主流，與主流技術對接產生障礙；因為銀行的合并，現存的任何一個核心系統無法對應不同文化的銀行多樣應用系統整合的需求；
-
風險：每一代的銀行面對的社會經濟活動不同，對系統的架構與應用要求產生結構性的影響，必須以重建的思維從根本解決；業務規模（業務量、經營范圍）擴大，舊系統無法應對；
-
運維：舊系統廠商退出市場（硬體、軟體）；因為希望合并迅速整合完成，急急忙忙地系統整合，導致舊系統降低服務水平，縮短原系統壽命；核心系統生命周期，因為科技與社會經濟活動改變而逐漸縮短；
-
成本：舊系統的應用系統時間久了打滿補丁，新的需求開發費時費力；舊核心系統成本貢獻比逐漸升高，特別是主機型系統用戶；
-
收益：核心系統經營管理模式隨著科技與應用的改變，產生多樣的核心系統經營方式可供銀行依據自身條件（規模、人力、成本、效益）選擇（自建、購買、托管）；
-
組織：舊系統開發、維護人才逐漸凋零，借著新系統的開發培養下一代的接班技術人才，
四、銀行核心系統建設的五類原則
銀行的金融交易涉及到客戶資金運轉，在國民經濟發展中處于特殊重要地位，所以銀行的業務特性決定了銀行對交易和資料的及時性與一致性要求非常高，必須準確、不可丟失，安全性、可用性、可追溯，更是互聯網金融企業無法比擬的，
例如，對于外匯業務，利率的實施變化決定了相關業務要實時相應，如果時效性、準確性達不到要求，就會給客戶或銀行帶來損失，再如，在證券行情實時變化時，銀證轉賬如果不能滿足要求，可能會給客戶帶來巨額損失；一些大額的轉賬或匯兌如無法滿足時效性及一致性，可能給客戶的資金使用帶來風險，當然，互聯網企業的優勢（如海量服務能力、注重客戶體驗、大資料服務能力等）也是傳統商業銀行轉型必須具備的，
1、及時性
及時性是指要及時回應客戶的交易行為，避免可能帶來的損失，因為銀行系統的處理能力與銀行規模和科技投入有關，所以主要從銀行核心系統的幾個關鍵指標來了解自身發展情況和目標，如回應時長、每秒事務處理數、每秒請求數等，
-
回應時長（RT）：從發出請求到得到回應的耗時，即從前端界面按交易提交鍵、到處理結果并反顯全部資訊到前端界面之間的時間間隔，一般可以采用毫秒單位來表示，而對一些RT比較敏感的業務場景下，可以使用精度更高的微秒來表示，
-
每秒事務處理數（TPS）：每秒能夠處理的事務數，其中T(Transactions)可以定義不同的含義，它可以是完整的一筆業務，也可以是單個的介面請求，
-
每秒請求數（RPS）：也可以叫做QPS，但它與TPS有所不同，前者注重請求能力，后者注重處理能力，不過，若所有請求都在得到回應后再次發起，那么RPS基本等于TPS，
-
資料庫性能：指的是有關資料庫的指標，比如資源超時、資源死鎖、資料庫連接、記憶體泄漏等，
2、一致性
在分布式銀行核心系統中，一致性是指資料在多個副本之間能否保持一致的特性，在一致性的需求下，當一個系統在資料一致性的狀態下執行更新操作后，應保證系統的資料仍然處于一致，提到一致性就離不開分布式事務、快取等，就不逐一展開了，
3、安全性
安全性是指通過資訊安全建設和管理，有效控制和防范資訊安全風險，確保企業與客戶的資訊及資金安全，主要包括機房、網路、資料、系統、制度等安全方面進行保障，
4、高可用
高可用是指系統提供的服務必須一直處于可用的狀態，所有處理環節避免單點故障，當故障發生時可以快速恢復，如果在故障發生時具備故障隔離或備災備容錯能力，如多活并行處理、兩地三中心等，RPO（Recovery Point Objective，恢復點目標）、RTO（Recovery Time Objective，恢復時間目標）等指標無限趨近于零，
如下表：
圖1-17 不同災難恢復能力等級下的RPO和RTO
圖1-18 可用性及衡量標準
可用水平（%），通常都包含了資訊系統計劃停機的時間，即為了系統維護、新版本投產等原因，人為主動的讓系統停止對外提供服務，因此，要提高可用水平，需要減少系統的計劃停機時間，
5、可追溯
可追溯是指金融交易的所有業務操作都要保留日志資料，做到資訊流的可查、可追溯、可審計，也是監管的要求，
五、銀行核心系統建設的五大模式
在銀行IT系統中，銀行核心系統建設是整體支出占比最大、最為復雜，對于技術要求最高的工程，需要持續投入非常多的資金與人力資源，而且還涉及到全行各關聯系統的配合或同步改造，專案建設周期往往少則一年，多則兩三年，
采取什么樣的模式來建設新核心系統，如何在本行能夠承受的前提下投入財力和人力，使系統建設既能對標同業又要符合實際發展情況，并能夠滿足未來銀行業務快速發展的需要，一直是一個困擾許多銀行決策層的難點問題，
銀行新核心系統的建設模式大致可分為五種，分別是外購或外包產品、完全自主研發、主導研發、專案研發外包和應用系統托管，對于采取哪種研發模式，需要綜合考慮諸多因素擇優選擇，切不能一概而論，在規劃中要提前明確和定位建設模式、合作伙伴以及維護方式等，
通常是銀行自身IT有強大的技術能力的大行，研發團隊越成熟，越應該走自主研發的道路，反之，中小型銀行的自身IT規劃能力及建設能力不太強，并要支持下一步的業務創新及快速實作業務需求有一定難度，采取外購外包模式，與合作伙伴共同實施核心系統建設是一個更好的選擇，不僅銀行可以用更低的成本獲得更好的技術和服務，并可以使自身在人員缺乏的情況下，將更多精力集中在需求分析設計、專案規劃與服務監控上，從而更好地推進核心專案的建設，
另外，銀行核心系統產品從縱向解剖，自底而上通常可以分解為基礎設施、技術平臺、應用模塊三大部分，越是基礎的越能通用，越靠近應用越要定制，否則做出來效果不好，并且結合外包、自主研發多維度統籌考慮，
1、外購或外包產品
對于科技力量薄弱、自身研發能力不足，業務規模在一兩年內甚至幾年內預估不會爆發增長的小銀行，采取外購或外包產品的模式更加合適，它們沒有多少IT人員，忙于日常如協助各個部門查資料、列印報表或結單、分析生產問題，或承接以運維類、報表類等低價值開發作業為主，沒有多少剩余時間進行研發與創新、甚至是學習或吃透其服務商產品的做法或優點，
除了外購產品更成熟或先進之外，銀行核心系統上線或更換速度更快，比如偏互聯網銀行基本保持在半年內，主要還是相關專案由于是新做，沒有負擔，所以周期短，
還見過銀行直接外購整個銀行IT系統，拆除科技部，直接將資訊科技的運維都外包給相關的機構，也是一種更經濟的可選擇的方式，或者一種過渡的方式，
當然，有利必有弊，該模式需認真分析以下三點：
1）是否適合國情、行情
銀行核心系統是一家銀行的引擎、發動機，也是一家銀行科技實力的重要體現，同時也服務于銀行的戰略、業務和組織架構、以及監管政策和法律法規，而不同國家、不同銀行有非常不同的目標、形式和歷史原因，例如，國內外的核心系統差異巨大，直接拿來使用可能會水土不服，
2）差異化開發及維護成本
外購的產品通常要適合本行特色業務，從而進行差異化開發或修改，差異化需求越大越多，修改和測驗的作業量就越大，可能會影響上線期限，當系統上線進入了維護階段，服務商會有半年到一年的免費維保期，但對新增需求的分析、設計、開發等方面要單獨算費用，因為過渡依賴存在不確定風險，故議價能力很弱，基本上是，維護成本占了系統建設整個生命周期所需費用的大頭，
3）系統間整合
指的是系統之間沒有統一的資料標準，使得銀行的資料資訊零亂分布，既有冗余又有缺失，或資料更新不同步，資料一致性無保障，比如有些銀行將核心系統進行拆分，單獨外購貸款系統或分散外購，不同的廠商框架或標準不一樣，若沒有統一標準或長遠規劃，不可能提供高質量的資訊服務，
該模式適用的銀行范圍有：部分中小城商/農商、民營銀行、外資銀行，而且部分銀行會要求產品能簡單部署在云平臺上，在自主可控方面陸續要求集成國產資料庫，當然，有相當研發能力的金融機構也不是絕對不能外購，
2、專案研發外包
專案研發外包模式使用較多，是指“外購產品+改造實施”的方式建設新核心，也可稱為專案外包，即在服務商的業務與技術人員入場前，確定好外包范圍和外包金額，銀行方不再太關注外包公司實際投入資源，而是重點關注專案質量和進度，
在專案實施程序中，銀行會根據里程碑計劃的執行情況和行內自主掌控要求，選派不同程度的人員參與需求分析和設計及評審或部分開發作業，具體的研發還是以服務商為主，
服務商目標和責任明確，銀行方投入精力小，有利于銀行擁有自主知識產權或者是共有知識產權，缺點是立項采購拉長了專案實施周期、銀行自有研發規范較難落實、專案質量受制于服務商實施團隊的能力，多家外包伙伴時溝通成本較大，
隨著銀行規模增大，可能還會衍生出多家服務商合作外包的方式做專案，降低對單個服務商的依賴，將可能造成的損失降到最低，
在專案前期，通常還會增加咨詢公司對本行的業務進行梳理和優化，銀行對自身業務把握清晰，但對未來發展和業界的領先實踐無法與咨詢公司相提并論，只有通過專業的理念和服務將業務分析透徹，才能很好指導后期的系統設計與開發作業，
其次，核心系統專案建設牽涉到銀行很多部門和組織，難免會有利益沖突與作業的協調配合，借助第三方專業的視角和可觀的角度能更高效的協調和解決問題，
該模式適用的銀行范圍有：部分中大小城商/農商，其主要訴求是替代掉原有的老舊核心系統，建立起產品的業務模型和架構建設，在自主可控方面部分銀行會要求集成國產資料庫，
3、自主研發
對于大型金融機構來說，銀行IT在逐步去外包化，盡管還存在外購系統的情況，但更多的是希望能掌控系統從而解決外購系統的重重束縛，或是完全自主研發代替外購或外包產品，為積極回應國家對金融核心領域技術自主可控的要求，銀行IT走自主研發的道路是必經之路，
不僅能完全使用本行的戰略、業務和組織架構，而且國內金融IT廠商技術力量相對薄弱，很多高水平畢業生不做外包，當行里研發隊伍的規模和素質達到一定程度，系統上線周期會快于外購系統，
算上研發人力費用、固定資產折舊、辦公費用、系統維護成本等，從整個產品生命周期看，自主研發總成本通常要低于外購產品，
該模式適用的銀行范圍有：國有大行、股份制、大農信、部分中大城商/農商行，大多數原有核心采用AS400或大機的銀行希望采用重構的方式完成核心下移，部分銀行會要求基于云平臺進行核心系統重構，在重構的規劃或程序中強調自主控，
4、主導研發
除了大型商業銀行，其他銀行規模相對比較大，研發團隊有較強的研發能力，但不具備完全的自主研發能力，那么，可以采取介于完全外購外包與自主研發之間的近自主研發的系統建設模式，
主導研發包括自主定義系統的架構、資料標準、介面標準、資料交換規范，以及系統設計、資料庫設計、流程設計等，專案與技術經理要由銀行研發人員擔當，便于日后能主導所有系統維護作業，
銀行進行外包采購的是“人力外包（俗稱買人頭）”，人力外包是以人力勞動時間為主要目標的外包方式，一般以開發工時為結算依據，銀行負責選人、分派任務、結果驗收，
其優點是專案可快速進入實施階段、使用人工靈活，有利于自主掌控，研發規范管理更好，知識傳承和連續性保障較好，缺點是銀行的管理難度高，外包人員流動性較大、缺乏對團隊的歸屬感和認同感，此外，如何客觀評價外包人員的勞動效率也是一個難題，
在人力外包的情況下，衍生出了新的形式用于嚴格規范對人力外包的管理，防止外包人力作業量不飽和，
比如以任務單的形式實施小微型專案外包，便于對人力外包的事前控制，要求從外包資源池中申請外包人力時，必須提出具體的作業內容和預估作業時長，并形成研發任務單，同時，管理難度有增加，需要明確評估每一個任務的作業量，
5、應用系統托管
上述提到的四種核心系統建設模式，基本都是一個銀行擁有一個自己的系統，還有一種模式是“應用系統托管”，可以理解為多法人機構共享的核心系統，
對于中小型金融機構或新成立的銀行，要新建一個僅供自己銀行使用的核心系統并進行日常的運維不容易，所謂麻雀雖小，五臟俱全，總體投入成本較大，
因此，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
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/511988.html
標籤：其他
上一篇：OnionArch - 采用DDD+CQRS+.Net 7.0實作的洋蔥架構
下一篇：設計模式-行為型模式之模板方法