中小銀行核心系統(tǒng)基礎(chǔ)架構(gòu)實踐規(guī)劃

1、中小銀行核心系統(tǒng)基礎(chǔ)架構(gòu)實踐規(guī)劃【摘要】：隨著全球 IT 產(chǎn)業(yè)的飛速發(fā)展，金融行業(yè)的 IT 建設(shè)逐步成為主導(dǎo)金融企業(yè)業(yè)務(wù)發(fā)展的核心驅(qū)動力。對于銀行的整個 IT 架構(gòu)從應(yīng)用的角度來看，會分為幾個層面：渠道層、總線層、交易系統(tǒng)層、數(shù)據(jù)層等。其中交易系統(tǒng)層是最關(guān)鍵的要素，所有銀行業(yè)中的借貸業(yè)務(wù)最終的完成會在交易系統(tǒng)層完成，所有業(yè)務(wù)的賬戶信息以及賬務(wù)都要在交易系統(tǒng)中的一個關(guān)鍵節(jié)點中流轉(zhuǎn)和記錄，這個關(guān)鍵節(jié)點就是我們熟知的核心系統(tǒng)。由此可見核心系統(tǒng)對于銀行的重要性，同樣核心系統(tǒng)的基礎(chǔ)架構(gòu)規(guī)劃和實踐又是支撐核心系統(tǒng)能夠良好運轉(zhuǎn)并且健康擴展的前提條件。本文以中小銀行核心系統(tǒng)基礎(chǔ)架構(gòu)為著眼點，深度分析并總結(jié)在規(guī)

2、劃和實踐過程中需要解決的一些關(guān)鍵問題，旨在為同業(yè)在此類項目建設(shè)過程中提供一些啟示和幫助。【關(guān)鍵字】：中小銀行；核心系統(tǒng)目 錄 TOC o 1-3 h z u HYPERLINK l _Toc524637443 1.中小銀行核心系統(tǒng)基礎(chǔ)架構(gòu)現(xiàn)狀 PAGEREF _Toc524637443 h 3 HYPERLINK l _Toc524637444 2.中小銀行核心系統(tǒng)基礎(chǔ)架構(gòu)現(xiàn)有問題 PAGEREF _Toc524637444 h 4 HYPERLINK l _Toc524637445 2.1.耦合性太高 PAGEREF _Toc524637445 h 4 HYPERLINK l _Toc524

3、637446 2.2.資源的物理格局限制 PAGEREF _Toc524637446 h 4 HYPERLINK l _Toc524637447 2.3.基礎(chǔ)架構(gòu)擴展性存在短板 PAGEREF _Toc524637447 h 6 HYPERLINK l _Toc524637448 2.4.數(shù)據(jù)安全技術(shù)局限性 PAGEREF _Toc524637448 h 6 HYPERLINK l _Toc524637449 3.中小銀行核心系統(tǒng)基礎(chǔ)架構(gòu)的優(yōu)化策略 PAGEREF _Toc524637449 h 7 HYPERLINK l _Toc524637450 3.1.去耦化設(shè)計 PAGEREF _To

4、c524637450 h 7 HYPERLINK l _Toc524637451 3.2.資源池化設(shè)計 PAGEREF _Toc524637451 h 9 HYPERLINK l _Toc524637452 3.3.基礎(chǔ)架構(gòu)擴展性設(shè)計 PAGEREF _Toc524637452 h 12 HYPERLINK l _Toc524637453 3.4.數(shù)據(jù)安全性設(shè)計 PAGEREF _Toc524637453 h 14 HYPERLINK l _Toc524637454 4.總結(jié)及展望 PAGEREF _Toc524637454 h 17中小銀行核心系統(tǒng)基礎(chǔ)架構(gòu)現(xiàn)狀伴隨著信息技術(shù)的發(fā)展歷程，國內(nèi)的

