銀行新核心基礎(chǔ)架構(gòu)方案設(shè)計技術(shù)手冊

1、銀行新核心基礎(chǔ)架構(gòu)方案設(shè)計技術(shù)手冊目 錄分析篇4銀行核心基礎(chǔ)架構(gòu)的現(xiàn)狀4銀行核心基礎(chǔ)架構(gòu)面臨問題5耦合性問題5資源格局限制5擴展性短板6數(shù)據(jù)安全局限性6銀行核心基礎(chǔ)架構(gòu)重構(gòu)必要性6三步走戰(zhàn)略分析7面對 FinTech 時代的機遇與挑戰(zhàn)7集中式與分布式9微服務(wù)與巨石10銀行核心基礎(chǔ)架構(gòu)重構(gòu)難點分析11交易和核算的分離問題11系統(tǒng)去耦問題11思維轉(zhuǎn)型12思維轉(zhuǎn)型13規(guī)劃篇13 HYPERLINK l _TOC_250024 銀行核心系統(tǒng)去耦設(shè)計13 HYPERLINK l _TOC_250023 業(yè)務(wù)模塊的邏輯拆分13 HYPERLINK l _TOC_250022 應(yīng)用模塊的分布式部署14 HY

2、PERLINK l _TOC_250021 基礎(chǔ)架構(gòu)的邏輯解耦14 HYPERLINK l _TOC_250020 資源池化方法14 HYPERLINK l _TOC_250019 應(yīng)用和資源的映射關(guān)系分析15 HYPERLINK l _TOC_250018 虛擬化方案的設(shè)計15一、各個資源池的設(shè)計15二、虛擬服務(wù)器對資源的分配策略15三、資源的動態(tài)優(yōu)化策略15 HYPERLINK l _TOC_250017 基礎(chǔ)架構(gòu)擴展性方法16 HYPERLINK l _TOC_250016 前提條件16 HYPERLINK l _TOC_250015 應(yīng)用層的擴展性設(shè)計16 HYPERLINK l _T

3、OC_250014 數(shù)據(jù)層的擴展性設(shè)計16 HYPERLINK l _TOC_250013 互聯(lián)網(wǎng)模式發(fā)展方法17 HYPERLINK l _TOC_250012 定位互聯(lián)網(wǎng)模式的位置17 HYPERLINK l _TOC_250011 互聯(lián)網(wǎng)模式發(fā)展思路17 HYPERLINK l _TOC_250010 設(shè)計實施篇18 HYPERLINK l _TOC_250009 銀行核心系統(tǒng)存儲解決方案18 HYPERLINK l _TOC_250008 銀行核心系統(tǒng)數(shù)據(jù)庫解決方案19 HYPERLINK l _TOC_250007 架構(gòu)規(guī)劃設(shè)計原則19 HYPERLINK l _TOC_250006

4、 數(shù)據(jù)庫性能影響20 HYPERLINK l _TOC_250005 Power 虛擬化架構(gòu)設(shè)計要點20 HYPERLINK l _TOC_250004 同時滿足 IOPS 和吞吐量21 HYPERLINK l _TOC_250003 數(shù)據(jù)庫集群的心跳網(wǎng)絡(luò)設(shè)計21 HYPERLINK l _TOC_250002 一、硬件及參數(shù)21 HYPERLINK l _TOC_250001 二、網(wǎng)卡綁定21三、SCAN IP22四、網(wǎng)絡(luò)參數(shù)22 HYPERLINK l _TOC_250000 虛擬化與物理機混合部署23文檔介紹目標人群本文章適合銀行從事 IT 建設(shè)的架構(gòu)師、工程師以及主導(dǎo)核心系統(tǒng)基礎(chǔ)架構(gòu)及

5、應(yīng)用系統(tǒng)建設(shè)或者改造項目的項目經(jīng)理等人群，可以幫助大家對項目或者技術(shù)選型及定位有一些相對 比較清晰的認識，從而指導(dǎo)其相關(guān)的技術(shù)工作。寫作目標本文從分析角度、規(guī)劃角度以及設(shè)計實施角度來詮釋銀行的核心交易系統(tǒng)建設(shè)所需注意 的一些細節(jié)問題。從基礎(chǔ)架構(gòu)的現(xiàn)狀、發(fā)展歷程以及在當今互聯(lián)網(wǎng)普及的這個環(huán)境下金融行 業(yè)的核心交易系統(tǒng)面臨的問題：系統(tǒng)敏捷性的問題、架構(gòu)擴展性的問題、架構(gòu)耦合性的問題 等等。對于每一個問題，不同的專家從不同的角度都做了詳細的詮釋，包括對問題的看法以 及解決問題的思路等等。在規(guī)劃篇當中，分別對系統(tǒng)建設(shè)的過程中涉及到的業(yè)務(wù)層、應(yīng)用層 以及基礎(chǔ)架構(gòu)層等各個方面進行了詳細的方法論介紹。在設(shè)計

6、實施篇中分別對銀行核心系統(tǒng) 的存儲層和數(shù)據(jù)庫層的關(guān)鍵技術(shù)和實施點進行了案例性的講解。希望通過各個層面的詮釋能 給讀者對銀行核心交易系統(tǒng)的建設(shè)帶來一個詳細完整的解釋。分析篇銀行核心基礎(chǔ)架構(gòu)的現(xiàn)狀伴隨著信息技術(shù)的發(fā)展歷程，國內(nèi)的金融行業(yè)一直在經(jīng)歷著各種變革。眾所周知在銀行 業(yè)內(nèi)，其核心系統(tǒng)對于銀行的重要意義，可以說核心系統(tǒng)的變遷代表著銀行業(yè)整體信息技術(shù) 體系的發(fā)展?？偟膩砜磭鴥?nèi)銀行業(yè)的核心系統(tǒng)發(fā)展經(jīng)歷了三個階段：第一階段：七十年代末到八十年代中期，銀行的儲蓄業(yè)務(wù)以及對公業(yè)務(wù)逐漸以計算機代 替手工操作，計算機是一個以網(wǎng)點為基礎(chǔ)的分散式信息管理域。這個階段談不上信息化的變 革，僅僅是電腦取代了手動操作

7、，完全是一種分散式的管理模式。第二階段：八十年代中期到九十年代末期，這一階段銀行開始通過使用計算機網(wǎng)絡(luò)技術(shù) 實現(xiàn)銀行部分業(yè)務(wù)的實時聯(lián)機處理，并逐步實現(xiàn)了銀行在一定區(qū)域范圍內(nèi)的數(shù)據(jù)集中及互聯(lián) 互通；區(qū)域集中讓所轄銀行得以共享數(shù)據(jù)資源，統(tǒng)一了科目設(shè)置，改進了業(yè)務(wù)流程。第三階段：二十世紀初至今，這一階段即所謂的數(shù)據(jù)大集中階段。全國性的銀行數(shù)據(jù)通信網(wǎng)絡(luò)框架基本建成，各銀行的綜合業(yè)務(wù)處理網(wǎng)絡(luò)相繼建成，一個多功能的、開放的銀行信息化體系初步形成；核心系統(tǒng)由原來的網(wǎng)狀架構(gòu)統(tǒng)一成總線集成架構(gòu)，系統(tǒng)間的接口規(guī)范以及報文格式等都形成了統(tǒng)一的行業(yè)標準，并且這些技術(shù)及標準在不斷的優(yōu)化發(fā)展過程當中。 國內(nèi)大部分城市商業(yè)

8、銀行，中小股份制銀行等都是在第三個階段直接發(fā)展起來的。其核心系統(tǒng)的建設(shè)也是直接套用既有標準規(guī)范進行實施的。應(yīng)用架構(gòu)基本遵循著總線架構(gòu)模式，業(yè)務(wù)處理層面既承擔了后臺聯(lián)機業(yè)務(wù)處理又承擔了銀行賬務(wù)處理；基礎(chǔ)架構(gòu)層面根據(jù)具體的業(yè)務(wù)負載不同基本會采用 IBM 的大型機、中型機、小型機等物理機模式；數(shù)據(jù)庫層面基本采用的比較成熟的關(guān)系型數(shù)據(jù)庫例如 DB2、Oracle、Infomix 等；高可用架構(gòu)多數(shù)采用的是前一個時代的操作系統(tǒng)層面的雙機熱備軟件實現(xiàn)的主備模式。當前，金融脫媒提速，金融監(jiān)管日趨嚴格，對商業(yè)銀行自身的發(fā)展提出了更高的要求， 商業(yè)銀行要想取得持續(xù)穩(wěn)定的發(fā)展需要進行架構(gòu)轉(zhuǎn)型。架構(gòu)轉(zhuǎn)型是一個復(fù)雜的

