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

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

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

企業(yè)服務(wù)、云計(jì)算谜慌、移動(dòng)互聯(lián)網(wǎng)領(lǐng)域中然想，高可用的分布式技術(shù)為支撐平臺(tái)正常運(yùn)作提供著關(guān)鍵性的技術(shù)支撐莺奔。從用戶角度欣范，特別是作為主要收入來(lái)源的企業(yè)用戶的角度出發(fā)变泄，保證業(yè)務(wù)處理的正確性和服務(wù)不中斷（高可用性）是支撐用戶信心的重要來(lái)源。高性能恼琼，高可用的分布式架構(gòu)就成了訪問(wèn)量高峰期時(shí)妨蛹，網(wǎng)站得以成功運(yùn)維的關(guān)鍵。

在當(dāng)今信息時(shí)代晴竞，數(shù)據(jù)和信息逐漸成為各行各業(yè)的業(yè)務(wù)基礎(chǔ)和命脈蛙卤。當(dāng)企業(yè)因?yàn)樾畔⒒瘞?lái)快捷的服務(wù)決策和方便管理時(shí)，也必須面對(duì)著數(shù)據(jù)丟失的危險(xiǎn)噩死。

容災(zāi)系統(tǒng)颤难，作為為計(jì)算機(jī)信息系統(tǒng)提供的一個(gè)能應(yīng)付各種災(zāi)難的環(huán)境，尤其是計(jì)算機(jī)犯罪已维、計(jì)算機(jī)病毒行嗤、掉電、網(wǎng)絡(luò)/通信失敗垛耳、硬件/軟件錯(cuò)誤和人為操作錯(cuò)誤等人為災(zāi)難時(shí)栅屏，容災(zāi)系統(tǒng)將保證用戶數(shù)據(jù)的安全性（數(shù)據(jù)容災(zāi)），甚至堂鲜，一個(gè)更加完善的容災(zāi)系統(tǒng)栈雳，還能提供不間斷的應(yīng)用服務(wù)（應(yīng)用容災(zāi)）〉蘖可以說(shuō)哥纫，容災(zāi)系統(tǒng)是數(shù)據(jù)存儲(chǔ)備份的最高層次。

每年的“雙11”酌予、“雙12”都是全球購(gòu)物者的狂歡節(jié)磺箕，今年的雙11有232個(gè)國(guó)家參與進(jìn)來(lái)，成為名副其實(shí)的全球瘋狂購(gòu)物節(jié)抛虫。11月11日松靡，全天的交易額達(dá)到912.17億元，其中在移動(dòng)端交易額占比68%今年每秒的交易峰值達(dá)到14萬(wàn)筆建椰，螞蟻金服旗下的支付寶交易峰值達(dá)到8.59萬(wàn)筆/秒雕欺，這一系列的數(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)對(duì)外界環(huán)境影響具備快速響應(yīng)能力，尤其是當(dāng)發(fā)生災(zāi)難性事件并對(duì)IDC節(jié)點(diǎn)產(chǎn)生影響時(shí)乃坤，能夠具備節(jié)點(diǎn)級(jí)別的快速恢復(fù)能力苛让，保障系統(tǒng)的持續(xù)可用沟蔑。2015年12月18日，年度高端技術(shù)盛會(huì)：“全球架構(gòu)師峰會(huì)——ArchSummit”在北京國(guó)際會(huì)議中心隆重召開(kāi)狱杰，會(huì)上瘦材，阿里巴巴高級(jí)系統(tǒng)工程師：善衡（曾歡）結(jié)合互聯(lián)網(wǎng)金融業(yè)務(wù)及系統(tǒng)特性，分享了在支付寶系統(tǒng)架構(gòu)演進(jìn)中仿畸，每個(gè)階段的高可用和容災(zāi)能力建設(shè)的解決思路食棕。本文由其演講內(nèi)容整理而成。

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

純真：童年時(shí)期2004年~2011年