5、金融行業(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ǔ)的分散式信息管理域。這個階段談不上信息化的變革，僅僅是電腦取代了手動操作，完全是一種分散式的管理模式。第二階段：八十年代中期到九十年代末期，這一階段銀行開始通過使用計算機網(wǎng)絡(luò)技術(shù)實現(xiàn)銀行部分業(yè)務(wù)的實時聯(lián)機處理，并逐步實現(xiàn)了銀行在一定區(qū)域范圍內(nèi)的數(shù)據(jù)集中及互聯(lián)互通；區(qū)域集中讓所轄銀行得以共享數(shù)據(jù)資源，統(tǒng)一

6、了科目設(shè)置，改進(jìn)了業(yè)務(wù)流程。第三階段：二十世紀(jì)初至今，這一階段即所謂的數(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è)標(biāo)準(zhǔn)，并且這些技術(shù)及標(biāo)準(zhǔn)在不斷的優(yōu)化發(fā)展過程當(dāng)中。國內(nèi)大部分城市商業(yè)銀行，中小股份制銀行等都是在第三個階段直接發(fā)展起來的。其核心系統(tǒng)的建設(shè)也是直接套用既有標(biāo)準(zhǔn)規(guī)范進(jìn)行實施的。應(yīng)用架構(gòu)基本遵循著總線架構(gòu)模式，業(yè)務(wù)處理層面既承擔(dān)了后臺聯(lián)機業(yè)務(wù)處理又承擔(dān)了銀行賬務(wù)處理；基礎(chǔ)架構(gòu)層面根據(jù)具體的業(yè)務(wù)負(fù)載不同基本會采

7、用 IBM 的大型機、中型機、小型機等物理機模式；數(shù)據(jù)庫層面基本采用的比較成熟的關(guān)系型數(shù)據(jù)庫例如 DB2、Oracle、Infomix 等；高可用架構(gòu)多數(shù)采用的是前一個時代的操作系統(tǒng)層面的雙機熱備軟件實現(xiàn)的主備模式。中小銀行核心系統(tǒng)基礎(chǔ)架構(gòu)現(xiàn)有問題耦合性太高從銀行的數(shù)據(jù)大集中到目前來講，銀行業(yè)務(wù)已經(jīng)經(jīng)歷了將近 20 年的發(fā)展。在互聯(lián)網(wǎng)和信息化沒有爆發(fā)的年代，銀行的業(yè)務(wù)類型相對固定，發(fā)展較為穩(wěn)定。銀行的核心系統(tǒng)大部分處于安全性、穩(wěn)定性以及高效性的考慮形成了大核心或者旁核心的局面，也就是既有存貸產(chǎn)品服務(wù)功能又有基礎(chǔ)性的公共服務(wù)功能還有銀行的會計核算功能。近些年來隨著互聯(lián)網(wǎng)以及信息化的爆發(fā)式推進(jìn)，銀

8、行的業(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è)標(biāo)準(zhǔn)及國家政策的變化要求銀行能夠快速適應(yīng)并變革。我們舉幾個簡單的例子：比如說為了爭取客戶，對于符合某些條件的客戶的存款產(chǎn)品，我們需要定制特殊的利率或者算法，如果我們的核心系統(tǒng)并非基于面向?qū)ο蠡蛘叻?wù)的設(shè)計模式來實現(xiàn)的松耦合架構(gòu)，那么可能會因為我們流程化的產(chǎn)品定義模型以及客戶定義模型導(dǎo)致我們對核心系統(tǒng)內(nèi)部進(jìn)行較為大的變更；比如說我們面臨互利網(wǎng)的環(huán)境希望推

