螞蟻金服異地多活的微服務(wù)體系

1、 從“挖光纜”到“剪網(wǎng)線”螞蟻金服異地多活的微服務(wù)體系 “異地多活”是互聯(lián)網(wǎng)系統(tǒng)的一種高可用部署架構(gòu)，而“單元化”正是實現(xiàn)異地多活的一個解題思路。說起這個話題，不得不提兩個事件：一件是三年多前的往事，另一件就發(fā)生今年的杭州云棲大會上。從“挖光纜”到“剪網(wǎng)線”2015年5月27日，因市政施工，支付寶杭州某數(shù)據(jù)中心的光纜被挖斷，造成對部分用戶服務(wù)不可用，時間長達數(shù)小時。其實支付寶的單元化架構(gòu)容災(zāi)很早就開始啟動了，2015年也基本上成型了。當(dāng)時由于事發(fā)突然，還是碰到很多實際問題，花費了數(shù)小時的時間，才在確保用戶數(shù)據(jù)完全正確的前提下，完成切換、恢復(fù)服務(wù)。雖然數(shù)據(jù)沒有出錯，但對于這樣體量的公司來說，服務(wù)

2、不可用的社會輿論影響也是非常大的。527這個數(shù)字，成為螞蟻金服全體技術(shù)人心中懸著那顆苦膽。我們甚至把技術(shù)部門所在辦公樓的一個會議室命名為527，把每年的5月27日定為技術(shù)日，來時刻警醒自己敬畏技術(shù)，不斷打磨技術(shù)。經(jīng)過幾年的臥薪嘗膽，時間來到2018年9月。云棲大會上，螞蟻金服發(fā)布了“三地五中心金融級高可用方案”?，F(xiàn)場部署了一個模擬轉(zhuǎn)賬系統(tǒng)，在場觀眾通過小程序互相不斷轉(zhuǎn)賬。服務(wù)端分布在三個城市的五個數(shù)據(jù)中心，為了感受更直觀，把杭州其中一個數(shù)據(jù)中心機柜設(shè)置在了會場。工作人員當(dāng)場把杭州兩個數(shù)據(jù)中心的網(wǎng)線剪斷，來模擬杭州的城市級災(zāi)難。網(wǎng)線剪斷之后，部分用戶服務(wù)不可用。經(jīng)過26秒，容災(zāi)切換完成，所有受影

3、響的用戶全部恢復(fù)正常。這個Demo當(dāng)然只是實際生產(chǎn)系統(tǒng)的一個簡化模型，但是其背后的技術(shù)是一致的。這幾年來，其實每隔幾周我們就會在生產(chǎn)環(huán)境做一次真實的數(shù)據(jù)中心斷網(wǎng)演習(xí)，來不斷打磨系統(tǒng)容災(zāi)能力。從大屏幕上可以看到，容災(zāi)切換包含了“數(shù)據(jù)庫切換”“緩存容災(zāi)切換”“多活規(guī)則切換”“中間件切換”“負(fù)載均衡切換”“域名解析切換”等多個環(huán)節(jié)。異地多活架構(gòu)是一個復(fù)雜的系統(tǒng)工程，其包含的技術(shù)內(nèi)涵非常豐富，單場分享實難面面俱到。本場是微服務(wù)話題專場，我們也將以應(yīng)用層的微服務(wù)體系作為切入點，一窺異地多活單元化架構(gòu)的真面目。去單點之路任何一個互聯(lián)網(wǎng)系統(tǒng)發(fā)展到一定規(guī)模時，都會不可避免地觸及到單點瓶頸?！皢吸c”在系統(tǒng)的不同

4、發(fā)展階段有不同的表現(xiàn)形式。提高系統(tǒng)伸縮能力和高可用能力的過程，就是不斷與各種層面的單點斗爭的過程。我們不妨以一個生活中最熟悉的場景作為貫穿始終的例子，來推演系統(tǒng)架構(gòu)從簡單到復(fù)雜，所遇到的問題。上圖展示的是用支付寶買早餐的情景，當(dāng)然角色是虛構(gòu)的。最早支付寶只是從淘寶剝離的一個小工具系統(tǒng)，處于單體應(yīng)用時代。這個時候移動支付當(dāng)然還沒出現(xiàn)，我們的例子僅用于幫助分析問題，請忽略這個穿幫漏洞。假設(shè)圖中的場景發(fā)生在北京，而支付寶系統(tǒng)是部署在杭州的機房。在小王按下“支付”按鈕的一瞬間，會發(fā)生什么事情呢？支付請求要從客戶端發(fā)送到服務(wù)端，服務(wù)端最終再把結(jié)果返回客戶端，必然會有一次異地網(wǎng)絡(luò)往返，耗時大約在數(shù)十毫秒的