9、過程，中小銀行應(yīng)基于自身的特點，更不能脫離自身情況，盲目跟進，而是應(yīng)該采取循序漸進的實施策略， 合理規(guī)劃，有序推進。商業(yè)銀行面對的競爭空前激烈，金融脫媒提速，金融監(jiān)管日趨嚴格， 對商業(yè)銀行自身的發(fā)展提出了更高的要求。與此同時，云計算、大數(shù)據(jù)、區(qū)塊鏈、移動互聯(lián)、 人工智能等一系列的新一代信息技術(shù)的發(fā)展和應(yīng)用，正式宣告了 FinTech 時代的來臨，在為銀行的發(fā)展帶來了全新發(fā)展機遇的同時，也對銀行信息化建設(shè)提出了更多的挑戰(zhàn)。在這其中，IT 架構(gòu)的搭建是銀行信息化建設(shè)的頂層設(shè)計中最為關(guān)鍵的一環(huán)，也是根本性的提升信息化能力的有利手段，它向上承載了企業(yè)愿景及頂層戰(zhàn)略，向下指導(dǎo)著各信息系統(tǒng)的定位和功能，發(fā)

10、揮著無可替代的中堅作用。相對于大型銀行和全國性股份制銀行來說，中小商業(yè)銀行面臨著科技人員儲備不足，信 息技術(shù)基礎(chǔ)薄弱，IT 架構(gòu)規(guī)劃能力不足等方面的問題。原有的 IT 架構(gòu)多呈現(xiàn)“自由生長” 的狀態(tài)，且難以滿足業(yè)務(wù)高速發(fā)展的要求，IT 架構(gòu)轉(zhuǎn)型勢在必行。架構(gòu)轉(zhuǎn)型是一個復(fù)雜的過程，中小銀行應(yīng)基于自身的特點，更不能脫離自身情況，盲目跟進，而是應(yīng)該采取循序漸進的實施策略，合理規(guī)劃，有序推進。銀行核心基礎(chǔ)架構(gòu)面臨問題耦合性問題從銀行的數(shù)據(jù)大集中到目前來講，銀行業(yè)務(wù)已經(jīng)經(jīng)歷了將近 20 年的發(fā)展。在互聯(lián)網(wǎng)和信息化沒有爆發(fā)的年代，銀行的業(yè)務(wù)類型相對固定，發(fā)展較為穩(wěn)定。銀行的核心系統(tǒng)大部分 處于安全性、穩(wěn)定

11、性以及高效性的考慮形成了大核心或者旁核心的局面，也就是既有存貸產(chǎn) 品服務(wù)功能又有基礎(chǔ)性的公共服務(wù)功能還有銀行的會計核算功能。近些年來隨著互聯(lián)網(wǎng)以及 信息化的爆發(fā)式推進，銀行的業(yè)務(wù)受到了越來越大的沖擊。利率的市場化發(fā)展要求銀行的產(chǎn)品計算模式必須能夠經(jīng)得起靈活性的挑戰(zhàn)；金融產(chǎn)品市場化競爭的激烈要求我們的產(chǎn)品及服務(wù)必須能夠隨時創(chuàng)新隨時變化；互聯(lián)網(wǎng)及移動信息化的發(fā)展要求銀行的支付結(jié)算手段必須能夠跟得上客戶的環(huán)境變化；行業(yè)標準及國家政策的變化要求銀行能夠快速適應(yīng)并變革。我們舉幾個簡單的例子：比如說為了爭取客戶，對于符合某些條件的客戶的存款產(chǎn)品，我們需要定制特殊的利率或者算法，如果我們的核心系統(tǒng)并非基于面

12、向?qū)ο蠡蛘叻?wù)的設(shè)計模式來實現(xiàn)的松耦合架構(gòu)，那么可能會因為我們流程化的產(chǎn)品定義模型以及客戶定義模型導(dǎo)致我們對核心系統(tǒng)內(nèi)部進行較為大的變更；比如說我們面臨互利網(wǎng)的環(huán)境希望推出有特色的產(chǎn)品來吸引客戶，很可能由于核心系統(tǒng)的接口模式固定化導(dǎo)致我們無法快速實現(xiàn)產(chǎn)品的創(chuàng)新和退出；比如說我們面臨的營改增問題，如果賬務(wù)核算和聯(lián)機業(yè)務(wù)以及公共處理模塊兒能夠邏輯隔離，那么這類的問題就不會帶給我們核心系統(tǒng)巨大的改動量， 也不必為此承擔巨大風險。諸如此類問題會有很多，所有的這些挑戰(zhàn)都不是過去那個胖核心或者大核心環(huán)境能夠解決的問題。這就要求銀行的核心系統(tǒng)在應(yīng)用系統(tǒng)層面必須實現(xiàn)對象化服務(wù)化的松耦合模式。資源格局限制從系統(tǒng)

13、的基礎(chǔ)架構(gòu)來講，由于過去那個大而全的開發(fā)模式導(dǎo)致核心系統(tǒng)本身的體量非常 大。在一個物理計算節(jié)點上需要支撐多個相互復(fù)雜調(diào)用的應(yīng)用服務(wù)。這也就形成了過去的大 型機、中型機、小型機的物理格局現(xiàn)狀。從單個業(yè)務(wù)或者交易的處理上來講，這種架構(gòu)一定 是穩(wěn)定的、高效的、安全的。隨著信息技術(shù)的發(fā)展，我相信今天各家銀行的大部分系統(tǒng)都已經(jīng)實現(xiàn)了資源的虛擬化級池化，最起碼在應(yīng)用節(jié)點的部署上基本都實現(xiàn)了。至于資源池虛擬化的好處就不用多說了， 但是為什么核心系統(tǒng)遲遲沒有實現(xiàn)呢？原因有兩點：首先是核心系統(tǒng)的體量太大，如果不是新建，很難把握核心系統(tǒng)內(nèi)部的邏輯關(guān)系實現(xiàn)架構(gòu)的調(diào)整。再有就是由于核心系統(tǒng)的體量太大，那么它對資源的需

14、求量也是非常大的，不是單個虛擬資源能夠解決的問題。我們暫不從架構(gòu)本身的先進性來談這個問題，我們從服務(wù)的角度來考慮考慮。相信核心 系統(tǒng)本身承載的幾個模塊兒：存貸產(chǎn)品、公共服務(wù)、客戶信息、賬務(wù)核算。過去這幾個模塊 兒可能相對提供服務(wù)的負載相對比較固定，所以一直安全穩(wěn)定運行了這么多年。但是今天在 渠道整合以及渠道創(chuàng)新的沖擊下，相信它們各自在日常的運行當中提供服務(wù)的頻率以及他們 需要的負載是存在巨大差異的，而且是在不斷變化的，在這種場景下如果繼續(xù)保持物理資源的獨立格局限制，那么必然帶來的是應(yīng)用上和業(yè)務(wù)上的僵硬。擴展性短板其基礎(chǔ)架構(gòu)擴展性瓶頸主要集中在兩個方面，第一個方面就是支撐銀行核心系統(tǒng)平臺層的擴展

15、性瓶頸，另外一個方面就是核心系統(tǒng)應(yīng)用層本身擴展性的瓶頸。從平臺層本身來講， 由于傳統(tǒng)模式下的核心系統(tǒng)的高負載高壓力的特點，大多數(shù)銀行都是采用小型機、中型機、 大型機等集中式物理架構(gòu)。那么今天互聯(lián)網(wǎng)業(yè)務(wù)的膨脹式發(fā)展必然會引發(fā)核心系統(tǒng)基礎(chǔ)架構(gòu)處理能力本身的擴展性要求，主要表現(xiàn)為處理并發(fā)以及處理復(fù)雜業(yè)務(wù)邏輯上的需求。這種基礎(chǔ)架構(gòu)本身是不具備靈活擴展能力的。另外一方面由于互聯(lián)網(wǎng)渠道業(yè)務(wù)的擴展，金融管理制度的快速改革，金融賬戶屬性本身的多樣化發(fā)展等因素造成的應(yīng)用層面本身的變更也變得比以往任何一個時期都會頻繁，但是我們傳統(tǒng)的核心系統(tǒng)都是會計、產(chǎn)品、總賬、聯(lián)機等模塊兒相對比較聚合的狀態(tài)，任何一個小的改動都可

