基于Power架構(gòu)實現(xiàn)銀行分布式核心系統(tǒng)

1、 基于Power架構(gòu)實現(xiàn)銀行分布式核心系統(tǒng) 【摘要】本文以某城商行核心業(yè)務(wù)系統(tǒng)升級建設(shè)項目為背景，根據(jù)近十多年以來銀行業(yè)業(yè)務(wù)發(fā)展的功能與非功能需求，建立短期以及中長期的核心系統(tǒng)改造目標，詳盡設(shè)計核心系統(tǒng)的業(yè)務(wù)邏輯，基礎(chǔ)架構(gòu)和浪潮K1 Power小型機選型配置、高可用測試等多階段、多維度項目實施和運維管理經(jīng)驗，為同業(yè)核心系統(tǒng)升級和改造提供可參考、可操作的真實案例和寶貴經(jīng)驗。一、項目背景核心業(yè)務(wù)系統(tǒng)建設(shè)是銀行信息化建設(shè)的核心部分，是銀行業(yè)運營的基礎(chǔ)。當前，核心業(yè)務(wù)系統(tǒng)的功能與定位已經(jīng)從綜合業(yè)務(wù)系統(tǒng)向穩(wěn)定、專業(yè)、靈活、核心等定位發(fā)生轉(zhuǎn)變。核心業(yè)務(wù)系統(tǒng)在銀行業(yè)務(wù)體系中處于重要核心地位，是數(shù)字銀行時代不

2、可或缺的關(guān)鍵支撐。當前銀行已經(jīng)邁入以智能方式提供無感知便捷服務(wù)的BANK4.0時代，銀行業(yè)金融機構(gòu)服務(wù)將會通過各種方式出現(xiàn)在人類周圍，隨著數(shù)字化技術(shù)的普及，個人銀行賬戶可能來自技術(shù)公司的各類智能終端設(shè)備，而非來自實體銀行。這種銀行改變方式帶來的挑戰(zhàn)不但來自傳統(tǒng)銀行業(yè)內(nèi)部，也有來自于金融市場上的技術(shù)公司。新的時代要求銀行前中后臺都要做出改變、所有業(yè)務(wù)與技術(shù)需要重構(gòu)、經(jīng)營模式需要轉(zhuǎn)變。數(shù)字化水平的提升，有助于銀行業(yè)彎道超車、實現(xiàn)跨越式發(fā)展。然而，當領(lǐng)先銀行已經(jīng)在享受數(shù)字化紅利，大部分中小銀行生存空間并不樂觀。中小銀行要想借助數(shù)字化實現(xiàn)錯位競爭，不是一蹴而就的?！般y行數(shù)字化，不是在所謂傳統(tǒng)業(yè)務(wù)之外另

3、建一套數(shù)字業(yè)務(wù)，應(yīng)該是所有業(yè)務(wù)的數(shù)字化”。一家真正意義上的數(shù)字銀行包含三大層次：一是底層基礎(chǔ)數(shù)據(jù)平臺；二是中間核心業(yè)務(wù)層；三是頂層的經(jīng)營決策層，做到智慧經(jīng)營才是數(shù)字化的頂點。通過核心業(yè)務(wù)系統(tǒng)升級建設(shè)，從整體架構(gòu)、系統(tǒng)功能、產(chǎn)品功能、數(shù)據(jù)支持和技術(shù)創(chuàng)新等各方面實現(xiàn)核心系統(tǒng)全方位能力的提升，逐步實現(xiàn)銀行數(shù)字化，為對接“植入式”銀行 4.0 夯實基礎(chǔ)，進一步滿足未來金融市場的需要。二、項目需求我行的核心銀行業(yè)務(wù)系統(tǒng)于2003年初投產(chǎn)上線，有效的支撐了該行各類業(yè)務(wù)發(fā)展16余年，隨著時間的推移及業(yè)務(wù)模式的快速發(fā)展，原有的核心業(yè)務(wù)系統(tǒng)受到傳統(tǒng)系統(tǒng)架構(gòu)的制約限制，“以客戶為中心”的設(shè)計程度較弱，參數(shù)化和產(chǎn)品

