張升：農業銀行的分佈式架構應用實踐與展望

近年來，以阿里爲表明的互聯網企業提出的「去IOE」，在業界引發了普遍的討論。「去IOE」直接含義是不使用傳統IT巨頭的產品，這些廠商產品雖然好，但基本處於市場壟斷地位，用戶議價能力較弱，成本高昂，技術受制於人，供應鏈風險較大。「去IOE」更深層次的含義是採用分佈式的架構替代集中式的架構，構建高可用、易擴展、低成本的分佈式架構。

隨着國家安全可控政策的實施，移動互聯網的興起，業務量的迅速提高，以及利率市場化所帶來的成本約束日益顯現，銀行業信息系統採用分佈式架構是大勢所趨。近年來，農業銀行在分佈式架構方面進行了一些探索和實踐。

1、概述

分佈式架構簡介

通常能夠將架構分爲兩類，一類是以垂直擴展（Scale up）爲主的架構，如經過增長單機配置，或者將中低端設備升級成爲高端設備，用以提高系統的處理能力，稱之爲集中式架構，早期的啞終端主機架構是典型表明；一類是以水平擴展（Scale out）爲主的架構，經過橫向擴充節點，如一個節點擴充到多個節點，每一個節點運行獨立實例，節點與節點之間經過網絡互連，隨着節點擴充系統處理能力可以隨之提高，單節點失效時，整個集羣仍然能夠對外提供服務，稱之爲分佈式架構。

信息系統發展到今天，單一的架構難以知足業務量、數據量不斷增加和業務需求靈活多變的要求，集中式架構與分佈式架構再也不是涇渭分明，每每處於融合狀態，如農業銀行全國數據大集中工程實施之前，核心系統部署在各省域中心，經過交換系統實現全行的業務聯網，從全行來看，核心系統是一個分佈式的架構，但從某個省中心來看，又是一個集中式的架構。全國集中之後，核心系統基於主機的並行耦合架構，將核心業務所有集中到一個數據庫當中，經過耦合器實現內存共享，通常將其理解爲集中式架構，但該架構自己也採用了許多分佈式技術，如應用服務層、數據服務層、存儲服務層均實現了多節點部署，單機故障不會影響到業務的連續運行，系統處理能力能夠經過垂直擴展或者水平擴展提高。

優缺點分析

一、集中式架構的優缺點

集中式架構系統底層通常採用成熟的商業基礎軟件構建，這種架構的優勢是成熟穩定，可用性、可靠性好，銀行的技術人員可專一於業務功能開發，無需過多關注底層技術的實現。全國數據大集中後，農業銀行核心業務系統交易成功率和業務連續性獲得了進一步提高，產品創新與推廣更爲高效，業務量年均增加率近30%，至2014年末，日均交易量在2.6億筆左右，峯值交易量突破3.2億筆/日。自集中以來，雖然業務產品和業務量均大幅增加，但底層技術架構基本保持不變，運維更爲集中統一，有力地保障了業務快速發展和生產的平穩運行。

缺點方面，一是風險度集中，雖然產品比較成熟穩定，但一旦出現軟件或者邏輯上的極端異常，也有可能致使整個集羣不可用，從而引起全局性停業。二是我國人口基數大，隨着經濟的快速發展，業務量在全球處於領先，許多新的問題、產品缺陷將有可能首先在我國觸發。三是成本高昂，集中式架構對基礎軟硬件產品的可靠性、可用性依賴度高，這些技術產品基本被極少數公司所壟斷，缺少有力的競爭者，IT成本居高不下。四是核心技術受制於人，供應鏈風險較大。

二、分佈式架構的優缺點

分佈式架構按照必定的維度將系統進行拆分，經過必定的負載均衡機制，將業務分攤到多個節點上處理。這種架構的優勢是能夠採用更開放的架構，各節點鬆耦合，對底層產品的可靠性、可用性依賴下降，能夠基於廉價的硬件和開源軟件構建，受單一廠商的制約較少，能夠引入多家廠商競爭，成本更爲低廉，可用性、可擴展性更好。尤爲是隨着應用規模的擴大，邊際成本將更低。

這種架構的難點是要作好各節點的協同工做，尤爲是要處理好數據的一致性、完整性問題。根據CAP理論，在可用性、分區性與一致性三者之間，同時只能知足兩個，若是要知足可用性（A）、分區性（P），就須要犧牲一致性（C），業界的通常作法主要是根據業務特色，經過較爲複雜的應用設計，放棄實時一致性、保障最終一致性來解決該問題，分佈式架構增長了應用設計和研發的複雜度。此外，隨着節點數的增長和分佈部署，對運維管理、異常處置也提出了更高的要求。