5、數(shù)量級，我們用紅色線表示。應(yīng)用進程內(nèi)部會發(fā)生很多次業(yè)務(wù)邏輯運算，用綠色圈表示，不涉及網(wǎng)絡(luò)開銷，耗時忽略不計。應(yīng)用會訪問多次數(shù)據(jù)庫，由于都在部署在同一個機房內(nèi)，每次耗時按一毫秒以下，一筆支付請求按10次數(shù)據(jù)庫訪問算（對于支付系統(tǒng)來說并不算多，一筆業(yè)務(wù)可能涉及到各種數(shù)據(jù)校驗、數(shù)據(jù)修改）。耗時大頭在無可避免的用戶到機房物理距離上，系統(tǒng)內(nèi)部處理耗時很小。到了服務(wù)化時代，一個好的RPC框架追求的是讓遠(yuǎn)程服務(wù)調(diào)用像調(diào)本地方法一樣簡單。隨著服務(wù)的拆分、業(yè)務(wù)的發(fā)展，原本進程內(nèi)部的調(diào)用變成了網(wǎng)絡(luò)調(diào)用。由于應(yīng)用都部署在同一個機房內(nèi)，業(yè)務(wù)整體網(wǎng)絡(luò)耗時仍然在可接受范圍內(nèi)。開發(fā)人員一般也不會特別在意這個問題，RPC服務(wù)

6、被當(dāng)成幾乎無開銷成本地使用，應(yīng)用的數(shù)量也在逐漸膨脹。服務(wù)化解決了應(yīng)用層的瓶頸，緊接著數(shù)據(jù)庫就成為制約系統(tǒng)擴展的瓶頸。雖然我們本次重點討論的是服務(wù)層，但要講單元化，數(shù)據(jù)存儲是無論如何繞不開的話題。這里先插播一下分庫分表的介紹，作為一個鋪墊。通過引入數(shù)據(jù)訪問中間件，可以實現(xiàn)對應(yīng)用透明的分庫分表。一個比較好的實踐是：邏輯拆分先一步到位，物理拆分慢慢進行。以賬戶表為例，將用戶ID的末兩位作為分片維度，可以在邏輯上將數(shù)據(jù)分成100份，一次性拆到100個分表中。這100個分表可以先位于同一個物理庫中，隨著系統(tǒng)的發(fā)展，逐步拆成2個、5個、10個，乃至100個物理庫。數(shù)據(jù)訪問中間件會屏蔽表與庫的映射關(guān)系，應(yīng)用

7、層不必感知。解決了應(yīng)用層和數(shù)據(jù)庫層單點后，物理機房又成為制約系統(tǒng)伸縮能力和高可用能力的最大單點。要突破單機房的容量限制，最直觀的解決辦法就是再建新的機房，機房之間通過專線連成同一個內(nèi)部網(wǎng)絡(luò)。應(yīng)用可以部署一部分節(jié)點到第二個機房，數(shù)據(jù)庫也可以將主備庫交叉部署到不同的機房。這一階段，只是解決了機房容量不足的問題，兩個機房邏輯上仍是一個整體。日常會存在兩部分跨機房調(diào)用：服務(wù)層邏輯上是無差別的應(yīng)用節(jié)點，每一次RPC調(diào)用都有一半的概率跨機房每個特定的數(shù)據(jù)庫主庫只能位于一個機房，所以宏觀上也一定有一半的數(shù)據(jù)庫訪問是跨機房的同城跨機房專線訪問的耗時在數(shù)毫秒級，圖中用黃色線表示。隨著微服務(wù)化演進如火如荼，這部分

