螞蟻金服（當(dāng)時還是支付寶）從 2013 年起就運行在單元化架構(gòu)上，除了具備異地容災(zāi)能力外，還能做到異地多活，可隨時在多城市、多數(shù)據(jù)中心調(diào)配流量。基于單元流量調(diào)配機制，可實現(xiàn)大規(guī)模集群的藍綠發(fā)布、灰度仿真環(huán)境，為充分驗證業(yè)務(wù)正確性、降低故障提供了基礎(chǔ)條件。相應(yīng)地，微服務(wù)體系也必須具備單元內(nèi)收斂、單元間可控路由等能力，來支撐單元化技術(shù)架構(gòu)的落地。本文根據(jù)玄霄 2018 年上海 QCon 演講內(nèi)容整理。

“異地多活”是互聯(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ù)不可用的社會輿論影響也是非常大的。

527 這個數(shù)字，成為螞蟻金服全體技術(shù)人心中懸著那顆苦膽。我們甚至把技術(shù)部門所在辦公樓的一個會議室命名為 527，把每年的 5 月 27 日定為技術(shù)日，來時刻警醒自己敬畏技術(shù)，不斷打磨技術(shù)。

經(jīng)過幾年的臥薪嘗膽，時間來到 2018 年 9 月。云棲大會上，螞蟻金服發(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)切換完成，所有受影響的用戶全部恢復(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ī)則切換”“中間件切換”“負載均衡切換”“域名解析切換”等多個環(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ī)模時，都會不可避免地觸及到單點瓶頸。“單點”在系統(tǒng)的不同發(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ù)十毫秒的數(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 框架追求的是讓遠程服務(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ù)被當(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)用層不必感知。

解決了應(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ù)化演進如火如荼，這部分耗時積少成多也很可觀。

改進后的同城多機房架構(gòu)，依靠不同服務(wù)注冊中心，將應(yīng)用層邏輯隔離開。只要一筆請求進入一個機房，應(yīng)用層就一定會在一個機房內(nèi)處理完。當(dāng)然，由于數(shù)據(jù)庫主庫只在其中一邊，所以這個架構(gòu)仍然不解決一半數(shù)據(jù)訪問跨機房的問題。

這個架構(gòu)下，只要在入口處調(diào)節(jié)進入兩個機房的請求比例，就可以精確控制兩個機房的負載比例。基于這個能力，可以實現(xiàn)全站藍綠發(fā)布。

“兩地三中心”是一種在金融系統(tǒng)中廣泛應(yīng)用的跨數(shù)據(jù)中心擴展與跨地區(qū)容災(zāi)部署模式，但也存在一些問題。異地災(zāi)備機房距離數(shù)據(jù)庫主節(jié)點距離過遠、訪問耗時過長，異地備節(jié)點數(shù)據(jù)又不是強一致的，所以無法直接提供在線服務(wù)。

在擴展能力上，由于跨地區(qū)的備份中心不承載核心業(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)。

螞蟻金服單元化實踐

螞蟻金服發(fā)展單元化架構(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)用層流量是完全隨機的。以圖中的簡化業(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ù)。“單元”可以作為一個相對獨立整體來挪動，甚至可以把部分單元部署到異地去。

單元化有幾個重要的設(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ù)。初期可能是部署成兩地三中心（允許多個單元位于同一個數(shù)據(jù)中心）。隨著架構(gòu)的發(fā)展，再整單元搬遷，演化成三地五中心，應(yīng)用層無需感知物理層面的變化。

回到前面買早餐的例子，小王的 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)賬操作一定會涉及到兩個賬戶，很可能位于不同的單元。張大媽的賬號就剛好位于另一個城市的 Regional 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ù)庫 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ù)訪問層。

總體指導(dǎo)思想是“多層防線，迷途知返”。每層只要能獲取到足夠的信息，就盡早將請求轉(zhuǎn)到正確的單元去，如果實在拿不到足夠的信息，就靠下一層。

• DNS 層照理說感知不到任何業(yè)務(wù)層的信息，但我們做了一個優(yōu)化叫“多域名技術(shù)”。比如 PC 端收銀臺的域名是 cashier.alipay.com，在系統(tǒng)已知一個用戶數(shù)據(jù)屬于哪個單元的情況下，就讓其直接訪問一個單獨的域名，直接解析到對應(yīng)的數(shù)據(jù)中心，避免了下層的跨機房轉(zhuǎn)發(fā)。例如上圖中的 cashiergtj.alipay.com，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ù)邏輯的地方。在通用的 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)容比較豐富，描述了城市、機房、邏輯單元的拓撲結(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)用遠程服務(wù)之前把分片 ID 放到 ThreadLocal 中？這樣也很不優(yōu)雅，違背了 RPC 框架的透明原則。

于是我們的解決方案是框架定義一個接口，由服務(wù)提供方給出一個實現(xiàn)類，描述如何從業(yè)務(wù)參數(shù)中獲取分片 ID。服務(wù)提供方在接口上打注解，告訴框架實現(xiàn)類的路徑。框架就可以在執(zhí)行 RPC 調(diào)用的時候，根據(jù)注解的實現(xiàn)，從參數(shù)中截出分片 ID。再結(jié)合全局路由規(guī)則中分片 ID 與邏輯單元之間的映射關(guān)系，就知道該選擇哪個單元的服務(wù)提供方了。

寫在最后

本文著重介紹了螞蟻金服異地多活單元化架構(gòu)的原理，以及微服務(wù)體系在此架構(gòu)下的關(guān)鍵技術(shù)實現(xiàn)。要在工程層面真正落地單元化，涉及的技術(shù)問題遠不止此。例如：數(shù)據(jù)層如何容災(zāi)？無法水平拆分的業(yè)務(wù)如何處理？

螞蟻技術(shù)團隊會堅持走技術(shù)開放路線，后續(xù)還會以不同的形式分享相關(guān)話題，也歡迎各位讀者留言探討。

文章版權(quán)歸極客邦科技 InfoQ 所有，未經(jīng)許可不得轉(zhuǎn)載哦~

總結(jié)

以上是生活随笔為你收集整理的“被动挖光缆”到“主动剪网线”，蚂蚁金服异地多活的微服务体系的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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