9、出有特色的的產(chǎn)品來吸引客戶，很可能由于核心系統(tǒng)的接口模式固定化導(dǎo)致我們無法快速實現(xiàn)產(chǎn)品的創(chuàng)新和退出；比如說我們面臨的營改增問題，如果賬務(wù)核算和聯(lián)機業(yè)務(wù)以及公共處理模塊兒能夠邏輯隔離，那么這類的問題就不會帶給我們核心系統(tǒng)巨大的改動量，也不必為此承擔(dān)巨大風(fēng)險。諸如此類問題會有很多，所有的這些挑戰(zhàn)都不是過去那個胖核心或者大核心環(huán)境能夠解決的問題。這就要求銀行的核心系統(tǒng)在應(yīng)用系統(tǒng)層面必須實現(xiàn)對象化服務(wù)化的松耦合模式。資源的物理格局限制從系統(tǒng)的基礎(chǔ)架構(gòu)來講，由于過去那個大而全的開發(fā)模式導(dǎo)致核心系統(tǒng)本身的體量非常 大。在一個物理計算節(jié)點上需要支撐多個相互復(fù)雜調(diào)用的應(yīng)用服務(wù)。這也就形成了過去的大型機、中型機

10、、小型機的物理格局現(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)的體量太大，那么它對資源的需求量也是非常大的，不是單個虛擬資源能夠解決的問題。我們暫不從架構(gòu)本身的先進(jìn)性來談這個問題，我們從服務(wù)的角度來考慮考慮。相信核心系統(tǒng)本身承載的幾個模塊兒：存貸產(chǎn)品、公共服務(wù)

11、、客戶信息、賬務(wù)核算。過去這幾個模塊兒可能相對提供服務(wù)的負(fù)載相對比較固定，所以一直安全穩(wěn)定運行了這么多年。但是今天在渠道整合以及渠道創(chuàng)新的沖擊下，相信它們各自在日常的運行當(dāng)中提供服務(wù)的頻率以及他們需要的負(fù)載是存在巨大差異的，而且是在不斷變化的，在這種場景下如果繼續(xù)保持物理資源的獨立格局限制，那么必然帶來的是應(yīng)用上和業(yè)務(wù)上的僵硬。基礎(chǔ)架構(gòu)擴展性存在短板其基礎(chǔ)架構(gòu)擴展性瓶頸主要集中在兩個方面，第一個方面就是支撐銀行核心系統(tǒng)平臺層的擴展性瓶頸，另外一個方面就是核心系統(tǒng)應(yīng)用層本身擴展性的瓶頸。從平臺層本身來講，由于傳統(tǒng)模式下的核心系統(tǒng)的高負(fù)載高壓力的特點，大多數(shù)銀行都是采用小型機、中型 機、大型機等集

12、中式物理架構(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)，任何一個小的改動都可能影響到所有的模塊兒，再有就是傳統(tǒng)核心系統(tǒng)業(yè)務(wù)邏輯似乎都有一個通病，就是對并發(fā)處理設(shè)計的考慮很少，這些因素都會限制我們核心系統(tǒng)應(yīng)用層的擴展性。數(shù)據(jù)安全技術(shù)局限性所

13、謂數(shù)據(jù)安全性主要是指在面臨設(shè)備物理故障或者是邏輯錯誤的時候，核心系統(tǒng)數(shù)據(jù)本身的容錯能力。這個容錯能力一方面來自于基礎(chǔ)架構(gòu)本身的數(shù)據(jù)高可用能力以及數(shù)據(jù)的容災(zāi)架構(gòu)設(shè)計，另外一方面來源于應(yīng)用層對于數(shù)據(jù)在整個流動過程中的校驗保護(hù)機制。基礎(chǔ)架構(gòu)層面?zhèn)鹘y(tǒng)核心系統(tǒng)的數(shù)據(jù)保護(hù)從基礎(chǔ)架構(gòu)層主要有幾種方式：其一是基于傳統(tǒng)塊兒存儲做的數(shù)據(jù)復(fù)制架構(gòu)，例如 HP 的 CA 技術(shù)、IBM 的 PPRC 技術(shù)，EMC 的 SRDF 技術(shù)等；其二是基于操作系統(tǒng)卷管理器層面做的邏輯鏡像技術(shù)，例如 LVM 的鏡像技術(shù)、VxVM 的鏡像技術(shù)等；其三是基于數(shù)據(jù)庫層面的復(fù)制技術(shù)，例如 Oracle 的 DG 技術(shù)，DB2 的 HADR

