http://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=402390133&idx=1&sn=395cf6e500ea912fe66eb0a1c7a47e8d&scene=0#wechat_redirect

持續可用和高速容災切換的能力，是技術人員追求的極致目標。在架構設計中，容災設計強調的是系統對外界環境影響具備高速響應能力。節點級別的高速恢復能力，保障系統的持續可用。

去年12月18日。全球架構師峰會上，阿里巴巴高級系統project師曾歡（善衡）結合互聯網金融業務及系統特性。分享了在支付寶系統架構演進中，每一個階段的高可用和容災能力建設的解決思路。

高可用和容災架構的意義

?

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

高性能。高可用的分布式架構就成了訪問量高峰期時，站點得以成功運維的關鍵。

?

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

?

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

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

在架構設計中，作為系統高可用性技術的重要組成部分，容災設計強調的是系統對外界環境影響具備高速響應能力，尤其是當發生災難性事件并對IDC節點產生影響時。可以具備節點級別的高速恢復能力。保障系統的持續可用。

2015年12月18日，年度高端技術盛會：“全球架構師峰會——ArchSummit”在北京國際會議中心隆重召開，會上。阿里巴巴高級系統project師：善衡（曾歡）結合互聯網金融業務及系統特性。分享了在支付寶系統架構演進中，每一個階段的高可用和容災能力建設的解決思路。本文由其演講內容整理而成。

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

?

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

在此階段。支付寶的系統架構相對照較簡化，如圖1所看到的，通過商用LB讓用戶的流量進到入口網關系統，支付寶的系統服務暴露也通過商用設備掛在VIP下。每一個提供服務的應用機器通過VIP來進行負載均衡。

早期支付寶的核心系統庫都在一個數據庫上（后期拆為多個數據庫）。即每一個核心系統都僅僅用單獨的數據庫。在這樣一個“物理上多機房，邏輯上單機房”的架構背后，每天的業務量僅僅為數十萬級，應用系統也僅僅有數十個。容災能力相對較低：比如單應用出現故障時無法及時有效地切換、主機和備用機進行切換時，一定程度上會導致業務中斷。甚至有時會有不得不進行停機維護的情況。使得整個系統面對數據故障時顯得十分被動。

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

?

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

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

鑒于第一階段支付寶碰到的這些痛點，在第二個階段。它將邏輯上的單個機房拆分成為多個機房，通過把硬負載轉換成為軟負載。以實現分布式的服務調用，例如以下圖所看到的。

下圖為基于常見的消費者和生產者模型來構建的業務模型，當中配置中心負責服務注冊以及相應服務提供方可用狀態變化的通知，從而將信息實時推送到消費方的訂閱關系上。值得注意的是，支付寶對原有架構做了一個較大的改進：它將普通的一體化配置中心分拆成兩個模塊。一個Session模塊。用于管理消費者和生產者的長連接保持；一個Data模塊。用于注冊服務時存儲相關。通過這兩個模塊的深度解耦。進一步提高整個配置中心的性能。

?

除此之外。支付寶還做了數據的水平擴展。事實上早在2011年之前。支付寶就已經開始從事此項工作，依據用戶的UID，將一個交易庫水平拆分為多個庫，例如以下圖所看到的。

在此期間，須要解決的問題就是“相應用透明”，怎樣通過“應用無感知”的方式進行用戶數據庫的拆分。是水平擴展實施時首先要考慮的；其次，怎樣通過一個數據中間件來管理數據分片的規則，也是數據水平擴展過程中的關鍵問題。

通過上述兩個比較典型的優化。支付寶的整個系統架構如圖5所看到的。從應用層面上來說每一個機房都是一個節點；從數據層面上，每一個機房有特定的幾個數據分片在里面。

在部署模式上，當支付寶擴張到3個或4個機房的時候，須要全局考慮數據分片部署，每一個機房都有可能不可用，這些備庫們應當分散到不同的多個機房里面，從而達到多機房備災的目的。