在此階段镰禾，支付寶的系統(tǒng)架構(gòu)相對(duì)比較簡(jiǎn)化皿曲，如圖1所示，通過(guò)商用LB讓用戶的流量進(jìn)到入口網(wǎng)關(guān)系統(tǒng)吴侦，支付寶的系統(tǒng)服務(wù)暴露也通過(guò)商用設(shè)備掛在VIP下屋休，每個(gè)提供服務(wù)的應(yīng)用機(jī)器通過(guò)VIP來(lái)進(jìn)行負(fù)載均衡。早期支付寶的核心系統(tǒng)庫(kù)都在一個(gè)數(shù)據(jù)庫(kù)上（后期拆為多個(gè)數(shù)據(jù)庫(kù)）备韧，即每個(gè)核心系統(tǒng)都只用單獨(dú)的數(shù)據(jù)庫(kù)劫樟。在這樣一個(gè)“物理上多機(jī)房，邏輯上單機(jī)房”的架構(gòu)背后织堂，每天的業(yè)務(wù)量?jī)H僅為數(shù)十萬(wàn)級(jí)叠艳，應(yīng)用系統(tǒng)也只有數(shù)十個(gè)，容災(zāi)能力相對(duì)較低：例如單應(yīng)用出現(xiàn)問(wèn)題時(shí)無(wú)法及時(shí)有效地切換易阳、主機(jī)和備用機(jī)進(jìn)行切換時(shí)附较，一定程度上會(huì)導(dǎo)致業(yè)務(wù)中斷，甚至有時(shí)會(huì)有不得不進(jìn)行停機(jī)維護(hù)的情況潦俺，使得整個(gè)系統(tǒng)面對(duì)數(shù)據(jù)故障時(shí)顯得十分被動(dòng)拒课。

隨著業(yè)務(wù)量的不斷增長(zhǎng)，該架構(gòu)發(fā)展到2011年事示，出現(xiàn)了一些比較典型的問(wèn)題早像。如下圖所示：由于系統(tǒng)內(nèi)部使用的都是LB設(shè)備，商用LB的瓶頸就尤其明顯肖爵，由于業(yè)務(wù)的發(fā)展累計(jì)卢鹦，VIP及其上面發(fā)布的服務(wù)越堆越多，設(shè)備如果出現(xiàn)抖動(dòng)或者宕機(jī)會(huì)對(duì)業(yè)務(wù)造成嚴(yán)重影響劝堪，這即是架構(gòu)上的單點(diǎn)冀自。第二個(gè)問(wèn)題就是數(shù)據(jù)庫(kù)的單點(diǎn)瓶頸谁榜。隨著業(yè)務(wù)量的不斷增加，單一的核心數(shù)據(jù)庫(kù)一旦出現(xiàn)異常凡纳，比如硬件故障、負(fù)載異常等等帝蒿，進(jìn)而會(huì)導(dǎo)致整個(gè)核心鏈路上的業(yè)務(wù)都不可用荐糜。

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

懵懂：少年時(shí)期2011年~2012年

鑒于第一階段支付寶碰到的這些痛點(diǎn)绣张，在第二個(gè)階段答渔，它將邏輯上的單個(gè)機(jī)房拆分成為多個(gè)機(jī)房，通過(guò)把硬負(fù)載轉(zhuǎn)換成為軟負(fù)載侥涵，以實(shí)現(xiàn)分布式的服務(wù)調(diào)用沼撕，如下圖所示。下圖為基于常見(jiàn)的消費(fèi)者和生產(chǎn)者模型來(lái)構(gòu)建的業(yè)務(wù)模型芜飘，其中配置中心負(fù)責(zé)服務(wù)注冊(cè)以及對(duì)應(yīng)服務(wù)提供方可用狀態(tài)變化的通知务豺，從而將信息實(shí)時(shí)推送到消費(fèi)方的訂閱關(guān)系上。值得注意的是嗦明，支付寶對(duì)原有架構(gòu)做了一個(gè)較大的改進(jìn)：它將普通的一體化配置中心分拆成兩個(gè)模塊笼沥，一個(gè)Session模塊，用于管理消費(fèi)者和生產(chǎn)者的長(zhǎng)連接保持娶牌；一個(gè)Data模塊奔浅，用于注冊(cè)服務(wù)時(shí)存儲(chǔ)相關(guān)。通過(guò)這兩個(gè)模塊的深度解耦诗良，進(jìn)一步提高整個(gè)配置中心的性能汹桦。