14、 技術(shù)等；其四是為了避免數(shù)據(jù)邏輯錯誤而采用的傳統(tǒng)備份技術(shù)。這些技術(shù)往往各有優(yōu)缺點，單一的技術(shù)體系或者是把不合適的技術(shù)手段運用到核心系統(tǒng)數(shù)據(jù)保護(hù)上，在真正發(fā)生問題的時候，后果往往是災(zāi)難性的。近些年來一些現(xiàn)實的案例也充分說明了這一點，例如本來的雙機高可用技術(shù)由于設(shè)備參數(shù)的錯誤設(shè)置導(dǎo)致腦裂問題，由于物理的復(fù)制缺乏邏輯校驗導(dǎo)致了故障場合下的數(shù)據(jù)切換失敗等等。應(yīng)用層面?zhèn)鹘y(tǒng)核心系統(tǒng)大部分采用的是胖核心的架構(gòu)模式，其實有一個非常重要的原因就是過去的技術(shù)體系當(dāng)中，應(yīng)用系統(tǒng)之間、應(yīng)用模塊兒之間、應(yīng)用接口之間的數(shù)據(jù)校驗處理機制相對比較空白，一旦一個業(yè)務(wù)邏輯跨越了比較多的環(huán)節(jié)，那么非常普通的一個傳輸錯誤、網(wǎng)絡(luò)中斷或

15、擁堵等事件就有可能導(dǎo)致整個交易處理的不一致或者是不完整。為了避免這種情況的發(fā)生，過去的核心系統(tǒng)盡量將很多的關(guān)聯(lián)模塊兒放在了同一個物理平臺上，以集中的方式來避免這種情況的發(fā)生。但是隨著今天我們業(yè)務(wù)的膨脹式發(fā)展，這種集中到了一定的規(guī)模就形成了一個限制。要打破這個限制將應(yīng)用解耦并分布式部署，需要解決的一個難題就是要以完善的校驗機制來保障整體業(yè)務(wù)邏輯的完整性和一致性。中小銀行核心系統(tǒng)基礎(chǔ)架構(gòu)的優(yōu)化策略去耦化設(shè)計業(yè)務(wù)模塊的邏輯拆分業(yè)界并沒有一個統(tǒng)一的定義，但是有一點可以明確的是銀行的核心系統(tǒng)不是一個單一的應(yīng)用系統(tǒng)，而是一組應(yīng)用系統(tǒng)的組合。具體包括：存款管理、貸款管理、支付結(jié)算、會計處理、總賬處理等等。在

16、這些模塊兒當(dāng)中有一個核心的線索可以將其串聯(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ā)展模式來決定是否將互聯(lián)網(wǎng)的賬戶和本地賬戶進(jìn)行分離，也就是一類賬戶和二三類賬戶的分離。如果我們的二三類賬戶業(yè)務(wù)非常龐大，而且發(fā)展趨勢頁也非常明確，那么不僅僅需要核心系統(tǒng)本身的賬戶分離，更需要業(yè)務(wù)部門重新來定義二三類賬戶業(yè)務(wù)的管理模式和權(quán)限歸屬問題。接下來，第二個需要解決的問題就是聯(lián)機

17、業(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ù)瓶頸，它的處理只影響銀行后臺會計事務(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)新進(jìn)行產(chǎn)品的靈活組合，而不是單一死板的產(chǎn)品模式。實現(xiàn)靈活定義的利率工廠模式

18、，根據(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)用基本的部署方式還是物理機的獨立格局部署方式，從其他系統(tǒng)的業(yè)務(wù)請求到核心系統(tǒng)內(nèi)部請求的處理基本都屬于獨立格局，這個流程涉及到的請求、調(diào)用、處理等事務(wù)基本都屬于固定模式，沒有任何動態(tài)分配算法來支撐。我們在核心系統(tǒng)去耦工程當(dāng)中，非常重要的一個事情就是要解決這種獨立部署的格局。首先就是要解決核心系統(tǒng)聯(lián)機應(yīng)用的負(fù)載均衡支持問題。有些核心系統(tǒng)的設(shè)計已

