融界2024年3月28日消息，據國家知識產權局公告，中國農業銀行股份有限公司取得一項名為“生產操作間管理系統及方法“，授權公告號CN114268440B，申請日期為2021年12月。
專利摘要顯示，本發明實施例公開了一種生產操作間管理系統及方法。該系統包括至少一個操作計算機、操作計算機對應的終端掃描器、用戶終端以及管理服務器，用戶終端包括終端處理模塊；其中，終端處理模塊用于在檢測到用戶的人員身份校驗通過時，生成用戶對應的密鑰信息并在用戶終端上進行顯示，終端掃描器用于獲取用戶終端顯示的密鑰信息，并將密鑰信息發送至管理服務器，管理服務器用于根據密鑰信息驗證用戶是否具備操作計算機的使用權限，若是，則控制操作計算機的使用權限開啟。該系統實現了基于終端實時生成的密鑰信息的操作計算機使用權限的驗證，通過實時計算的密鑰信息保證了操作用戶權限的監控與防篡改，進而保證了操作計算機的信息安全。
本文源自金融界
文詳細介紹了我國銀行核心系統的定義、位置與邊界，發展歷程、更換核心系統的原因，以及新核心建設的五大模式與其特點對比。希望內容能夠幫助銀行科技從業者建立起對銀行核心系統的整體認知，提供一定積極的指導作用與借鑒意義，從而引發思考并促進行業交流與探討，共同為我國的銀行科技蓬勃發展貢獻自己的智慧與經驗。
在這里，特別要感謝張廣老師，對我國銀行核心系統的發展歷程部分進行了完善和補充，特別是關于目前業內流行的分布式微服務組建模式，學到很多。希望后續有更多的小伙伴來分享自己的見解或想法，一起思維碰撞，探索更多可能……
此文分為以下五部分：
一、銀行核心系統的定義與邊界
二、我國銀行核心系統的發展歷程
三、銀行核心系統更換的原因分析
四、銀行核心系統建設的五類原則
五、銀行核心系統建設的五大模式
一、銀行核心系統的定義與邊界
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、及時性
及時性是指要及時響應客戶的交易行為，避免可能帶來的損失。因為銀行系統的處理能力與銀行規模和科技投入有關，所以主要從銀行核心系統的幾個關鍵指標來了解自身發展情況和目標，如響應時長、每秒事務處理數、每秒請求數等。
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年左右出現了銀行間共享合作平臺，各參與行共同建設，從調研論證、項目立項、需求分析、開發、測試到上線后的運維，成員行公共參與并實踐，因此減少了研發過程中的重復開發，節省掉研發費用后均攤成本，將用戶利益做到最大化，最終為金融機構提供各種所謂金融服務。
隨著涉及金融云服務的快速發展，云服務企業已成熟，如山東城商行聯盟、興業銀銀平臺、神碼金融云等，其應用系統托管的模式幫助中小城商行、民營銀行解決了發展過程中各種各樣的難題。
結語
關于我國銀行核心系統定義、邊界與位置，我國銀行核心系統整個發展歷程、更換核心系統的原因和原則，以及新核心的建設五大模式就介紹完了。
相信對于初學者來說，已經逐漸建立起了對銀行核心系統領域的整體認知、搭建起了屬于自己的第一層級知識樹。對行業同仁來說，對目前銀行核心系統發展到分布式微服務的模式有了更深的理解，當然很多實現的模式所帶來的問題與機會需要繼續思考，也包括業內各大服務商正研發的云原生核心系統等，都還需要在實踐與使用的過程中不斷研究與探索，從而更好地權衡利弊、更進一步地追尋方案最優解。
>>>>
參考資料
作者丨代堂明
來源丨公眾號：小代嘚吧嘚（ID：xiaodaitalkshow）
dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：editor@dbaplus.cn
關于我們
dbaplus社群是圍繞Database、BigData、AIOps的企業級專業社群。資深大咖、技術干貨，每天精品原創文章推送，每周線上技術分享，每月線下技術沙龍，每季度Gdevops&DAMS行業大會。
關注公眾號【dbaplus社群】，獲取更多原創技術文章和精選工具下載
券之星消息，根據企查查數據顯示工商銀行（601398）新獲得一項發明專利授權，專利名為“回歸測試方法、裝置、計算機系統和計算機可讀存儲介質”，專利申請號為CN202110107378.1，授權日為2024年2月6日。
專利摘要：本公開提供了一種回歸測試方法、回歸測試裝置、計算機系統、計算機可讀存儲介質和計算機程序產品，可用于人工智能、信息安全、物聯網領域或其他領域。其中，該方法包括：獲取執行被測試程序時錄制得到的錄制數據，其中，錄制數據包括被測試程序的入口調用方法所對應的入口調用請求參數、被測試程序的目標執行方法所對應的第一請求參數和第一響應值以及與被測試程序相關的中間件對應的第二請求參數和第二響應值；獲取待測試程序，其中，待測試程序為對被測試程序進行程序上的修改得到；以及根據錄制數據對待測試程序進行回歸測試。
今年以來工商銀行新獲得專利授權232個，較去年同期減少了29.91%。
數據來源：企查查
以上內容由證券之星根據公開信息整理，由算法生成，與本站立場無關。證券之星力求但不保證該信息（包括但不限于文字、視頻、音頻、數據及圖表）全部或者部分內容的的準確性、完整性、有效性、及時性等，如存在問題請聯系我們。本文為數據整理，不對您構成任何投資建議，投資有風險，請謹慎決策。