2、農業銀行在分佈式架構上的實踐

隨着Linux等開源軟件日益成熟，X86服務器的可靠性、處理性能快速提高，虛擬化、集羣、大數據、高速網絡技術獲得普遍應用，爲構建分佈式架構提供了有利條件。近年來，農業銀行在主機和開放領域對分佈式架構進行了研究和實踐。

主機領域

以新一代核心銀行系統建設爲契機，農業銀行對主機的架構進行了優化。

一是將交易路由層分離出來，採用獨立的負載均衡設備實現交易的統一接入和負載均衡調度，減小了對主機的依賴，下降了資源消耗。

二是採用讀寫分離設計，構建主機開放融合架構，將查詢類交易的應用邏輯處理下移到國產X86服務器上，經過DRDA方式訪問主機數據庫，從試點狀況來看，交易下移後可比下移前可節省60%左右的主機計算資源消耗，效果明顯。

三是將明細數據下移到開放平臺上，基於Hadoop架構實現明細業務查詢。

四是將能夠下移的業務系統總體下移到開放平臺，減小主機資源使用。

開放領域

全國數據大集中以後，農業銀行大力推動集羣架構、虛擬化技術的應用，採用Linux替代UNIX，用X86服務器替代小型機，引入集羣數據庫和MPP數據庫，探索存儲虛擬化應用，構建更加開放的分佈式架構，同時增強監管控等運維平臺研發，下降分佈式架構所帶來的運維壓力，提高系統運維標準化、自動化水平。

一、農業銀行開放平臺分佈式架構

下圖列出了農業銀行目前開放平臺的典型架構，從應用接入層、應用服務層到數據服務層和存儲服務層，均實現了分佈式部署。

圖1：農業銀行開放平臺分佈式架構

1）應用接入層負責前端訪問需求的統一接入，以及對後端應用服務器的交易分發和負載均衡，負載均衡集羣採用軟件或者硬件實現。經過應用接入層實現了前端對後端的透明訪問，後端系統能夠根據業務量和系統性能按需擴展，彈性部署。

2）應用服務層負責應用邏輯的處理，以Java和.net平臺爲主，集羣中各節點基於對等結構，運行狀態獨立，任何一個節點出現問題，可以經過前端負載均衡集羣及時判斷和隔離，硬件層面所有采用X86服務器，2014年以來新購設備所有實現了自主可控，基於計算虛擬化實現資源使用的彈性伸縮。

3）數據服務層負責數據的存取服務，按類型整體分爲聯機事務處理（OLTP）和聯機分析處理（OLAP）兩個領域。

OLTP領域通常採用成熟的廠商產品，保持2-3家造成必定競爭，下降集中度風險。對於大業務量的OLTP場景，採用讀寫分離、聯機與批量分離設計，或者按照必定的維度對數據庫進行拆分，如網銀系統，日均交易量已經達到上億筆，單數據庫處理起來壓力很是大，按照客戶等維度拆分紅多個數據庫，實現了數據庫的堆疊和橫向擴展，單個數據庫異常對全局無影響或者影響極爲有限。

圖2：分佈式數據庫架構

隨着X86服務器可靠性和處理能力提高，以及集羣數據庫技術的成熟，農業銀行加大了X86服務器在數據庫領域的使用力度，2014年，全國集中的信貸系統數據庫從高端小型機遷移到國產X86服務器，日均交易量達3000萬筆。在新一代銀行卡受理環境系統建設中，全面採用X86服務器構建集羣數據庫計算環境，根據業務特色，進行鍼對性的設計，保障了數據庫單點失效後的業務連續性。對於業務量不是特別大的場景，利用虛擬化技術，構建集中部署、有效隔離、彈性伸縮的數據庫資源池，爲系統整合提供了支撐。

OLAP領域，農業銀行較早地實現了分佈式數據庫集羣架構，2011年，以審計三期系統建設爲契機，基於分佈式數據庫集羣，採用幾臺X86服務器，實現了全行審計數據的大集中，管理數據達30TB以上，知足了上千審計人員的使用。基於此，將分析型系統的數據庫部署架構所有統一到X86集羣上。2013年開始，農業銀行積極與國內主流廠商開展合做，攻克多個技術難點，構建了分佈式的MPP集羣數據庫，目前最大的集羣達到56節點，所管理的數據1.5PB，日做業量達40000以上。在業務邏輯相對簡單或者非結構化領域，採用Hadoop架構知足數據分析需求，2013年末，核心系統明細查詢業務遷移到Hadoop平臺，知足了廣大客戶明細查詢需求。

