餓了么技術(shù)團(tuán)隊(duì)花了1年多的時(shí)間，實(shí)現(xiàn)了業(yè)務(wù)的整體異地多活，能夠靈活的在多個(gè)異地機(jī)房之間調(diào)度用戶，實(shí)現(xiàn)了自由擴(kuò)容和多機(jī)房容災(zāi)的目標(biāo)。本文介紹這個(gè)項(xiàng)目的整體結(jié)構(gòu)，還簡(jiǎn)要介紹實(shí)現(xiàn)多活的5大核心基礎(chǔ)組件，為讀者建立基本的概念模型，后續(xù)會(huì)有系列文章陸續(xù)介紹每個(gè)組件的實(shí)現(xiàn)細(xì)節(jié)。讀者能夠從中了解到做異地多活的大方向，為實(shí)現(xiàn)自己的異地多活，或者是容災(zāi)備份提供參考。
背景：為什么要做異地多活？
餓了么要做多活，是受業(yè)務(wù)發(fā)展的驅(qū)動(dòng)，經(jīng)過幾年的高速發(fā)展，我們的業(yè)務(wù)已經(jīng)擴(kuò)大到單個(gè)數(shù)據(jù)中心撐不住了，主要機(jī)房已經(jīng)不能再加機(jī)器，業(yè)務(wù)卻不斷的要求加擴(kuò)容，所以我們需要一個(gè)方案能夠把服務(wù)器部署到多個(gè)機(jī)房。另外一個(gè)更重要的原因是，整個(gè)機(jī)房級(jí)別的故障時(shí)有發(fā)生，每次都會(huì)帶來嚴(yán)重的后果，我們需要在發(fā)生故障時(shí)，能夠把一個(gè)機(jī)房的業(yè)務(wù)全部遷移到別的機(jī)房，保證服務(wù)可用。
歸納起來，我們要達(dá)到兩個(gè)目標(biāo)：
- 服務(wù)可以擴(kuò)展到多個(gè)機(jī)房
- 能夠應(yīng)對(duì)整個(gè)機(jī)房級(jí)別的故障
解決這兩個(gè)問題的常見辦法是做異地多活，把服務(wù)分散到多個(gè)機(jī)房，自然擴(kuò)展和高可用的問題就迎刃而解了。
餓了么有自己的特殊情況，對(duì)于其他大部分公司來說，其實(shí)要不要做多活，主要就是看下圖這樣一個(gè)曲線。
對(duì)于一個(gè)業(yè)務(wù)快速增長(zhǎng)的企業(yè)，每次故障帶來的損失也相應(yīng)是加速增長(zhǎng)的，而技術(shù)的投入總體上是線性的，初期故障損失小于技術(shù)投入，在某個(gè)時(shí)間點(diǎn)，故障的損失會(huì)超過技術(shù)投入，這時(shí)就要用一些高可用方案，來避免故障，多活就是其中最重要的一種。
異地多活面臨的主要挑戰(zhàn)是網(wǎng)絡(luò)延遲，以北京到上海 1468 公里，即使是光速傳輸，一個(gè)來回也需要接近10ms，我們?cè)趯?shí)際測(cè)試的過程中，發(fā)現(xiàn)上海到北京的網(wǎng)絡(luò)延遲，一般是 30 ms。這 30 ms可以和運(yùn)算系統(tǒng)中其他的延遲時(shí)間做個(gè)比較：
L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns
Compress 1K bytes with Zippy ............. 3,000 ns = 3 μs
Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 μs
SSD random read ........................ 150,000 ns = 150 μs
Read 1 MB sequentially from memory ..... 250,000 ns = 250 μs
Round trip within same datacenter ...... 500,000 ns = 0.5 ms
Read 1 MB sequentially from SSD* ..... 1,000,000 ns = 1 ms
上海之間兩個(gè)機(jī)房的網(wǎng)絡(luò)延時(shí)................. 1,000,000 ns = 1 ms
Disk seek ........................... 10,000,000 ns = 10 ms
Read 1 MB sequentially from disk .... 20,000,000 ns = 20 ms
北京到上海的網(wǎng)絡(luò)延時(shí).................... 30,000,000 ns = 30 ms
Send packet CA->Netherlands->CA .... 150,000,000 ns = 150 ms
北京上海兩地的網(wǎng)絡(luò)延遲時(shí)間，大致是內(nèi)網(wǎng)網(wǎng)絡(luò)訪問速度的 60 倍（30ms/0.5ms），如果不做任何改造，一方直接訪問另外一方的服務(wù)，那么我們的APP的反應(yīng)會(huì)比原來慢 60 倍，其實(shí)考慮上多次往返，可能會(huì)慢600倍。
如果機(jī)房都在上海，那么網(wǎng)絡(luò)延遲只有內(nèi)網(wǎng)速度的2倍，可以當(dāng)成一個(gè)機(jī)房使用。所有有些公司的多活方案，會(huì)選擇同城機(jī)房，把同城的幾個(gè)機(jī)房當(dāng)成一個(gè)機(jī)房部署，可以在不影響服務(wù)架構(gòu)的情況下擴(kuò)展出多個(gè)機(jī)房，不失為一個(gè)快速見效的方法。我們?cè)谧龆嗷畹某跗谝灿懻撨^同城方案，比如在北京周邊建設(shè)一個(gè)新機(jī)房，遷移部分服務(wù)到新機(jī)房，兩個(gè)機(jī)房專線連接，服務(wù)間做跨機(jī)房調(diào)用。雖然這個(gè)方案比較容易，也解決了機(jī)房的擴(kuò)展問題，但是對(duì)高可用卻沒有好處，相反還帶來了更高的風(fēng)險(xiǎn)。
與同城多活的方案不同，異地多活的方案會(huì)限制機(jī)房間的相互調(diào)用，需要定義清晰的服務(wù)邊界，減少相互依賴，讓每個(gè)機(jī)房都成為獨(dú)立的單元，不依賴于其他機(jī)房。經(jīng)過幾番考量，我們最終選擇了異地多活的方案，對(duì)這兩個(gè)方案的比較和思考可以見下表，異地多活雖然更困難一點(diǎn)，但是能同時(shí)達(dá)到我們的兩個(gè)核心目標(biāo)，更為可行。
設(shè)計(jì)：異地多活的實(shí)現(xiàn)思路和方法
我們的異地多活方案的，有幾條基本原則，整個(gè)多活方案都是這些原則的自然推導(dǎo)。但在介紹一下這些原則之前，先要說明一下餓了么的服務(wù)流程，才能讓大家更好的理解這些原則的來由
下面這張簡(jiǎn)圖是我們的主流程：
業(yè)務(wù)過程中包含3個(gè)最重要的角色，分別是用戶、商家和騎手，一個(gè)訂單包含3個(gè)步驟：
- 用戶打開我們的APP，系統(tǒng)會(huì)推薦出用戶位置附近的各種美食，推薦順序中結(jié)合了用戶習(xí)慣，推薦排序，商戶的推廣等。用戶找到中意的食物 ，下單并支付，訂單會(huì)流轉(zhuǎn)到商家。
- 商家接單并開始制作食物，制作完成后，系統(tǒng)調(diào)度騎手趕到店面，取走食物
- 騎手按照配送地址，把食物送到客戶手中。
整個(gè)下單到配送完成，有嚴(yán)格的時(shí)間要求，必須在短短的幾十分鐘內(nèi)完成，我們的服務(wù)和地理位置強(qiáng)相關(guān)，并且實(shí)時(shí)性要求高，服務(wù)的地域性和實(shí)時(shí)性是我們的核心特性，多活設(shè)計(jì)最重要的是滿足這兩個(gè)特性。
進(jìn)過反復(fù)討論，我們的多活架構(gòu)通過遵循以下幾條基本原則，來滿足這兩個(gè)核心特性：
- 業(yè)務(wù)內(nèi)聚：?jiǎn)蝹€(gè)訂單的旅單過程，要在一個(gè)機(jī)房中完成，不允許跨機(jī)房調(diào)用。這個(gè)原則是為了保證實(shí)時(shí)性，旅單過程中不依賴另外一個(gè)機(jī)房的服務(wù)，才能保證沒有延遲。我們稱每個(gè)機(jī)房為一個(gè) ezone，一個(gè) ezone 包含了餓了么需要的各種服務(wù)。一筆業(yè)務(wù)能夠內(nèi)聚在一個(gè) ezone 中，那么一個(gè)定單涉及的用戶，商家，騎手，都會(huì)在相同的機(jī)房，這樣訂單在各個(gè)角色之間流轉(zhuǎn)速度最快，不會(huì)因?yàn)楦鞣N異常情況導(dǎo)致延時(shí)。恰好我們的業(yè)務(wù)是地域化的，通過合理的地域劃分，也能夠?qū)崿F(xiàn)業(yè)務(wù)內(nèi)聚。
- 可用性優(yōu)先：當(dāng)發(fā)生故障切換機(jī)房時(shí)，優(yōu)先保證系統(tǒng)可用，首先讓用戶可以下單吃飯，容忍有限時(shí)間段內(nèi)的數(shù)據(jù)不一致，在事后修復(fù)。每個(gè) ezone 都會(huì)有全量的業(yè)務(wù)數(shù)據(jù)，當(dāng)一個(gè) ezone 失效后，其他的 ezone 可以接管用戶。用戶在一個(gè)ezone的下單數(shù)據(jù)，會(huì)實(shí)時(shí)的復(fù)制到其他ezone。
- 保證數(shù)據(jù)正確：在確?？捎玫那闆r下，需要對(duì)數(shù)據(jù)做保護(hù)以避免錯(cuò)誤，在切換和故障時(shí)，如果發(fā)現(xiàn)某些訂單的狀態(tài)在兩個(gè)機(jī)房不一致，會(huì)鎖定該筆訂單，阻止對(duì)它進(jìn)行更改，保證數(shù)據(jù)的正確。
- 業(yè)務(wù)可感：因?yàn)榛A(chǔ)設(shè)施還沒有強(qiáng)大到可以抹去跨機(jī)房的差異，需要讓業(yè)務(wù)感知多活邏輯，業(yè)務(wù)代碼要做一些改造，包括：需要業(yè)務(wù)代碼能夠識(shí)別出業(yè)務(wù)數(shù)據(jù)的歸屬，只處理本 ezone 的數(shù)據(jù)，過濾掉無關(guān)的數(shù)據(jù)。完善業(yè)務(wù)狀態(tài)機(jī)，能夠在數(shù)據(jù)出現(xiàn)不一致的時(shí)候，通過狀態(tài)機(jī)發(fā)現(xiàn)和糾正。
這幾條基本原則，貫穿了餓了么多活的整個(gè)設(shè)計(jì)。
基于這幾條原則，我們從服務(wù)劃分，流量路由，業(yè)務(wù)改造等方面設(shè)計(jì)了多活方案，下面簡(jiǎn)要介紹一主要邏輯。
服務(wù)劃分（Sharding）：
為了實(shí)現(xiàn)業(yè)務(wù)內(nèi)聚，我們首先要選擇一個(gè)劃分方法（Sharding Key），對(duì)服務(wù)進(jìn)行分區(qū)，讓用戶，商戶，騎手能夠正確的內(nèi)聚到同一個(gè) ezone 中。分區(qū)方案是整個(gè)多活的基礎(chǔ)，它決定了之后的所有邏輯。
根據(jù)餓了么的業(yè)務(wù)特點(diǎn)，我們自然的選擇地理位置作為劃分業(yè)務(wù)的單元，把地理位置上接近的用戶，商戶，騎手劃分到同一個(gè)ezone，這樣一個(gè)訂單的履單流程就會(huì)在一個(gè)機(jī)房完成，能夠保證最小的延時(shí)，在某個(gè)機(jī)房出現(xiàn)問題的時(shí)候，也可以按照地理位置把用戶，商戶，騎手打包遷移到別的機(jī)房即可。
所以我們最終選擇的方案如下圖，自定義地理劃分圍欄，用圍欄把全國分為多個(gè) shard，圍欄的邊界盡量按照行政省界，必要的時(shí)候做一些調(diào)整，避免圍欄穿過市區(qū)。一個(gè)ezone可以包含多個(gè) shard，某個(gè) ezone 的 shard ，可以隨時(shí)切換到另外一個(gè) ezone ，靈活的調(diào)度資源和failover。
這樣的劃分方案，基本解決了垮城市下單的問題，線上沒有觀察到有跨 ezone 下單的情況。圍欄的劃分是靈活的，可以隨著以后業(yè)務(wù)的拓展進(jìn)行修改，因?yàn)槊總€(gè)機(jī)房都是全量數(shù)據(jù)，所以調(diào)整圍欄不會(huì)導(dǎo)致問題。
對(duì)這種劃分方法，有一些常見的疑問，比如：
1.如果兩個(gè)城市是接壤的，會(huì)出現(xiàn)商家和用戶處于不同 ezone 的情況，豈不是破壞了內(nèi)聚性原則？
這種情況確實(shí)會(huì)出現(xiàn)，為了盡量避免，我們?cè)趧澐謘hard的時(shí)候沒有簡(jiǎn)單的用城市名稱，而是用了復(fù)雜的地理圍欄實(shí)現(xiàn)，地理圍欄主體按照省界劃分，再加上局部微調(diào)，我們最大限度的避免了跨ezone下單的情況。但如果真的出現(xiàn)了，用戶下單也不受影響，最多只是狀態(tài)有1s左右的延遲。
2.用戶是會(huì)動(dòng)的，如果用戶從北京到了上海，那么劃分規(guī)則應(yīng)該怎么應(yīng)對(duì)？
用戶在北京下單，數(shù)據(jù)落在北京shard，到上海下單，數(shù)據(jù)則落在上海的 shard，借助于底層的數(shù)據(jù)同步工具，用戶無論在什么地方，都能看到自己的數(shù)據(jù)，但是有1s左右的延時(shí)，對(duì)于大部分的業(yè)務(wù)場(chǎng)景，這個(gè)延遲是可以承受的。當(dāng)然也有些業(yè)務(wù)場(chǎng)景不能接受這 1s 的延時(shí)，我們也提供了另外的方案來應(yīng)對(duì)，參考下文介紹Globa Zone的章節(jié)。
3.為什么不簡(jiǎn)單點(diǎn)，按照用戶的ID來切分？
阿里是按照用戶ID的取模來劃分單元的，比較簡(jiǎn)潔。我們?nèi)绻灿肐D做切分，同一地方的用戶，商戶，騎手可能被劃分到不同 ezone，就會(huì)出現(xiàn)比較多的跨機(jī)房調(diào)用，這樣就更可能出現(xiàn)延遲，難以保證實(shí)時(shí)性。所以，我們本地配送的業(yè)務(wù)模式，決定了需要用地理位置來劃分服務(wù)。
流量路由：
基于地理位置劃分規(guī)則，我們開發(fā)了統(tǒng)一的流量路由層（API Router），這一層負(fù)責(zé)對(duì)客戶端過來的 API 調(diào)用進(jìn)行路由，把流量導(dǎo)向到正確的 ezone。API Router 部署在多個(gè)公有云機(jī)房中，用戶就近接入到公有云的API Router，還可以提升接入質(zhì)量。
前端 APP 做了改造，為每個(gè)請(qǐng)求都帶上了分流標(biāo)簽，API Router 會(huì)檢查流量上自帶的分流標(biāo)簽，把分流標(biāo)簽轉(zhuǎn)換為對(duì)應(yīng)的 Shard ID，再查詢 Shard ID 對(duì)應(yīng)的 eZone，最終決定把流量路由到哪個(gè) ezone。
最基礎(chǔ)的分流標(biāo)簽是地理位置，有了地理位置，AR 就能計(jì)算出正確的 shard 歸屬。但業(yè)務(wù)是很復(fù)雜的，并不是所有的調(diào)用都能直接關(guān)聯(lián)到某個(gè)地理位置上，我們使用了一種分層的路由方案，核心的路由邏輯是地理位置，但是也支持其他的一些 High Level Sharding Key，這些 Sharding Key 由 APIRouter 轉(zhuǎn)換為核心的 Sharding Key，具體如下圖。這樣既減少了業(yè)務(wù)的改造工作量，也可以擴(kuò)展出更多的分區(qū)方法。
除了入口處的路由，我們還開發(fā)了 SOA Proxy，用于路由SOA調(diào)用的，和API Router基于相同的路由規(guī)則。APIRouter 和 SOAProxy 構(gòu)成了流量的路由通道，讓我們可以靈活的控制各種調(diào)用在多活環(huán)境下的走向。
數(shù)據(jù)復(fù)制：
為了實(shí)現(xiàn)可用優(yōu)先原則，所有機(jī)房都會(huì)有全量數(shù)據(jù)，這樣用戶可以隨時(shí)切換到其他機(jī)房，全量數(shù)據(jù)就需要對(duì)數(shù)據(jù)進(jìn)行實(shí)時(shí)復(fù)制，我們開發(fā)了相應(yīng)的中間件，對(duì) mysql，zookeeper ，消息隊(duì)列和 redis 的數(shù)據(jù)進(jìn)行復(fù)制。
Mysql 數(shù)據(jù)復(fù)制工具 DRC:
Mysql 的數(shù)據(jù)量最大，每個(gè)機(jī)房產(chǎn)生的數(shù)據(jù)，都通過 DRC 復(fù)制到其他 ezone，每個(gè)ezone的主鍵取值空間是ezoneid + 固定步長(zhǎng)，所以產(chǎn)生的 id 各不相同，數(shù)據(jù)復(fù)制到一起后不會(huì)發(fā)生主鍵沖突。按照分區(qū)規(guī)則，正常情況下，每個(gè) ezone 只會(huì)寫入自己的數(shù)據(jù)，但萬一出現(xiàn)異常，2個(gè) ezone 同時(shí)更新了同一筆數(shù)據(jù)，就會(huì)產(chǎn)生沖突。DRC 支持基于時(shí)間戳的沖突解決方案，當(dāng)一筆數(shù)據(jù)在兩個(gè)機(jī)房同時(shí)被修改時(shí)，最后修改的數(shù)據(jù)會(huì)被保留，老的數(shù)據(jù)會(huì)被覆蓋。
ZooKeeper 復(fù)制：
有些全局的配置信息，需要在所有機(jī)房都完全一致，我們開發(fā)了 zookeeper 復(fù)制工具，用于在多個(gè)機(jī)房中同步 ZK 信息。
消息隊(duì)列和Redis復(fù)制：
MQ,Redis 的復(fù)制與 ZK 復(fù)制類似，也開發(fā)了 相應(yīng)的復(fù)制工具。
強(qiáng)一致保證：
對(duì)于個(gè)別一致性要求很高的應(yīng)用，我們提供了一種強(qiáng)一致的方案（Global Zone），Globa Zone是一種跨機(jī)房的讀寫分離機(jī)制，所有的寫操作被定向到一個(gè) Master 機(jī)房進(jìn)行，以保證一致性，讀操作可以在每個(gè)機(jī)房的 Slave庫執(zhí)行，也可以 bind 到 Master 機(jī)房進(jìn)行，這一切都基于我們的數(shù)據(jù)庫訪問層（DAL）完成，業(yè)務(wù)基本無感知。
切換過程和各種異常保護(hù)：
避免數(shù)據(jù)錯(cuò)誤非常重要，在網(wǎng)絡(luò)斷開，或者是切換過程中，特別容易產(chǎn)生錯(cuò)誤數(shù)據(jù)。比如由于復(fù)制延時(shí)，訂單狀態(tài)不一致，用戶有可能會(huì)重復(fù)支付。為了避免我們采取了一些保護(hù)措施，避免在切換時(shí)發(fā)生錯(cuò)誤。
- 在網(wǎng)絡(luò)中斷時(shí)，如果不是必要，不做切換，因?yàn)槿我鈫蝹€(gè)機(jī)房能夠提供完整服務(wù)。
- 如果需要切換，對(duì)鎖定切換過程中的訂單，直到切換完成，數(shù)據(jù)復(fù)制正常，才開放鎖定。這個(gè)過程也通過 DAL 來實(shí)現(xiàn)
- 對(duì)于標(biāo)記為其他機(jī)房的寫入數(shù)據(jù)，DAL 會(huì)進(jìn)行保護(hù)，拒絕寫入。
- DRC 會(huì)檢查并報(bào)告錯(cuò)誤的寫入操作，方便檢查隱藏問題。
通過以上4條的保護(hù)，我們保證了數(shù)據(jù)的正確性，頻繁的切換也不會(huì)出現(xiàn)異常的業(yè)務(wù)數(shù)據(jù)。
多個(gè)機(jī)房的Cache刷新：
數(shù)據(jù)的變更信息，通過 DRC 廣播到多個(gè)機(jī)房，實(shí)現(xiàn)緩存的刷新，保證各個(gè)機(jī)房的緩存一致性。
整體結(jié)構(gòu)
以上介紹了各個(gè)考慮的方面，現(xiàn)在可以綜合起來看，餓了么多活的整體結(jié)構(gòu)如下圖：
業(yè)務(wù)改造：
業(yè)務(wù)可感知是一條基本原則，通過中間件提供的服務(wù)，多活邏輯會(huì)暴露給業(yè)務(wù)方，例如：當(dāng)前服務(wù)所屬的 ezone，路由策略，數(shù)據(jù)的歸屬 shard 等，基于這些信息，業(yè)務(wù)可以執(zhí)行很多的邏輯。包括：
- 后臺(tái)任務(wù)可以過濾掉非本 ezone 的數(shù)據(jù)。
- 可以在發(fā)生切換時(shí)，執(zhí)行特定的邏輯，觸發(fā)特定動(dòng)作。
- 業(yè)務(wù)需要準(zhǔn)備一些數(shù)據(jù)修復(fù)邏輯，在萬一發(fā)生不一致時(shí)，手工或者自動(dòng)糾正數(shù)據(jù)。
實(shí)現(xiàn)：多活的基礎(chǔ)中間件
下面簡(jiǎn)要介紹一下支持以上功能的中間件，我們歸納為多活 5 大基礎(chǔ)組件，之后會(huì)有系列文章，介紹每個(gè)基礎(chǔ)組件的具體實(shí)現(xiàn)。
APIRouter ： 路由分發(fā)服務(wù)
API Router是一個(gè)HTTP反向代理和負(fù)載均衡器，部署在公有云中作為HTTP API流量的入口，它能識(shí)別出流量的歸屬 shard ，并根據(jù) shard 將流量轉(zhuǎn)發(fā)到對(duì)應(yīng)的 ezone。API Router 支持多種路由鍵，可以是地理位置，也可以是商戶ID，訂單ID等等，最終由 API Router 映射為統(tǒng)一的 Sharding ID。
Global Zone Service：全局狀態(tài)協(xié)調(diào)器
GZS 維護(hù)著整個(gè)多活的路由表，其他所有的服務(wù)都從 GZS 訂閱路由信息。切換機(jī)房的操作也在 GZS 控制臺(tái)中完成。路由表包括：地理圍欄信息，shard 到 ezone 的歸屬信息，商鋪ID／訂單ID 等路由邏輯層到 shard id 的映射關(guān)系等。GZS 通過在 SDK 端建立 Cache，來保證shard 邏輯能夠最快速度執(zhí)行，基本不需要和 GZS 交互，同時(shí)也有實(shí)時(shí)推送機(jī)制，確保在數(shù)據(jù)變更后能夠快速通知到其他的服務(wù)。
SOA Proxy：內(nèi)部網(wǎng)關(guān)
SOA Proxy 實(shí)現(xiàn)了對(duì) SOA 調(diào)用的路由，執(zhí)行和 API Router 相似的邏輯，但只用在機(jī)房之間進(jìn)行通信的場(chǎng)景。業(yè)務(wù)使用 SOA Proxy 需要對(duì)代碼做一些修改，把路由信息加入到調(diào)用的上下文中。
Data Replication Center：數(shù)據(jù)復(fù)制
DRC 負(fù)責(zé) Mysql 數(shù)據(jù)的實(shí)時(shí)雙向復(fù)制，保證跨機(jī)房延時(shí)在 1s 以內(nèi)。提供了基于時(shí)間的沖突解決方案，確保各個(gè)機(jī)房的數(shù)據(jù)一致。DRC 除了復(fù)制數(shù)據(jù)，還對(duì)外提供了數(shù)據(jù)變更的通知，讓業(yè)務(wù)能夠感知到其他機(jī)房的數(shù)據(jù)變化，做相應(yīng)的處理，例如清除Cache等。除了DRC，我們還有 ZK復(fù)制工具，RMQ 復(fù)制工具，Redis復(fù)制工具，基本每個(gè)數(shù)據(jù)層次，都有對(duì)應(yīng)的復(fù)制方案。
Data Access Layer：數(shù)據(jù)訪問
數(shù)據(jù)訪問層支撐了 Globa Zone 的邏輯，還提供了最后一道保護(hù)，拒絕路由錯(cuò)誤的數(shù)據(jù)寫入，是多活最底層的支撐。
未來：下一步多活的計(jì)劃
目前餓了么的服務(wù)已經(jīng)部署到2個(gè)異地機(jī)房，下一步我們會(huì)擴(kuò)展到3-4個(gè)機(jī)房，并且在公有云上建立一個(gè)新的ezone，充分利用公有云的強(qiáng)大的擴(kuò)展能力，未來我們將能夠快速的在全世界各地搭建數(shù)據(jù)中心，也能夠快速的利用各種公有云基礎(chǔ)設(shè)施，實(shí)現(xiàn)全球規(guī)模的高可用和擴(kuò)展性。
文獻(xiàn)引用：
Latency numbers every programmer should know
作者介紹：
李雙濤，餓了么框架工具部高級(jí)架構(gòu)師，參與了整個(gè)餓了么多活的設(shè)計(jì)和實(shí)施過程。職業(yè)生涯中，有兩次參與這種大規(guī)模的整站高可用改造，一次在 Cisco Webex，一次在餓了么，積累了一些高可用和異地多活方面的經(jīng)驗(yàn)。
轉(zhuǎn)自：https://zhuanlan.zhihu.com/p/32009822