?

這樣的多機房多活的第二代架構體系，其優勢在于：

• 進行了數據的水平拆分。從而理論上能夠無限擴展數據/資源。

• 應用多機房獨立部署，不再存在單個機房影響總體的情況；

• 服務調用機房內隔離。通過軟負載的方式去做機房內的服務本地化，不再去依賴還有一個機房內同樣的服務；

• 相較上一個階段具有更高、更可靠的可用性。

  ?

盡管在此過程中自然攻克了上述的單點問題，但仍存在一個問題沒有解決。即數據庫日常維護時，或由于硬件的故障導致數據庫宕機時，支付寶須要進行主備切換，在此過程中業務是有損的狀態。普通情況下當IDC出現故障的時候。project師們會通過前端的流量管控系統先把用戶的流量從出現異常的機房切換到正常的機房中。然后進行數據庫的主備切換。即將備用負載替換主用負載。

在這個過程中。有兩個比較大的痛點：

• 主備切換時數據“一致性”的問題。即主備切換時，怎樣在把影響時間降至最低的情況下。保證數據不被丟失。完完整整地拷貝至備用數據庫。

  ?

• 主備切換時數據存取不可用導致的業務暫停問題。

一旦數據庫發生問題，我們須要進行主備切換時。由于切換過程中的數據不可寫，部分用戶操作后的狀態不正確，對用戶來說是會操心的。

為了解決問題，我們制定了一個Failover方案。

該方案主要通過業務層進行改造，比如針對流水型的業務數據，我們是這么來做的：正常進行數據流量存取的時候，僅僅有主庫提供路線服務。主庫和備庫之間進行正常的數據同步。可是Failover庫不進行數據同步，正常狀態下對業務系統不可見。即正常情況下，沒有數據流經過Failover庫，并且Failover庫是空的，沒有不論什么歷史數據，例如以下圖所看到的：

一旦故障發生。主庫發生宕機，支付寶人員將通過容災切換將全部數據的讀寫放置在FailOver數據層中進行。

由于是實時流水型的數據，所以不會對歷史數據產生不論什么依賴和影響。切換完畢后。整個核心鏈路上的業務就已經全面恢復起來了。通過這樣的方式，使得支付寶能夠將數據庫在短短5分鐘內進行切換，一旦故障解除，隨時能夠將數據讀寫又一次切換到主存儲庫上來。

FailOver方案上線后，支付寶基本上全部的核心業務都基于此進行了方案改造，并針對不同的業務（不僅限于應用層）都會有不同的FailOver方案。

如今，支付寶在原有的方案基礎上再多準備一個Failover數據庫（如圖8中藍色圖形所看到的）。與之前提到的容災設計一樣，假設須要進一步保證Failover庫的可用性，還能夠添加Failover庫的備庫。此外Failover庫須要與主庫分開，能夠與主庫、備庫都不放在同一個機房。

3成熟：青年時期2012年~2015年

通過“多機房多活”的架構改造以及FailOver方案的實施。滿以為未來三年都無需為IDC資源去發愁的支付寶研發團隊，在順利支撐完2012年的“雙11”，為下一年做規劃時卻發現夢想破滅了。由于他們遇到了嚴峻的新問題：

• DB連接數不夠。由于一個機房中的應用系統就是一個節點，沒有分片的概念，只唯獨數據的分片。用戶進入隨意應用節點時。系統須要依據用戶的UID分片查用戶應該去往哪個數據庫，這時候每一個應用節點都會與全部數據庫節點保持連接。

  而傳統關系型數據庫的連接數是十分寶貴的，當支付寶面對不斷增長的用戶擴容需求時，由于DB連接數資源無法繼續擴充，導致應用也不能繼續擴容了。不僅無法滿足日常增長需求，更別提“雙11”這樣短時間爆發式增長的用戶需求。

  ?