19、經(jīng)采取了分布式架構(gòu)，利用一些分布式中間件以及緩存的中間件來實現(xiàn)聯(lián)機業(yè)務(wù)請求的分布式部署。這是一種趨勢，無論是用 Tuxedo 軟件負(fù)載，還是利用 F5 硬件負(fù)載，都應(yīng)該實現(xiàn)應(yīng)用層面的負(fù)載均衡部署。當(dāng)然支撐這種部署方式的前提是應(yīng)用層面必須具備對業(yè)務(wù)處理邏輯的校驗，無論是會話策略還是鏈接策略，都因該具備交易處理的邏輯校驗功能，以支撐核心系統(tǒng)業(yè)務(wù)處理的分布式架構(gòu)。基礎(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)又

20、會擔(dān)心其處理能受限導(dǎo)致系統(tǒng)整體的穩(wěn)定性和高可用性受限。因此在核心系統(tǒng)基礎(chǔ)架構(gòu)的選型過程中既要考慮到單個物理資源的處理能力受限問題，又要考慮到單個物理資源對整體核心系統(tǒng)群的擴展性和靈活性受限的問題。因此在當(dāng)前環(huán)境下，應(yīng)該結(jié)合二者之優(yōu)勢來設(shè)計整體核心系統(tǒng)整體。單個物理資源的選型我們要考慮到其足夠的處理能力，橫向的資源擴展我們要考慮到資源的橫向組合性，足夠適應(yīng)虛擬化技 術(shù)、資源池技術(shù)帶給我們的資源整合優(yōu)勢。數(shù)據(jù)庫的選型我們要充分注重其縱向的處理能力，應(yīng)用服務(wù)器的選型我們要充分注重其橫向的擴展能力。資源池化設(shè)計應(yīng)用和資源的映射關(guān)系分析說到應(yīng)用和資源的映射關(guān)系，其實就是什么類型的應(yīng)用需要什么類型的資源去

21、支撐。比如說有些應(yīng)用是計算秘密性應(yīng)用，有些應(yīng)用是內(nèi)存密集性應(yīng)用，還有一些應(yīng)用是存儲密集性應(yīng)用。但是對于資源實體，也就是我們的服務(wù)器或者是存儲設(shè)備來講，是無法實現(xiàn)特定應(yīng)用類型的資源配比，因此一定會造成某一方面或者某幾方面的資源浪費而某一方面的資源緊缺。因此，在核心系統(tǒng)各種資源池化的整體思路框架之下，首先是要分析出核心系統(tǒng)各個業(yè)務(wù)模塊，各個層面對資源的需求狀況究竟是什么樣的。例如，可能聯(lián)機交易業(yè)務(wù)的處理更多的是內(nèi)存資源的耗用，而批量業(yè)務(wù)的處理更多的是 CPU 資源的耗用。數(shù)據(jù)庫內(nèi)的數(shù)據(jù)處理更多的是 IO 和內(nèi)存資源的耗用。只有前期對于核心系統(tǒng)各個模塊兒的資源耗用特點有一個清晰的把我，那么才能支撐我

22、們后期對資源池的劃分和虛擬資源的設(shè)計。虛擬化方案的設(shè)計多為虛擬化方案的設(shè)計，主要是指對虛擬化解決方案的選型以及具體虛擬化設(shè)計方案的規(guī)劃。對于虛擬化解決方案的選型主要依賴于我們所選硬件的兼容性要求，例如 X86 服務(wù)器的虛擬化解決方案相對寬松，而 Power 架構(gòu)服務(wù)器的虛擬化解決方案相對比較狹隘。所以今天的客戶更多是選擇了基于 X86 架構(gòu)的服務(wù)器資源。當(dāng)我們選定了支撐我們虛擬化方案的硬件資源之后，那么就是對具體虛擬化設(shè)計方案的規(guī)劃。主要涉及以下幾個方面的詳細(xì)規(guī)劃設(shè)計：各個資源池的設(shè)計無論是什么樣的資源池化技術(shù)，一個共通的功能特性就是可以實現(xiàn) CPU、內(nèi)存、網(wǎng)絡(luò)、存儲等資源的共享技術(shù)。用哪些物

