互聯(lián)網(wǎng)多活技術(shù)架構(gòu)及運(yùn)維

1、 互聯(lián)網(wǎng)多活技術(shù)架構(gòu)及運(yùn)維餓了么多活系統(tǒng)架構(gòu)餓了么業(yè)務(wù)快速發(fā)展，給技術(shù)帶來了海量請求和高并發(fā)、微服務(wù)的挑戰(zhàn)，同時開發(fā)團(tuán)隊(duì)快節(jié)奏的版本迭代和服務(wù)快速上線的要求也驅(qū)動運(yùn)維團(tuán)隊(duì)提供穩(wěn)定、高效的運(yùn)維服務(wù)。我是餓了么的技術(shù)運(yùn)營負(fù)責(zé)人，見證了餓了么業(yè)務(wù)的飛速發(fā)展。記得 2015 年加入餓了么的時候，我們的日訂單量只有 30 萬筆；而到了 2017 年，我們的日訂單量已經(jīng)超過 1000 萬筆。考慮到我們在整個市場的體量和單個機(jī)房至多只能處理 2000 萬筆訂單的上限，我們逐步推進(jìn)了面向百分之百冗余多活的新規(guī)劃。今天的分享主要分為三個部分：多活場景及業(yè)務(wù)形態(tài)餓了么多活運(yùn)維挑戰(zhàn)餓了么運(yùn)營體系探索多活場景及業(yè)務(wù)形

2、態(tài)餓了么多活的現(xiàn)狀首先介紹一下餓了么整個多活的現(xiàn)狀：我們在北京和上海共有兩個機(jī)房提供生產(chǎn)服務(wù)。機(jī)房和 ezone 是兩個不同的概念，一個機(jī)房可以擴(kuò)展多個 ezone，目前是一對一關(guān)系。我們還有兩個部署在公有云的接入點(diǎn)，作為全國流量請求入口。它們分別受理南北方的部分流量請求，接入點(diǎn)都部署在阿里云上面，同時從運(yùn)維容災(zāi)角度出發(fā)。我們考慮到兩個云入口同時“宕掉”的可能性，正在籌建 IDC 內(nèi)的備用接入點(diǎn)，作為災(zāi)備的方案。多活從 2017 年 5 月份的第一次演練成功到現(xiàn)在，我們經(jīng)歷過 16 次整體性的多活切換。這 16 次切換既包含正常的演練，也包含由于發(fā)生故障而進(jìn)行的真實(shí)切換。其中，最近的一次切換是

3、因?yàn)槲覀兩虾C(jī)房的公網(wǎng)出口發(fā)生了故障，我們將其所有流量都切換到了北京。實(shí)現(xiàn)多活的背景下面我從五方面介紹實(shí)施多活之前的一些背景狀況：業(yè)務(wù)特點(diǎn)技術(shù)復(fù)雜運(yùn)維兜底故障頻發(fā)機(jī)房容量業(yè)務(wù)特點(diǎn)：我們有三大流量入口，分別是用戶端、商戶端以及騎手端。一個典型的下單流程是：用戶打開 App產(chǎn)生一個訂單，店家在商戶端進(jìn)行接單，然后生成一個物流派送服務(wù)的運(yùn)單。而該流程與傳統(tǒng)電商訂單的區(qū)別在于：如果在商城生成一個訂單，后臺商戶端可以到第二天才收到，這種延時并無大礙。但是對于餓了么就不行，外賣的時效性要求很高，如果在 10 分鐘之內(nèi)商戶還未接單的話，用戶要么會去投訴，要么可能就會取消訂單，更換美團(tuán)、百度外賣，從而會造成用

