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

持續(xù)可用和高速容災(zāi)切換的能力，是技術(shù)人員追求的極致目標(biāo)。在架構(gòu)設(shè)計(jì)中，容災(zāi)設(shè)計(jì)強(qiáng)調(diào)的是系統(tǒng)對外界環(huán)境影響具備高速響應(yīng)能力。節(jié)點(diǎn)級別的高速恢復(fù)能力，保障系統(tǒng)的持續(xù)可用。

去年12月18日。全球架構(gòu)師峰會上，阿里巴巴高級系統(tǒng)project師曾歡（善衡）結(jié)合互聯(lián)網(wǎng)金融業(yè)務(wù)及系統(tǒng)特性。分享了在支付寶系統(tǒng)架構(gòu)演進(jìn)中，每一個階段的高可用和容災(zāi)能力建設(shè)的解決思路。

高可用和容災(zāi)架構(gòu)的意義

?

企業(yè)服務(wù)、云計(jì)算、移動互聯(lián)網(wǎng)領(lǐng)域中。高可用的分布式技術(shù)為支撐平臺正常運(yùn)作提供著關(guān)鍵性的技術(shù)支撐。從用戶角度，特別是作為主要收入來源的企業(yè)用戶的角度出發(fā)。保證業(yè)務(wù)處理的正確性和服務(wù)不中斷（高可用性）是支撐用戶信心的重要來源。

高性能。高可用的分布式架構(gòu)就成了訪問量高峰期時，站點(diǎn)得以成功運(yùn)維的關(guān)鍵。

?

在當(dāng)今信息時代，數(shù)據(jù)和信息逐漸成為各行各業(yè)的業(yè)務(wù)基礎(chǔ)和命脈。當(dāng)企業(yè)由于信息化帶來快捷的服務(wù)決策和方便管理時。也必須面對著數(shù)據(jù)丟失的危急。

?

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

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

在架構(gòu)設(shè)計(jì)中，作為系統(tǒng)高可用性技術(shù)的重要組成部分，容災(zāi)設(shè)計(jì)強(qiáng)調(diào)的是系統(tǒng)對外界環(huán)境影響具備高速響應(yīng)能力，尤其是當(dāng)發(fā)生災(zāi)難性事件并對IDC節(jié)點(diǎn)產(chǎn)生影響時。可以具備節(jié)點(diǎn)級別的高速恢復(fù)能力。保障系統(tǒng)的持續(xù)可用。

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

支付寶的系統(tǒng)架構(gòu)。其發(fā)展歷程能夠分為清晰的3個階段，每個階段都有自己獨(dú)特的特點(diǎn)和架構(gòu)上對應(yīng)的痛點(diǎn)。在每個階段的發(fā)展過程中，支付寶的技術(shù)人員針對不同的問題進(jìn)行諸多的思考，在解決這些問題的過程中也做了諸多的嘗試。

?

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

在此階段。支付寶的系統(tǒng)架構(gòu)相對照較簡化，如圖1所看到的，通過商用LB讓用戶的流量進(jìn)到入口網(wǎng)關(guān)系統(tǒng)，支付寶的系統(tǒng)服務(wù)暴露也通過商用設(shè)備掛在VIP下。每一個提供服務(wù)的應(yīng)用機(jī)器通過VIP來進(jìn)行負(fù)載均衡。

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

隨著業(yè)務(wù)量的不斷增長，該架構(gòu)發(fā)展到2011年，出現(xiàn)了一些比較典型的問題。例如以下圖所看到的：因?yàn)橄到y(tǒng)內(nèi)部使用的都是LB設(shè)備，商用LB的瓶頸就尤其明顯，因?yàn)闃I(yè)務(wù)的發(fā)展累計(jì)，VIP及其上面公布的服務(wù)越堆越多，設(shè)備假設(shè)出現(xiàn)抖動或者宕機(jī)會對業(yè)務(wù)造成嚴(yán)重影響，這即是架構(gòu)上的單點(diǎn)。第二個問題就是數(shù)據(jù)庫的單點(diǎn)瓶頸。隨著業(yè)務(wù)量的不斷添加。單一的核心數(shù)據(jù)庫一旦出現(xiàn)異常，比方硬件故障、負(fù)載異常等等，進(jìn)而會導(dǎo)致整個核心鏈路上的業(yè)務(wù)都不可用。