除此之外，支付寶還做了數(shù)據(jù)的水平擴(kuò)展鉴裹。其實(shí)早在2011年之前营勤，支付寶就已經(jīng)開(kāi)始從事此項(xiàng)工作，根據(jù)用戶的UID壹罚，將一個(gè)交易庫(kù)水平拆分為多個(gè)庫(kù)葛作，如下圖所示。在此期間猖凛，需要解決的問(wèn)題就是“對(duì)應(yīng)用透明”赂蠢，如何通過(guò)“應(yīng)用無(wú)感知”的方式進(jìn)行用戶數(shù)據(jù)庫(kù)的拆分，是水平擴(kuò)展實(shí)施時(shí)首先要考慮的辨泳；其次虱岂，如何通過(guò)一個(gè)數(shù)據(jù)中間件來(lái)管理數(shù)據(jù)分片的規(guī)則玖院，也是數(shù)據(jù)水平擴(kuò)展過(guò)程中的關(guān)鍵問(wèn)題。

通過(guò)上述兩個(gè)比較典型的優(yōu)化第岖，支付寶的整個(gè)系統(tǒng)架構(gòu)如圖5所示难菌。從應(yīng)用層面上來(lái)說(shuō)每個(gè)機(jī)房都是一個(gè)節(jié)點(diǎn)；從數(shù)據(jù)層面上蔑滓，每個(gè)機(jī)房有特定的幾個(gè)數(shù)據(jù)分片在里面郊酒。在部署模式上，當(dāng)支付寶擴(kuò)張到3個(gè)或4個(gè)機(jī)房的時(shí)候键袱，需要全局考慮數(shù)據(jù)分片部署燎窘，每個(gè)機(jī)房都有可能不可用，這些備庫(kù)們應(yīng)當(dāng)分散到不同的多個(gè)機(jī)房里面蹄咖，從而達(dá)到多機(jī)房備災(zāi)的目的褐健。

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

1.進(jìn)行了數(shù)據(jù)的水平拆分澜汤，從而理論上可以無(wú)限擴(kuò)展數(shù)據(jù)/資源蚜迅；

2.應(yīng)用多機(jī)房獨(dú)立部署，不再存在單個(gè)機(jī)房影響整體的情況俊抵；

3.服務(wù)調(diào)用機(jī)房?jī)?nèi)隔離慢叨，通過(guò)軟負(fù)載的方式去做機(jī)房?jī)?nèi)的服務(wù)本地化，不再去依賴(lài)另一個(gè)機(jī)房?jī)?nèi)相同的服務(wù)务蝠；

4.相較上一個(gè)階段具有更高拍谐、更可靠的可用性。

雖然在此過(guò)程中自然解決了上述的單點(diǎn)問(wèn)題馏段，但仍存在一個(gè)問(wèn)題沒(méi)有解決轩拨。即數(shù)據(jù)庫(kù)日常維護(hù)時(shí)，或因?yàn)橛布墓收蠈?dǎo)致數(shù)據(jù)庫(kù)宕機(jī)時(shí)院喜，支付寶需要進(jìn)行主備切換亡蓉，在此過(guò)程中業(yè)務(wù)是有損的狀態(tài)。一般情況下當(dāng)IDC出現(xiàn)問(wèn)題的時(shí)候喷舀，工程師們會(huì)通過(guò)前端的流量管控系統(tǒng)先把用戶的流量從出現(xiàn)異常的機(jī)房切換到正常的機(jī)房中砍濒，然后進(jìn)行數(shù)據(jù)庫(kù)的主備切換拇派，即將備用負(fù)載替換主用負(fù)載稠茂。

在這個(gè)過(guò)程中般甲，有兩個(gè)比較大的痛點(diǎn)：

1.主備切換時(shí)數(shù)據(jù)“一致性”的問(wèn)題豪硅，即主備切換時(shí)，如何在把影響時(shí)間降至最低的情況下贼急，保證數(shù)據(jù)不被丟失昏翰，完完整整地拷貝至備用數(shù)據(jù)庫(kù)傻咖。

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