4）存儲服務層

存儲層主要是完成數據的存儲、備份，農業銀行主要使用的存儲分爲SAN和NAS兩類，經過LVM鏡像、存儲複製、虛擬化等技術實現存儲的高可用。在品牌方面保持3家左右的競爭，近年來隨着國產自主可控產品的日益成熟，農業銀行在國產SAN、NAS存儲方面應用日益普遍。此外，基於服務器、萬兆網絡、固態盤和軟件定義的分佈式存儲技術逐步成熟，農業銀行也對其進行了研究和試點。

二、分佈式架構與運維管理

分佈式架構下降了單個節點對基礎軟硬件的可靠性、可用性依賴，經過架構來保障系統的總體可用性。但隨着分佈式架構、虛擬化等技術的實施，設備與系統數量快速增加，一個系統涉及的節點衆多，爲運維管理帶來了較大的挑戰。爲此，農業銀行在監管控系統建設方面作了大量工做，以提高運維管理的標準化、自動化水平。

一是在監控管理方面，大力推動基礎架構與應用產品的集中監控管理，通過多年的建設，基本實現了計算、存儲、網絡等基礎架構的7*24小時監控，對關鍵應用系統創建了端到端的實時監控，出現異常後，可以實現快速發現、快速定位、快速處置。

二是研發推廣了自動化運維管理平臺，實現了系統的批量部署、合規檢查等功能。

三是研發推廣了集中密碼管理與行爲審計系統，實現了密碼集中管理、單點登陸、行爲審計。

四是基於ITIL流程平臺，推廣ISO20000等規範，統一了變動、事件、問題等管理流程。

3、將來展望

雖然農業銀行近年來在分佈式架構上作了一些研究和實踐，但仍有許多提高空間。特別是農業銀行正在創建兩地三中心多活架構，以此爲契機，將進一步提高分佈式架構在多中心的應用。

一是主機平臺上，深刻研究業務特色和應用架構，將能夠下移的應用和數據遷移到開放平臺。進一步推廣主機開放融合架構，擴大查詢交易遷移範圍，從核心系統業務類型來看，查詢類交易佔比達70%左右，若是能將大部分查詢類交易移植到融合架構上，效果將更爲顯著。另外，以同城中心建設爲契機，實現核心系統的同城雙活部署，確保極端狀況下的數據零丟失和業務連續運行。

二是開放平臺上，經過對集羣技術、分佈式數據庫、分佈式存儲等技術的深刻應用，結合業務特色對應用進行精心設計，以同城和異地災備中心建設爲契機，將業務合理分佈到多箇中心，構建多活架構，進一步提高系統的健壯性和應急處置能力。

三是運維管理上，增強開發與運維的融合，持續優化完善現有的監管控平臺，增強流程平臺與自動化平臺的融合，進一步提高端到端的運維管理標準化、自動化水平，提高問題發現、定位、處置能力。

總結

綜上所述，分佈式架構具備更好的可擴展性，對基礎軟硬件的可靠性、可用性依賴度更低，能夠採用更加開放、廉價的產品構建。但咱們也要看到其給應用設計、研發、運維管理所帶來的挑戰。總之，技術是爲業務服務的，不管是集中式架構仍是分佈式架構，各有優缺點，咱們須要根據不一樣的應用場景，選擇合適的技術架構。此外，銀行與互聯網企業在信息系統建設上，不管是業務類型、風險容忍度、監管要求上，仍是技術架構和文化機制上，有着較大的差別。確保客戶資金安全和生產運行穩定，是銀行信息化建設的首要原則，在分佈式架構應用當中，要結合技術可控、風險可控、成本可控綜合考量，要本着實事求是、穩妥前行的原則逐步推動。

【預告】 首屆中國人工智能大會（CCAI 2015）將於7月26-27日在北京友誼賓館召開。機器學習與模式識別、大數據的機遇與挑戰、人工智能與認知科學、智能機器人四個主題專家雲集。人工智能產品庫將同步上線，預定諮詢：QQ：1192936057。歡迎關注。