4、戶的流失。另外，我們也有很強(qiáng)的地域性。比如說在上海生成的訂單，一般只適用于上海本地區(qū)，而不會需要送到其他地方。同時，我們的業(yè)務(wù)也有著明顯的峰值，上午的高峰，一般在 11 點(diǎn)；而下午則會是在 5 點(diǎn)到 6 點(diǎn)之間。我們通過整個監(jiān)控曲線便可對全鏈路的請求一目了然。這就是我們公司乃至整個外賣行業(yè)的業(yè)務(wù)特點(diǎn)。技術(shù)復(fù)雜：上圖是流量請求從進(jìn)入到底層的整個技術(shù)架構(gòu)。SOA（面向服務(wù)的體系結(jié)構(gòu)）系統(tǒng)架構(gòu)本身并不復(fù)雜，其實(shí)大部分互聯(lián)網(wǎng)公司的技術(shù)架構(gòu)演進(jìn)到最后都是類似的。我們真正的復(fù)雜之處在于：各種組件、基礎(chǔ)設(shè)施以及整個的接入層存在多語言的問題。在 2015 年之前，我們的前端是用 PHP 寫的，而后端則是 Py

5、thon 寫的。在經(jīng)歷了兩年的演進(jìn)之后，我們現(xiàn)在已把所有由 PHP 語言寫的部分都替換掉了。而為了適用多種語言，我們的組件不得不為某一種語言多做一次適配。比如說：我們要跟蹤（trace）整個鏈路，而且用到了多種語言，那么我們就要為之研發(fā)出多種 SDK，并需要花大量的成本去維護(hù)這些 SDK?？梢?，復(fù)雜性往往不在于我們有多少組件，而是我們要為每一種組件所提供的維護(hù)上。我們當(dāng)前的整個 SOA 框架體系主要面向兩種語言：Python 和 Java，逐漸改造成更多地面向 Java。中間的 API Everything 包含了許多為不同的應(yīng)用場景而開發(fā)的各種 API 項(xiàng)目。而我們基礎(chǔ)設(shè)施方面，主要包括了整

6、個存儲與緩存，以及公有云和私有云。運(yùn)維兜底：在業(yè)務(wù)飛速發(fā)展的過程當(dāng)中，我們的運(yùn)維團(tuán)隊(duì)做得更多的還是“兜底”工作。最新的統(tǒng)計，我們現(xiàn)在有將近 16000 臺服務(wù)器、1600 個應(yīng)用、1000 名開發(fā)人員、4 個物理 IDC、以及部署了防護(hù)層的兩朵云。也有一些非常小的第三方云服務(wù)平臺，包括 AWS 和阿里聚石塔等。在業(yè)務(wù)增長過程當(dāng)中，基于整個 IDC 的基礎(chǔ)設(shè)施環(huán)境，我們對交付的機(jī)型統(tǒng)一定制，并且改進(jìn)了采購的供應(yīng)鏈，包括：標(biāo)準(zhǔn)化的整機(jī)柜交付和數(shù)據(jù)清洗等。對于應(yīng)用使用的數(shù)據(jù)庫與緩存，我們也做了大量的資源拆分與改造工作，比如數(shù)據(jù)庫，改造關(guān)鍵路徑隔離，垂直拆分，sharding，SQL 審核，接入數(shù)據(jù)庫

7、中間件dal，對緩存 redis 使用治理，遷移自研的 redis cluster 代理 corvus，聯(lián)合框架實(shí)現(xiàn)存儲使用的規(guī)范化，服務(wù)化。曾經(jīng)面臨比較大的挑戰(zhàn)是數(shù)據(jù)庫 DDL，表設(shè)計在每家公司都有一些自己的特點(diǎn)，例如阿里、百度他們每周 DDL 次數(shù)很少。但是我們每周則會有將近三位數(shù)的 DDL 變更，這和項(xiàng)目文化以及業(yè)務(wù)交付有關(guān)。DBA 團(tuán)隊(duì)以及 DAL 團(tuán)隊(duì)為此做了幾件事情：表數(shù)據(jù)量紅線，基于 Gh-OST 改進(jìn) online schema change 工具，Edb 自助發(fā)布。這樣大大減少了數(shù)據(jù)庫 DDL 事故率以及變更效率。在多活改造過程中，工具的研發(fā)速度相對落后，我們在運(yùn)維部署服務(wù)，