16、能影響到所有的模塊兒，再有就是傳統(tǒng)核心系統(tǒng)業(yè)務(wù)邏輯似乎都有一個通病，就是對并發(fā)處理設(shè)計的考慮很少，這些因素都會限制我們核心系統(tǒng)應(yīng)用層的擴展性。數(shù)據(jù)安全局限性所謂數(shù)據(jù)安全性主要是指在面臨設(shè)備物理故障或者是邏輯錯誤的時候，核心系統(tǒng)數(shù)據(jù)本 身的容錯能力。這個容錯能力一方面來自于基礎(chǔ)架構(gòu)本身的數(shù)據(jù)高可用能力以及數(shù)據(jù)的容災(zāi) 架構(gòu)設(shè)計，另外一方面來源于應(yīng)用層對于數(shù)據(jù)在整個流動過程中的校驗保護機制。傳統(tǒng)核心系統(tǒng)的數(shù)據(jù)保護從基礎(chǔ)架構(gòu)層主要有幾種方式：其一是基于傳統(tǒng)塊兒存儲做的數(shù)據(jù)復(fù)制架構(gòu)，例如 HP 的 CA 技術(shù)、IBM 的 PPRC 技術(shù)，EMC 的 SRDF 技術(shù)等；其二是基于操作系統(tǒng)卷管理器層面做的邏

17、輯鏡像技術(shù)，例如 LVM 的鏡像技術(shù)、VxVM 的鏡像技術(shù)等；其三是基于數(shù)據(jù)庫層面的復(fù)制技術(shù)，例如 Oracle 的 DG 技術(shù)，DB2 的 HADR 技術(shù)等； 其四是為了避免數(shù)據(jù)邏輯錯誤而采用的傳統(tǒng)備份技術(shù)。這些技術(shù)往往各有優(yōu)缺點，單一的技術(shù)體系或者是把不合適的技術(shù)手段運用到核心系統(tǒng)數(shù)據(jù)保護上，在真正發(fā)生問題的時候，后果往往是災(zāi)難性的。近些年來一些現(xiàn)實的案例也充分說明了這一點，例如本來的雙機高可用技術(shù)由于設(shè)備參數(shù)的錯誤設(shè)置導(dǎo)致腦裂問題，由于物理的復(fù)制缺乏邏輯校驗導(dǎo)致了故障場合下的數(shù)據(jù)切換失敗等等。傳統(tǒng)核心系統(tǒng)大部分采用的是胖核心的架構(gòu)模式，其實有一個非常重要的原因就是過去 的技術(shù)體系當中，應(yīng)

18、用系統(tǒng)之間、應(yīng)用模塊兒之間、應(yīng)用接口之間的數(shù)據(jù)校驗處理機制相對 比較空白，一旦一個業(yè)務(wù)邏輯跨越了比較多的環(huán)節(jié)，那么非常普通的一個傳輸錯誤、網(wǎng)絡(luò)中 斷或擁堵等事件就有可能導(dǎo)致整個交易處理的不一致或者是不完整。為了避免這種情況的發(fā) 生，過去的核心系統(tǒng)盡量將很多的關(guān)聯(lián)模塊兒放在了同一個物理平臺上，以集中的方式來避 免這種情況的發(fā)生。但是隨著今天我們業(yè)務(wù)的膨脹式發(fā)展，這種集中到了一定的規(guī)模就形成 了一個限制。要打破這個限制將應(yīng)用解耦并分布式部署，需要解決的一個難題就是要以完善 的校驗機制來保障整體業(yè)務(wù)邏輯的完整性和一致性。銀行核心基礎(chǔ)架構(gòu)重構(gòu)必要性三步走戰(zhàn)略分析傳統(tǒng)核心系統(tǒng)大部分采用的是胖核心的架構(gòu)模

19、式，其實有一個非常重要的原因就是過去 的技術(shù)體系當中，應(yīng)用系統(tǒng)之間、應(yīng)用模塊兒之間、應(yīng)用接口之間的數(shù)據(jù)校驗處理機制相對 早期的銀行 IT 主要解決傳統(tǒng)手工記賬與傳票核算電子化等核心任務(wù)，主要采用“柜面服務(wù)+核心系統(tǒng)”為主體的系統(tǒng)框架，應(yīng)用邏輯和 IT 系統(tǒng)都極為簡單。隨著銀行業(yè)務(wù)的高速發(fā)展，陸續(xù)推出銀行卡、支付結(jié)算、投資理財?shù)刃滦偷臉I(yè)務(wù)產(chǎn)品和種類，核心系統(tǒng)所承載 的交易范圍越來越多，系統(tǒng)規(guī)模愈發(fā)龐大，處理壓力日趨增大;同時，原有面向會計核算的 系統(tǒng)架構(gòu)已經(jīng)難以滿足快速變化的市場需要以及客戶的多樣化需求。為解決上述問題，首先應(yīng)當對核心系統(tǒng)的功能進行重新定義，并對核心系統(tǒng)與其他應(yīng)用 系統(tǒng)之間的業(yè)務(wù)

20、流程進行重新設(shè)計，通過對核心系統(tǒng)的合理“瘦身”，以開放、靈活、松耦 合的原則重新布局銀行的各類應(yīng)用系統(tǒng)。為了快速滿足市場變化以及客戶差異化需求，還需 要大幅度提升核心系統(tǒng)等底層平臺的參數(shù)化配置能力。遵循上述建設(shè)思路，北京銀行通過“三步走”戰(zhàn)略，實現(xiàn)了 IT 架構(gòu)的華麗轉(zhuǎn)身。第一步，對核心系統(tǒng)的功能進行重新定位，將非核心系統(tǒng)交易處理功能逐步剝離使其成 為專業(yè)應(yīng)用系統(tǒng)，并搭建全行級的企業(yè)服務(wù)總線，負責對全行交易進行統(tǒng)一調(diào)配管理，同時 使用科學(xué)有效的全行級的服務(wù)治理手段，實現(xiàn)對服務(wù)的分析、定義、設(shè)計、實現(xiàn)、組合、運 行、退出等全生命周期過程制定標準規(guī)范并嚴格執(zhí)行，保證服務(wù)的統(tǒng)一性和標準化。第二步，剝

21、離核心系統(tǒng)中數(shù)據(jù)處理加工及統(tǒng)計分析的功能，搭建企業(yè)級的操作數(shù)據(jù)存儲 平臺，經(jīng)過幾年的系統(tǒng)建設(shè)，逐步形成“全行級數(shù)據(jù)服務(wù)總線”，與企業(yè)服務(wù)總線共同組成“雙總線”架構(gòu)。除此以外，通過制訂全行統(tǒng)一的數(shù)據(jù)標準并引入數(shù)據(jù)管控平臺，落地數(shù)據(jù) 治理，大幅度提升數(shù)據(jù)質(zhì)量。第三步，打造“以客戶為中心”的新一代核心業(yè)務(wù)系統(tǒng)，重構(gòu)核心系統(tǒng)交易調(diào)度框架及日終批處理平臺，全面提升參數(shù)化配置能力，使得系統(tǒng)架構(gòu)整體水平及性能得到了質(zhì)的飛躍。 在技術(shù)平臺全面升級的基礎(chǔ)上，新一代核心系統(tǒng)實現(xiàn)了客戶信息統(tǒng)一管理、利率及費率差異化定價、產(chǎn)品參數(shù)靈活配置、賬戶多層級化并向產(chǎn)品型賬戶轉(zhuǎn)型、網(wǎng)點層級多樣化、會計引擎模型化的業(yè)務(wù)支持能力。

22、依托參數(shù)化的架構(gòu)設(shè)計使得新一代核心系統(tǒng)成為業(yè)務(wù)發(fā)展的強力支撐。面對 FinTech 時代的機遇與挑戰(zhàn)全球金融治理核心機構(gòu)金融穩(wěn)定理事會對“金融科技”的定義為：金融科技是指技術(shù)帶 來的金融創(chuàng)新，它能創(chuàng)造新的業(yè)務(wù)模式、應(yīng)用、流程或產(chǎn)品，從而對金融市場、金融機構(gòu)或 金融服務(wù)的提供方式造成重大影響。FinTech 時代對銀行信息系統(tǒng)，特別是整體 IT 架構(gòu)帶來了深遠的影響和變革。下面，將結(jié)合北京銀行近幾年的實踐經(jīng)驗，從應(yīng)用架構(gòu)、技術(shù)架構(gòu) 和數(shù)據(jù)架構(gòu)三個方面，討論中小銀行在新時期中進行 IT 架構(gòu)轉(zhuǎn)型的思路、難點及對策。1.加強統(tǒng)一管理，應(yīng)用架構(gòu)向“大平臺+微服務(wù)”方式轉(zhuǎn)型應(yīng)用架構(gòu)是對實現(xiàn)業(yè)務(wù)能力、支撐