4、組件化程度不高，在客戶體驗、產(chǎn)品創(chuàng)新、差異化定價、參數(shù)管理方面的需求響應(yīng)程度較弱。整體開發(fā)實施費時費力，周期過長，不能快速響應(yīng)業(yè)務(wù)部門的需求，對未來銀行的業(yè)務(wù)發(fā)展支撐能力不足，已經(jīng)無法適應(yīng)當前BANK 4.0時代的快速業(yè)務(wù)變化。核心業(yè)務(wù)系統(tǒng)需要實現(xiàn)高度業(yè)務(wù)規(guī)則化、產(chǎn)品參數(shù)化、技術(shù)組件化、數(shù)據(jù)標準化的信息系統(tǒng)，以便能夠更高效、更敏捷、更安全地響應(yīng)業(yè)務(wù)創(chuàng)新發(fā)展的要求。核心系統(tǒng)支持分層、松耦合、面向服務(wù)的SOA架構(gòu)，以適應(yīng) IT 系統(tǒng)、服務(wù)、產(chǎn)品、流程變化的能力；平臺需滿足可靠性、可維護性、可移植性、高可用性、系統(tǒng)稽核性、安全性、開放性、擴展性等非功能性需求；系統(tǒng)性能需求主要包括：對集群的支持、文件

5、傳輸方式的要求、多節(jié)點應(yīng)用部署能力、批量控制、接口性能、并發(fā)度控制、數(shù)據(jù)庫幾個方面。數(shù)據(jù)標準要求：符合我行數(shù)據(jù)標準需求，實施的設(shè)計方案要符合我行數(shù)據(jù)標準，數(shù)據(jù)架構(gòu)及數(shù)據(jù)模型應(yīng)符合我行相關(guān) IT 規(guī)范及數(shù)據(jù)標準的要求。核心系統(tǒng)軟件還具備高穩(wěn)定性、高可靠性、高安全性、高性能等非功能性要求。在技術(shù)能力上需要滿足以下特征：支持分布式集群部署、靈活的架構(gòu)設(shè)計、組件化的應(yīng)用、7*24小時不間斷服務(wù)能力、數(shù)據(jù)安全管理、快捷高效的二次開發(fā)、詳盡的產(chǎn)品文檔支持、全面的7*24小時運維監(jiān)控等。三、建設(shè)目標本次我行新核心業(yè)務(wù)系統(tǒng)升級建設(shè)的目標為：（一）新建設(shè)一套行業(yè)內(nèi)先進主流、安全穩(wěn)定的核心銀行系統(tǒng)。實現(xiàn)信息技術(shù)應(yīng)

6、用和業(yè)務(wù)發(fā)展的雙支撐，促進數(shù)字化金融應(yīng)用能力和服務(wù)水平邁上新臺階，為銀行助力實體經(jīng)濟發(fā)展提供有力IT技術(shù)支撐，增強和優(yōu)化運營基礎(chǔ)、服務(wù)能力、產(chǎn)品工具、風險防控、創(chuàng)新引擎等多領(lǐng)域支撐能力。（二）實現(xiàn)“以客戶為中心，以產(chǎn)品為導向”的服務(wù)發(fā)展模式。構(gòu)建統(tǒng)一客戶視圖、綠色生態(tài)的賬戶管理體系、快速多元化的產(chǎn)品定制、724小時不間斷的運營服務(wù)、嚴密合規(guī)的內(nèi)控風控管理，從“以賬戶為中心”的運營模式，向“以客戶為中心”的模式轉(zhuǎn)變，為廣大客戶提供更好、更快、更優(yōu)的服務(wù)體驗。四、軟硬件選型思路及經(jīng)驗核心業(yè)務(wù)系統(tǒng)作為銀行最關(guān)鍵的聯(lián)機事務(wù)型(OLTP)系統(tǒng)，在服務(wù)器硬件選型階段建議采用TPC組織的TPC-C型標準。操