?

怎樣消除系統(tǒng)架構(gòu)其中存在的單點(diǎn)問題。優(yōu)雅解決未來1-3年之間業(yè)務(wù)量增長（數(shù)百萬級/天）和機(jī)器數(shù)量增長（數(shù)百個系統(tǒng)），是首先要解決的問題，于是帶來了下一代架構(gòu)革新。

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

鑒于第一階段支付寶碰到的這些痛點(diǎn)，在第二個階段。它將邏輯上的單個機(jī)房拆分成為多個機(jī)房，通過把硬負(fù)載轉(zhuǎn)換成為軟負(fù)載。以實(shí)現(xiàn)分布式的服務(wù)調(diào)用，例如以下圖所看到的。

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

?

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

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

通過上述兩個比較典型的優(yōu)化。支付寶的整個系統(tǒng)架構(gòu)如圖5所看到的。從應(yīng)用層面上來說每一個機(jī)房都是一個節(jié)點(diǎn)；從數(shù)據(jù)層面上，每一個機(jī)房有特定的幾個數(shù)據(jù)分片在里面。

在部署模式上，當(dāng)支付寶擴(kuò)張到3個或4個機(jī)房的時候，須要全局考慮數(shù)據(jù)分片部署，每一個機(jī)房都有可能不可用，這些備庫們應(yīng)當(dāng)分散到不同的多個機(jī)房里面，從而達(dá)到多機(jī)房備災(zāi)的目的。

?

這樣的多機(jī)房多活的第二代架構(gòu)體系，其優(yōu)勢在于：

• 進(jìn)行了數(shù)據(jù)的水平拆分。從而理論上能夠無限擴(kuò)展數(shù)據(jù)/資源。

• 應(yīng)用多機(jī)房獨(dú)立部署，不再存在單個機(jī)房影響總體的情況；

• 服務(wù)調(diào)用機(jī)房內(nèi)隔離。通過軟負(fù)載的方式去做機(jī)房內(nèi)的服務(wù)本地化，不再去依賴還有一個機(jī)房內(nèi)同樣的服務(wù)；

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

  ?

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

在這個過程中。有兩個比較大的痛點(diǎn)：

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

  ?

• 主備切換時數(shù)據(jù)存取不可用導(dǎo)致的業(yè)務(wù)暫停問題。

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

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

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

一旦故障發(fā)生。主庫發(fā)生宕機(jī)，支付寶人員將通過容災(zāi)切換將全部數(shù)據(jù)的讀寫放置在FailOver數(shù)據(jù)層中進(jìn)行。

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

FailOver方案上線后，支付寶基本上全部的核心業(yè)務(wù)都基于此進(jìn)行了方案改造，并針對不同的業(yè)務(wù)（不僅限于應(yīng)用層）都會有不同的FailOver方案。

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

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

通過“多機(jī)房多活”的架構(gòu)改造以及FailOver方案的實(shí)施。滿以為未來三年都無需為IDC資源去發(fā)愁的支付寶研發(fā)團(tuán)隊(duì)，在順利支撐完2012年的“雙11”，為下一年做規(guī)劃時卻發(fā)現(xiàn)夢想破滅了。由于他們遇到了嚴(yán)峻的新問題：