23、理資源去組織成為那些可用的資源池就是我們這一個步驟需要考慮的問題。對于應(yīng)用服務(wù)器資源來講，彼此產(chǎn)生沖突的是 CPU 和內(nèi)存資源，需要建立統(tǒng)一的 CPU 和內(nèi)存資源池。對于數(shù)據(jù)庫服務(wù)器來講，除了內(nèi)存資源的沖突之外，更多的是存儲資源的沖突，因此需要建立統(tǒng)一的存儲資源池。虛擬服務(wù)器對資源的分配策略由于不同的應(yīng)用對不同資源的獲取和訪問具有不同的屬性特點以及不同的重要程度之分，因此我們在對不同虛擬服務(wù)器的資源分配上需要建立不同的動態(tài)分配以及優(yōu)先級策略分配模型。比如，在數(shù)據(jù)庫服務(wù)器和應(yīng)用服務(wù)器的資源競爭策略當(dāng)中，那么數(shù)據(jù)庫服務(wù)器的內(nèi)存優(yōu)先級一定高于其他服務(wù)器；在聯(lián)機應(yīng)用服務(wù)器和批量應(yīng)用服務(wù)器的資源競爭當(dāng)中

24、，一定會有時間段的區(qū)分，設(shè)計爭奪策略的時候需要充分考慮到時間段的分布；數(shù)據(jù)庫服務(wù)器和其他服務(wù)器存儲資源的使用和競爭過程當(dāng)中，一定會有 IOPS 和高可用的區(qū)分，在具體的分配策略當(dāng)中我們需要充分考慮到這一點的區(qū)別。 資源的動態(tài)優(yōu)化策略所謂資源的動態(tài)優(yōu)化策略是指在不同的時間區(qū)分以及不同的業(yè)務(wù)場合下，資源的分配是否可以根據(jù)實際情況進(jìn)行變化以及如何變化，再有就是資源產(chǎn)生沖突的場合下，可用資源應(yīng)該如何分配。成熟的資源池虛擬化技術(shù)可以通過資源的優(yōu)先級、資源的分配粒度、資源的共享以及回收策略來實現(xiàn)資源在不同時間和空間下的平滑遷移。但是前期條件是我們需要根據(jù)應(yīng)用的不同特點來設(shè)計合理的資源動態(tài)調(diào)配策略，其主要涉

25、及以下幾個方面： 1、虛擬資源和物理資源的分配粒度，保障物理資源得到足夠細(xì)粒度的分配。2、虛擬資源的動態(tài)分配優(yōu)先級，根據(jù)業(yè)務(wù)優(yōu)先級來保障資源的分配優(yōu)先級。3、虛擬資源的預(yù)留及限制規(guī)則，根據(jù)預(yù)留規(guī)則，限制規(guī)則來保障在極端場合下對重要業(yè)務(wù)的保障?；A(chǔ)架構(gòu)擴展性設(shè)計前提條件核心系統(tǒng)的基礎(chǔ)架構(gòu)是否可以實現(xiàn)靈活的擴展性決定于應(yīng)用系統(tǒng)本身的模塊兒化設(shè)計是否合理，主要表現(xiàn)為以下幾個方面：1）聯(lián)機交易是否可以實現(xiàn)跨機處理，也就是聯(lián)機業(yè)務(wù)不同業(yè)務(wù)邏輯是否可以根據(jù)交易當(dāng)中的某些屬性實現(xiàn)物理層面的跨機處理，邏輯層面的業(yè)務(wù)統(tǒng)一性。2）緩存數(shù)據(jù)在整個交易過程的一致性保持，通過緩存中間件、消息中間件等機制實現(xiàn)交易臨時數(shù)據(jù)

