美團外賣從 2013 年 11 月開始起步，經過數年的高速發展，一直在不斷地刷新著記錄。2018 年 5 月 19 日，日訂單量峰值突破 2000 萬單，已經成為全球規模最大的外賣平臺。

業務的快速發展對系統穩定性提出了更高的要求，如何為線上用戶提供高穩定的服務體驗，保障全鏈路業務和系統高可用運行，不僅需要后端服務支持，更需要在端上提供全面的技術保障。

而相對服務端而言，客戶端運行環境千差萬別，不可控因素多，面對突發問題應急能力差。

因此，構建客戶端的高可用建設體系，保障服務穩定高可用，不僅是對工程師的技術挑戰，也是外賣平臺的核心競爭力之一。

高可用建設體系的思路

一個設計良好的大型客戶端系統往往是由一系列各自獨立的小組共同開發完成的，每一個小組都應當具有明確定義的的職責劃分。

各業務模塊之間推行“松耦合”開發模式，讓業務模塊擁有隔離式變更的能力，是一種可以同時提升開發靈活性和系統健壯性的有效手段。

下面是美團外賣整體的業務架構，以商品交易鏈路（門店召回，商品展示，交易）為核心方向進行建設，局部上依據業務特點和團隊分工分成多個可獨立運維單元單獨維護。

可獨立運維單元的簡單性是可靠性的前提條件，這使得我們能夠持續關注功能迭代，不斷完成相關的工程開發任務。

我們將問題依照生命周期劃分為三個階段：發現、定位、解決，圍繞這三個階段的持續建設，構成了美團外賣高可用建設體系的核心。

美團外賣質量保障體系全景圖

這是美團外賣客戶端整體質量體系全景圖。整體思路：監控報警，日志體系，容災。

通過采集業務穩定性，基礎能力穩定性，性能穩定性三大類指標數據并上報，使得衡量客戶端系統質量的標準得以完善。

通過設立基線，應用特定業務模型對這一系列指標進行監控報警，客戶端具備了分鐘級感知核心鏈路穩定性的能力。

而通過搭建日志體系，整個系統有了提取關鍵線索能力，多維度快速定位問題。

當問題一旦定位，我們就能通過美團外賣的線上運維規范進行容災操作：降級，切換通道或限流，從而保證整體的核心鏈路穩定性。

背景監控&報警

監控系統，處于整個服務可靠度層級模型的最底層，是運維一個可靠的穩定系統必不可少的重要組成部分。

為了保障全鏈路業務和系統高可用運行，需要在用戶感知問題之前發現系統中存在的異常，離開了監控系統，我們就沒有能力分辨客戶端是不是在正常提供服務。

按照監控的領域方向，可以分成系統監控與業務監控：

• 系統監控，主要用于基礎能力如端到端成功率，服務響應時長，網絡流量，硬件性能等相關的監控。

系統監控側重在無業務侵入和定制系統級別的監控，更多側重在業務應用的底層，多屬于單系統級別的監控。

• 業務監控，側重在某個時間區間，業務的運行情況分析。業務監控系統構建于系統監控之上，可以基于系統監控的數據指標計算，并基于特定的業務介入，實現多系統之間的數據聯合與分析，并根據相應的業務模型，提供實時的業務監控與告警。

按照業務監控的時效性，可以繼續將其細分成實時業務監控與離線業務監控。

• 實時業務監控，通過實時的數據采集分析，幫助快速發現及定位線上問題，提供告警機制及介入響應（人工或系統）途徑，幫助避免發生系統故障。
• 離線的業務監控，對一定時間段收集的數據進行數據挖掘、聚合、分析，推斷出系統業務可能存在的問題，幫助進行業務上的重新優化或改進的監控。

美團外賣的業務監控，大部分屬于實時業務監控。借助美團統一的系統監控建設基礎，美團外賣聯合公司其他部門將部分監控基礎設施進行了改造、共建和整合復用，并打通形成閉環（監控，日志，回撈）。