• DB連接數(shù)不夠。由于一個機(jī)房中的應(yīng)用系統(tǒng)就是一個節(jié)點(diǎn)，沒有分片的概念，只唯獨(dú)數(shù)據(jù)的分片。用戶進(jìn)入隨意應(yīng)用節(jié)點(diǎn)時。系統(tǒng)須要依據(jù)用戶的UID分片查用戶應(yīng)該去往哪個數(shù)據(jù)庫，這時候每一個應(yīng)用節(jié)點(diǎn)都會與全部數(shù)據(jù)庫節(jié)點(diǎn)保持連接。

  而傳統(tǒng)關(guān)系型數(shù)據(jù)庫的連接數(shù)是十分寶貴的，當(dāng)支付寶面對不斷增長的用戶擴(kuò)容需求時，由于DB連接數(shù)資源無法繼續(xù)擴(kuò)充，導(dǎo)致應(yīng)用也不能繼續(xù)擴(kuò)容了。不僅無法滿足日常增長需求，更別提“雙11”這樣短時間爆發(fā)式增長的用戶需求。

  ?

• 城市IDC資源限制問題。2012年夏天。杭州經(jīng)歷了長時間高溫天氣，因?yàn)闄C(jī)房執(zhí)行的耗電較高，市政為了緩解電力供應(yīng)壓力。下達(dá)了一紙通文，隨時可能關(guān)閉掉支付寶的某些機(jī)房供電。

  ?

• 機(jī)房間高流量問題。

  因?yàn)橐粋€業(yè)務(wù)請求與后端數(shù)據(jù)讀取之間的比例為1:N（當(dāng)中N可能是幾十甚至上百），在“雙11”高流量的沖擊下。跨機(jī)房的流量會變得很的大。因此對于網(wǎng)絡(luò)帶寬和網(wǎng)絡(luò)質(zhì)量也有著很高的要求。

  ?

• 跨IDC網(wǎng)絡(luò)延時問題。

  因?yàn)闃I(yè)務(wù)請求和后端數(shù)據(jù)讀取1:N配比問題，導(dǎo)致同城機(jī)房之間距離略微遠(yuǎn)一些。就會產(chǎn)生1、2毫秒的同城機(jī)房延時。被擴(kuò)大后就會成為困擾用戶的網(wǎng)絡(luò)延時問題。

新的問題進(jìn)而帶來對新一代架構(gòu)的要求：

• 徹底解決DB連接數(shù)的問題。

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

  須要支付寶走出杭州。不能單單在杭州進(jìn)行機(jī)房的擴(kuò)張和建設(shè)。

• 保證業(yè)務(wù)的連續(xù)性。去降低故障發(fā)生的時候?qū)τ谟脩舻拇驍嚒τ跇I(yè)務(wù)的中斷。

  ?

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

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

• 高可用-異地多活。對于支付寶來說，傳統(tǒng)的“兩地三中心”要求：機(jī)房分屬兩個不同地區(qū)，同城其中兩個機(jī)房是“雙活”，即活躍的主機(jī)房，異地機(jī)房通過復(fù)制數(shù)據(jù)來做“冷備”。即備用機(jī)房。若同城兩個機(jī)房都出現(xiàn)故障。一旦須要切換異地機(jī)房，因?yàn)椴恢喇惖乩鋫錂C(jī)房執(zhí)行起來是什么情況，因此非常難決策。

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

  ?

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

  如圖9所看到的。傳統(tǒng)的服務(wù)化架構(gòu)下每一次調(diào)用服務(wù)時，系統(tǒng)都會隨機(jī)選擇一臺機(jī)器或一個節(jié)點(diǎn)完畢整次的調(diào)用。而單元化之后支付寶能夠把不論什么一個節(jié)點(diǎn)固定到一個單獨(dú)的單元內(nèi)，即固定的節(jié)點(diǎn)相應(yīng)一條固定的鏈路，再基于數(shù)據(jù)分片的方法完畢將節(jié)點(diǎn)“單元化”的設(shè)置。

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