7、作系統(tǒng)、數(shù)據(jù)庫、中間件等基礎(chǔ)軟件的選擇應(yīng)該遵循“行業(yè)主流、安全穩(wěn)定”的原則，同時，兼顧與硬件設(shè)備的兼容性，并充分結(jié)合銀保監(jiān)會信息科技基礎(chǔ)軟件缺陷列表做好版本的規(guī)劃及相關(guān)補丁的更新工作。五、方案規(guī)劃設(shè)計經(jīng)驗（一）核心業(yè)務(wù)系統(tǒng)應(yīng)用情況新核心業(yè)務(wù)系統(tǒng)在應(yīng)用部分采用zookeeper作為服務(wù)注冊中心，內(nèi)部通過微服務(wù)架構(gòu)實現(xiàn)應(yīng)用的分布式。分布式服務(wù)運行圖對外提供統(tǒng)一的通訊接入網(wǎng)關(guān)，內(nèi)部使用分布式微服務(wù)串接整個業(yè)務(wù)流程，提供服務(wù)路由、負載均衡、集群容錯、流量控制等進行內(nèi)部微服務(wù)的調(diào)度，在應(yīng)用層面實現(xiàn)去中心化的分布式架構(gòu)。在部署方式上，系統(tǒng)內(nèi)部按照交易與核算分離的設(shè)計思想，拆分成交易與核算兩個獨立的模塊，兩

8、個模塊獨立部署。核心系統(tǒng)的各類應(yīng)用以分布式集群多節(jié)點冗余架構(gòu)部署于x86架構(gòu)的虛擬化中，操作系統(tǒng)本版本為RedHat 7.4，各類應(yīng)用程序未使用單獨的中間件產(chǎn)品，而是采用典型的基于Zookeeper、Apache Dubbo等分布式框架軟件實現(xiàn)分布式部署。架構(gòu)設(shè)計從核心系統(tǒng)各類服務(wù)注冊、發(fā)布、消費，到應(yīng)用多活聯(lián)機服務(wù)，再到數(shù)據(jù)庫高可用角度出發(fā)，既能滿足上層核心與外圍系統(tǒng)的業(yè)務(wù)訪問連續(xù)性需求，又能保障核心系統(tǒng)自身健壯健全的高可用需求。核心業(yè)務(wù)系統(tǒng)應(yīng)用對外提供服務(wù)采用8節(jié)點多活模式，8節(jié)點中任意節(jié)點都可獨立提供全部的核心聯(lián)機服務(wù)。ESB （企業(yè)服務(wù)總線）與核心系統(tǒng)應(yīng)用通過Zookeeper服務(wù)注冊

9、、發(fā)現(xiàn)等方式進行連接通訊，ESB又將自身的服務(wù)發(fā)布在Zookeeper服務(wù)注冊中心，外圍系統(tǒng)通過自身操作系統(tǒng)中安裝的ESB Agent軟件代理采用Round Robbin輪詢算法將外部的訪問請求均衡的分布到各個ESB 節(jié)點，最終均衡的訪問到核心應(yīng)用的8個節(jié)點中。一旦某一核心應(yīng)用節(jié)點出現(xiàn)問題，通過Zookeeper服務(wù)注冊中心探測機制關(guān)閉對應(yīng)的ESB節(jié)點通路即可，不影響其他節(jié)點提供對外服務(wù)。（二）核心業(yè)務(wù)系統(tǒng)應(yīng)用服務(wù)調(diào)用方式核心系統(tǒng)對外提供服務(wù)方式主要分為 2 種，第一種是間接訪問方式：通過ESB（企業(yè)服務(wù)總線）進行間接調(diào)用訪問，網(wǎng)上銀行、手機銀行等外圍系統(tǒng)訪問發(fā)布在 ESB（企業(yè)服務(wù)總線）的核

10、心業(yè)務(wù)系統(tǒng)應(yīng)用服務(wù)。第二種直接訪問方式：柜面系統(tǒng)、ESB直接訪問核心業(yè)務(wù)系統(tǒng)應(yīng)用服務(wù)。第一種方式ESB通過發(fā)布通用的Web Services接口，減少外圍的報文格式轉(zhuǎn)換，提高了外圍系統(tǒng)的改造工作量，提高了外圍系統(tǒng)的接口調(diào)用的穩(wěn)定率。采用第二種方法的系統(tǒng)屬于調(diào)用接口較為復雜或與核心系統(tǒng)報文接口相似的系統(tǒng)，這類系統(tǒng)一般不適合通過ESB 進行間接調(diào)用。（三）核心業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫情況在部署方式上，系統(tǒng)內(nèi)部按照交易與核算分離的設(shè)計思想，拆分成交易與核算兩個獨立的模塊，兩個模塊獨立部署。在數(shù)據(jù)庫層面進行了垂直拆分將交易庫與核算庫拆分成兩個獨立的數(shù)據(jù)庫，實現(xiàn)了數(shù)據(jù)層面的分布式。新核心業(yè)務(wù)系統(tǒng)按照產(chǎn)品功能分為“

