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

1、銀行新核心基礎(chǔ)架構(gòu)方案設(shè)計(jì)技術(shù)手冊(cè)目 錄分析篇4銀行核心基礎(chǔ)架構(gòu)的現(xiàn)狀4銀行核心基礎(chǔ)架構(gòu)面臨問題5耦合性問題5資源格局限制5擴(kuò)展性短板6數(shù)據(jù)安全局限性6銀行核心基礎(chǔ)架構(gòu)重構(gòu)必要性6三步走戰(zhàn)略分析7面對(duì) FinTech 時(shí)代的機(jī)遇與挑戰(zhàn)7集中式與分布式9微服務(wù)與巨石10銀行核心基礎(chǔ)架構(gòu)重構(gòu)難點(diǎn)分析11交易和核算的分離問題11系統(tǒng)去耦問題11思維轉(zhuǎn)型12思維轉(zhuǎn)型13規(guī)劃篇13 HYPERLINK l _TOC_250024 銀行核心系統(tǒng)去耦設(shè)計(jì)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è)計(jì)15一、各個(gè)資源池的設(shè)計(jì)15二、虛擬服務(wù)器對(duì)資源的分配策略15三、資源的動(dòng)態(tài)優(yōu)化策略15 HYPERLINK l _TOC_250017 基礎(chǔ)架構(gòu)擴(kuò)展性方法16 HYPERLINK l _TOC_250016 前提條件16 HYPERLINK l _TOC_250015 應(yīng)用層的擴(kuò)展性設(shè)計(jì)16 HYPERLINK l _T

3、OC_250014 數(shù)據(jù)層的擴(kuò)展性設(shè)計(jì)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è)計(jì)實(shí)施篇18 HYPERLINK l _TOC_250009 銀行核心系統(tǒng)存儲(chǔ)解決方案18 HYPERLINK l _TOC_250008 銀行核心系統(tǒng)數(shù)據(jù)庫解決方案19 HYPERLINK l _TOC_250007 架構(gòu)規(guī)劃設(shè)計(jì)原則19 HYPERLINK l _TOC_250006

4、 數(shù)據(jù)庫性能影響20 HYPERLINK l _TOC_250005 Power 虛擬化架構(gòu)設(shè)計(jì)要點(diǎn)20 HYPERLINK l _TOC_250004 同時(shí)滿足 IOPS 和吞吐量21 HYPERLINK l _TOC_250003 數(shù)據(jù)庫集群的心跳網(wǎng)絡(luò)設(shè)計(jì)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 虛擬化與物理機(jī)混合部署23文檔介紹目標(biāo)人群本文章適合銀行從事 IT 建設(shè)的架構(gòu)師、工程師以及主導(dǎo)核心系統(tǒng)基礎(chǔ)架構(gòu)及

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

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

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

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

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

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

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

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

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

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

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

16、能影響到所有的模塊兒，再有就是傳統(tǒng)核心系統(tǒng)業(yè)務(wù)邏輯似乎都有一個(gè)通病，就是對(duì)并發(fā)處理設(shè)計(jì)的考慮很少，這些因素都會(huì)限制我們核心系統(tǒng)應(yīng)用層的擴(kuò)展性。數(shù)據(jù)安全局限性所謂數(shù)據(jù)安全性主要是指在面臨設(shè)備物理故障或者是邏輯錯(cuò)誤的時(shí)候，核心系統(tǒng)數(shù)據(jù)本 身的容錯(cuò)能力。這個(gè)容錯(cuò)能力一方面來自于基礎(chǔ)架構(gòu)本身的數(shù)據(jù)高可用能力以及數(shù)據(jù)的容災(zāi) 架構(gòu)設(shè)計(jì)，另外一方面來源于應(yīng)用層對(duì)于數(shù)據(jù)在整個(gè)流動(dòng)過程中的校驗(yàn)保護(hù)機(jī)制。傳統(tǒng)核心系統(tǒng)的數(shù)據(jù)保護(hù)從基礎(chǔ)架構(gòu)層主要有幾種方式：其一是基于傳統(tǒng)塊兒存儲(chǔ)做的數(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ù)邏輯錯(cuò)誤而采用的傳統(tǒng)備份技術(shù)。這些技術(shù)往往各有優(yōu)缺點(diǎn)，單一的技術(shù)體系或者是把不合適的技術(shù)手段運(yùn)用到核心系統(tǒng)數(shù)據(jù)保護(hù)上，在真正發(fā)生問題的時(shí)候，后果往往是災(zāi)難性的。近些年來一些現(xiàn)實(shí)的案例也充分說明了這一點(diǎn)，例如本來的雙機(jī)高可用技術(shù)由于設(shè)備參數(shù)的錯(cuò)誤設(shè)置導(dǎo)致腦裂問題，由于物理的復(fù)制缺乏邏輯校驗(yàn)導(dǎo)致了故障場(chǎng)合下的數(shù)據(jù)切換失敗等等。傳統(tǒng)核心系統(tǒng)大部分采用的是胖核心的架構(gòu)模式，其實(shí)有一個(gè)非常重要的原因就是過去 的技術(shù)體系當(dāng)中，應(yīng)

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

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

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

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

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

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

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

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

26、主機(jī)的單方面依賴， 也為未來全面國(guó)產(chǎn)化之路奠定堅(jiān)實(shí)基礎(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ù)處 理的方式比較單一，對(duì)于海量的、不同類型的數(shù)據(jù)加工及應(yīng)用能力不足，已不能滿足新時(shí)期 業(yè)務(wù)對(duì)于數(shù)據(jù)分析的需求。只有通過創(chuàng)建全方位數(shù)據(jù)整合能力的多元化數(shù)據(jù)架構(gòu)，才能滿足“大數(shù)據(jù)”時(shí)代不同層次的多樣化數(shù)據(jù)服務(wù)要求。北京銀行經(jīng)過多年的努力，在數(shù)據(jù)架構(gòu)上逐步構(gòu)建起由源系統(tǒng)數(shù)據(jù)處理、采集交換、數(shù)據(jù)傳輸、加工計(jì)算、數(shù)據(jù)應(yīng)用等多方面共同組建的“智慧數(shù)據(jù)生

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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