8、組件的推廣和治理過程中，大部分都還是人工推廣、治理。我們還負(fù)責(zé)全網(wǎng)的穩(wěn)定性，以及故障管理，包括預(yù)案演練、故障發(fā)現(xiàn)、應(yīng)急響應(yīng)、事故復(fù)盤等，以及對事故定損定級。故障管理并不是為了追責(zé)，而是通過記錄去分析每一次故障發(fā)生的原因，以及跟進(jìn)改進(jìn)措施，避免故障再次發(fā)生。我們還定義了一個全網(wǎng)穩(wěn)定性計數(shù)器，記錄未發(fā)生重大事故的累計時間，當(dāng)故障定級應(yīng)達(dá)到 P2 以上時清零重新開始。歷史上我們保持最長的全網(wǎng)穩(wěn)定性紀(jì)錄是 135 天，而美團(tuán)已經(jīng)超過了 180 天，還有一些差距。故障頻發(fā)：根據(jù)上圖“故障頻發(fā)”所反映的數(shù)據(jù)，大家可以看到，2015 年和 2016 年的數(shù)據(jù)慘不忍睹。按天計算，我們經(jīng)常會出現(xiàn) P2 級別以上

9、的事故，最短的是隔 1 天就出現(xiàn) 1 個 P2 以上事故。我們不得不進(jìn)行改進(jìn)，于是我們組建了一個叫 NOC（Notification Operation Center）的團(tuán)隊(duì)。這個是參照 Google SRE 所建立的負(fù)責(zé) 7*24 應(yīng)急響應(yīng)團(tuán)隊(duì)，以及初步原因判斷，執(zhí)行常規(guī)的演練，組織復(fù)盤，跟進(jìn)復(fù)盤改進(jìn)落地情況。NOC 定義公司通用故障定級定損/定責(zé)的標(biāo)準(zhǔn)：P0P5 的事故等級，其參照的標(biāo)準(zhǔn)來自于業(yè)務(wù)特性的四個維度，它們分別是：在高峰期/非高峰期的嚴(yán)重影響，包括受損時間段和受損時長。對全網(wǎng)業(yè)務(wù)訂單的損失比。損失金額。輿情的影響。包括與美團(tuán)、百度外賣、其他平臺的競爭。不過區(qū)別于外賣食材的本身品質(zhì)

10、，我們這里討論的是技術(shù)上的故障。比如商家無緣無故取消了客戶的訂單，或是由于其他各種原因?qū)е驴蛻粼谖⒉?、或向客服部門投訴的數(shù)量上升。上述這些不同的維度，結(jié)合高峰期與低峰期的不同，都是我們定級的標(biāo)準(zhǔn)。根據(jù)各種事故運(yùn)營定級/定責(zé)的規(guī)范，我們建立了響應(yīng)的排障 SOP（標(biāo)準(zhǔn)操作流程），進(jìn)而我們用報表來進(jìn)行統(tǒng)計。除了故障的次數(shù)之外，MTTR（平均恢復(fù)時間）也是一個重要的指標(biāo)。通過響應(yīng)的 SOP，我們可以去分析某次故障的本身原因，是因?yàn)榘l(fā)現(xiàn)的時間較長，還是響應(yīng)的時間較長，亦或排障的時間比較長。通過落地的標(biāo)準(zhǔn)化流程，并且根據(jù)報表中的 MTTR，我們就可以分析出在發(fā)生故障之后，到底是哪個環(huán)節(jié)花費(fèi)了較長的時間。提