我們構建了特定符合外賣業務流程的實時業務監控，而離線的業務監控，主要通過用戶行為的統計與業務數據的挖掘分析，來幫助產品設計，運營策略行為等產生影響。目前這部分監控主要由美團外賣數據組提供服務。

值得特別說明的是單純的信息匯總展示，無需或無法立即做出介入動作的業務監控，可以稱之為業務分析。

如特定區域的活動消費情況、區域訂單數量、特定路徑轉換率、曝光點擊率等，除非這些數據用來決策系統實時狀態健康情況，幫助產生系統維護行為，否則這部分監控由離線來處理更合適。

我們把客戶端穩定性指標分為 3 類維度：

• 業務穩定性指標
• 基礎能力穩定性指標
• 性能穩定性指標

對不同的指標，我們采用不同的采集方案進行提取上報，匯總到不同系統；在設定完指標后，我們就可以制定基線，并依照特定的業務模型制定報警策略。

美團外賣客戶端擁有超過 40 項度量質量指標，其中 25 項指標支持分鐘級別報警。

報警通道依據緊急程度支持郵件，IM 和短信三條通道。因此，我們團隊具備及時發現影響核心鏈路穩定性的關鍵指標變化能力。

一個完善的監控報警系統是非常復雜的，因此在設計時一定要追求簡化。以下是《Site Reliability Engineering：How Google Runs Production Systems》一書中提到的告警設置原則：

最能反映真實故障的規則應該可預測性強，非常可靠，并且越簡單越好

不常用的數據采集，匯總以及告警配置應該定時清除（某些 SRE 團隊的標準是一季度未使用即刪除）

沒有暴露給任何監控后臺、告警規則的采集數據指標應該定時清除

通過監控&報警系統，2017 年下半年美團外賣客戶端團隊共發現影響核心鏈路穩定性超過 20 起問題：包括爬蟲、流量、運營商 403 問題、性能問題等。目前，所有問題均已全部改造完畢。

日志體系

監控系統的一個重要特征是生產緊急告警。一旦出現故障，需要有人來調查這項告警，以決定目前是否存在真實故障，是否需要采取特定方法緩解故障，直至查出導致故障的問題根源。

簡單定位和深入調試的過程必須要保持非常簡單，必須能夠被團隊中任何一個人所理解。日志體系，在簡化這一過程中起到了決定性作用。

美團外賣的日志體系總體分為 3 大類：

• 全量日志系統，主要負責采集整體性指標，如網絡可用性，埋點可用性。我們可以通過它了解到系統整體大盤，了解整體波動，確定問題影響范圍。
• 個體日志系統，用于提取個體用戶的關鍵信息，從而針對性的分析特定客訴問題。
• 異常日志系統，主要采集異常指標，如大圖問題，分享失敗，定位失敗等。我們通過它可以迅速獲取異常上下文信息，分析解決問題。

這三類日志，構成了完整的客戶端日志體系。

日志的一個典型使用場景是處理單點客訴問題，解決系統潛在隱患。個體日志系統，用于簡化工程師提取關鍵線索步驟，提升定位分析問題效率。在這一領域，美團外賣使用的是點評平臺開發的 Logan 服務。

作為美團移動端底層的基礎日志庫，Logan 接入了集團眾多日志系統，例如端到端日志、用戶行為日志、代碼級日志、崩潰日志等。

并且這些日志全部都是本地存儲，且有多重加密機制和嚴格的權限審核機制，在處理用戶客訴時才對數據進行回撈和分析，保證用戶隱私安全。

通過設計和實施美團外賣核心鏈路日志方案，我們打通了用戶交易流程中各系統如訂單，用戶中心，Crash 平臺與 Push 后臺之間的底層數據同步。

通過輸出標準問題分析手冊，針對常見個體問題的分析和處理得以標準化；通過制定日志撈取 SOP 并定期演練，線上追溯能力大幅提升，日常客訴絕大部分可在 30 分鐘內定位原因。