一旦數(shù)據(jù)庫(kù)發(fā)生故障券敌，我們需要進(jìn)行主備切換時(shí)唾戚，因?yàn)榍袚Q過(guò)程中的數(shù)據(jù)不可寫(xiě)，部分用戶操作后的狀態(tài)不對(duì)待诅，對(duì)用戶來(lái)說(shuō)是會(huì)擔(dān)心的叹坦。為了解決這個(gè)問(wèn)題，我們制定了一個(gè)Failover方案卑雁。該方案主要通過(guò)業(yè)務(wù)層進(jìn)行改造募书，例如針對(duì)流水型的業(yè)務(wù)數(shù)據(jù)，我們是這么來(lái)做的：正常進(jìn)行數(shù)據(jù)流量存取的時(shí)候序厉，只有主庫(kù)提供路線服務(wù)，主庫(kù)和備庫(kù)之間進(jìn)行正常的數(shù)據(jù)同步毕箍，但是Failover庫(kù)不進(jìn)行數(shù)據(jù)同步弛房，正常狀態(tài)下對(duì)業(yè)務(wù)系統(tǒng)不可見(jiàn)。即正常情況下而柑，沒(méi)有數(shù)據(jù)流經(jīng)過(guò)Failover庫(kù)文捶，而且Failover庫(kù)是空的，沒(méi)有任何歷史數(shù)據(jù)媒咳，如下圖所示：

一旦故障發(fā)生粹排，主庫(kù)發(fā)生宕機(jī)，支付寶人員將通過(guò)容災(zāi)切換將所有數(shù)據(jù)的讀寫(xiě)放置在FailOver數(shù)據(jù)層中進(jìn)行涩澡。因?yàn)槭菍?shí)時(shí)流水型的數(shù)據(jù)顽耳，所以不會(huì)對(duì)歷史數(shù)據(jù)產(chǎn)生任何依賴(lài)和影響。切換完成后妙同，整個(gè)核心鏈路上的業(yè)務(wù)就已經(jīng)全面恢復(fù)起來(lái)了射富。通過(guò)這種方式，使得支付寶可以將數(shù)據(jù)庫(kù)在短短5分鐘內(nèi)進(jìn)行切換粥帚，一旦故障解除胰耗，隨時(shí)可以將數(shù)據(jù)讀寫(xiě)重新切換到主存儲(chǔ)庫(kù)上來(lái)。

FailOver方案上線后芒涡，支付寶基本上所有的核心業(yè)務(wù)都基于此進(jìn)行了方案改造柴灯，并針對(duì)不同的業(yè)務(wù)（不僅限于應(yīng)用層）都會(huì)有不同的FailOver方案。現(xiàn)在费尽，支付寶在原有的方案基礎(chǔ)上再多準(zhǔn)備一個(gè)Failover數(shù)據(jù)庫(kù)（如圖8中藍(lán)色圖形所示）赠群，與之前提到的容災(zāi)設(shè)計(jì)一樣，如果需要進(jìn)一步保證Failover庫(kù)的可用性旱幼，還可以增加Failover庫(kù)的備庫(kù)乎串。此外Failover庫(kù)需要與主庫(kù)分開(kāi)，可以與主庫(kù)、備庫(kù)都不放在同一個(gè)機(jī)房叹誉。

成熟：青年時(shí)期2012年~2015年

通過(guò)“多機(jī)房多活”的架構(gòu)改造以及FailOver方案的實(shí)施鸯两，滿以為未來(lái)三年都無(wú)需為IDC資源去發(fā)愁的支付寶研發(fā)團(tuán)隊(duì)，在順利支撐完2012年的“雙11”长豁，為下一年做規(guī)劃時(shí)卻發(fā)現(xiàn)夢(mèng)想破滅了钧唐。因?yàn)樗麄冇龅搅藝?yán)峻的新問(wèn)題：

1.DB連接數(shù)不夠。由于一個(gè)機(jī)房中的應(yīng)用系統(tǒng)就是一個(gè)節(jié)點(diǎn)匠襟，沒(méi)有分片的概念钝侠，僅僅只有數(shù)據(jù)的分片。用戶進(jìn)入任意應(yīng)用節(jié)點(diǎn)時(shí)酸舍，系統(tǒng)需要根據(jù)用戶的UID分片查用戶應(yīng)該去往哪個(gè)數(shù)據(jù)庫(kù)帅韧，這時(shí)候每個(gè)應(yīng)用節(jié)點(diǎn)都會(huì)與所有數(shù)據(jù)庫(kù)節(jié)點(diǎn)保持連接。而傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)的連接數(shù)是十分寶貴的啃勉，當(dāng)支付寶面對(duì)不斷增長(zhǎng)的用戶擴(kuò)容需求時(shí)忽舟，因?yàn)镈B連接數(shù)資源無(wú)法繼續(xù)擴(kuò)充，導(dǎo)致應(yīng)用也不能繼續(xù)擴(kuò)容了淮阐，不僅無(wú)法滿足日常增長(zhǎng)需求叮阅，更別提“雙11”這樣短時(shí)間爆發(fā)式增長(zhǎng)的用戶需求。