11、到“故障頻發(fā)”，我們認(rèn)為所有的故障，包括組件上的故障和底層服務(wù)器的故障，都會最終反映到業(yè)務(wù)曲線之上。因此我們 NOC 辦公室有一個大屏幕來顯示重要業(yè)務(wù)曲線，當(dāng)曲線的走勢發(fā)生異常的時候，我們就能及時響應(yīng)通知到對應(yīng)的人員。在訂單的高峰期，我們更講求時效性。即發(fā)生了故障之后，我們要做的第一件事，或者說我們的目標(biāo)是快速地止損，而不是去花時間定位問題。這就是我們?nèi)?shí)現(xiàn)多活的目的，而多活正是為我們的兜底工作進(jìn)行“續(xù)命”。原來我只有一個機(jī)房，如果該機(jī)房的設(shè)施發(fā)生了故障，而正值業(yè)務(wù)高峰期的時候，后果是不堪設(shè)想的。機(jī)房容量：我們再來看看整個機(jī)房的容量，在 2015 年之前，當(dāng)時訂單量很少，我們的服務(wù)器散落在機(jī)房

12、里，機(jī)型也比較隨意。而到了 2015 年，我們大概有了 1500 臺服務(wù)器；在 2016 年間，我們增長到了 6000 臺；2017 年，我們則擁有將近 16000 臺。這些還不包括在云上的 ECS 數(shù)量。有過 IDC 相關(guān)工作經(jīng)歷的同學(xué)可能都知道：對于大型公司的交付，往往都是以模塊簽的合同。但初期我們并不知道業(yè)務(wù)發(fā)展會這么快，服務(wù)器是和其他公司公用模塊和機(jī)架，服務(wù)器也是老舊而且非標(biāo)準(zhǔn)化，同時組網(wǎng)的環(huán)境也非常復(fù)雜。甚至有一段時期，我們就算有錢去購買服務(wù)器，機(jī)房里也沒有擴(kuò)容的空間。為什么要做多活為什么要做多活，總結(jié)一下有四個方面：容災(zāi)續(xù)命、服務(wù)擴(kuò)展、單機(jī)房容量、和其他的一些原因。如上圖右側(cè)所示，

13、我們通過一個類似 X/Y 軸的曲線進(jìn)行評估。隨著業(yè)務(wù)規(guī)模的增長，技術(shù)投入，服務(wù)擴(kuò)展，故障損失已不是一種并行增長的關(guān)系了。餓了么多活運(yùn)維挑戰(zhàn)下面分享一下我們當(dāng)時做了哪些運(yùn)維的規(guī)劃，主要分為五個部分：多活技術(shù)架構(gòu)IDC 規(guī)劃SOA 服務(wù)改造數(shù)據(jù)庫改造容災(zāi)保障多活技術(shù)架構(gòu)我們通過設(shè)置既可把昆山劃分到上海，又可以劃到蘇州（這與行政區(qū)無關(guān)、僅關(guān)系到外賣的遞送半徑）。因此我們提出了地理圍欄的概念，研發(fā)了 GZS 組件。我們把全國省市在 GZS（globalzone service）服務(wù)上區(qū)分地理圍欄，將全國分成了 32 個 Shard，來自每個 Shard 的請求進(jìn)入系統(tǒng)之后，通過 GZS 判斷請求應(yīng)該路

14、由到所屬的機(jī)房。如圖最下方所示，對于一些有強(qiáng)一致性需求的數(shù)據(jù)要求，我們提出了 Global zone 的概念。屬于 Global zone 的數(shù)據(jù)庫，寫操作僅限于在一個機(jī)房，讀的操作可以在不同 zone 內(nèi)的 local slave 上。多活技術(shù)架構(gòu)五大核心組件：API Router：流量入口 API Router，這是我們的第一個核心的組件，提供請求代理及路由功能。GZS：管理地理圍欄數(shù)據(jù)及 Shard 分配規(guī)則。DRC：DRC（Data replication center）數(shù)據(jù)庫跨機(jī)房同步工具，同時支持?jǐn)?shù)據(jù)變更訂閱，用于緩存同步。SOA proxy：多活非多活之間調(diào)用。DAL：原本是數(shù)據(jù)

