原文：https://www.enmotech.com/web/detail/1/850/1.htmlv
一般可以將架構分爲兩類，一類是以垂直擴展（Scale up）爲主的架構，如通過增加單機配置，或者將中低端設備升級成爲高端設備，用以提升系統的處理能力，稱之爲集中式架構，早期的啞終端主機架構是典型代表。
概述
（一）分佈式架構簡介
一般可以將架構分爲兩類，一類是以垂直擴展（Scale up）爲主的架構，如通過增加單機配置，或者將中低端設備升級成爲高端設備，用以提升系統的處理能力，稱之爲集中式架構，早期的啞終端主機架構是典型代表；一類是以水平擴展（Scale out）爲主的架構，通過橫向擴充節點，如一個節點擴充到多個節點，每個節點運行獨立實例，節點與節點之間通過網絡互連，隨着節點擴充系統處理能力能夠隨之提升，單節點失效時，整個集羣仍然可以對外提供服務，稱之爲分佈式架構[2]。
信息系統發展到今天，單一的架構難以滿足業務量、數據量不斷增長和業務需求靈活多變的要求，集中式架構與分佈式架構不再是涇渭分明，往往處於融合狀態，如農業銀行全國數據大集中工程實施以前，核心系統部署在各省域中心，通過交換系統實現全行的業務聯網，從全行來看，核心系統是一個分佈式的架構，但從某個省中心來看，又是一個集中式的架構。全國集中以後，核心系統基於主機的並行耦合架構，將核心業務全部集中到一個數據庫當中，通過耦合器實現內存共享，一般將其理解爲集中式架構，但該架構本身也採用了許多分佈式技術，如應用服務層、數據服務層、存儲服務層均實現了多節點部署，單機故障不會影響到業務的連續運行，系統處理能力可以通過垂直擴展或者水平擴展提升。
（二）優缺點分析
1、集中式架構的優缺點
集中式架構系統底層一般採用成熟的商業基礎軟件構建，這種架構的優點是成熟穩定，可用性、可靠性好，銀行的技術人員可專注於業務功能開發，無需過多關注底層技術的實現。全國數據大集中後，農業銀行核心業務系統交易成功率和業務連續性得到了進一步提升，產品創新與推廣更爲高效，業務量年均增長率近30%，至2016年底，日均交易量在3.2億筆左右，峯值交易量突破4.5億筆/日，業務級交易峯值突破13000tps。自集中以來，雖然業務產品和業務量均大幅增長，但底層技術架構基本保持不變，運維更爲集中統一，有力地保障了業務快速發展和生產的平穩運行。
缺點方面，一是風險度集中，雖然產品比較成熟穩定，但一旦出現軟件或者邏輯上的極端異常，也有可能導致整個集羣不可用，從而引發全局性停業。二是我國人口基數大，隨着經濟的快速發展，業務量在全球處於領先，許多新的問題、產品缺陷將有可能首先在我國觸發。三是成本高昂，集中式架構對基礎軟硬件產品的可靠性、可用性依賴度高，這些技術產品基本被極少數公司所壟斷，缺乏有力的競爭者，IT成本居高不下。四是核心技術受制於人，供應鏈風險較大。
2、分佈式架構的優缺點
分佈式架構按照一定的維度將系統進行拆分，通過一定的負載均衡機制，將業務分攤到多個節點上處理。這種架構的優點是可以採用更開放的架構，各節點松耦合，對底層產品的可靠性、可用性依賴降低，可以基於廉價的硬件和開源軟件構建，受單一廠商的制約較少，可以引入多家廠商競爭，成本更爲低廉，可用性、可擴展性更好。尤其是隨着應用規模的擴大，邊際成本將更低。
這種架構的難點是要做好各節點的協同工作，尤其是要處理好數據的一致性、完整性問題。根據CAP理論[3]，在可用性、分區性與一致性三者之間，同時只能滿足兩個，如果要滿足可用性（A）、分區性（P），就需要犧牲一致性（C），業界的一般做法主要是根據業務特點，通過較爲複雜的應用設計，放棄實時一致性、保障最終一致性來解決該問題，分佈式架構增加了應用設計和研發的複雜度。此外，隨着節點數的增加和分佈部署，對運維管理、異常處置也提出了更高的要求。
農業銀行在分佈式架構上的實踐
隨着Linux等開源軟件日益成熟，X86服務器的可靠性、處理性能快速提升，虛擬化、集羣、大數據、高速網絡技術得到廣泛應用，爲構建分佈式架構提供了有利條件。近年來，農業銀行在主機和開放領域對分佈式架構進行了研究和實踐。
（一）主機領域
以新一代核心銀行系統建設爲契機，農業銀行對主機的架構進行了優化。一是將交易路由層分離出來，實現交易的統一接入和負載均衡調度，減少了對主機的依賴，降低了資源消耗。二是採用讀寫分離設計，構建主機開放融合架構，將查詢類交易的應用邏輯處理下移到國產X86服務器上，通過DRDA方式訪問主機數據庫，從試點情況來看，交易下移後可比下移前可節省60%左右的主機計算資源消耗，效果明顯。三是將明細數據下移到開放平臺上，基於Hadoop架構實現明細業務查詢。四是將可以下移的業務系統整體下移到開放平臺，減少主機資源使用。
（二）開放領域
全國數據大集中之後，農業銀行大力推進集羣架構、虛擬化技術的應用，採用Linux替代UNIX，用X86服務器替代小型機，引入集羣數據庫和MPP數據庫，探索存儲虛擬化應用，構建更加開放的分佈式架構，同時加強監管控等運維平臺研發，降低分佈式架構所帶來的運維壓力，提升系統運維標準化、自動化水平。
1、農業銀行開放平臺分佈式架構
下圖列出了農業銀行目前開放平臺的典型架構，從應用接入層、應用服務層到數據服務層和存儲服務層，均實現了分佈式部署。
（1）應用接入層負責前端訪問需求的統一接入，以及對後端應用服務器的交易分發和負載均衡。通過應用接入層實現了前端對後端的透明訪問，後端系統可以根據業務量和系統性能按需擴展，彈性部署。
（2）應用服務層負責應用邏輯的處理，以Java和.net平臺爲主，集羣中各節點基於對等結構，運行狀態獨立，任何一個節點出現問題，能夠通過前端負載均衡集羣及時判斷和隔離，硬件層面全部採用X86服務器，基於計算虛擬化實現資源使用的彈性伸縮。
（3）數據服務層負責數據的存取服務，按類型總體分爲聯機事務處理（OLTP）和聯機分析處理（OLAP）兩個領域。
OLTP領域一般採用成熟的廠商產品，保持2-3家形成一定競爭，降低集中度風險。對於大業務量的OLTP場景，採用讀寫分離、聯機與批量分離設計，或者按照一定的維度對數據庫進行拆分，如網銀系統，日均交易量已經達到上億筆，單數據庫處理起來壓力非常大，按照客戶等維度拆分成多個數據庫，實現了數據庫的堆疊和橫向擴展，單個數據庫異常對全局無影響或者影響極爲有限。
隨着X86服務器可靠性和處理能力提升，以及集羣數據庫技術的成熟，農業銀行加大了X86服務器在數據庫領域的使用力度，2014年，全國集中的信貸系統數據庫從高端小型機遷移到國產X86服務器，日均交易量達3000萬筆。在新一代銀行卡受理環境系統建設中，全面採用X86服務器構建集羣數據庫計算環境，根據業務特點，進行鍼對性的設計，保障了數據庫單點失效後的業務連續性。對於業務量不是特別大的場景，利用虛擬化技術，構建集中部署、有效隔離、彈性伸縮的數據庫資源池，爲系統整合提供了支撐。
OLAP領域，農業銀行較早地實現了分佈式數據庫集羣架構，2011年，以審計三期系統建設爲契機，基於分佈式數據庫集羣，採用4臺X86服務器，實現了全行審計數據的大集中，管理數據達30TB以上，滿足了上千審計人員的使用。基於此，將分析型系統的數據庫部署架構全部統一到X86集羣上。2013年開始，農業銀行積極與國內主流廠商開展合作，攻克多個技術難點，構建了分佈式的MPP集羣數據庫，目前最大的集羣達到56節點，所管理的數據達2PB，日作業量達40000以上。在業務邏輯相對簡單或者非結構化領域，採用Hadoop架構滿足數據分析需求，2013年底，核心系統明細查詢業務遷移到Hadoop平臺，滿足了廣大客戶明細查詢需求。
（4）存儲服務層
存儲層主要是完成數據的存儲、備份，農業銀行主要使用的存儲分爲SAN和NAS兩類，通過LVM鏡像、存儲複製、虛擬化等技術實現存儲的高可用。在品牌方面保持3家左右的競爭，近年來隨着國產自主可控產品的日益成熟，農業銀行在國產SAN、NAS存儲方面應用日益廣泛。此外，基於服務器、萬兆網絡、固態盤和軟件定義的分佈式存儲技術逐步成熟，農業銀行也對其進行了研究和試點。
分佈式架構與運維管理
分佈式架構降低了單個節點對基礎軟硬件的可靠性、可用性依賴，通過架構來保障系統的整體可用性。但隨着分佈式架構、虛擬化等技術的實施，設備與系統數量快速增長，一個系統涉及的節點衆多，爲運維管理帶來了較大的挑戰。爲此，農業銀行在監管控系統建設方面做了大量工作，以提升運維管理的標準化、自動化水平。
一是在監控管理方面，大力推進基礎架構與應用產品的集中監控管理，經過多年的建設，基本實現了計算、存儲、網絡等基礎架構的7*24小時監控，對關鍵應用系統建立了端到端的實時監控，出現異常後，能夠實現快速發現、快速定位、快速處置。二是研發推廣了自動化運維管理平臺，實現了系統的批量部署、合規檢查等功能。三是研發推廣了用戶統一管理、行爲審計等系統，實現了密碼集中管理、單點登錄、行爲審計。四是基於ITIL流程平臺，推廣ISO20000等規範，統一了變更、事件、問題等管理流程。
未來展望
雖然農業銀行近年來在分佈式架構上做了一些研究和實踐，但仍有許多提升空間。特別是農業銀行正在建立兩地三中心多活架構，以此爲契機，將進一步提升分佈式架構在多中心的應用。
一是主機平臺上，深入研究業務特點和應用架構，將可以下移的應用和數據遷移到開放平臺。進一步推廣主機開放融合架構，擴大查詢交易遷移範圍，從核心系統業務類型來看，查詢類交易佔比達70%左右，如果能將大部分查詢類交易移植到融合架構上，效果將更爲顯著。另外，以兩地三中心建設爲契機，實現核心系統的異地雙活部署，提升系統處理能力、災備系統的可靠性，確保極端情況下的業務連續運行。
二是開放平臺上，通過對集羣技術、分佈式數據庫、分佈式存儲等技術的深入應用，結合業務特點對應用進行精心設計，以兩地三中心爲契機，將業務合理分佈到多箇中心，構建多活架構，進一步提升系統的健壯性和應急處置能力。
三是運維管理上，加強開發與運維的融合，持續優化完善現有的監管控平臺，加強流程平臺與自動化平臺的融合，加強實時流數據的應用，進一步提升端到端的運維管理標準化、自動化水平，提升問題發現、定位、處置能力。
總結
綜上所述，分佈式架構具有更好的可擴展性，對基礎軟硬件的可靠性、可用性依賴度更低，可以採用更加開放、廉價的產品構建。但我們也要看到其給應用設計、研發、運維管理所帶來的挑戰。總之，技術是爲業務服務的，無論是集中式架構還是分佈式架構，各有優缺點，我們需要根據不同的應用場景，選擇合適的技術架構。此外，銀行與互聯網企業在信息系統建設上，無論是業務類型、風險容忍度、監管要求上，還是技術架構和文化機制上，有着較大的差異。確保客戶資金安全和生產運行穩定，是銀行信息化建設的首要原則，在分佈式架構應用當中，要結合技術可控、風險可控、成本可控綜合考量，要本着實事求是、穩妥前行的原則逐步推進。
（來自：e-works）