2.城市IDC資源限制問(wèn)題泣特。2012年夏天浩姥，杭州經(jīng)歷了長(zhǎng)時(shí)間高溫天氣，由于機(jī)房運(yùn)行的耗電較高状您，市政為了緩解電力供應(yīng)壓力勒叠，下達(dá)了一紙通文，隨時(shí)可能關(guān)閉掉支付寶的某些機(jī)房供電膏孟。

3.機(jī)房間高流量問(wèn)題缴饭。由于一個(gè)業(yè)務(wù)請(qǐng)求與后端數(shù)據(jù)讀取之間的比例為1:N（其中N可能是幾十甚至上百），在“雙11”高流量的沖擊下骆莹，跨機(jī)房的流量會(huì)變得非常的大颗搂，因此對(duì)于網(wǎng)絡(luò)帶寬和網(wǎng)絡(luò)質(zhì)量也有著非常高的要求。

4.跨IDC網(wǎng)絡(luò)延時(shí)問(wèn)題幕垦。由于業(yè)務(wù)請(qǐng)求和后端數(shù)據(jù)讀取1:N配比問(wèn)題丢氢，導(dǎo)致同城機(jī)房之間距離稍微遠(yuǎn)一些，就會(huì)產(chǎn)生1先改、2毫秒的同城機(jī)房延時(shí)疚察，被擴(kuò)大后就會(huì)成為困擾用戶的網(wǎng)絡(luò)延時(shí)問(wèn)題。

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

1.徹底解決DB連接數(shù)的問(wèn)題仇奶。

2.徹底解決IDC資源限制的問(wèn)題貌嫡。需要支付寶走出杭州，不能單單在杭州進(jìn)行機(jī)房的擴(kuò)張和建設(shè)。

3.保證業(yè)務(wù)的連續(xù)性岛抄。去減少故障發(fā)生的時(shí)候?qū)τ谟脩舻拇驍_别惦、對(duì)于業(yè)務(wù)的中斷。

4.藍(lán)綠發(fā)布夫椭。在日常發(fā)布時(shí)掸掸，會(huì)通過(guò)線下的發(fā)布測(cè)試，預(yù)發(fā)布蹭秋，最終到線上的發(fā)布過(guò)程扰付。線上發(fā)布通常采用的是金絲雀模式，應(yīng)用分成多組進(jìn)行發(fā)布仁讨，每一組的用戶不固定羽莺，可能會(huì)影響到大部分乃至全站的用戶。因此支付寶團(tuán)隊(duì)希望日常發(fā)布時(shí)洞豁，能夠最小限度影響用戶（可能是1%甚至1‰）盐固，新代碼上線之后最小力度來(lái)驗(yàn)證新代碼符合預(yù)期。因此需要一種新的發(fā)布方式來(lái)支持族跛。

5.高可用-異地多活闰挡。對(duì)于支付寶來(lái)說(shuō)锐墙，傳統(tǒng)的“兩地三中心”要求：機(jī)房分屬兩個(gè)不同地區(qū)礁哄，同城當(dāng)中兩個(gè)機(jī)房是“雙活”，即活躍的主機(jī)房溪北，異地機(jī)房通過(guò)復(fù)制數(shù)據(jù)來(lái)做“冷備”桐绒，即備用機(jī)房。若同城兩個(gè)機(jī)房都出現(xiàn)問(wèn)題之拨，一旦需要切換異地機(jī)房茉继，由于不知道異地冷備機(jī)房運(yùn)行起來(lái)是什么情況，因此很難決策蚀乔。支付寶希望異地的機(jī)房也能實(shí)時(shí)進(jìn)行流量的讀寫(xiě)烁竭，以便數(shù)據(jù)流量可以來(lái)回切換，而不用擔(dān)心在切換后無(wú)法知道數(shù)據(jù)將是什么狀態(tài)吉挣。

