銀行新核心基礎架構方案設計技術手冊

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

28、主動加強 金融風險管理，為全行客戶的資金安全保駕護航。集中式與分布式集中或者分布本身是兩種處理問題的方式或者風格，就像是同步與異步一樣。但是市場 上的一些流行理念卻活生生將集中與分布劃分成了兩個彼此對峙的陣營。在所謂的集中式陣 營中，如果一定要找一個靶子，那么基于 IBM Z（俗稱主機）的技術堆棧可以算得上“眾矢之的”的集中式源頭。傳統銀行的 IT 架構目前多為集中式和分布式的混合架構，不同的系統架構遷移策略也不一樣。對于集中式架構，多為大型機或者小型機服務器，操作系統為 UNIX 系統。集中式架構的過渡，對于原有系統的架構沒有任何影響，因為 LINUXONE 本身也是大型機服務器的架構，唯一

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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