8、耗時積少成多也很可觀。改進后的同城多機房架構(gòu)，依靠不同服務(wù)注冊中心，將應(yīng)用層邏輯隔離開。只要一筆請求進入一個機房，應(yīng)用層就一定會在一個機房內(nèi)處理完。當(dāng)然，由于數(shù)據(jù)庫主庫只在其中一邊，所以這個架構(gòu)仍然不解決一半數(shù)據(jù)訪問跨機房的問題。這個架構(gòu)下，只要在入口處調(diào)節(jié)進入兩個機房的請求比例，就可以精確控制兩個機房的負(fù)載比例?；谶@個能力，可以實現(xiàn)全站藍(lán)綠發(fā)布?！皟傻厝行摹笔且环N在金融系統(tǒng)中廣泛應(yīng)用的跨數(shù)據(jù)中心擴展與跨地區(qū)容災(zāi)部署模式，但也存在一些問題。異地災(zāi)備機房距離數(shù)據(jù)庫主節(jié)點距離過遠(yuǎn)、訪問耗時過長，異地備節(jié)點數(shù)據(jù)又不是強一致的，所以無法直接提供在線服務(wù)。在擴展能力上，由于跨地區(qū)的備份中心不承載核心

9、業(yè)務(wù)，不能解決核心業(yè)務(wù)跨地區(qū)擴展的問題；在成本上，災(zāi)備系統(tǒng)僅在容災(zāi)時使用，資源利用率低，成本較高；在容災(zāi)能力上，由于災(zāi)備系統(tǒng)冷備等待，容災(zāi)時可用性低，切換風(fēng)險較大。小結(jié)一下前述幾種架構(gòu)的特點。直到這時，微服務(wù)體系本身的變化并不大，無非是部署幾套、如何隔離的問題，每套微服務(wù)內(nèi)部仍然是簡單的架構(gòu)。架構(gòu)類型優(yōu)勢問題單體應(yīng)用網(wǎng)絡(luò)開銷小擴展性差，維護困難單機房服務(wù)化解耦，可擴展容量受限，機房級單點同城多機房階段一突破單機房容量瓶頸非必要的跨機房網(wǎng)絡(luò)開銷大同城多機房階段二非必要的跨機房網(wǎng)絡(luò)開銷?。粰C房級容災(zāi)能力城市級單點兩地三中心異地容災(zāi)能力網(wǎng)絡(luò)耗時與數(shù)據(jù)一致性難兩全螞蟻金服單元化實踐螞蟻金服發(fā)展單元化架

10、構(gòu)的原始驅(qū)動力，可以概括為兩句話：異地多活容災(zāi)需求帶來的數(shù)據(jù)訪問耗時問題，量變引起質(zhì)變數(shù)據(jù)庫連接數(shù)瓶頸制約了整體水平擴展能力，危急存亡之秋第一條容易理解，正是前面討論的問題，傳統(tǒng)的兩地三中心架構(gòu)在解決地區(qū)級單點問題上效果并不理想，需要有其他思路。但這畢竟也不是很急的事情，真正把單元化之路提到生死攸關(guān)的重要性的，是第二條。到2013年，支付寶核心數(shù)據(jù)庫都已經(jīng)完成了水平拆分，容量綽綽有余，應(yīng)用層無狀態(tài)，也可以隨意水平擴展。但是按照當(dāng)年雙十一的業(yè)務(wù)指標(biāo)做技術(shù)規(guī)劃的時候，卻碰到了一個棘手的問題：Oracle數(shù)據(jù)庫的連接不夠用了。雖然數(shù)據(jù)庫是按用戶維度水平拆分的，但是應(yīng)用層流量是完全隨機的。以圖中的簡化