6.????單元化派撕。基于上述幾個(gè)問(wèn)題的思考睬魂，支付寶走到了單元化的一步终吼。如圖9所示，傳統(tǒng)的服務(wù)化架構(gòu)下每一次調(diào)用服務(wù)時(shí)氯哮，系統(tǒng)都會(huì)隨機(jī)選擇一臺(tái)機(jī)器或一個(gè)節(jié)點(diǎn)完成整次的調(diào)用际跪。而單元化之后支付寶可以把任何一個(gè)節(jié)點(diǎn)固定到一個(gè)單獨(dú)的單元內(nèi)，即固定的節(jié)點(diǎn)對(duì)應(yīng)一條固定的鏈路，再基于數(shù)據(jù)分片的方法完成將節(jié)點(diǎn)“單元化”的設(shè)置姆打。

單元化的核心思想包括核心剝離以及長(zhǎng)尾獨(dú)立良姆。核心剝離指的是將核心業(yè)務(wù)進(jìn)行剝離；將業(yè)務(wù)數(shù)據(jù)按照UserID進(jìn)行拆分穴肘，從而實(shí)現(xiàn)多機(jī)房部署歇盼；在此基礎(chǔ)上將每一個(gè)機(jī)房的調(diào)用進(jìn)行封閉式設(shè)置；每一個(gè)單元中的業(yè)務(wù)數(shù)據(jù)無(wú)需和其它單元進(jìn)行同步评抚。長(zhǎng)尾獨(dú)立則針對(duì)非核心的應(yīng)用豹缀，這些業(yè)務(wù)數(shù)據(jù)并不按照UID進(jìn)行拆分，核心業(yè)務(wù)并不依賴(lài)于長(zhǎng)尾應(yīng)用慨代。

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

數(shù)據(jù)水平拆分，即將所有線上核心業(yè)務(wù)分離開(kāi)來(lái)侍匙。由于核心業(yè)務(wù)集合都能按照用戶ID去做水平切片氮惯，支付寶團(tuán)隊(duì)將數(shù)據(jù)切片后按照機(jī)房進(jìn)行分布，然后通過(guò)循序漸進(jìn)的方式逐步將每個(gè)單元之間的調(diào)用完整地封閉掉想暗。每一個(gè)單元的數(shù)據(jù)都是經(jīng)過(guò)分片的數(shù)據(jù)妇汗，不需和其它單元進(jìn)行同步。

上層單元化改造说莫，即將歷史的杨箭、不能拆分的業(yè)務(wù)獨(dú)立出來(lái)。2013年储狭，支付寶實(shí)現(xiàn)了兩個(gè)單元：?jiǎn)卧狝放置核心業(yè)務(wù)互婿，例如核心鏈路的支付、交易等辽狈；單元B放置無(wú)法拆分的歷史業(yè)務(wù)慈参，例如某些不重要的業(yè)務(wù)等。

支付寶單元化架構(gòu)于2013年完成刮萌，幫助支付寶順利支撐過(guò)了2013年的“雙11”驮配。而2014年~2015年，支付寶一直在嘗試解決異地延時(shí)的問(wèn)題：即如果不去對(duì)全局?jǐn)?shù)據(jù)進(jìn)行分割或是本地化的話着茸，當(dāng)把業(yè)務(wù)單元搬到異地時(shí)壮锻，由于每一次業(yè)務(wù)的發(fā)生基本上都會(huì)依賴(lài)全局?jǐn)?shù)據(jù)，且會(huì)對(duì)應(yīng)多次數(shù)據(jù)訪問(wèn)元扔，而每一次數(shù)據(jù)訪問(wèn)都會(huì)產(chǎn)生異地所帶來(lái)的延時(shí)躯保，積少成多，時(shí)間延遲就會(huì)達(dá)到秒級(jí)澎语，用戶體驗(yàn)大幅度下降途事⊙榘茫基于這個(gè)問(wèn)題的考慮，支付寶研發(fā)團(tuán)隊(duì)做了一個(gè)很大的決定：他們引入了單元C尸变，通過(guò)將無(wú)法拆分的全量數(shù)據(jù)進(jìn)行全局復(fù)制（異地機(jī)房之間的復(fù)制）义图，以便于支撐核心業(yè)務(wù)本地調(diào)用，進(jìn)而實(shí)現(xiàn)讀寫(xiě)分離召烂，將跨城市的調(diào)用減少到最小力度碱工。如下圖所示。

由于數(shù)據(jù)的寫(xiě)入操作會(huì)在每一個(gè)數(shù)據(jù)單元上進(jìn)行奏夫，而單元C的數(shù)據(jù)讀取是要求全量的怕篷，所以進(jìn)行這一項(xiàng)改造的時(shí)候需要底層的支持，從而解決架構(gòu)改造時(shí)數(shù)據(jù)一致性和時(shí)效性的問(wèn)題酗昼。為了解決這個(gè)問(wèn)題廊谓，支付寶團(tuán)隊(duì)提出了兩種解決方案：