11、交易模塊、核算模塊、通訊網(wǎng)關(guān)模塊、報表模塊、運行監(jiān)控模塊、參數(shù)管理模塊”，按照數(shù)據(jù)不同特性將核心業(yè)務(wù)數(shù)據(jù)劃分為5個數(shù)據(jù)庫。核心系統(tǒng)的數(shù)據(jù)庫采用Oracle 19.6，根據(jù)用途，具體劃分為5個數(shù)據(jù)庫：“交易庫”、“核算庫”、“T+0報表庫”、“OM參數(shù)庫”及“OMS運維監(jiān)控管理庫”。“交易庫”承載全部業(yè)務(wù)交易數(shù)據(jù)；“核算庫”承載每天日庫批處理過程中發(fā)生的交易數(shù)據(jù)，當批處理完成后“核算庫”中數(shù)據(jù)再歸集至“核算庫”，“T+0報表庫”承載各類交易報表展示匯總數(shù)據(jù)，“OM參數(shù)庫”承載所有的核心關(guān)鍵通用參數(shù)配置數(shù)據(jù)，“OMS運維監(jiān)控管理庫”承載核心業(yè)務(wù)系統(tǒng)的運行監(jiān)控及版本變更等各類監(jiān)控管理數(shù)據(jù)。交易模塊、

12、核算模塊及T+0報表模塊等重要的數(shù)據(jù)庫都部署在成熟、穩(wěn)定的浪潮K1 Power9系列小型機上，操作系統(tǒng)版本為AIX 7.2，數(shù)據(jù)庫版本為Oracle 19c（19.6）。核心系統(tǒng)的5個數(shù)據(jù)庫都全部通過HDS GAD底層存儲雙活技術(shù)進行數(shù)據(jù)庫的第一層保護，通過數(shù)據(jù)庫的Oracle RAC集群技術(shù)實現(xiàn)數(shù)據(jù)庫的第二層保護，通過數(shù)據(jù)庫的Oracle ADG復制技術(shù)進行數(shù)據(jù)庫的第三層保護，Oracle ADG復制技術(shù)將生產(chǎn)庫的數(shù)據(jù)實時復制到災(zāi)備端目標數(shù)據(jù)庫，形成生產(chǎn)數(shù)據(jù)庫的只讀庫, 只讀庫可以承載一部分查詢業(yè)務(wù)，并且當生產(chǎn)庫發(fā)生故障時，也可以將只讀庫快速切換至可讀可寫狀態(tài)，起到生產(chǎn)庫實時災(zāi)難備份的作用。

13、（四）核心業(yè)務(wù)系統(tǒng)邏輯架構(gòu)隨著自有新核心業(yè)務(wù)系統(tǒng)及新數(shù)據(jù)中心的建成，生產(chǎn)數(shù)據(jù)中心、同城容災(zāi)數(shù)據(jù)中心以及異地容災(zāi)數(shù)據(jù)中心均發(fā)生變化，同城雙中心采用“應(yīng)用分布式雙活、數(shù)據(jù)庫主備”的方式進行部署，在合理利用災(zāi)備服務(wù)資源的情況下最大化的保障了數(shù)據(jù)的一致性。新一代核心系統(tǒng)項目在新數(shù)據(jù)中心投入必要主機、存儲與網(wǎng)絡(luò)資源，確保新一代核心系統(tǒng)基礎(chǔ)架構(gòu)資源方面能夠滿足功能要求、性能需求、數(shù)據(jù)標準要求以及穩(wěn)定、可靠、安全等非功能性要求，選擇由浪潮K1 Power系列小型機承載重要應(yīng)用（包含：實時交易應(yīng)用、核算應(yīng)用、T+0報表應(yīng)用）和核心數(shù)據(jù)庫（包含：交易數(shù)據(jù)庫、核算數(shù)據(jù)庫、T+0報表數(shù)據(jù)庫），下圖是同城雙中心架構(gòu)下

