寫在前面
2018年4月，中國外賣市場迎來鉅變，外賣從無人問津開始，到現在已經培育成互聯網巨頭必爭之地。作爲爲數不多能夠達到日千萬訂單級別的業務，其後端服務是怎麼支撐的？InfoQ採訪了ArchSummit出品人、美團點評技術總監方建平，請他回顧及展望美團外賣的後端架構史，本文根據採訪整理而成。
美團外賣後端架構迭代各階段
美團外賣發展到今天差不多有 4 年多的時間，按照外賣業務發展的幾個特徵，可以相應地把外賣技術分成三個主要階段：
第一階段：業務初探期
大約截止到 2015 年初，持續差不多一年左右的時間。這個階段的主要特徵就是美團對於外賣的業務還處於市場摸索期，研發人員相對也比較少，差不多 10 來個同學，產品上需要快速迭代、試錯。
所以這個階段的系統架構比較簡單，就是典型的單系統 Web 應用服務，主要是需要滿足產品需求上的快速上線，驗證業務模型的市場可行性。
第二階段：業務爆發期
外賣業務在 2015 年初開始了爆發式增長。基於當前外賣的業務特性，90% 以上的交易都是在午高峯和晚高峯這個期間完成的，對業務系統來說高峯期負載重，壓力大。這個階段，我們主要是從最早期的基於單系統的 Web 應用架構，向分佈式服務架構的遷移改造。期間主要優化工作如下：
一、做架構的拆分，應對高併發、保證高性能
對系統的拆分，主要體現在系統服務層、以及數據存儲層上。
通過對線上業務流程的分解，將外賣系統分成數據瀏覽體系、用戶訂單交易體系、商戶接單配送體系、用戶信息 UGC 服務等，同時也針對大的業務服務體系內的流量分佈、以及功能差異性，再做進一步的拆解。比如瀏覽體系中會有門店服務、商品服務、搜索推薦服務等等。
針對併發的讀寫數據壓力，我們也針對性地搭建了相應的分佈式緩存服務、針對特定數據庫表，例如訂單表，也進行了基於訂單 ID、門店 ID、用戶 ID 等多個維度的拆庫、拆表操作。
二、構建系統化運維體系，保障服務高可用
分佈式系統拆分，提升了外賣服務的併發處理能力，同時也給線上運維帶來了負擔。需要對線上近百個服務應用、幾千臺機器資源進行運維管理，才能保證整個業務鏈路服務的穩定體驗。這個期間，我們在業務系統的可運維方面，做了大量的工作。例如：
-
通過完整業務鏈路的梳理，形成關聯各服務接口的 SLA，保障核心鏈路的穩定 ;
-
通過定期的全鏈路壓測，驗證各子系統的處理極限，合理規劃系統容量；
-
通過鏈路故障模擬演練，驗證各服務系統在功能層面、系統層面的故障降級處理能力
第三階段：業務擴展期
這個期間是伴隨着業務爆發期逐步開始的。外賣的業務中，除了傳統的餐飲品類外，還逐步提供了鮮花、生鮮、果蔬、商超、以及跑腿服務等業務的擴展。7 月 6-9 日，我除了在 ArchSummit 深圳站 上擔任《大型分佈式系統架構》出品人，也會現場分享美團外賣這個階段在服務端的架構迭代，包括數據處理上的技巧經驗，這裏簡單總結下：
業務擴展期階段外賣業務和產品，我們期望以最小的代價，支持不同品類的差異性服務，能夠在當前的系統中快速上線。對技術來說，就需要將系統由業務的功能化向業務的平臺化方向發展。
我們通過對通用電商邏輯的抽取，形成公共服務平臺，將差異性的品類業務特性，通過系統插件或者流程配置的方式，集成到公共服務平臺上，以達到整個鏈路的整合複用。例如：
-
將訂單交易流程通過類似工作流引擎的方式，針對不同的品類，配置不同的流程模板，使其能夠靈活的運行在整個外賣的核心交易體系之中；
-
商家促銷活動平臺，支持從門店、商品、區域等等不同品類進行各種活動配置，滿足不同品類的營銷需求。
美團外賣後端新項目
當前美團外賣業務依然處於持續增長期，年前我們的日訂單剛突破了 1800 多萬。伴隨着業務的發展，基於業務背後的技術系統也日趨複雜。無論是對於機器資源規模，還是系統服務之間的調度關聯，都對線上服務的運維帶來很大的挑戰。
爲保證外賣線上服務規模的可擴展和可運維，近期我們正在開展兩大項目：一個是外賣的 Set 化部署項目、另一個是智能化業務運維繫統建設。
外賣 Set 化部署項目
這個項目的目標是爲了解決外賣當前大數據、高併發場景下的機房集羣資源規模限制問題。我們希望將用戶與商家的大規模請求流量，按照特定的規則，拆分到不同 Set 內，同時在 Set 內做到整個用戶交易流程的閉環。這樣我們並可以通過可控容量大小的 Set 劃分，達到分散系統壓力，快速支持擴容的能力。
Set 化不是一項新技術，當前業界也有部分公司已經在線上實施了，我們計劃 2018 年下半年進入部署狀態。這塊涉及到的基礎服務改造，應用服務改造非常多，我想等我們上線後，可以總結下經驗，再來給大家詳細分享下。
外賣智能化業務運維建設項目
在美團外賣的穩定性建設過程中，我們希望通過一套智能化運維繫統，幫助快速、準確地識別各鏈路子系統服務異常，發現問題根因，並自動執行對應的異常解決預案，從而避免或減少線上事故影響。
當前業界關於 AIOps 這塊的探索也有很多，我們也在同步的跟進摸索中，目前主要還處於基礎性建設期間，包括核心鏈路的故障演練系統、全鏈路壓測系統、告警分析診斷系統，服務自保護系統等等。
高併發應對策略
這裏簡單介紹下我們的高峯低谷策略、動態調度設計、目前的瓶頸，以及我們的優先級策略。
高峯低谷策略
針對當前外賣的週期性峯值波動特性，我們的主要採取如下幾個策略：
系統基礎運行能力的適度冗餘
外賣系統在系統架構的設計上，無論是在服務層面系統部署，還是數據層面的存儲資源都會做適當的冗餘。比如我們大部分的核心繫統服務，會保持線上高峯時 1.5 倍左右的冗餘，以保證高峯期間的業務異常流量情況下的系統可用。
系統資源的動態調配
美團外賣的服務系統都是部署在美團私有云上的，最近一年來，我們也在很多的服務上使用了美團內部的彈性計算容器，以應對外賣系統的突增壓力時，可以做到近實時的系統快速擴容。同時在低峯期也可以釋放資源，提升機器資源利用率。
系統在極限壓力下的自我保護
除了從基本的資源部署上來保證以外，在外賣的系統設計中，也會採取大量的自保護策略，其中包括各系統服務的限流、降級、熔斷等自我保護策略，以保證系統在異常流量壓力下核心鏈路的可用性。
動態調度設計
外賣業務鏈路較長，其中關聯角色有三方：用戶、商家、騎手，簡單的業務流程是：用戶下單 ->商家接單 / 發配送 ->騎手接單配送。
外賣服務是一個強履約服務，需要盡最大可能，保障用戶下單之後，以最快的時間內送達商品，保障用戶的體驗。外賣當前主要基於餐飲的商品，屬於非標品服務，同時也是基於人員配送的即時物流服務，所以一定時間內的服務規模是有限的。一旦商家商品供給能力不足、或者配送資源不足的時候，都需要通過系統來調節。
例如，當運力充足但商家訂單過多，出餐瓶頸出現的時候，爲保證用戶的體驗，我們會從產品上提示用戶商家忙，繼續下單需要能夠讓用戶有延遲送達的預期；同時針對訂單較多，出餐較慢的商家，也會在門店列表排序上給予一定的關聯因子降級。
對於運力不足的情況下，也會通過適當的實時策略調整，來保證現有運力的供給平衡，比如在高峯期之外降低配送費，高峯期間提升配送費來調節需求的平衡分佈。在極端天氣，爆單的情況下，可以通過動態調整特定區域商家的配送範圍，來保證用戶體驗。
總之在外賣的整個交易鏈路中，用戶、商家、配送等系統之間的實時數據是互通的，各業務系統通過關注不同的實時數據變化，採用不同的策略應對，從而調節整個業務的運作模式，保證外賣鏈路三方的平衡。
當前瓶頸
隨着業務規模的進一步擴展，當前外賣分佈式架構體系中，系統各層的水平擴展性是我們可能會面臨的瓶頸。 具體來說，我們面臨的問題包括如下兩點：
服務層單個集羣大小受限
服務層雖然是無狀態服務，理論上可以無限增加，但是單個集羣規模越大，運維成本就會越高，比如基礎服務治理對於服務狀態的維護、更新、同步等。
數據存儲單個集羣大小受限
單個集羣的從庫個數是受限的，從庫越多，主庫消耗越大，導致從庫個數是受限的。
所以總的來說，系統集羣規模是存在上限的，導致實時線上服務的系統處理能力受限。近期我們啓動了外賣服務 Set 化升級，結合外賣的強地域特徵，將流量按照地域拆分開，每部分流量由單獨集羣提供服務，從將整個大的分佈式集羣拆分爲多個小集羣，從而可以通過從業務邏輯層的設置，來達到控制集羣規模大小的目的。
在當前我們的非 Set 化架構體系中，受限於上面提到的兩點，大約可以滿足兩倍於當前業務的數據量，可以支撐近一年左右的業務增長。隨着我們的 Set 化項目 2018 年完成部署，理論上通過增加新的 Set 集羣，進一步擴展系統能力，可很好地支持未來 3~5 年的業務增長。
優先級策略
作爲一個線上即時交易服務系統，在線上資源不足，或者故障發生時，我們首先會優先保護和訂單交易相關的核心業務鏈路。這條鏈路從用戶能感知到的服務就是：商家列表的瀏覽、商家內的商品展示、用戶提單支付、商品騎手配送。
這就需要我們梳理最小化的核心服務鏈路，除此之外的其他鏈路分支所關聯的所有服務，都可以在故障時刻被降級。比如針對商家列表的排序、推薦、廣告服務、評論服務、搜索服務等等。
而實現最小化交易鏈路保證的前提是：各系統具備能夠降級非核心服務接口依賴的能力。外賣服務經過這幾年的不斷業務梳理與積累，逐步開發實現了各業務鏈路的限流開關、功能服務開關、依賴服務降級開關百餘個。這些開關通過我們的事故緊急預案，被分類組織到我們的業務運維繫統中，一旦對應的事故發生，我們可以快速的通過系統，來完成批量的服務降級處理，從而避免事故的發生、或減少事故造成的損失。
外賣高峯期的入口請求 QPS 達到 20W 左右，這其中包含了部分惡意攻擊或抓取流量。針對惡意爬蟲抓取這塊，我們會與公司內部的反爬團隊一起做這塊的防範工作。而針對突發的攻擊性流量，除了公司上層流量入口層的控制以外，外賣自身的服務也會根據用戶或地域維度做一定的限流策略，避免惡意攻擊造成對正常流量的影響。
架構優化
擴容還是性能優化
爲達到目標系統的容量，一般有擴容和性能優化兩種手段，這兩種手段會根據服務當前的具體情況配合使用。大的原則是：長期保持系統的優化、緊急狀況擴容或按照長期業務趨勢規劃擴容。具體我們在擴容和性能優化上做的事情如下：
關於擴容能力
外賣的業務技術系統，構建在美團內部分佈式基礎中間件之上（例如分佈式緩存、消息隊列、服務治理中間件等），這些通用的分佈式組件，爲上層應用的水平擴容，提供了基礎能力保證。
對外賣業務系統，我們也進行了對應的系統拆分 (例如交易服務、營銷服務、評論服務、商品門店服務等)，拆分中保證各服務均採用無狀態設計，可以快速支持水平擴容。另外類似營銷這樣存在突發流量的服務，也接入到美團彈性計算容器中，可以支持根據流量變化，來進行自動化的擴縮容。
關於性能優化
針對外賣高併發場景，合併分散的調用接口，降低各服務系統間訪問頻次，防止一次調用鏈中對依賴服務的請求次數放大；提升數據獲取性能，優化存儲結構設計（分庫、分表、建索引），採用適當的存儲方式（DB、分佈式緩存、文件索引、本地內存等）；將部分請求處理異步化，非實時處理離線化等。
對於如何避免過度依賴擴容，大的方面還是從系統的性能優化入手，當機器資源達到服務瓶頸的時候，需要深入分析具體瓶頸點在哪裏，是存儲、CPU、帶寬還是其他的原因。然後針對具體的點，再考慮是否必須擴容。在外賣定期進行的全鏈路壓測場景中，我們會根據壓測的數據，結合各服務的 SLA 要求，來評估各服務的處理能力，再結合未來業務的增長趨勢，做較長期的容量擴容規劃。
系統架構拆分原則
架構的拆分需要匹配業務規模的發展程度，並具備一定的超前性。過早的拆分會造成不必要的資源浪費，而過晚的拆分，則又會累積現有系統的風險，增加拆分業務的梳理難度。
在外賣的技術發展過程中，由於外賣早期的業務爆發太快，相對技術資源儲備不足，拆分的時機是落後於業務發展的，所以早期也出現過很多的線上事故。後來我們通過快速的系統架構拆分與調整，逐步完善起外賣的後端體系架構，減少了線上事故的發生。總結起來，我們針對系統架構的拆分遵循以下三個原則：
流量拆分原則
外賣服務流量按類型，我們可以簡單的分爲 To C 流量和 To B 流量，也就是面向外賣用戶和麪向商家、運營的流量。針對不同流量的服務系統會拆分，典型的比如：針對商家或 BD 運營的門店管理、商品管理、營銷活動配置管理等，就會和線上的門店、商品、營銷等服務分開。除了服務系統上，存儲 DB 上也會拆分，中間我們會採用一些實時的數據同步機制，保證數據的一致性。
另外一個維度的流量拆分是按照同步與異步的請求分類。 就是從用戶流量的發起方來看，在請求的處理鏈條中，那些可以異步處理的邏輯服務，會從實時鏈路處理系統中分拆。比如我們的用戶提單系統、與商家接單處理系統、發配送系統等之間都是異步拆分的。
功能閉合原則
在軟件設計領域有一個著名的康威（Conway）定律，其中提到組織架構與軟件架構相互影響的辯證關係。我們在按照業務功能垂直拆分的過程中，也會有同樣的考慮，儘量在一個組織架構中，將功能性業務系統閉合，減少跨團隊之間的溝通成本，提升產品開發迭代效率。比如我們的的搜索服務、推薦服務、訂單交易服務、UGC 服務、營銷服務、門店商品服務等等。
平臺服務原則
對不同業務系統公用邏輯或服務的抽取，形成基礎性中間件平臺，服務於多個業務系統，從而降低維護與開發的成本。
比如我們的數據算法工程平臺，我們發現在很多的業務系統中，都會有些算法策略迭代，它們都需要線上特徵數據、策略 A/B 實驗、效果分析、工程系統支撐等。所以我們將此抽取成一個公共的工程平臺，算法只需要提供策略邏輯代碼，上傳到平臺上，平臺提供針對業務系統對接的標準化服務接口、特徵的統一管理服務、算法的版本管理、A/B 實驗、以及效果分析等等。這樣的業務中間平臺，可以很好的提升了各業務系統的開發效率。
如何梳理核心鏈路思路
作爲線上即時 O2O 電商業務，外賣業務核心是爲用戶提供訂單交易履約，因此我們的核心鏈路是根據訂單交易的業務場景來梳理的。主要包括門店瀏覽、商品選購、交易支付、訂單配送環節，這四大業務環節強依賴的服務接口組合起來的鏈路，就是核心鏈路。而不在此關鍵鏈路中的服務或非強依賴服務鏈路，我們將此歸集爲非核心鏈路。
對於如何合理地對業務鏈路進行分級，需要看業務規模的發展階段，早期可以只劃分核心鏈路和非核心鏈路兩級即可，後期可以再針對非核心鏈路，進一步向下劃分，用以確定更細粒度的降級容錯控制。
比如我們在外賣入口 API 層，調度外賣紅包服務的鏈路中，會按照紅包的使用、紅包的瀏覽、紅包的獲取等進行進一步的分級，當紅包的系統壓力過大時，按照核心與非核心鏈路的分級方式，我們就只能直接降級紅包系統服務了，這樣對整個下單交易不會有太大問題，但不能使用紅包，會影響用戶的下單體驗。所以按照進一步的鏈路梳理降級，我們會優先保證紅包的使用接口服務，而降級其他的紅包調用鏈路。
當然，如果針對非核心鏈路分級太細，也會同時帶來服務維護成本的提升，這塊需要針對業務做相應的平衡。
人工智能探索
美團外賣自成立以來，就開始做一些 AI 方面的研究和嘗試。比如：
OCR 方面，針對商家的證件照識別、營業執照識別等，這塊的識別召回達到了 85% 以上，準確率我們達到 99% 以上；
機器人 方面，我們在和業界的一些智能音箱和家庭服務類機器人公司對接外賣服務，通過語音對話交流的方式，完成整個外賣訂單的交易；
用戶 方面，我們不久前上線了外賣智能助手服務，目前大家可以在微信錢包的美團外賣入口看到，也有部分 App 灰度用戶可以看到。通過與智能助手小袋對話，她可以幫你快速的完成商家、商品的自動選擇和推薦，體驗還不錯，大家可以去試試；
騎手配送 方面，美團外賣也在積極開發配送機器人，前不久剛剛發佈了一個測試版本，大家可以在網絡上搜到。
總之，正如王興之前在“中國發展高層論壇 2018 年會”中說的，美團將會在科技創新、人工智能方面積極發展，普惠所有大衆。外賣作爲一個重要的連接線上線下的服務體，也會不斷在 AI 方面做更多的嘗試。
外賣的業務目標是能夠在幾年內達到每天上億次的用戶服務，那麼針對外賣後端架構的發展，我想後續會更多的關注在多品類支撐的平臺化改造方面，以及在越來越複雜的系統關係調度與智能化運維方向，