11、業(yè)務(wù)鏈路為例，任意一個核心應(yīng)用節(jié)點C可能訪問任意一個數(shù)據(jù)庫節(jié)點D，都需要占用數(shù)據(jù)庫連接。連接是數(shù)據(jù)庫非常寶貴的資源，是有上限的。當(dāng)時的支付寶，面臨的問題是不能再對應(yīng)用集群擴容，因為每增加一臺機器，就需要在每個數(shù)據(jù)分庫上新增若干連接，而此時幾個核心數(shù)據(jù)庫的連接數(shù)已經(jīng)到達上限。應(yīng)用不能擴容，意味著支付寶系統(tǒng)的容量定格了，不能再有任何業(yè)務(wù)量增長。別說大促，可能再過一段時間連日常業(yè)務(wù)也支撐不了了。單元化架構(gòu)基于這樣一種設(shè)想：如果應(yīng)用層也能按照數(shù)據(jù)層相同的拆片維度，把整個請求鏈路收斂在一組服務(wù)器中，從應(yīng)用層到數(shù)據(jù)層就可以組成一個封閉的單元。數(shù)據(jù)庫只需要承載本單元的應(yīng)用節(jié)點的請求，大大節(jié)省了連接數(shù)?！皢卧?/p>

12、”可以作為一個相對獨立整體來挪動，甚至可以把部分單元部署到異地去。單元化有幾個重要的設(shè)計原則：核心業(yè)務(wù)必須是可分片的必須保證核心業(yè)務(wù)的分片是均衡的，比如支付寶用用戶ID作分片維度核心業(yè)務(wù)要盡量自包含，調(diào)用要盡量封閉整個系統(tǒng)都要面向邏輯分區(qū)設(shè)計，而不是物理部署在實踐上，我們推薦先從邏輯上切分若干均等的單元，再根據(jù)實際物理條件，把單元分布到物理數(shù)據(jù)中心。單元均等的好處是更容易做容量規(guī)劃，可以根據(jù)一個單元的壓測結(jié)果方便換算成整站容量。我們把單元叫做Regional Zone。例如，數(shù)據(jù)按100份分片，邏輯上分為5個Regional Zone，每個承載20份數(shù)據(jù)分片的業(yè)務(wù)。初期可能是部署成兩地三中心（

13、允許多個單元位于同一個數(shù)據(jù)中心）。隨著架構(gòu)的發(fā)展，再整單元搬遷，演化成三地五中心，應(yīng)用層無需感知物理層面的變化?；氐角懊尜I早餐的例子，小王的ID是12345666，分片號是66，應(yīng)該屬于Regional Zone 04；而張大媽ID是54321233，分片號33，應(yīng)該屬于Regional Zone 02。應(yīng)用層會自動識別業(yè)務(wù)參數(shù)上的分片位，將請求發(fā)到正確的單元。業(yè)務(wù)設(shè)計上，我們會保證流水號的分片位跟付款用戶的分片位保持一致，所以絕大部分微服務(wù)調(diào)用都會收斂在Regional Zone 04內(nèi)部。但是轉(zhuǎn)賬操作一定會涉及到兩個賬戶，很可能位于不同的單元。張大媽的賬號就剛好位于另一個城市的Region

14、al Zone 02。當(dāng)支付系統(tǒng)調(diào)用賬務(wù)系統(tǒng)給張大媽的賬號加錢的時候，就必須跨單元調(diào)用Regional Zone 02的賬務(wù)服務(wù)。圖中用紅線表示耗時很長（幾十毫秒級）的異地訪問。從宏觀耗時示意圖上就可以比較容易地理解單元化的思想了：單元內(nèi)高內(nèi)聚，單元間低耦合，跨單元調(diào)用無法避免，但應(yīng)該盡量限定在少數(shù)的服務(wù)層調(diào)用，把整體耗時控制在可接受的范圍內(nèi)（包括對直接用戶體驗和對整體吞吐量的影響）。前面講的是正常情況下如何“多活”，機房故障情況下就要發(fā)揮單元之間的容災(zāi)互備作用了。一個城市整體故障的情況下，應(yīng)用層流量通過規(guī)則的切換，由事先規(guī)劃好的其他單元接管。數(shù)據(jù)層則是依靠自研的基于Paxos協(xié)議的分布式數(shù)據(jù)