• 城市IDC資源限制問題。2012年夏天。杭州經歷了長時間高溫天氣，因為機房執行的耗電較高，市政為了緩解電力供應壓力。下達了一紙通文，隨時可能關閉掉支付寶的某些機房供電。

  ?

• 機房間高流量問題。

  因為一個業務請求與后端數據讀取之間的比例為1:N（當中N可能是幾十甚至上百），在“雙11”高流量的沖擊下。跨機房的流量會變得很的大。因此對于網絡帶寬和網絡質量也有著很高的要求。

  ?

• 跨IDC網絡延時問題。

  因為業務請求和后端數據讀取1:N配比問題，導致同城機房之間距離略微遠一些。就會產生1、2毫秒的同城機房延時。被擴大后就會成為困擾用戶的網絡延時問題。

新的問題進而帶來對新一代架構的要求：

• 徹底解決DB連接數的問題。

• 徹底解決IDC資源限制的問題。

  須要支付寶走出杭州。不能單單在杭州進行機房的擴張和建設。

• 保證業務的連續性。去降低故障發生的時候對于用戶的打攪、對于業務的中斷。

  ?

• 藍綠公布。在日常公布時。會通過線下的公布測試。預公布，終于到線上的公布過程。線上公布通常採用的是金絲雀模式，應用分成多組進行公布，每一組的用戶不固定，可能會影響到大部分乃至全站的用戶。因此支付寶團隊希望日常公布時，可以最小限度影響用戶（可能是1%甚至1‰）。新代碼上線之后最小力度來驗證新代碼符合預期。

  因此須要一種新的公布方式來支持。

• 高可用-異地多活。對于支付寶來說，傳統的“兩地三中心”要求：機房分屬兩個不同地區，同城其中兩個機房是“雙活”，即活躍的主機房，異地機房通過復制數據來做“冷備”。即備用機房。若同城兩個機房都出現故障。一旦須要切換異地機房，因為不知道異地冷備機房執行起來是什么情況，因此非常難決策。

  支付寶希望異地的機房也能實時進行流量的讀寫，以便數據流量能夠來回切換，而不用操心在切換后無法知道數據將是什么狀態。

  ?

• 單元化。基于上述幾個問題的思考。支付寶走到了單元化的一步。

  如圖9所看到的。傳統的服務化架構下每一次調用服務時，系統都會隨機選擇一臺機器或一個節點完畢整次的調用。而單元化之后支付寶能夠把不論什么一個節點固定到一個單獨的單元內，即固定的節點相應一條固定的鏈路，再基于數據分片的方法完畢將節點“單元化”的設置。

單元化的核心思想包含核心剝離以及長尾獨立。

核心剝離指的是將核心業務進行剝離；將業務數據依照UserID進行拆分。從而實現多機房部署。在此基礎上將每個機房的調用進行封閉式設置；每個單元中的業務數據無需和其他單元進行同步。

長尾獨立則針對非核心的應用。這些業務數據并不依照UID進行拆分。核心業務并不依賴于長尾應用。

支付寶單元化架構實現的主要思想有兩點，例如以下圖所看到的：

數據水平拆分，即將全部線上核心業務分離開來。因為核心業務集合都能依照用戶ID去做水平切片，支付寶團隊將數據切片后依照機房進行分布。然后通過循序漸進的方式逐步將每個單元之間的調用完整地封閉掉。每個單元的數據都是經過分片的數據，不需和其他單元進行同步。

上層單元化改造，即將歷史的、不能拆分的業務獨立出來。2013年，支付寶實現了兩個單元：單元A放置核心業務，比如核心鏈路的支付、交易等；單元B放置無法拆分的歷史業務，比如某些不重要的業務等。