1.基于DB同步的數(shù)據(jù)復(fù)制。針對(duì)某些對(duì)于延時(shí)并非十分敏感的業(yè)務(wù)麻削，單就基于主備同步來(lái)做數(shù)據(jù)的同步蒸痹。

2.基于消息系統(tǒng)的數(shù)據(jù)復(fù)制。由于異地?cái)?shù)據(jù)同步比較耗時(shí)呛哟，對(duì)于延時(shí)非常敏感的業(yè)務(wù)來(lái)說(shuō)叠荠，支付寶基于可靠的消息系統(tǒng)做一個(gè)數(shù)據(jù)復(fù)制（內(nèi)部稱(chēng)為數(shù)據(jù)總線），通過(guò)它將上層基于應(yīng)用去做數(shù)據(jù)的復(fù)制扫责，大概時(shí)間位于毫秒級(jí)榛鼎。底層DB主備同步同時(shí)進(jìn)行。

通過(guò)本地化調(diào)用公给，支付寶有效地解決了DB連接數(shù)問(wèn)題借帘、機(jī)房間流量限制問(wèn)題蜘渣、跨IDC的延時(shí)問(wèn)題淌铐；通過(guò)異地的單元部署以及不斷的容災(zāi)演練和數(shù)據(jù)切換，支付寶有效地解決了城市IDC資源限制和異地IDC容災(zāi)問(wèn)題蔫缸。另外還有一個(gè)訴求——“藍(lán)綠發(fā)布”腿准，支付寶是這么實(shí)現(xiàn)的。

如下圖所示拾碌，藍(lán)綠發(fā)布即每個(gè)單元里面分為一個(gè)Blue組和一個(gè)Green組吐葱，日常模式下兩個(gè)組各承擔(dān)50%的用戶流量；發(fā)布前將Green組中的50%流量移到Blue組中校翔，然后對(duì)Green進(jìn)行兩批無(wú)序發(fā)布弟跑；新代碼發(fā)布上去后，將Blue組中的流量先切換1%~2%到Green組中進(jìn)行驗(yàn)證防症，以最大程度減少對(duì)用戶的打擾孟辑，驗(yàn)證完畢后哎甲，再逐步將100%的流量全部切換至新的Green組，重復(fù)前面的步驟發(fā)布Blue組饲嗽，驗(yàn)證完畢后切回每個(gè)組各50%流量的日常模式炭玫。

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

總結(jié)

通過(guò)單元化的系統(tǒng)配置袄膏，使得支付寶整個(gè)系統(tǒng)架構(gòu)具有很強(qiáng)的高可用性和容災(zāi)能力巫财。具體來(lái)說(shuō)有三點(diǎn)：

1.更靈活的流量管控，可以實(shí)現(xiàn)以更小的力度和更快的速度來(lái)進(jìn)行數(shù)據(jù)切換哩陕。

2.自定義化的數(shù)據(jù)流量分配平项。由于每一個(gè)數(shù)據(jù)單元需要多少資源、需要支撐多少交易量可以前期確定悍及，因此支付寶可以按照實(shí)際的需求量進(jìn)行單元維度的擴(kuò)展闽瓢。

3.快速恢復(fù)的容災(zāi)能力。通過(guò)單元化之后心赶，不僅使得數(shù)據(jù)單元內(nèi)Blue組和Green組之間可以切換流量扣讼，再向上一個(gè)級(jí)別，單元和單元之間缨叫、機(jī)房和機(jī)房之間椭符、同城內(nèi)數(shù)據(jù)中心之間甚至城市和城市之間也可以自如地進(jìn)行故障發(fā)生時(shí)的應(yīng)急切換。在這里順便給大家推薦一個(gè)架構(gòu)交流群：617434785耻姥，里面會(huì)分享一些資深架構(gòu)師錄制的視頻錄像：有Spring销钝，MyBatis，Netty源碼分析琐簇，高并發(fā)蒸健、高性能、分布式婉商、微服務(wù)架構(gòu)的原理似忧，JVM性能優(yōu)化這些成為架構(gòu)師必備的知識(shí)體系。