高可用和容災架構的意義

企業服務、云計算、移動互聯網領域中，高可用的分布式技術為支撐平臺正常運作提供著關鍵性的技術支撐。從用戶角度，特別是作為主要收入來源的企業用戶的角度出發，保證業務處理的正確性和服務不中斷（高可用性）是支撐用戶信心的重要來源。高性能，高可用的分布式架構就成了訪問量高峰期時，網站得以成功運維的關鍵。

在當今信息時代，數據和信息逐漸成為各行各業的業務基礎和命脈。當企業因為信息化帶來快捷的服務決策和方便管理時，也必須面對著數據丟失的危險。

容災系統，作為為計算機信息系統提供的一個能應付各種災難的環境，尤其是計算機犯罪、計算機病毒、掉電、網絡/通信失敗、硬件/軟件錯誤和人為操作錯誤等人為災難時，容災系統將保證用戶數據的安全性（數據容災），甚至，一個更加完善的容災系統，還能提供不間斷的應用服務（應用容災）。可以說，容災系統是數據存儲備份的最高層次。

每年的“雙11”、“雙12”都是全球購物者的狂歡節，今年的雙11有232個國家參與進來，成為名副其實的全球瘋狂購物節。11月11日，全天的交易額達到912.17億元，其中在移動端交易額占比68%今年每秒的交易峰值達到14萬筆，螞蟻金服旗下的支付寶交易峰值達到8.59萬筆/秒，這一系列的數字，考驗的是支付寶背后強大的IT支持能力。而持續可用和快速容災切換的能力，是支付寶技術人員追求的極致目標。

在架構設計中，作為系統高可用性技術的重要組成部分，容災設計強調的是系統對外界環境影響具備快速響應能力，尤其是當發生災難性事件并對IDC節點產生影響時，能夠具備節點級別的快速恢復能力，保障系統的持續可用。2015年12月18日，年度高端技術盛會：“全球架構師峰會——ArchSummit”在北京國際會議中心隆重召開，會上，阿里巴巴高級系統工程師：善衡（曾歡）結合互聯網金融業務及系統特性，分享了在支付寶系統架構演進中，每個階段的高可用和容災能力建設的解決思路。本文由其演講內容整理而成。

支付寶的系統架構，其發展歷程可以分為清晰的3個階段，每一個階段都有自己獨特的特點和架構上相應的痛點。在每一個階段的發展過程中，支付寶的技術人員針對不同的問題進行諸多的思考，在解決這些問題的過程中也做了諸多的嘗試。

純真：童年時期2004年~2011年

在此階段，支付寶的系統架構相對比較簡化，如圖1所示，通過商用LB讓用戶的流量進到入口網關系統，支付寶的系統服務暴露也通過商用設備掛在VIP下，每個提供服務的應用機器通過VIP來進行負載均衡。早期支付寶的核心系統庫都在一個數據庫上（后期拆為多個數據庫），即每個核心系統都只用單獨的數據庫。在這樣一個“物理上多機房，邏輯上單機房”的架構背后，每天的業務量僅僅為數十萬級，應用系統也只有數十個，容災能力相對較低：例如單應用出現問題時無法及時有效地切換、主機和備用機進行切換時，一定程度上會導致業務中斷，甚至有時會有不得不進行停機維護的情況，使得整個系統面對數據故障時顯得十分被動。

隨著業務量的不斷增長，該架構發展到2011年，出現了一些比較典型的問題。如下圖所示：由于系統內部使用的都是LB設備，商用LB的瓶頸就尤其明顯，由于業務的發展累計，VIP及其上面發布的服務越堆越多，設備如果出現抖動或者宕機會對業務造成嚴重影響，這即是架構上的單點。第二個問題就是數據庫的單點瓶頸。隨著業務量的不斷增加，單一的核心數據庫一旦出現異常，比如硬件故障、負載異常等等，進而會導致整個核心鏈路上的業務都不可用。

如何消除系統架構當中存在的單點問題，優雅解決未來1-3年之間業務量增長（數百萬級/天）和機器數量增長（數百個系統），是首先要解決的問題，于是帶來了下一代架構革新。

懵懂：少年時期2011年~2012年

鑒于第一階段支付寶碰到的這些痛點，在第二個階段，它將邏輯上的單個機房拆分成為多個機房，通過把硬負載轉換成為軟負載，以實現分布式的服務調用，如下圖所示。下圖為基于常見的消費者和生產者模型來構建的業務模型，其中配置中心負責服務注冊以及對應服務提供方可用狀態變化的通知，從而將信息實時推送到消費方的訂閱關系上。值得注意的是，支付寶對原有架構做了一個較大的改進：它將普通的一體化配置中心分拆成兩個模塊，一個Session模塊，用于管理消費者和生產者的長連接保持；一個Data模塊，用于注冊服務時存儲相關。通過這兩個模塊的深度解耦，進一步提高整個配置中心的性能。