在這一過程中，通過個體暴露出影響核心鏈路穩定性的問題也均已全部改進/修復。

故障排查是運維大型系統的一項關鍵技能。采用系統化的工具和手段而不僅僅依靠經驗甚至運氣，這項技能是可以自我學習，也可以內部進行傳授。

容災備份

針對不同級別的服務，應該采取不同的手段進行有效止損。非核心依賴，通過降級向用戶提供可伸縮的服務。

而核心依賴，采用多通道方式進行依賴備份容災，保證交易路徑鏈路的高可用；異常流量，通過多維度限流，最大限度保證業務可用性的同時，給予用戶良好的體驗。

總結成三點，即：非核心依賴降級、核心依賴備份、過載保護限流。接下來我們分別來闡述這三方面。

降級

在這里選取美團外賣客戶端整體系統結構關系圖來介紹非核心依賴降級建設概覽。

圖上中間紅色部分是核心關鍵節點，即外賣業務的核心鏈路：定位，商家召回，商品展示，下單；藍色部分，是核心鏈路依賴的關鍵服務；黃色部分，是可降級服務。

我們通過梳理依賴關系，改造前后端通訊協議，實現了客戶端非核心依賴可降級。

而后端服務，通過各級緩存，屏蔽隔離策略，實現了業務模塊內部可降級，業務之間可降級。這構成了美團外賣客戶端整體的降級體系。

右邊則是美團外賣客戶端業務/技術降級開關流程圖。通過推拉結合，緩存更新策略，我們能夠分鐘級別同步降級配置，快速止損。

目前，美團外賣客戶端有超過 20 項業務/能力支持降級。通過有效降級，我們避開了 1 次 S2 級事故，多次 S3、S4 級事故。

此外，降級開關整體方案產出 SDK horn，推廣至集團酒旅、金融等其他核心業務應用。

備份

核心依賴備份建設上，在此重點介紹美團外賣多網絡通道。網絡通道，作為客戶端的最核心依賴，卻是整個全鏈路體系最不可控的部分，經常出現問題。

網絡劫持，運營商故障，甚至光纖被物理挖斷等大大小小的故障嚴重影響了核心鏈路的穩定性。因此，治理網絡問題，必須要建設可靠的多通道備份。

這是美團外賣多網絡通道備份示意圖。美團外賣客戶端擁有 Shark、HTTP、HTTPS、HTTP DNS 四條網絡通道：整體網絡以 Shark 長連通道為主通道，其余三條通道作為備份通道。

配合完備的開關切換流程，可以在網絡指標發生驟降時，實現分鐘級別的分城市網絡通道切換。

而通過制定故障應急 SOP 并不斷演練，提升了我們解決問題的能力和速度，有效應對各類網絡異常。我們的網絡通道開關思路也輸出至集團其他部門，有效支持了業務發展。

限流

服務過載是另一類典型的事故。究其原因大部分情況下都是由于少數調用方調用的少數接口性能很差，導致對應服務的性能惡化。

若調用端缺乏有效降級容錯，在某些正常情況下能夠降低錯誤率的手段，如請求失敗后重試，反而會讓服務進一步性能惡化，甚至影響本來正常的服務調用。

美團外賣業務在高峰期訂單量已達到了相當高的規模量級，業務系統也極其復雜。

根據以往經驗，在業務高峰期，一旦出現異常流量瘋狂增長從而導致服務器宕機，則損失不可估量。

因此，美團外賣前后端聯合開發了一套“流量控制系統”，對流量實施實時控制。

這樣既能日常保證業務系統穩定運轉，也能在業務系統出現問題的時候提供一套優雅的降級方案，最大限度保證業務的可用性，在將損失降到最低的前提下，給予用戶良好的體驗。

整套系統，后端服務負責識別打標分類，通過統一的協議告訴前端所標識類別。