14、的核心業(yè)務(wù)系統(tǒng)整體的邏輯架構(gòu)圖，采用浪潮K1 Power系列小型機及PC服務(wù)器實現(xiàn)集成部署：同城雙中心分別部署兩套分布式核心應(yīng)用，例如：主中心部署5個接入網(wǎng)關(guān)、8個核心交易模塊節(jié)點、4個核心核算節(jié)點、2個T+0報表、2個T+0展現(xiàn)端、1套zookeeper注冊中心集群、1套redis集群作為分布式緩存；同城中心部署5個接入網(wǎng)關(guān)、8個核心交易模塊節(jié)點、4個核心核算節(jié)點、2個T+0報表、2個T+0展現(xiàn)端、1套zookeeper注冊中心集群、1套redis集群作為分布式緩存。所有節(jié)點單中心內(nèi)部通過集群的方式實現(xiàn)本地高可用，T+0報表服務(wù)對外通過硬件負載均衡設(shè)備對外提供服務(wù)。（五）核心業(yè)務(wù)系統(tǒng)軟硬件資

15、源配置為確保新一代核心業(yè)務(wù)系統(tǒng)基礎(chǔ)架構(gòu)資源方面能夠滿足功能要求、性能需求、數(shù)據(jù)標準要求以及穩(wěn)定、可靠、安全等非功能性要求，選擇由浪潮K1 Power系列小型機（主要為E950、S924）承載重要應(yīng)用（包含：實時交易應(yīng)用、核算應(yīng)用、T+0報表應(yīng)用）和核心數(shù)據(jù)庫（包含：交易數(shù)據(jù)庫、核算數(shù)據(jù)庫、T+0報表數(shù)據(jù)庫），完全采用Dlpar邏輯分區(qū)技術(shù)實現(xiàn)部署，詳細如下所示：文件系統(tǒng)規(guī)劃，嚴格按照XX銀行AIX操作系統(tǒng)安裝配置規(guī)范要求，統(tǒng)一模板克隆方式進行部署，主要包括：rootvg中各系統(tǒng)文件系統(tǒng)大小、SAN存儲VG類型、PP size 和Concurrent屬性，LV大小、屬組關(guān)系，文件系統(tǒng)大小與訪問權(quán)

16、限，網(wǎng)絡(luò)存儲本地與遠程掛載點，自啟動配置等。存儲容量配置規(guī)劃，按照滿足未來3年數(shù)據(jù)增長需求，將存量與增量數(shù)據(jù)統(tǒng)籌考慮。六、實施經(jīng)驗分享（一）高可用性測試高可用性測試是核心業(yè)務(wù)系統(tǒng)未來能否安全平穩(wěn)運行的重要保障，是系統(tǒng)正式上線運行前不可或缺的一項測試工作，是保障業(yè)務(wù)連續(xù)性的一項重要舉措，測試目的是配合前端應(yīng)用壓力測試的場景，連帶應(yīng)用負載均衡共同測試，模擬系統(tǒng)上線后的實際壓力情況，并通過對單臺物理主機的電源、網(wǎng)絡(luò)線路、光纖線路、操作系統(tǒng)的非計劃內(nèi)關(guān)閉與斷開，觀測對業(yè)務(wù)連續(xù)性的實際影響，判斷計劃內(nèi)和非計劃內(nèi)宕機各種異常引發(fā)的業(yè)務(wù)影響情況。配置操作系統(tǒng)層面高可用軟件（PowerHA、VMware HA