23、業(yè)務(wù)發(fā)展的應(yīng)用功能的結(jié)構(gòu)化描述，重點需回答業(yè)務(wù) 功能在哪里實現(xiàn)最優(yōu)的問題，包括應(yīng)用的設(shè)計原則、分層分域與邊界定義、集成關(guān)系等方面 的內(nèi)容。中小銀行受自身技術(shù)資源有限的實際問題，存在根據(jù)部門需求被動開發(fā)，缺少統(tǒng)一 的應(yīng)用架構(gòu)規(guī)劃、設(shè)計及統(tǒng)一管理，部分功能重復(fù)建設(shè)。鑒于上述問題，在應(yīng)用架構(gòu)轉(zhuǎn)型方面，我們要考慮如下幾方面問題：一是基于現(xiàn)有系統(tǒng)功能，整合應(yīng)用，解決目前應(yīng)用系統(tǒng)多、功能分散、重疊、界限不清 晰等問題，推動全行集中的“企業(yè)級”應(yīng)用平臺建設(shè)，即進行“大平臺”建設(shè)。二是面對新時期下業(yè)務(wù)和產(chǎn)品需求的不斷變化，原有的單體應(yīng)用模式由于耦合度高，關(guān)聯(lián)依賴復(fù)雜，變更的時候在開發(fā)和運維方面都存在較大困難和

24、風險;同時，也不便于進行擴 展。為解決上述問題，需要對業(yè)務(wù)系統(tǒng)進行充分的組件化和服務(wù)化，構(gòu)建“微服務(wù)”架構(gòu)。三是全面提升“IT 服務(wù) IT”的能力，通過平臺工具的引入，提升開發(fā)、測試及運維的自動化智能化水平，加強統(tǒng)一管理。例如：北京銀行使用的項目流程全生命周期管理平臺， 通過一系列自動化部署流水線完成環(huán)境部署、代碼的發(fā)布、測試、版本管理等項目流程全生命周期的管理，合理利用有限的開發(fā)資源，很好地滿足了業(yè)務(wù)和監(jiān)管要求。2.以混合式集成解決方案，平穩(wěn)推進技術(shù)架構(gòu)轉(zhuǎn)型技術(shù)架構(gòu)是支撐應(yīng)用和數(shù)據(jù)的技術(shù)基礎(chǔ)?；ヂ?lián)網(wǎng)、數(shù)字化及智能化等一些系列技術(shù)的高 速發(fā)展，對傳統(tǒng)銀行業(yè)的支付、理財、客戶管理等核心領(lǐng)域產(chǎn)生了

25、極大的沖擊和挑戰(zhàn)。中小 銀行大多采用的是小型機和高端存儲，不利于資源靈活管理和成本合理控制，原有的集中式 閉源技術(shù)架構(gòu)已經(jīng)不能滿足互聯(lián)網(wǎng)時代開放、高效、彈性及多并發(fā)的業(yè)務(wù)發(fā)展要求。通過對自身業(yè)務(wù)與技術(shù)現(xiàn)狀的深度分析以及對未來 IT 發(fā)展趨勢的合理預(yù)估，北京銀行逐步確定以“便捷容量、彈性擴展、自主可控、高質(zhì)高效、安全穩(wěn)定”為主要目標搭建技術(shù)架構(gòu);以將集中式與分布式進行有機結(jié)合的混合式集成為總體策略保證傳統(tǒng)金融對于“高標 準、高性能、低風險、低成本”的特性要求;明確以“先管理后交易系統(tǒng)、先普通后關(guān)鍵系統(tǒng)、先外圍后核心系統(tǒng)”為實施步驟平穩(wěn)開啟技術(shù)架構(gòu)轉(zhuǎn)型之路，并積極探索“主機下移”的解決方案，減少對

26、主機的單方面依賴， 也為未來全面國產(chǎn)化之路奠定堅實基礎(chǔ)。3.構(gòu)建多元化數(shù)據(jù)架構(gòu)，滿足多樣化數(shù)據(jù)服務(wù)需求數(shù)據(jù)架構(gòu)立足于解決數(shù)據(jù)全生命周期過程的統(tǒng)一管理，包括數(shù)據(jù)產(chǎn)生、數(shù)據(jù)流轉(zhuǎn)、數(shù)據(jù) 整合、數(shù)據(jù)應(yīng)用、數(shù)據(jù)歸檔與消亡等內(nèi)容。中小銀行在數(shù)據(jù)應(yīng)用建設(shè)方面起步較晚，數(shù)據(jù)處 理的方式比較單一，對于海量的、不同類型的數(shù)據(jù)加工及應(yīng)用能力不足，已不能滿足新時期 業(yè)務(wù)對于數(shù)據(jù)分析的需求。只有通過創(chuàng)建全方位數(shù)據(jù)整合能力的多元化數(shù)據(jù)架構(gòu)，才能滿足“大數(shù)據(jù)”時代不同層次的多樣化數(shù)據(jù)服務(wù)要求。北京銀行經(jīng)過多年的努力，在數(shù)據(jù)架構(gòu)上逐步構(gòu)建起由源系統(tǒng)數(shù)據(jù)處理、采集交換、數(shù)據(jù)傳輸、加工計算、數(shù)據(jù)應(yīng)用等多方面共同組建的“智慧數(shù)據(jù)生

27、態(tài)圈”，實現(xiàn)標準化、平臺化、智能化、移動化的發(fā)展要求。在這其中，大數(shù)據(jù)平臺是整體數(shù)據(jù)架構(gòu)中的重要支點，該平臺依托大數(shù)據(jù)及云計算技術(shù)自建，以“優(yōu)化客戶體驗、強化風險防控、建設(shè)智能化運營、 提升營銷能力”為切入點，持續(xù)打造智能高效的“金融大數(shù)據(jù)服務(wù)”，逐步實現(xiàn)從數(shù)據(jù)支撐向數(shù)據(jù)驅(qū)動的模式轉(zhuǎn)變。北京銀行依托大數(shù)據(jù)平臺對行內(nèi)數(shù)據(jù)、外部數(shù)據(jù)進行沉淀整合，對外提供個人、企業(yè)身 份信息核驗，個人、企業(yè)工商報告及消費行為偏好報告等實時查詢服務(wù)接口，有效提升全行 的業(yè)務(wù)營銷能力水平，全面降低獲客、營銷成本;同時，從交易反欺詐模型、大數(shù)據(jù)征信體系兩個領(lǐng)域入手，探索大數(shù)據(jù)與銀行風險防控工作的結(jié)合點與創(chuàng)新業(yè)務(wù)應(yīng)用模式，

28、主動加強 金融風險管理，為全行客戶的資金安全保駕護航。集中式與分布式集中或者分布本身是兩種處理問題的方式或者風格，就像是同步與異步一樣。但是市場 上的一些流行理念卻活生生將集中與分布劃分成了兩個彼此對峙的陣營。在所謂的集中式陣 營中，如果一定要找一個靶子，那么基于 IBM Z（俗稱主機）的技術(shù)堆?？梢运愕蒙稀氨娛钢摹钡募惺皆搭^。傳統(tǒng)銀行的 IT 架構(gòu)目前多為集中式和分布式的混合架構(gòu)，不同的系統(tǒng)架構(gòu)遷移策略也不一樣。對于集中式架構(gòu)，多為大型機或者小型機服務(wù)器，操作系統(tǒng)為 UNIX 系統(tǒng)。集中式架構(gòu)的過渡，對于原有系統(tǒng)的架構(gòu)沒有任何影響，因為 LINUXONE 本身也是大型機服務(wù)器的架構(gòu)，唯一

29、需要處理的，就是 UNIX 系統(tǒng)的遷移，提前做好操作系統(tǒng)的兼容性適配工作就可以完成遷移。對于分布式架構(gòu)，大部分銀行是基于 X86 服務(wù)器構(gòu)建，操作系統(tǒng)多為 LINUX。對于這種架構(gòu)，操作系統(tǒng)的兼容性測試和適配的工作量要小一些，因為 linuxone 本身對LINUX 系統(tǒng)支持的很好。linuxone 在支持分布式架構(gòu)方面，主要是在單臺 CPU 中通過虛擬化擴展的形式，創(chuàng)建一個可軟件定義的分布式系統(tǒng)。對于分布式架構(gòu)來說，如果遠有分布 式架構(gòu)是基于物理機，可以直接進行 P2V 的遷移。如果原有的分布式架構(gòu)是基于虛擬機， 那么更多的工作量是完成 V2V 的遷移。因為 linuxone 支持的虛擬化是

30、 Z/VM 和 KVM，在虛擬機轉(zhuǎn)換方面，適配的工作量更大一些。在現(xiàn)階段，銀行可以選擇一些新建的系統(tǒng)或者非核心的系統(tǒng)，在 linuxone 上先完成部分業(yè)務(wù)的部署，建立基于 LINUXONE 的基礎(chǔ)架構(gòu)，然后根據(jù)業(yè)務(wù)系統(tǒng)的情況，逐步完成架構(gòu)的過渡。linuxone 對比大型機和小型機。linuxone 基于大型機 Z13 基礎(chǔ)架構(gòu)，所以對比大型機，只是在操作系統(tǒng)上可以支持 linux，其他特性與大型機完全一樣。對比小型機，在性能上，LinuxONE 有著非常強大的硬件配置，最多可支持 141 顆處理器，8000 臺虛擬機以及成千上萬的容器，并且具有多級虛擬化能力。在安全性上，有著比小型機更可靠