15、庫中間件，為了防止數(shù)據(jù)被路由到錯誤的機(jī)房，造成數(shù)據(jù)不一致的情況，多活項(xiàng)目中配合做了一些改造。整個多活技術(shù)架構(gòu)的核心目標(biāo)在于：始終保證在一個機(jī)房內(nèi)完成整個訂單的流程。為了實(shí)現(xiàn)這個目標(biāo)，研發(fā)了 5 大功能組件，還調(diào)研識別有著強(qiáng)一致性的數(shù)據(jù)需求，一起從整體上做了規(guī)劃和改造。IDC 規(guī)劃在 2016 年底啟動多活項(xiàng)目，確定了南北兩個機(jī)房，以及流量入口，開始進(jìn)行 IDC 選型，實(shí)地考察了幾家上海的 IDC 公司，最終選擇了萬國數(shù)據(jù)機(jī)房。同時結(jié)合做抗 100% 流量服務(wù)器預(yù)算、提交采購部門采購需求。規(guī)劃多活聯(lián)調(diào)測試環(huán)境，模擬生產(chǎn)雙 ezone、劃分 vpc，以及最后的業(yè)務(wù)同期改造。如上圖右側(cè)所示，以兩處不

16、同的流量為例，不同區(qū)域通過接入層進(jìn)來的流量，分別對應(yīng)北京和上海不同的機(jī)房，在正常情況下整個訂單的流程也都會在本區(qū)域的機(jī)房被處理，同時在必要時能夠相互分流。SOA 服務(wù)改造我們對 SOA 服務(wù)注冊發(fā)現(xiàn)也做了一些改造工作。先說下多活以前是什么情況，某一個應(yīng)用服務(wù)AppId要上線，物理集群環(huán)境準(zhǔn)備好，在 SOA 注冊時對應(yīng)了一個 SOA cluster 集群。另外一些大的集群，對不同的業(yè)務(wù)調(diào)用劃分不同的泳道，并將這些泳道在應(yīng)用發(fā)布的時候，定義到不同的應(yīng)用集群上，這就是整個AppId部署的邏輯。這對于單機(jī)房來說是很簡單的，但是在雙機(jī)房場景中，需要改造成同一個AppId，只調(diào)用本機(jī)房的 SOA clus

17、ter，我們在甬道和分布集群的基礎(chǔ)上引入了一個類似于單元的 ezone 概念。SOA Mode 的改造方案，其中包括如下三種模式：Orig：兼容模式，默認(rèn)的服務(wù)注冊發(fā)現(xiàn)方式。Prefix：收回服務(wù)注冊、統(tǒng)一 SOA 服務(wù)注冊的方式。此模式主要針對的是我們許多新上線的多活應(yīng)用。對于一些老的業(yè)務(wù)，默認(rèn)還是沿用 Orig 模式。Route：這是回收 SOA 服務(wù)調(diào)用的最終模式，進(jìn)一步實(shí)現(xiàn)了統(tǒng)一 SOA 的服務(wù)注冊發(fā)現(xiàn)。整個 IDC、ezone、運(yùn)維架構(gòu)等信息對于業(yè)務(wù)方都是透明，從而降低了業(yè)務(wù)方對于 SOA 所產(chǎn)生的維護(hù)工作量。數(shù)據(jù)庫改造按照前面對整個應(yīng)用部署的劃分，即多活、非多活以及強(qiáng)一致性的 Gl