17、），數(shù)據(jù)庫層面的高可用技術(shù)（Oracle RAC及ADG），存儲層面的高可用技術(shù)（HDS GAD雙活），防患設(shè)備故障與邏輯故障對生產(chǎn)系統(tǒng)造成不良影響。核心系統(tǒng)的高可用性測試場景包含架構(gòu)中的各功能主機數(shù)據(jù)庫和應(yīng)用服務(wù)器，如聯(lián)機交易應(yīng)用8節(jié)點之間的高可用、聯(lián)機交易2節(jié)點RAC數(shù)據(jù)庫高可用、核算應(yīng)用4節(jié)點之間的高可用、核算數(shù)據(jù)庫2節(jié)點RAC數(shù)據(jù)庫高可用等場景的 故障切換過程，驗證其中一個節(jié)點或一部分節(jié)點發(fā)生故障后其余正常節(jié)點是否能夠持續(xù)提供服務(wù)，記錄自動切換及應(yīng)用時間、交易響應(yīng)率恢復時間等。對交易數(shù)據(jù)庫、交易應(yīng)用、核算數(shù)據(jù)庫、核算應(yīng)用、T+0報表數(shù)據(jù)庫、T+0報表應(yīng)用的高可用冗余環(huán)節(jié)均做高可用性測試

18、完成后，在硬件冗余架構(gòu)、RAC集群軟件、應(yīng)用負載和分布式的作用下，各系統(tǒng)均通過高可用性測試，且業(yè)務(wù)連續(xù)性未受到任何影響（業(yè)務(wù)未發(fā)生中斷情況）。因核心業(yè)務(wù)系統(tǒng)的3套關(guān)鍵數(shù)據(jù)庫都采用RAC集群模式部署，當其中一個主機發(fā)生宕機情況，另外一個節(jié)點會持續(xù)提供服務(wù)，但從LoadRunner工具界面中會反映出現(xiàn)短時間的交易響應(yīng)率下降情況。測試過程中，發(fā)現(xiàn)當應(yīng)用程序數(shù)據(jù)源配置了后端RAC數(shù)據(jù)庫的VIP地址后，當一臺主機故障后會導致一部分交易一直失敗，原因為“主機故障后VIP地址雖然漂移至另外一臺主機，但是該VIP不會啟動監(jiān)聽”，故前端應(yīng)用程序在配置數(shù)據(jù)源時，必須配置RAC數(shù)據(jù)庫的SCAN IP而非VIP（若使

19、用域名，則域名必須解析至SCAN IP）。具備DNS解析條件的情況下，一定要按照Oracle官方強烈推薦，使用DNS域名實現(xiàn)對RAC數(shù)據(jù)庫的訪問。此外，核算數(shù)據(jù)庫承擔夜間批量，在配置JDBC數(shù)據(jù)源時，需要將數(shù)據(jù)庫連接字符串配置為“LOAD_BALANCE=OFF，F(xiàn)AILOVER=ON”，即：關(guān)閉數(shù)據(jù)庫負載均衡模式，將RAC數(shù)據(jù)庫工作模式配置為熱備模式，否則在數(shù)據(jù)庫負載均衡模式下，夜間批量產(chǎn)生大量的SQL執(zhí)行導致兩個數(shù)據(jù)庫節(jié)點間頻繁的內(nèi)存交互會導致GC等待，進而影響批量執(zhí)行效率，最終導致RAC雙節(jié)點的執(zhí)行效率反而比單節(jié)點效率低。（二）內(nèi)存消耗異常問題在測試過程中發(fā)現(xiàn)，Oracle 19c數(shù)據(jù)庫

20、服務(wù)器的內(nèi)存利用率遠遠高于以往經(jīng)驗值，經(jīng)過反復測試驗證，最終發(fā)現(xiàn)使用AIX 7.2 TL3 SP2或AIX 7.2 TL3 SP3時，Oracle 19c數(shù)據(jù)庫服務(wù)器存在內(nèi)存消耗異常增加的BUG，該問題為Oracle與AIX兼容性問題所引發(fā)，具體如下所示：最后，根據(jù)Oracle官方推薦解決了該問題，有效降低了內(nèi)存的使用率，具體方法如下所示：Oracle建議的修復方法 （修改makefile，然后relink）（1）Shutdown database, listener and Oracle Enterprise Manager associated to the ORACLE_HOME software（2）cd $ORACLE_HOME/rdbms/lib（3）Make a backup file of the env_rdbms.mk file (cp env_rdbms.mk env_rdbms.mk_backup（4）Edit the env_rdbms.mk and perform the following change:replace the next