15、庫OceanBase，自動把對應(yīng)容災(zāi)單元的從節(jié)點選舉為主節(jié)點，實現(xiàn)應(yīng)用分片和數(shù)據(jù)分片繼續(xù)收斂在同一單元的效果。我們之所以規(guī)劃為“兩地三中心”“三地五中心”這樣的物理架構(gòu)，實際上也是跟OceanBase的副本分布策略息息相關(guān)的。數(shù)據(jù)層異地多活，又是另一個宏大的課題了，以后可以專題分享，這里只簡略提過。這樣，借助單元化異地多活架構(gòu)，才能實現(xiàn)開頭展示的“26秒完成城市級容災(zāi)切換”能力。關(guān)鍵技術(shù)組件單元化是個復(fù)雜的系統(tǒng)工程，需要多個組件協(xié)同工作，從上到下涉及到DNS層、反向代理層、網(wǎng)關(guān)/WEB層、服務(wù)層、數(shù)據(jù)訪問層?？傮w指導(dǎo)思想是“多層防線，迷途知返”。每層只要能獲取到足夠的信息，就盡早將請求轉(zhuǎn)到正確

16、的單元去，如果實在拿不到足夠的信息，就靠下一層。DNS層照理說感知不到任何業(yè)務(wù)層的信息，但我們做了一個優(yōu)化叫“多域名技術(shù)”。比如PC端收銀臺的域名是，在系統(tǒng)已知一個用戶數(shù)據(jù)屬于哪個單元的情況下，就讓其直接訪問一個單獨的域名，直接解析到對應(yīng)的數(shù)據(jù)中心，避免了下層的跨機房轉(zhuǎn)發(fā)。例如上圖中的，gtj就是內(nèi)部一個數(shù)據(jù)中心的編號。移動端也可以靠下發(fā)規(guī)則到客戶端來實現(xiàn)類似的效果。反向代理層是基于Nginx二次開發(fā)的，后端系統(tǒng)在通過參數(shù)識別用戶所屬的單元之后，在Cookie中寫入特定的標(biāo)識。下次請求，反向代理層就可以識別，直接轉(zhuǎn)發(fā)到對應(yīng)的單元。網(wǎng)關(guān)/Web層是應(yīng)用上的第一道防線，是真正可以有業(yè)務(wù)邏輯的地方。

17、在通用的HTTP攔截器中識別Session中的用戶ID字段，如果不是本單元的請求，就 forward到正確的單元。并在Cookie中寫入標(biāo)識，下次請求在反向代理層就可以正確轉(zhuǎn)發(fā)。服務(wù)層RPC框架和注冊中心內(nèi)置了對單元化能力的支持，可以根據(jù)請求參數(shù)，透明地找到正確單元的服務(wù)提供方。數(shù)據(jù)訪問層是最后的兜底保障，即使前面所有的防線都失敗了，一筆請求進入了錯誤的單元，在訪問數(shù)據(jù)庫的時候也一定會去正確的庫表，最多耗時變長，但絕對不會訪問到錯誤的數(shù)據(jù)。這么多的組件要協(xié)同工作，必須共享同一份規(guī)則配置信息。必須有一個全局的單元化規(guī)則管控中心來管理，并通過一個高效的配置中心下發(fā)到分布式環(huán)境中的所有節(jié)點。規(guī)則的內(nèi)

18、容比較豐富，描述了城市、機房、邏輯單元的拓?fù)浣Y(jié)構(gòu)，更重要的是描述了分片ID與邏輯單元之間的映射關(guān)系。服務(wù)注冊中心內(nèi)置了單元字段，所有的服務(wù)提供者節(jié)點都帶有“邏輯單元”屬性。不同機房的注冊中心之間互相同步數(shù)據(jù)，最終所有服務(wù)消費者都知道每個邏輯單元的服務(wù)提供者有哪些。RPC框架就可以根據(jù)需要選擇調(diào)用目標(biāo)。RPC框架本身是不理解業(yè)務(wù)邏輯的，要想知道應(yīng)該調(diào)哪個單元的服務(wù)，信息只能從業(yè)務(wù)參數(shù)中來。如果是從頭設(shè)計的框架，可能直接約定某個固定的參數(shù)代表分片ID，要求調(diào)用者必須傳這個參數(shù)。但是單元化是在業(yè)務(wù)已經(jīng)跑了好多年的情況下的架構(gòu)改造，不可能讓所有存量服務(wù)修改接口。要求調(diào)用者在調(diào)用遠(yuǎn)程服務(wù)之前把分片ID放到ThreadLocal中？這樣也很不優(yōu)雅，違背了RPC框架的透明原則。于是我們的解決方案是框架