26、的一致性保持。聯(lián)機處理業(yè)務(wù)當(dāng)中，每一筆交易實際經(jīng)理的交易邏輯過程可能會比較多，但是如何在分布式處理過程當(dāng)中區(qū)別某一個交易就需要某些會話屬性的臨時數(shù)據(jù)在交易過程中的持久性。3）盡可能的數(shù)據(jù)分離，對于傳統(tǒng)的核心系統(tǒng)來講，業(yè)務(wù)上沒有太多的區(qū)分導(dǎo)致底層數(shù)據(jù)庫當(dāng)中的數(shù)據(jù)區(qū)分度不是非常合理，尤其在并發(fā)較高的場合下，底層數(shù)據(jù)的熱點競爭非常激烈。如果我們要實現(xiàn)基礎(chǔ)架構(gòu)的靈活擴展性，那么從業(yè)務(wù)上需要將底層數(shù)據(jù)盡量重新設(shè)計實現(xiàn)良好的分離性。應(yīng)用層的擴展性設(shè)計應(yīng)用層的擴展性設(shè)計主要取決于以下幾個個方面：首先、從整體架構(gòu)設(shè)計上需要有負(fù)載分發(fā)層來實現(xiàn)業(yè)務(wù)請求的分布式分發(fā)，無論是用 F5 硬件還是用 Tuxedo 等實現(xiàn)

27、的軟件層面的負(fù)載均衡，總之在核心系統(tǒng)應(yīng)用層之前需要一個負(fù)載均衡層來實現(xiàn)整體架構(gòu)的靈活擴展性。只有負(fù)載均衡層作為業(yè)務(wù)請求的接口才能實現(xiàn)應(yīng)用服務(wù)器的靈活增加或者減少。其次、將業(yè)務(wù)交易狀態(tài)進(jìn)行分布式緩存。對于存粹的互聯(lián)網(wǎng)應(yīng)用來講，多數(shù)是無 需保持其業(yè)務(wù)狀態(tài)的，但是對于金融行業(yè)的交易業(yè)務(wù)來講，大部分是需要保持及交易狀態(tài)信息的，也就是說在整個復(fù)雜的交易流程當(dāng)中，其交易狀態(tài)是需要保存下來的。如果要實現(xiàn)整體架構(gòu)的擴展性，那么就必須有相應(yīng)的狀態(tài)數(shù)據(jù)緩存層來支撐其他部件的靈活擴展性。再有、應(yīng)用節(jié)點的選擇要實現(xiàn)虛擬化。用虛擬化之后的規(guī)模效應(yīng)以及其靈活快速 交付性來實現(xiàn)應(yīng)用層的足夠擴展性。這個其實并不難理解，如果還

28、是延續(xù)傳統(tǒng)的物理格局方式，那么即使有前端的負(fù)載均衡層以及分布式緩存或者隊列，也很難實現(xiàn)架構(gòu)的靈活擴展性，瓶頸在于其交付和部署的耗時。數(shù)據(jù)層的擴展性設(shè)計對于核心系統(tǒng)的數(shù)據(jù)層來講，主要是指數(shù)據(jù)庫。對于傳統(tǒng)的胖核心的架構(gòu)來講， 其數(shù)據(jù)庫多屬于重量級數(shù)據(jù)庫，借貸數(shù)據(jù)歸屬于同一個數(shù)據(jù)整體。它對數(shù)據(jù)庫實例的要求更多的是偏向于服務(wù)器縱向處理能力的依賴，橫向的擴展性基本上不具備，橫向的高可用可能更多的是 HA 的模式，高可用能力非常有限。如果在核心系統(tǒng)應(yīng)用架構(gòu)能夠拆分，業(yè)務(wù)可以重新進(jìn)行分析重組的前提條件之下，那么數(shù)據(jù)的訪問也是可以重新再作切分，比如說聯(lián)機和會計總賬數(shù)據(jù)的的適當(dāng)切分，借貸數(shù)據(jù)的切分等。由于銀行的