而前端，通過多級流控檢查，對不同流量進行區分處理：彈驗證碼，或排隊等待，或直接處理，或直接丟棄。

面對不同場景，系統支持多級流控方案，可有效攔截系統過載流量，防止系統雪崩。

此外，整套系統擁有分接口流控監控能力，可對流控效果進行監控，及時發現系統異常。整套方案在數次異常流量增長的故障中，經受住了考驗。

發布

隨著外賣業務的發展，美團外賣的用戶量和訂單量已經達到了相當的量級，在線直接全量發布版本/功能影響范圍大，風險高。

版本灰度和功能灰度是一種能夠平滑過渡的發布方式：即在線上進行 A/B 實驗，讓一部分用戶繼續使用產品（特性）A，另一部分用戶開始使用產品（特性）B。

如果各項指標平穩正常，結果符合預期，則擴大范圍，將所有用戶都遷移到 B 上來，否則回滾。

灰度發布可以保證系統的穩定，在初試階段就可以發現問題，修復問題，調整策略，保證影響范圍不被擴散。

美團外賣客戶端在版本灰度及功能灰度已較為完善：

• 版本灰度，iOS 采用蘋果官方提供的分階段發布方式，Android 則采用美團自研的 EVA 包管理后臺進行發布。這兩類發布均支持逐步放量的分發方式。
• 功能灰度，功能發布開關配置系統依據用戶特征維度（如城市，用戶 ID）發布，并且整個配置系統有測試和線上兩套不同環境，配合固定的上線窗口，保證上線的規范性。

對應的，相應的監控基礎設施也支持分用戶特征維度（如城市，用戶 ID）監控，避免了那些無法在整體大盤體現的灰度異常。

此外，無論版本灰度或功能灰度，我們均有相應最小灰度周期和回滾機制，保證整個灰度發布過程可控，最小化問題影響。

線上運維

在故障來臨時如何應對，是整個質量保障體系中最關鍵的環節。沒有人天生就能完美的處理緊急情況，面對問題，恰當的處理需要平時不斷的演練。

圍繞問題的生命周期，即發現、定位、解決（預防），美團外賣客戶端團隊組建了一套完備的處理流程和規范來應對影響鏈路穩定性的各類線上問題。

整體思路：建立規范，提前建設，有效應對，事后總結，如下圖：

在不同階段用不同方式解決不同問題，事前確定完整的事故流程管理策略，并確保平穩實施，經常演練，問題的平均恢復時間大大降低，美團外賣核心鏈路的高穩定性才能夠得以保障。

未來展望

當前美團外賣業務仍然處于快速增長期。伴隨著業務的發展，背后支持業務的技術系統也日趨復雜。

在美團外賣客戶端高可用體系建設過程中，我們希望能夠通過一套智能化運維系統，幫助工程師快速、準確的識別核心鏈路各子系統異常，發現問題根源。

并自動執行對應的異常解決預案，進一步縮短服務恢復時間，從而避免或減少線上事故影響。

誠然，業界關于自動化運維的探索有很多，但多數都集中在后臺服務領域，前端方向成果較少。

我們外賣技術團隊目前也在同步的探索中，正處于基礎性建設階段，歡迎更多業界同行跟我們一起討論、切磋。

作者：陳航、富強、徐宏

簡介：陳航，美團高級技術專家。2015 年加入美團，目前負責美團外賣 iOS 團隊，對移動端架構演進，監控報警備份容災，移動端線上運維等領域有深刻理解。

富強，美團資深工程師。2015 年加入美團，是外賣 iOS 的早期開發者之一，目前作為美團外賣 iOS 基礎設施小組負責人，負責外賣基礎設施及廣告運營相關業務。

徐宏，美團高級工程師。2016 年加入美團，目前作為外賣 iOS 團隊主力開發，負責移動端 APM 性能監控，高可用基礎設施支撐相關推進工作。