31、的安全架構(gòu)。LinuxONE 是商用服務(wù)器中唯一獲得 EAL 5+最高等級安全認證。提供從芯片、交易、到檔案全面且高速的加密機制，確保對關(guān)鍵敏感的數(shù)據(jù)與資料的保護。LinuxONE 的加密技術(shù)，能夠?qū)⒚恳还P交易記錄進行實時監(jiān)測，并保護數(shù)據(jù)安全，可以為銀行提供最安全的信息系統(tǒng)。主機的技術(shù)堆棧在半個世紀前開啟了以服務(wù)器為核心的計算時代，發(fā)展和成熟于業(yè)務(wù)、 數(shù)據(jù)大集中處理時代。其一直立足于關(guān)鍵事務(wù)處理的企業(yè)級計算。作為一個發(fā)展最為成熟的通用商業(yè)計算體系，不難發(fā)現(xiàn)其技術(shù)堆棧秉持的一些關(guān)鍵性假設(shè)和原則：以成熟、領(lǐng)先的貫穿全堆棧的系統(tǒng)優(yōu)勢，來為用戶換取在開發(fā)交付和運行維護上更大的專注性。這其實是多年來流行

32、在企業(yè)級計算領(lǐng)域的一個重要原則Separation of Concerns（關(guān)注分離、專于其事）。經(jīng)典的企業(yè) IT 組織格局以及技術(shù)支持生態(tài)也都是基于這樣的基本原型逐漸演化形成的。在成熟的主機用戶身上，我們能夠看到一些典型的特征。比如，從系統(tǒng)角度：精簡的系統(tǒng)部署、充裕的擴展能力、連續(xù)的業(yè)務(wù)可用、集約的運維規(guī)模。從開發(fā)角度：專注于業(yè)務(wù)的開發(fā)模式，更好的架構(gòu)包容性（有容乃大）。不難發(fā)現(xiàn)，要達到的首要目標并不是所謂集中，而是打造一個最高品質(zhì)的通用商業(yè)計算體系。換言之，就是通過系統(tǒng)化的技術(shù)手段保障其核心價值的可復(fù)制性和普遍性，而不依賴 于對運維或應(yīng)用等外部因素提出過多特質(zhì)化的要求。當然，在多年的實踐中

33、，運維和應(yīng)用也 一定會根據(jù)系統(tǒng)的特點（優(yōu)勢以及短板）而發(fā)展出具有獨特性的資產(chǎn)?？梢哉f這幾年主機用 戶一系列以減少消耗為導(dǎo)向的優(yōu)化舉措也是非常有益的探索。但是我們應(yīng)該認識到，一個成 熟的商業(yè)技術(shù)堆棧與興起于互聯(lián)網(wǎng)超級玩家的技術(shù)堆棧在發(fā)展模式上的確存在差異。超級互 聯(lián)網(wǎng)玩家追求對于技術(shù)全棧盡可能的自主掌控是基于其超級龐大的業(yè)務(wù)和科技體量、爆發(fā)式 的發(fā)展增速，以及業(yè)務(wù)和科技融為一體的企業(yè)基因。商業(yè)系統(tǒng)的運作則是基于契約式。說白 了就是，用經(jīng)濟手段交換能力，用合約手段保障承諾。當然，今天國內(nèi)互聯(lián)網(wǎng)巨頭紛紛開始 以科技輸出進入這個領(lǐng)域，都面臨著從“自食狗糧”向商業(yè)契約化的過渡和轉(zhuǎn)化。這一點遲 早會把不同

34、基因的參與者拉回到同一個角斗場。其次，就算回到集中與分布的技術(shù)紛爭。我認為也很難完全把一個技術(shù)體系簡單歸為集中或者分布。很多人可能沒有認識到，基于主機的傳統(tǒng)交易中間件 CICS 本身就是為分布式服務(wù)而構(gòu)建。CICS 的縮寫據(jù)說可以解釋為 CICS IS CONTAINER SERVICE，這并非笑談！ 作為分布式服務(wù)所需要的容器化運行環(huán)境、遠程調(diào)用框架、服務(wù)的注冊、發(fā)現(xiàn)、路由、負載均衡等等能力在這個技術(shù)體系內(nèi)都有對應(yīng)的經(jīng)典實現(xiàn)方式。至于在物理部署模式上是采用水平擴展、垂直擴展或者混合模式，更多的是從性能的優(yōu)化、運維的效率、擴展的空間等多種角度來綜合考慮。反觀近年來市場上流行的分布式架構(gòu)實踐，其

35、實質(zhì)往往無外乎是開源技術(shù)的采納，應(yīng)用的服務(wù)化（甚至微服務(wù)化）、以及去狀態(tài)或者無狀態(tài)化，嚴格一致性的妥協(xié)， 廣泛的異步式處理，再加上數(shù)據(jù)的業(yè)務(wù)性或者技術(shù)性分散。在過往全球互聯(lián)網(wǎng)巨頭的實踐中， 這些手段的運用都是有其上下文和條件的。但是如果將之作為一個教條的概念，甚至賦予新一代“銀彈”的期望，不求甚解甚至囫圇吞棗，也會帶來負面而深遠的影響?！安话阉须u蛋放到一個籃子里”成為了所謂分布式陣營的一個貌似絕對正確的理念和 旗號。在實踐中，可以看到不少過于僵化和教條的做法，比如在沒有擴展性瓶頸的前提下單 純用技術(shù)性手段強行分拆數(shù)據(jù)。我認為一些問題已經(jīng)超越了雞蛋和籃子的關(guān)系。而是要不要 把蛋黃和蛋清放到一個

