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