支付寶單元化架構于2013年完畢，幫助支付寶順利支撐過了2013年的“雙11”。而2014年~2015年，支付寶一直在嘗試解決異地延時的問題：即假設不去對全局數據進行切割或是本地化的話，當把業務單元搬到異地時。因為每一次業務的發生基本上都會依賴全局數據，且會相應多次數據訪問。而每一次數據訪問都會產生異地所帶來的延時。積少成多。時間延遲就會達到秒級，用戶體驗大幅度下降。基于這個問題的考慮，支付寶研發團隊做了一個非常大的決定：他們引入了單元C，通過將無法拆分的全量數據進行全局復制（異地機房之間的復制），以便于支撐核心業務本地調用，進而實現讀寫分離。將跨城市的調用降低到最小力度。

例如以下圖所看到的。

因為數據的寫入操作會在每個數據單元上進行，而單元C的數據讀取是要求全量的，所以進行這一項改造的時候須要底層的支持，從而解決架構改造時數據一致性和時效性的問題。

為了解決問題，支付寶團隊提出了兩種解決方式：

• 基于DB同步的數據復制。針對某些對于延時并不是十分敏感的業務。單就基于主備同步來做數據的同步。

• 基于消息系統的數據復制。因為異地數據同步比較耗時。對于延時很敏感的業務來說，支付寶基于可靠的消息系統做一個數據復制（內部稱為數據總線），通過它將上層基于應用去做數據的復制，大概時間位于毫秒級。底層DB主備同步同一時候進行。

  ?

通過本地化調用，支付寶有效地攻克了DB連接數問題、機房間流量限制問題、跨IDC的延時問題；通過異地的單元部署以及不斷的容災演練和數據切換，支付寶有效地攻克了城市IDC資源限制和異地IDC容災問題。另外另一個訴求——“藍綠公布”，支付寶是這么實現的。

?

例如以下圖所看到的。藍綠公布即每一個單元里面分為一個Blue組和一個Green組，日常模式下兩個組各承擔50%的用戶流量；公布前將Green組中的50%流量移到Blue組中，然后對Green進行兩批無序公布。新代碼公布上去后，將Blue組中的流量先切換1%~2%到Green組中進行驗證。以最大程度降低對用戶的打攪，驗證完成后。再逐步將100%的流量所有切換至新的Green組，反復前面的步驟公布Blue組，驗證完成后切回每一個組各50%流量的日常模式。

?

至此，支付寶單元化全局架構例如以下圖所看到的。每個機房單元中有單元A和單元C。單元A中按邏輯分為了兩個組，單元C之間進行全局的數據復制；每個單元中部署了一套分布式的容災管控系統。使得支付寶能在單個機房故障的時候去做更加高速的應對。

?

總結? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

通過單元化的系統配置，使得支付寶整個系統架構具有非常強的高可用性和容災能力。

詳細來說有三點：

• 更靈活的流量管控，能夠實現以更小的力度和更快的速度來進行數據切換。

• 自己定義化的數據流量分配。

  因為每個數據單元須要多少資源、須要支撐多少交易量能夠前期確定，因此支付寶能夠依照實際的需求量進行單元維度的擴展。

• 高速恢復的容災能力。

  通過單元化之后。不僅使得數據單元內Blue組和Green組之間能夠切換流量，再向上一個級別。單元和單元之間、機房和機房之間、同城內數據中心之間甚至城市和城市之間也能夠自如地進行故障發生時的應急切換。不僅使得支付寶實現了“異地多活”的架構能力。更使其順利經過了2015年“雙11”的洗禮。

曾歡：花名“善衡”。2012年增加阿里巴巴集團技術保障部應用運維團隊，2013、2014年主要負責天貓、淘寶等核心系統運維工作，2014年底和2015年負責螞蟻金服運維、穩定性相關的工作。參與了螞蟻金服同城多活到異地多活的研發項目。

?

轉載于:https://www.cnblogs.com/davidwang456/articles/8392719.html

總結

以上是生活随笔為你收集整理的支付宝的高可用与容灾架构演进的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。