18、obal zone，對數(shù)據(jù)庫也進(jìn)行了相應(yīng)的規(guī)劃。我們先后進(jìn)行了業(yè)務(wù)數(shù)據(jù)一致性的調(diào)研，復(fù)制一致性的規(guī)劃，多活的集群改造成通過 DRC 來雙向復(fù)制，Global zone 則采用原生的 Replication。具體改造可分為三部分：數(shù)據(jù)庫集群改造，根據(jù)倒排期的時間點(diǎn)，分派專門的團(tuán)隊(duì)去跟進(jìn)，將整個過程拆分出詳細(xì)的操作計劃。數(shù)據(jù)庫中間件 DAL 改造，增加校驗(yàn)功能，保證 SQL 不會寫入錯誤的機(jī)房。實(shí)現(xiàn)了寫入錯誤的數(shù)據(jù)保護(hù)，增加一道兜底防護(hù)。DRC 改造，多活兩地實(shí)例間改造程 DRC 復(fù)制。容災(zāi)保障容災(zāi)保障，區(qū)分了三個不同的等級：流量入口故障，常見的有 DNS 解析變更，網(wǎng)絡(luò)出口故障，某省市骨干線路故

19、障，以及 AR 故障。IDC 內(nèi)故障，常見的有變更發(fā)布故障，歷史 Bug 觸發(fā)，錯誤配置，硬件故障，網(wǎng)絡(luò)故障，容量問題等。單機(jī)房完全不可用。目前尚未完全實(shí)現(xiàn)，但是我們?nèi)缃裾谶M(jìn)行斷網(wǎng)演練。模擬某個機(jī)房里的所有 zone 都因?yàn)椴豢煽沽﹀吹袅?，也要保證該機(jī)房的所有應(yīng)用能夠被切換到另一個機(jī)房，繼續(xù)保障服務(wù)可用。當(dāng)然這沒能從根本上解決雙機(jī)房同時發(fā)生故障的情況。當(dāng)雙機(jī)房同時發(fā)生問題時，目前還是要依賴于有經(jīng)驗(yàn)的工程師，以及我們自動化的故障定位服務(wù)。餓了么運(yùn)營體系探索在整個餓了么運(yùn)維轉(zhuǎn)型的過程中，我們?nèi)绾螌⒔M織能力轉(zhuǎn)型成為運(yùn)營能力？下面是我們的五個思路：應(yīng)用發(fā)布監(jiān)控體系預(yù)案和演練容量規(guī)劃單機(jī)房成本分析應(yīng)用

20、發(fā)布首先來看應(yīng)用發(fā)布。在單機(jī)房的時候，我們一個 AppId 對應(yīng)一個或多個 SOA cluster 集群，同時運(yùn)維會配置灰度機(jī)器群組，并要求關(guān)鍵應(yīng)用需要灰度 30 分鐘。那么在多活情況下，應(yīng)用如何實(shí)現(xiàn)發(fā)布呢？我們在規(guī)劃中采用了兩種方式可選：把所有 zone 看成一個大型的“集群”，沿用灰度機(jī)器群體的發(fā)布策略。我們先在單個機(jī)房里做一次灰度，然后延伸到所有的 zone，保證每個關(guān)鍵應(yīng)用都遵循灰度大于 30 分鐘的規(guī)則，最后再全量到所有的 zone 上。把單個 zone 看成一個“集群”，有多少個 zone 就有多少個“集群”。首先灰度 zoneA、并全量 zoneA，然后灰度 zoneB、并全量 zoneB?；蛘吣部梢韵然叶?zoneA、并灰度 zoneB，然后同時觀察、并驗(yàn)證發(fā)布的狀態(tài)，最后再全量 zoneA、并全量 zoneB。您可以根據(jù)自身情況自行選擇和實(shí)現(xiàn)。監(jiān)控體系餓了么目前有三大監(jiān)控體系：全鏈路監(jiān)控。在 Agent 啟動時讀取一個文件，以獲知當(dāng)前處于哪個 zone，然后會在 metric 中為 ezoneid 增加一個 tag，并且進(jìn)行指標(biāo)聚合。默認(rèn)在一個機(jī)房里可有多個 zone。業(yè)務(wù)監(jiān)控。進(jìn)行分機(jī)房的部署，將 st