29、核心交易數(shù)據(jù)都是二維表結(jié)構(gòu)化數(shù)據(jù)，最適合其處理的也是關(guān)系型數(shù) 據(jù)庫，我們不能將架構(gòu)的擴展性寄希望于某些 NOSQL 分部式數(shù)據(jù)庫的引入，這個不合理也不科學(xué)。在既有的關(guān)系型數(shù)據(jù)基礎(chǔ)之上，我們要想提高數(shù)據(jù)庫層面的架構(gòu)擴展性只能通過分庫分表的方式來降低數(shù)據(jù)的熱點問題，從而將不同的業(yè)務(wù)訪問分擔(dān)到不同的數(shù)據(jù)庫實例上，從而實現(xiàn)數(shù)據(jù)庫架構(gòu)的整體擴展性部署。數(shù)據(jù)安全性設(shè)計基礎(chǔ)架構(gòu)層的數(shù)據(jù)保護(hù)技術(shù)選型對于基礎(chǔ)架構(gòu)層的數(shù)據(jù)保護(hù)技術(shù)會有很多，有一些已經(jīng)被金融行業(yè)采用多年。每一種技術(shù)都不是十全十美的，必然會有它的優(yōu)缺點，如果我們能根據(jù)自己的環(huán)境需求來選擇合適的數(shù)據(jù)保護(hù)技術(shù)，那么整體上就會實現(xiàn)對核心系統(tǒng)數(shù)據(jù)的一個完整性

30、保護(hù)。首先，我們基于常見的一些數(shù)據(jù)保護(hù)技術(shù)進(jìn)行逐一優(yōu)缺點分析：存儲層同步異步復(fù)制技術(shù)。系統(tǒng)層或者存儲網(wǎng)關(guān)層的卷鏡像技術(shù)。數(shù)據(jù)庫實例層的高可用技術(shù)。數(shù)據(jù)庫應(yīng)用層的數(shù)據(jù)復(fù)制技術(shù)。對于存儲層的同步異步復(fù)制技術(shù)，一般用于跨站點的容災(zāi)解決方案。其數(shù)據(jù)復(fù)制的性能要比其他的技術(shù)手段快，但是實現(xiàn)的架構(gòu)相對比較固定單一。對于系統(tǒng)層或者存儲網(wǎng)關(guān)層實現(xiàn)的卷鏡像技術(shù)來講，多用于跨設(shè)備跨樓層實現(xiàn)的存儲高可用性保障，但是不適合遠(yuǎn)距離的容災(zāi)保護(hù)。以上這兩種技術(shù)來講，最大的缺陷在于對數(shù)據(jù)的邏輯保護(hù)缺失。而數(shù)據(jù)庫實例層的高可用技術(shù)只能針對數(shù)據(jù)訪問的連續(xù)性進(jìn)行保護(hù)，不能對數(shù)據(jù)本身提供保護(hù)。數(shù)據(jù)庫應(yīng)用層的數(shù)據(jù)復(fù)制技術(shù)相對是一種數(shù)據(jù)庫層比較安全的數(shù)據(jù)保護(hù)技術(shù)，但是其實現(xiàn)的僅僅是單純的表數(shù)據(jù)層保護(hù)。那么基于以上的分析，我們可以根據(jù)我們的具體核心系統(tǒng)基礎(chǔ)架構(gòu)數(shù)據(jù)保護(hù)的需求以及現(xiàn)有的環(huán)境狀況來選擇合適的技術(shù)手段組合形成我們的整體數(shù)據(jù)保護(hù)架構(gòu)。比如說，對于核心系統(tǒng)的數(shù)據(jù)庫本身