36、蛋殼里！未來運維和業(yè)務(wù)將不得不為這些麻煩而買單。套用流行的佛系用語，“是諸法空相，不生不滅，不垢不凈，不增不減，不集中不分布， 不同步不異步?！睂嵺`者需要睜開智慧的架構(gòu)之眼，以己之眼明辨是非，而不人云亦云。微服務(wù)與巨石隨著微服務(wù)架構(gòu)的迅速躥紅，這顆新的“銀彈”又給市場注入了巨大的想象力。人們在傳統(tǒng)的交付和運維苦海中掙扎著，怎么加班交付都不夠敏捷，怎么解耦應(yīng)用都還是一團亂麻， 怎么監(jiān)控生產(chǎn)都還是如履薄冰。與微服務(wù)相對的巨石架構(gòu)隨即躺槍成為了萬惡之源，如過街老鼠人人喊打。然而如果我們稍微研究一下微服務(wù)架構(gòu)的歷史沿革和實質(zhì)，會發(fā)現(xiàn)其關(guān)鍵強調(diào)的是一種 架構(gòu)和交付的文化，“微”的目的是為了服務(wù)能夠獨立、

37、自治的垂直演進。記得曾經(jīng)有一種 非常有趣的說法，單個微服務(wù)的設(shè)計、開發(fā)、測試和運維的所有人加在一起吃飯，只需要兩 張批薩就夠了，這是就是著名的“Two pizza team”原則。在這種模式之下，devOps 幾乎毫無例外的是剛需。然而如果僅僅是教條地將微服務(wù)作為一種普遍性準則，不分場合，生 搬硬套，同樣會遭遇尷尬。在實踐中，人們往往最多的問題就是，找不到傳統(tǒng)應(yīng)用重構(gòu)為微服務(wù)的合適場景。而且這種架構(gòu)和交付方式對于經(jīng)典的組織結(jié)構(gòu)和文化也造成了極大的沖 擊。如何跳出傳統(tǒng)的紅海（苦海）的束縛，找到一片業(yè)務(wù)和架構(gòu)的藍海，成為了很多實踐者 關(guān)心的話題?；氐健肮歉小钡默F(xiàn)實中，對于傳統(tǒng)企業(yè)而言，微服務(wù)的采納

38、有可能并不是一個最急迫的 核心問題。而且我們相信經(jīng)過這么多年應(yīng)用的治理，在一個有一定水準的企業(yè)內(nèi)，巨石架構(gòu) 的弊端也沒有外界想象那么嚴重。但是在實踐中，必須承認服務(wù)化治理本身的確是一個既急 迫又長期的過程，自 SOA 時代以來落下的功課早晚是要交上的?！案邇?nèi)聚、低耦合”在什么時代都是服務(wù)的黃金法則。我們在前面曾經(jīng)提到過，主機架構(gòu)對于應(yīng)用有著更大的包容性。這一點在服務(wù)治理的歷程中是可以得到印證的。記得十幾年前，IBM 就建議主機 CICS 的用戶在部署應(yīng)用時，盡量將長交易、短交易，不同業(yè)務(wù)目標的應(yīng)用分配部署到不同群組的 CICS 容器（region）中去。這樣可以利用系統(tǒng)對于混雜工作負載的調(diào)度管

39、理能力，充分地利用系統(tǒng)資源。然而這么多年過去了，大多數(shù)國內(nèi)銀行的主機用戶仍然利用著系統(tǒng)尚充裕的垂直擴展性，保持著近乎極簡的部署模式。不少用戶不分或者極少劃分業(yè)務(wù)群組，在每個 CICS 容器中都部署近乎全量的應(yīng)用，并通過外圍路由來區(qū)分不同類型的訪問請求。這樣的做法從積極的意義上，可以認為充分利用了系統(tǒng)架構(gòu)的優(yōu)勢，簡化了開發(fā)、部署和運維，并通過架構(gòu)的包容性為服務(wù)治理爭取了時間。然而，人們也應(yīng)該意識到，這樣的架構(gòu)如果平移到另外一個所謂的分布式應(yīng)用平臺，其結(jié)果將是災(zāi)難的。毋庸置疑，服務(wù)的治理是一項長治久安的百年大計。從這個意義上，微服務(wù)本身并不是 解決這個問題的“一招鮮”。微服務(wù)或者巨石作為兩種不同風

40、格的架構(gòu)，從長遠來講是可以 共生共存的，更何況在二者之間還有廣闊的地帶。關(guān)鍵是找到彼此最合適的領(lǐng)域。我認為在 垂直的數(shù)字化場景這個領(lǐng)域中，可以嘗試在新的數(shù)字化堆棧中開展微服務(wù)的嘗試。當然這種 嘗試也需要找到合適的抓手，不可僵化套用。比如，在一些大型企業(yè)的實踐中，先通過無狀 態(tài)的彈性應(yīng)用去推動新技術(shù)堆棧的發(fā)展，有可能是更加符合現(xiàn)實訴求的。最后，通過以上的探討，讓我們嘗試拋出一些架構(gòu)融合的觀察和建議。在傳統(tǒng)經(jīng)典的技術(shù)堆棧（如基于 IBM Z）之外，新的技術(shù)堆棧（所謂數(shù)字化雙翼）正在成型，并迅速演變。這些技術(shù)堆棧之間并不能簡單用商業(yè)/開源，集中/分布，傳統(tǒng)/顛覆來進行概念化二元對峙 的區(qū)分。在各自的

41、發(fā)展路徑上，甚至是可以彼此參照，互相包容，共同進化的。銀行核心基礎(chǔ)架構(gòu)重構(gòu)難點分析交易和核算的分離問題交易和核算分離呢，其實說白了，就是先讓客戶將業(yè)務(wù)做完，而賬務(wù)處理呢卻在晚上通 過跑批的方式處理。這樣就是借貸平衡記賬了，比如我們現(xiàn)在的一個繳費交易，首先從客戶 賬務(wù)上扣錢，然后記到一個對應(yīng)的內(nèi)部科目里去。這樣就實現(xiàn)了一借一貸。但是這樣的記賬 有個弊端。就是客戶可以很多個，但是對應(yīng)的內(nèi)部科目卻只有一個，由于每次記賬這個內(nèi)部 戶都是被鎖住的（防止臟數(shù)據(jù)），那么如果在大量并發(fā)交易的時候，很多客戶都在繳費，就 會出現(xiàn)鎖表的情況，造成業(yè)務(wù)中斷。還是這個繳費功能，白天客戶繳費了，客戶金額立刻扣減，同時登記

42、一個客戶臺賬。等到晚上批處理來執(zhí)行的時候，批量的將這個臺賬數(shù)據(jù)跑入內(nèi) 部戶中完成記賬處理。這樣從客戶的角度來看，金額實時減少了，說明繳費成功了，而對于 賬務(wù)處理，在晚上按順序批量執(zhí)行，不會出現(xiàn)大量搶占內(nèi)部戶資源的情況。系統(tǒng)去耦問題這個解耦其實是核心系統(tǒng)本身的解耦，因為傳統(tǒng)核心系統(tǒng)將聯(lián)機業(yè)務(wù)和賬務(wù)業(yè)務(wù)結(jié)合到 一起，非常龐大。而且聯(lián)機業(yè)務(wù)本身各個模塊之間得耦合度非常高，產(chǎn)品靈活性及架構(gòu)的擴 展性不是非常好。所以這個解耦是說我首先要把核心系統(tǒng)中的總賬剝離，然后將聯(lián)機業(yè)務(wù)涉 及的模塊進行重新分析設(shè)計，改造為內(nèi)部耦合性相對小一些的架構(gòu)，從而可以支撐應(yīng)用節(jié)點 本身的分布式部署。并不是說要打破現(xiàn)有的總線架構(gòu)

43、。實際上核心系統(tǒng)的去耦主要就是要把總賬系統(tǒng)剝離，總賬系統(tǒng)從核心剝離出來之后，核心面臨的集中式壓力就分散，其他交易系統(tǒng)與原有核心系統(tǒng)的架構(gòu)耦合性就會小，整體架構(gòu)的耦合性都會降低。同時也為未來互聯(lián)網(wǎng)的核心交易業(yè)務(wù)架構(gòu)的變革提供了條件。業(yè)界并沒有一個統(tǒng)一的定義，但是有一點可以明確的是銀行的核心系統(tǒng)不是一個單一的應(yīng)用系統(tǒng)，而是一組應(yīng)用系統(tǒng)的組合。具體包括：存款管理、貸款管理、支付結(jié)算、會計處理、總賬處理等等。在這些模塊兒當中有一個核心的線索可以將其串聯(lián)到一起就是賬戶數(shù)據(jù)，這個賬戶既有個人的賬戶也有機構(gòu)的賬戶。所有圍繞賬戶產(chǎn)生的一些借貸行為組成了銀行核心系統(tǒng)聯(lián)機業(yè)務(wù)的流轉(zhuǎn)以及會計實務(wù)的處理。今天的互聯(lián)網(wǎng)

44、時代，很多銀行的互聯(lián)網(wǎng)業(yè)務(wù)已經(jīng)成為銀行的核心業(yè)務(wù)。要解決傳統(tǒng)核心的去耦問題，首先第一個需要解決的問題就是根據(jù)自己銀行的業(yè)務(wù)發(fā)展模式來決定是否將互聯(lián)網(wǎng)的賬戶和本地賬戶進行分離，也就是一類賬戶和二三類賬戶的分離。如果我們的二三類賬戶業(yè)務(wù)非常龐大，而且發(fā)展趨勢頁也非常明確，那么不僅僅需要核心系統(tǒng)本身的賬戶分離，更需要業(yè)務(wù)部門重新來定義二三類賬戶業(yè)務(wù)的管理模式和權(quán)限歸屬問題。接下來，第二個需要解決的問題就是聯(lián)機業(yè)務(wù)和總賬業(yè)務(wù)的分離。總賬業(yè)務(wù)系統(tǒng)可以單獨切分為一個獨立系統(tǒng)，聯(lián)機業(yè)務(wù)、信貸業(yè)務(wù)、支付業(yè)務(wù)、互聯(lián)網(wǎng)交易等等這些業(yè)務(wù)完全成為一中對等的模式來支撐銀行的日常金融服務(wù)?？傎~業(yè)務(wù)系統(tǒng)成為一個單獨的可以對

45、接各種業(yè)務(wù)類型的賬務(wù)平臺，由于它屬于賬務(wù)類系統(tǒng)沒有實時提供金融服務(wù)的屬性，也就不會成為業(yè)務(wù)服務(wù)瓶頸，它的處理只影響銀行后臺會計事務(wù)，屬于內(nèi)部業(yè)務(wù)。第三個需要解決的問題就是聯(lián)機業(yè)務(wù)系統(tǒng)內(nèi)部本身的設(shè)計。以客戶為中心的設(shè)計，建立基于全面了解客戶能力的客戶統(tǒng)一視圖，提供客戶統(tǒng)一入口的客戶服務(wù)全面整合。建立組合模式的產(chǎn)品工廠， 可以根據(jù)業(yè)務(wù)創(chuàng)新進行產(chǎn)品的靈活組合，而不是單一死板的產(chǎn)品模式。實現(xiàn)靈活定義的利率工廠模式，根據(jù)未來客戶服務(wù)的市場化建立內(nèi)部定價體系，提供多維參數(shù)化定價體制，提供多為利率組合模式，既可以實現(xiàn)通用計算模型又可以實現(xiàn)特殊化的利率模型。多法人支持， 在數(shù)據(jù)庫底層設(shè)計中引入法人字段，做到數(shù)

46、據(jù)隔離?？傎~系統(tǒng)從核心剝離要看剝離到什么程度了，剝離得太多，那原來的核心就不叫核心了，涉及到具體業(yè)務(wù)層面的術(shù)語我不太清楚，我的個人理解是，要剝離就得梳理總賬系統(tǒng)的組成， 這些組成之間又有哪些關(guān)聯(lián)性，剝離之后如何繼續(xù)進行關(guān)聯(lián)，跨系統(tǒng)關(guān)聯(lián)的性能和并發(fā)如何考慮；應(yīng)用系統(tǒng)（無論是外部交易系統(tǒng)還是核心內(nèi)部交易系統(tǒng)）對這些組成的交易事務(wù)是在一個事務(wù)內(nèi)部還是分開多個事務(wù)（如果這些組成剝離開來，各系統(tǒng)的交易事務(wù)也得考慮到剝離）；剝離后的批量問題如何解決（原來集中式批量，現(xiàn)在分布式批量）；剝離后原核心的定位和新核心的位置（兩個或多核心間其實也是緊耦合的，畢竟總賬中的子集還是要依賴于 總賬的，如果剝離了子集，核心

47、總賬還是要出來獲取子集的）；如何分步式，穩(wěn)妥的進行剝 離，也就是剝離方式的安全有序性問題等等。耦合性最大的應(yīng)該是賬務(wù)系統(tǒng)，清算頭寸等，幾乎只要是交易系統(tǒng)，只要涉及到賬務(wù)， 也就是錢的交易，都要記賬，那就得去核心系統(tǒng)的數(shù)據(jù)庫里記，取核心系統(tǒng)數(shù)據(jù)庫里查，否者各個系統(tǒng)都管著各自的賬務(wù)，那這個賬務(wù)同步的開銷就更大，沒法進行下去了，就想?yún)^(qū)塊鏈那樣，賬務(wù)交易實時性能更是無法保證。所以說交易系統(tǒng)和賬務(wù)系統(tǒng)是高度耦合的，無論這個交易系統(tǒng)是在核心內(nèi)部還是核心外圍，都有這樣的問題，所以問題的核心不在于剝不剝離交易系統(tǒng)，而在于剝不剝離賬務(wù)類系統(tǒng)，也就是雙核心或者多核心其實做的事情都是一件事，就是賬務(wù)類系統(tǒng)剝離，有的

48、把清算頭寸從核心剝離，有的把互聯(lián)網(wǎng)賬務(wù)處理從核心剝離等等，為的就是減輕傳統(tǒng)核心的壓力，組建多核心，但可能也會帶來很多新的問題，剝離的過程也是需要仔細梳理和思考的，比如賬務(wù)和清算頭寸是緊耦合的，頭寸剝離出去后，核心還可能要出去取這個頭寸信息，那此時的核心就不是真核心后臺了，而是多核心共存，互相融合的了，這個融合又可能帶來很多新的問題和思考，總之不是那么輕易的事，任重道遠， 穩(wěn)重求進。思維轉(zhuǎn)型思想決定著行為。長久以來，傳統(tǒng)銀行的科技團隊始終將確?？蛻艉豌y行的資金安全作 為恪守鐵律，特別是對于承受風險能力較弱的中小銀行來說，安全生產(chǎn)就是生命線。所以在 技術(shù)的選擇上，使用最成熟、最穩(wěn)定、最可靠的技術(shù)，

49、一直是中小銀行的基本工作原則。因 此，在最初的技術(shù)選擇上無一例外地選擇使用以 IOE 為代表的成熟商用軟件和體系架構(gòu)。新時代的 IT 架構(gòu)轉(zhuǎn)型，在設(shè)計、開發(fā)、測試、運維及管理上需要有不同的思維和技術(shù)能力，這對現(xiàn)有技術(shù)團隊的思想觀念和工作模式造成了巨大的沖擊，需要有一個“脫胎換骨” 的轉(zhuǎn)變過程。例如北京銀行高層領(lǐng)導(dǎo)高度重視 IT 架構(gòu)轉(zhuǎn)型工作，清晰且堅定地向自己的管理層和員工，傳達銀行在 IT 架構(gòu)轉(zhuǎn)型的戰(zhàn)略和想法，并推動銀行全身心擁抱這一場全新的技術(shù)革命;二是虛心向在新技術(shù)應(yīng)用方面更具優(yōu)勢的互聯(lián)網(wǎng)公司及金融同業(yè)學(xué)習，并采用多 種形式的交流合作，做好新時代下的系統(tǒng)能力建設(shè);三是技術(shù)部門與業(yè)務(wù)部門

50、需要更加密切 合作，協(xié)同推進新的 IT 架構(gòu)發(fā)揮最大價值。思維轉(zhuǎn)型相對于原有的 IT 架構(gòu)，新的技術(shù)架構(gòu)對于設(shè)計、研發(fā)、運維等人員的知識結(jié)構(gòu)有著新的要求，架構(gòu)轉(zhuǎn)型需要與人員知識結(jié)構(gòu)轉(zhuǎn)型相配套。目前的新興技術(shù)具有類型多、變化快等 特點，中小銀行沒有充足的技術(shù)力量對這些新技術(shù)進行跟蹤與探索。而研究這些技術(shù)的大多 為創(chuàng)新型公司，一般規(guī)模小、成立時間短且缺乏對銀行應(yīng)用特點的理解和金融行業(yè)的實戰(zhàn)經(jīng) 驗，難以提供持續(xù)穩(wěn)定的技術(shù)支持。一是在諸如云計算、區(qū)塊鏈等關(guān)鍵技術(shù)上組建研發(fā)實驗室，對新技術(shù)進行研究、創(chuàng)新、 試點和培訓(xùn)，為銀行發(fā)展儲備相關(guān)技術(shù)人才。將專業(yè)性人才的培養(yǎng)集中在核心技術(shù)領(lǐng)域，可以使得中小銀行中有

51、限的 IT 人員發(fā)揮最大價值，切實保證關(guān)鍵技術(shù)的自主可控;二是高度重視并積極建立吸引和留住關(guān)鍵人才的長效機制，通過建立信息科技專業(yè)技術(shù)崗位序列，讓專家型技術(shù)人員有良好的職業(yè)發(fā)展空間;三是積極開展與國內(nèi)有實力供應(yīng)商的合作，通過成立金融科技實驗室聯(lián)合開展技術(shù)難點的研發(fā)和攻關(guān)，共同找到新技術(shù)在銀行領(lǐng)域應(yīng)用的最優(yōu)方 案。多年的架構(gòu)轉(zhuǎn)型發(fā)展之路，充滿了困難、阻礙，有過質(zhì)疑、猶豫，也有成效和欣喜。在FinTech 時代的浪潮下，隨著轉(zhuǎn)型工作向銀行核心應(yīng)用及基礎(chǔ)環(huán)節(jié)的推進，難度、風險和困難也將越來越大。對此，北京銀行將在戰(zhàn)略上堅定不移，在戰(zhàn)術(shù)上高度重視，在實施上細致 入微。在確?，F(xiàn)有信息系統(tǒng)穩(wěn)定、安全運營的

52、前提下，順利推進架構(gòu)轉(zhuǎn)型的全面勝利，從而 有力支撐業(yè)務(wù)創(chuàng)新!規(guī)劃篇銀行核心系統(tǒng)去耦設(shè)計業(yè)務(wù)模塊的邏輯拆分業(yè)界并沒有一個統(tǒng)一的定義，但是有一點可以明確的是銀行的核心系統(tǒng)不是一個單一的應(yīng)用系統(tǒng)，而是一組應(yīng)用系統(tǒng)的組合。具體包括：存款管理、貸款管理、支付結(jié)算、會計處理、總賬處理等等。在這些模塊兒當中有一個核心的線索可以將其串聯(lián)到一起就是賬戶數(shù)據(jù)， 這個賬戶既有個人的賬戶也有機構(gòu)的賬戶。所有圍繞賬戶產(chǎn)生的一些借貸行為組成了銀行核心系統(tǒng)聯(lián)機業(yè)務(wù)的流轉(zhuǎn)以及會計實務(wù)的處理。今天的互聯(lián)網(wǎng)時代，很多銀行的互聯(lián)網(wǎng)業(yè)務(wù)已經(jīng)成為銀行的核心業(yè)務(wù)。要解決傳統(tǒng)核心的去耦問題，首先第一個需要解決的問題就是根據(jù)自己銀行的業(yè)務(wù)發(fā)

53、展模式來決定是否將互聯(lián)網(wǎng)的賬戶和本地賬戶進行分離，也就是一類賬戶和二三類賬戶的分離。如果我們的二三類賬戶業(yè)務(wù)非常龐大，而且發(fā)展趨勢頁也非常明確，那么不僅僅需要核心系統(tǒng)本身的賬戶分離， 更需要業(yè)務(wù)部門重新來定義二三類賬戶業(yè)務(wù)的管理模式和權(quán)限歸屬問題。接下來，第二個需要解決的問題就是聯(lián)機業(yè)務(wù)和總賬業(yè)務(wù)的分離?？傎~業(yè)務(wù)系統(tǒng)可以單 獨切分為一個獨立系統(tǒng)，聯(lián)機業(yè)務(wù)、信貸業(yè)務(wù)、支付業(yè)務(wù)、互聯(lián)網(wǎng)交易等等這些業(yè)務(wù)完全成 為一中對等的模式來支撐銀行的日常金融服務(wù)。總賬業(yè)務(wù)系統(tǒng)成為一個單獨的可以對接各種 業(yè)務(wù)類型的賬務(wù)平臺，由于它屬于賬務(wù)類系統(tǒng)沒有實時提供金融服務(wù)的屬性，也就不會成為 業(yè)務(wù)服務(wù)瓶頸，它的處理只影響

54、銀行后臺會計事務(wù)，屬于內(nèi)部業(yè)務(wù)。第三個需要解決的問題就是聯(lián)機業(yè)務(wù)系統(tǒng)內(nèi)部本身的設(shè)計。以客戶為中心的設(shè)計，建立基于全面了解客戶能力的客戶統(tǒng)一視圖，提供客戶統(tǒng)一入口的客戶服務(wù)全面整合。建立組合模式的產(chǎn)品工廠，可以根據(jù)業(yè)務(wù)創(chuàng)新進行產(chǎn)品的靈活組合，而不是單一死板的產(chǎn)品模式。實現(xiàn)靈活定義的利率工廠模式，根據(jù)未來客戶服務(wù)的市場化建立內(nèi)部定價體系，提供多維參數(shù)化定價體制，提供多為利率組合模式，既可以實現(xiàn)通用計算模型又可以實現(xiàn)特殊化的利率模型。 多法人支持，在數(shù)據(jù)庫底層設(shè)計中引入法人字段，做到數(shù)據(jù)隔離。應(yīng)用模塊的分布式部署傳統(tǒng)的核心系統(tǒng)，無論是聯(lián)機應(yīng)用還是批量應(yīng)用基本的部署方式還是物理機的獨立格局部署方式，從

55、其他系統(tǒng)的業(yè)務(wù)請求到核心系統(tǒng)內(nèi)部請求的處理基本都屬于獨立格局，這個流程涉及到的請求、調(diào)用、處理等事務(wù)基本都屬于固定模式，沒有任何動態(tài)分配算法來支撐。 我們在核心系統(tǒng)去耦工程當中，非常重要的一個事情就是要解決這種獨立部署的格局。首先就是要解決核心系統(tǒng)聯(lián)機應(yīng)用的負載均衡支持問題。有些核心系統(tǒng)的設(shè)計已經(jīng)采取了分布式 架構(gòu)，利用一些分布式中間件以及緩存的中間件來實現(xiàn)聯(lián)機業(yè)務(wù)請求的分布式部署。這是一 種趨勢，無論是用 Tuxedo 軟件負載，還是利用 F5 硬件負載，都應(yīng)該實現(xiàn)應(yīng)用層面的負載均衡部署。當然支撐這種部署方式的前提是應(yīng)用層面必須具備對業(yè)務(wù)處理邏輯的校驗，無論 是會話策略還是鏈接策略，都因該具

56、備交易處理的邏輯校驗功能，以支撐核心系統(tǒng)業(yè)務(wù)處理 的分布式架構(gòu)?；A(chǔ)架構(gòu)的邏輯解耦核心系統(tǒng)的基礎(chǔ)架構(gòu)主要是指支撐核心系統(tǒng)應(yīng)用以及核心系統(tǒng)數(shù)據(jù)庫的平臺架構(gòu)，既包 括計算資源的集成又包括存儲資源的集成。如果采用大型機、中型機、小型機的架構(gòu)勢必會 導(dǎo)致核心系統(tǒng)本身的靈活性受限。如果采用通用 X86 分布式的架構(gòu)又會擔心其處理能受限導(dǎo)致系統(tǒng)整體的穩(wěn)定性和高可用性受限。因此在核心系統(tǒng)基礎(chǔ)架構(gòu)的選型過程中既要考慮到單個物理資源的處理能力受限問題， 又要考慮到單個物理資源對整體核心系統(tǒng)群的擴展性和靈活性受限的問題。因此在當前環(huán)境下，應(yīng)該結(jié)合二者之優(yōu)勢來設(shè)計整體核心系統(tǒng)整體。單個物理資源的選型我們要考慮到其足

57、夠的處理能力，橫向的資源擴展我們要考慮到資源的橫向組合性，足夠適應(yīng)虛擬化技術(shù)、資源池技術(shù)帶給我們的資源整合優(yōu)勢。數(shù)據(jù)庫的選型我們要充分注重其縱向的處理能力，應(yīng)用服務(wù)器的選型我們要充分注重其橫向的擴展能力。資源池化方法應(yīng)用和資源的映射關(guān)系分析說到應(yīng)用和資源的映射關(guān)系，其實就是什么類型的應(yīng)用需要什么類型的資源去支撐。比 如說有些應(yīng)用是計算秘密性應(yīng)用，有些應(yīng)用是內(nèi)存密集性應(yīng)用，還有一些應(yīng)用是存儲密集性 應(yīng)用。但是對于資源實體，也就是我們的服務(wù)器或者是存儲設(shè)備來講，是無法實現(xiàn)特定應(yīng)用 類型的資源配比，因此一定會造成某一方面或者某幾方面的資源浪費而某一方面的資源緊缺。因此，在核心系統(tǒng)各種資源池化的整體思

58、路框架之下，首先是要分析出核心系統(tǒng)各個業(yè) 務(wù)模塊，各個層面對資源的需求狀況究竟是什么樣的。例如，可能聯(lián)機交易業(yè)務(wù)的處理更多 的是內(nèi)存資源的耗用，而批量業(yè)務(wù)的處理更多的是 CPU 資源的耗用。數(shù)據(jù)庫內(nèi)的數(shù)據(jù)處理更多的是 IO 和內(nèi)存資源的耗用。只有前期對于核心系統(tǒng)各個模塊兒的資源耗用特點有一個清晰的把我，那么才能支撐我們后期對資源池的劃分和虛擬資源的設(shè)計。虛擬化方案的設(shè)計多為虛擬化方案的設(shè)計，主要是指對虛擬化解決方案的選型以及具體虛擬化設(shè)計方案的 規(guī)劃。對于虛擬化解決方案的選型主要依賴于我們所選硬件的兼容性要求，例如 X86 服務(wù)器的虛擬化解決方案相對寬松，而 Power 架構(gòu)服務(wù)器的虛擬化解決

59、方案相對比較狹隘。所以今天的客戶更多是選擇了基于 X86 架構(gòu)的服務(wù)器資源。當我們選定了支撐我們虛擬化方案的硬件資源之后，那么就是對具體虛擬化設(shè)計方案的規(guī) 劃。主要涉及以下幾個方面的詳細規(guī)劃設(shè)計：一、各個資源池的設(shè)計無論是什么樣的資源池化技術(shù)，一個共通的功能特性就是可以實現(xiàn) CPU、內(nèi)存、網(wǎng)絡(luò)、存儲等資源的共享技術(shù)。用哪些物理資源去組織成為那些可用的資源池就是我們這一個步驟需要考慮的問題。對于應(yīng)用服務(wù)器資源來講，彼此產(chǎn)生沖突的是 CPU 和內(nèi)存資源，需要建立統(tǒng)一的 CPU 和內(nèi)存資源池。對于數(shù)據(jù)庫服務(wù)器來講，除了內(nèi)存資源的沖突之外，更多的是存儲資源的沖突，因此需要建立統(tǒng)一的存儲資源池。二、虛擬

60、服務(wù)器對資源的分配策略由于不同的應(yīng)用對不同資源的獲取和訪問具有不同的屬性特點以及不同的重要程度之分，因此我們在對不同虛擬服務(wù)器的資源分配上需要建立不同的動態(tài)分配以及優(yōu)先級策略分 配模型。比如，在數(shù)據(jù)庫服務(wù)器和應(yīng)用服務(wù)器的資源競爭策略當中，那么數(shù)據(jù)庫服務(wù)器的內(nèi) 存優(yōu)先級一定高于其他服務(wù)器；在聯(lián)機應(yīng)用服務(wù)器和批量應(yīng)用服務(wù)器的資源競爭當中，一定 會有時間段的區(qū)分，設(shè)計爭奪策略的時候需要充分考慮到時間段的分布；數(shù)據(jù)庫服務(wù)器和其 他服務(wù)器存儲資源的使用和競爭過程當中，一定會有 IOPS 和高可用的區(qū)分，在具體的分配策略當中我們需要充分考慮到這一點的區(qū)別。三、資源的動態(tài)優(yōu)化策略所謂資源的動態(tài)優(yōu)化策略是指在