核心剝離指的是將核心業(yè)務(wù)進(jìn)行剝離；將業(yè)務(wù)數(shù)據(jù)依照UserID進(jìn)行拆分。從而實(shí)現(xiàn)多機(jī)房部署。在此基礎(chǔ)上將每個機(jī)房的調(diào)用進(jìn)行封閉式設(shè)置；每個單元中的業(yè)務(wù)數(shù)據(jù)無需和其他單元進(jìn)行同步。

長尾獨(dú)立則針對非核心的應(yīng)用。這些業(yè)務(wù)數(shù)據(jù)并不依照UID進(jìn)行拆分。核心業(yè)務(wù)并不依賴于長尾應(yīng)用。

支付寶單元化架構(gòu)實(shí)現(xiàn)的主要思想有兩點(diǎn)，例如以下圖所看到的：

數(shù)據(jù)水平拆分，即將全部線上核心業(yè)務(wù)分離開來。因?yàn)楹诵臉I(yè)務(wù)集合都能依照用戶ID去做水平切片，支付寶團(tuán)隊(duì)將數(shù)據(jù)切片后依照機(jī)房進(jìn)行分布。然后通過循序漸進(jìn)的方式逐步將每個單元之間的調(diào)用完整地封閉掉。每個單元的數(shù)據(jù)都是經(jīng)過分片的數(shù)據(jù)，不需和其他單元進(jìn)行同步。

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

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

例如以下圖所看到的。

因?yàn)閿?shù)據(jù)的寫入操作會在每個數(shù)據(jù)單元上進(jìn)行，而單元C的數(shù)據(jù)讀取是要求全量的，所以進(jìn)行這一項(xiàng)改造的時候須要底層的支持，從而解決架構(gòu)改造時數(shù)據(jù)一致性和時效性的問題。

為了解決問題，支付寶團(tuán)隊(duì)提出了兩種解決方式：

• 基于DB同步的數(shù)據(jù)復(fù)制。針對某些對于延時并不是十分敏感的業(yè)務(wù)。單就基于主備同步來做數(shù)據(jù)的同步。

• 基于消息系統(tǒng)的數(shù)據(jù)復(fù)制。因?yàn)楫惖財(cái)?shù)據(jù)同步比較耗時。對于延時很敏感的業(yè)務(wù)來說，支付寶基于可靠的消息系統(tǒng)做一個數(shù)據(jù)復(fù)制（內(nèi)部稱為數(shù)據(jù)總線），通過它將上層基于應(yīng)用去做數(shù)據(jù)的復(fù)制，大概時間位于毫秒級。底層DB主備同步同一時候進(jìn)行。

  ?

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

?

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

?

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

?

總結(jié)? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

通過單元化的系統(tǒng)配置，使得支付寶整個系統(tǒng)架構(gòu)具有非常強(qiáng)的高可用性和容災(zāi)能力。

詳細(xì)來說有三點(diǎn)：

• 更靈活的流量管控，能夠?qū)崿F(xiàn)以更小的力度和更快的速度來進(jìn)行數(shù)據(jù)切換。

• 自己定義化的數(shù)據(jù)流量分配。

  因?yàn)槊總€數(shù)據(jù)單元須要多少資源、須要支撐多少交易量能夠前期確定，因此支付寶能夠依照實(shí)際的需求量進(jìn)行單元維度的擴(kuò)展。

• 高速恢復(fù)的容災(zāi)能力。

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

曾歡：花名“善衡”。2012年增加阿里巴巴集團(tuán)技術(shù)保障部應(yīng)用運(yùn)維團(tuán)隊(duì)，2013、2014年主要負(fù)責(zé)天貓、淘寶等核心系統(tǒng)運(yùn)維工作，2014年底和2015年負(fù)責(zé)螞蟻金服運(yùn)維、穩(wěn)定性相關(guān)的工作。參與了螞蟻金服同城多活到異地多活的研發(fā)項(xiàng)目。

?

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/8392719.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。