技術架構分享：美團配送系統架構演進實踐

美團配送自成立以來，業務經歷了多次跨越式的發展。業務的飛速增長，對系統的整體架構和基礎設施提出了越來越高的要求，同時也不斷驅動著技術團隊深刻理解業務、準確定位領域模型、高效支撐系統擴充套件。如何在業務高速增長、可用性越來越高的背景下實現系統架構的快速有效升級？如何保證複雜業務下的研發效率與質量？本文將為大家介紹美團配送的一些思考與實踐。

配送業務

從物流到同城即時配送

物流行業的發展離不開商業的發展，近些年，商業的變革為物流發展創造了新的機會。電商的興起有效帶動了快遞行業的飛速發展，直接造就了順豐、四通一達這樣的快遞公司。而近年來O2O商業模式的興起，尤其是外賣、生鮮等到家場景的發展促進了同城即時配送的快速發展。

與物流領域下的其他分支不同，同城即時配送具有如下特點:

• 時效快：美團外賣平均送達時間28min。

• 距離短：配送距離多數為3~5km範圍，較大的擴充套件到同城範圍。

• 隨機性強：取貨點、交付點具有時間與空間的隨機性，預測與規劃難度相對較高。

同城即時配送業務的發展契機

行業的流程再造一般離不開兩個因素：

• 內因：技術或基礎設施取得重大突破

• 外因：使用者消費升級或市場發生重大變化

技術方面，AI與大資料的應用逐步普及，基於人工智慧可以對配送難度、ETA、騎手能力精確評估。GPS的快速發展與GIS廠商能力的不斷開放，使得基於LBS的應用大大降低了開發成本。基礎設施方面，得益於國家的持續投入，行動網路的質量不斷提升，成本逐年下降，也間接促使智慧手機幾乎實現了全民覆蓋。

市場方面，由於中國人口具有超大規模性的特點，人群聚集度高，外賣等到家場景在各大城市尤其是一線城市的需求持續增強。使用者對於外賣的安全、時效、配送員的服裝、禮貌用語等都有更高的要求。

在這兩個因素的共同作用下，促成了同城即時配送行業的發展。而對於同城即時配送業務而言，履約能力與運營效率是研發團隊要重點解決的兩個問題：

1. 履約能力保證：實現平臺對運單排程的實時把控，具備供需調控能力。

2. 運營效率提升：加強對配送騎手的管控能力，提升配送全業務的運營效率，持續降低成本。

技術挑戰

美團配送系統的本質——機器與海量騎手協作，服務於全國使用者和商家的大規模協作系統。技術的挑戰本質上源於業務的痛點，具體體現為線上的強履約能力要求與線下的強運營能力要求。技術上的挑戰也同樣來源於線上和線下兩個方面：

• 線上履約的SLA要求更高。配送業務需要兼顧使用者、商家、騎手三端利益，任何一次當機的影響都可能是災難性的。如果體驗不好，使用者會說，為什麼我付了錢，卻還餓肚子？商家會說，這是因為出了餐沒人取；但是對騎手來說，會覺得自己付出了時間與勞動，卻沒有獲得足夠的收益。

• 線下的業務複雜性更高。多條業務線管理模式不同，對於如何兼顧系統在共性和差異化上有很大挑戰。

美團配送系統架構的演進過程可以分為三個階段：

1. MVP階段：業務模式探索，快速試錯，如何具備快速迭代能力。

2. 規模化階段：業務成指數級增長，如何既保證業務發展，又解決系統可用性、擴充套件性、研發效率等問題。

3. 精細化階段：業務模式逐步成熟，運營逐步精細化，如何透過產品技術創新驅動業務發展。

MVP階段

試錯階段，需要快速探索業務模式到底是不是一個方向，這個階段不要期望很多事情都想得很清楚，使用者和市場會快速反饋結果。所以，對於技術團隊而言，這個階段最主要的能力是快。搶奪市場，唯快不破。

從系統架構角度，MVP階段只需要做粗粒拆解，我們按照人、財、物三大領域將系統做了初步服務劃分，以保證後續的業務領域都可以從這三個主領域中分離、繼承。

順便提一下當時團隊的組織形式，研發團隊按專案制組織，大家共同維護一套系統。當時團隊中無QA崗位，由PM、RD共同保證開發質量，一天釋出二十幾次是常態。

進入這個階段，業務和產品已經得到了市場的初步驗證，的確找到了正確的方向。同時，業務發展增速也對研發團隊的能力提出了更高的要求，因為這個階段會有大量緊急且重要的事情湧現，且系統可用性、擴充套件性方面的問題會逐步凸顯，如果處理不當，就會導致系統故障頻發、研發效率低下等問題，使研發疲於奔命。

這個階段從架構層面我們重點在思考三個方面的問題：

• 整體架構應該如何演化？履約系統與運營系統的邊界在哪裡？

• 履約系統的可用性如何保證？系統容量如何規劃？

• 運營系統如何解決業務的真正痛點？如何在大量“瑣碎需求”下提升研發效率？

解決以上問題的整體思路為化繁為簡（理清邏輯關係）、分而治之（專業的人做專業的事）、逐步演進（考慮ROI）。

整體架構設計

在整體架構上，我們將配送系統拆解為履約系統、運營系統和主資料平臺。

履約系統（圖右上側）的設計上，首先按照使用者側與騎手側做了初步劃分，這樣拆分兼顧了雙端角色和排程流程的統一。例如：使用者側更關注發單的成功率與訂單狀態的一致性，騎手側則更關注派單效果、推單成功率等，整體上解耦了發單、支付、排程等模組。

運營系統（圖左上側）方面，需求長期多而雜，架構設計上需要先想清楚配送的運營系統應該管什麼、不應該管什麼。在長期的專案開發中，我們從業務戰略與組織架構出發，在明確業務戰略目標和階段策略下，梳理每個業務團隊/崗位的核心職責、考核目標、組織之間的協作流程，最終整理出現階段配送運營管理的中心為四個領域：

• 經營規劃：如何科學地定義目標，並保證目標能夠有效達成。

• 業務管理：如何提升每一個業務管理過程的效率與質量。

• 騎手運營：騎手是核心資源，一個城市需要多少騎手、騎手分級是否科學、如何調控需要系統性方案。

• 結算平臺：提高錢的效能，是能否做到成本領先的關鍵。如何把錢用得對、用得準需要長期思考。

除了履約、運營兩個系統的架構設計外，架構設計層面還有一個非常關鍵的問題，即履約、運營系統的邊界與職責如何劃分的問題。個人理解這個問題可能是O2O類業務在規模化階段最關鍵的架構設計問題，如果不能有效解決將為系統的可用性、擴充套件性埋下巨大隱患。履約、運營兩個方向的業務需求和技術職責有較大差異，且多數資料的生產都在運營系統，最核心最關鍵的應用在履約系統。雖然各自的領域職責是清晰的，但對於具體的需求邊界上不見得簡單明瞭。對此，我們借鑑了MDM思路，提出了主資料平臺（圖下側）的概念，重點解決履約系統與運營系統的合作與邊界問題。

主資料平臺

主資料是企業資訊系統中最基礎的業務單位資料，對於配送而言是組織、崗位、人員、商家、使用者、城市等資料。與之對應的是業務資料，例如：訂單、考勤、薪資等。主資料有兩個最關鍵的特徵：

1. 基礎性：業務資料生長在主資料的維度上，例如：訂單資料是使用者、商家兩個主資料實體下的交易資料

2. 共享性：各類系統都強依賴於主資料，主資料的變化上游各業務系統需要感知與聯動

主資料管理並非一蹴而就，是伴隨業務發展逐步迭代的。早期系統較簡單，上游系統直接從DB中讀取資料並應用。這種方案在系統逐步複雜之後，容易出現多個團隊開發互相影響，不利於系統擴充套件，並且在可用性上有很大風險。為此我們專門成立的主資料的團隊，獨立拆分了主資料服務，並把所有對於資料的訪問收回到服務上。在此基礎上，經過不斷的迭代和演進，最終我們吸收了CQRS（Command Query Responsibility Segregation）和MDM（Master Data Management）的思想，將整個主資料平臺逐步劃分成四個部分：

• 生產系統：負責對資料生產的建模，隔離資料生產對核心模型的影響。例如：騎手入職、組織拆分流程等。

• 核心模型：挖掘資料實體關係，提升模型能力。例如：一人多崗、雙線彙報等。

• 運力中心：面向履約系統的應用場景支援，將騎手諸多屬性抽象為運力模型，並對可用性、吞吐能力著重建設。

• 管理中心：面向運營系統提供標準化框架，提供資訊檢索、流程審批、許可權控制等場景的統一解決方案。

系統可用性

業務的快速增長對系統的可用性提出越來越高的要求，在方法論層面，我們按照事故發生的時間序列（事前、事中、事後）提出了四大能力建設，即：預防能力、診斷能力、解決能力、規避能力。同時，在具體工作上，我們劃分為流程和系統兩個方面。

可用性建設是一個長期專案。考慮到ROI，起步階段重點完成事前的流程建設，即上線規範等一系列線上操作流程，這個工作在早期能夠規避80%的線上故障。在流程規範跑通並證實有效之後，再逐步透過系統建設提升人效。

容災能力

容災能力建設上，首先思考的問題是系統最大的風險點是什麼。從管理的角度來看，職責的“灰色地帶”通常是系統質量容易出現風險的地方。因此，早期最先做的容災處理是核心依賴、第三方依賴的降級，優先保證一旦依賴的服務、中介軟體出現問題，系統自身具備最基本的降級能力。

第二階段我們提出了端到端的容災能力。首先，我們建設了業務大盤，定義了實時監控核心業務指標（單量、線上騎手數等），透過這些指標能夠快速判斷系統是不是出了問題。其次，我們在核心指標上擴充套件了關鍵維度（城市、App版本、運營商等），以快速評估問題有多大影響。最後，我們透過Trace系統，將服務間的呼叫關係與鏈路級成功率視覺化展現，具備了快速定位問題的根因在哪的能力。

第三階段，我們期望將容災預案整合到系統中，基於各類事故場景打造定製化、一體化的容災工具，這樣可以進一步縮短故障的響應、處理時間以及研發學習成本。例如，為了進一步提升配送系統的SLA，我們在端到端的容災能力上深度最佳化，重點解決了騎手弱網、無網的情況下的端到端互動問題。中國某些地區人群非常密集但移動運營商網路質量較差，會導致騎手到了這個區域後操作App延遲較大甚至無法操作，這對騎手的正常工作有非常大的影響。因此，我們在行動網路鏈路層面不斷加強長連線、多路互備的能力，並將網路的診斷、處理、驗證工具一體化，使騎手App的端到端到達率有了進一步的提升。

系統容量

對於一個規模快速增長的業務，系統的容量規劃是一個長期命題。容量規劃的關鍵點是評估與擴容。

評估方面，在業務發展早期我們一個架構師就能夠完全掌控整個系統，採用靜態評估的方式基本可以衡量系統容量。隨著系統複雜度逐漸提升，我們逐步引入了Trace、中介軟體容量監控等工具輔助評估容量，由架構師團隊定義容量評估主框架，由各團隊細化評估每個子系統的容量。當業務已經變得非常複雜時，沒有任何一個人或團隊能夠保證精確完成容量評估，這時我們啟動了場景壓測、引流壓測、全鏈路壓測等專案，透過 流量標記 + 影子表 + 流量偏移 + 場景回放 等手段，實現了透過線上流量按比例回放壓測的能力，透過系統報告精確評估容量與瓶頸點。

擴容方面，我們分階段依次實施了冗餘備份（主從分離）、垂直拆分（拆分核心屬性與非核心屬性）、水平拆分（分庫分表）、自動歸檔。

運營系統迭代效率

運營系統涉及一個業務運營管理的方方面面，我們在業務領域上除了明確目標、過程、運力、資金四個領域外，打造了一套運營系統整合解決方案集合。研發透過持續投入精力在平臺化服務或元件的長期建設上，使每個垂直的運營系統擴充套件性得到保證，從而不斷提升研發效率。以工作流場景為例，透過動態表單 + 流程平臺的方式，統一各類業務流、審批流的工程實現，各類管理動作的效率與質量可量化，找到流程阻塞節點，自動化部分流程環節，透過技術手段不斷降低人工成本。

精細化階段

業務發展不斷成熟之後，業務的各類運營管理動作會趨於精細化。這個階段，業務對於產品技術有更高要求，期望透過產品技術創新不斷打造技術壁壘，保持領先優勢。配送的業務特點天然對AI應用有很強的需求，大到供給調整，小到資源配置，都是AI發揮效力的主戰場。對於工程層面，需要持續思考的問題是如何更好地實現AI的業務應用。為此我們重點提升了幾方面的能力：

• 降低試錯成本：構建模擬平臺，打造演算法的“沙箱環境”，線上下環境快速評估演算法效果。

• 提升演算法特徵迭代效率：構建特徵平臺，統一演算法策略迭代框架與特徵資料生產框架，提升特徵資料質量。

• 提升導航資料質量：持續深耕LBS平臺，提升基礎資料質量，提供位置、導航、空間的應用能力。

模擬平臺的核心是打造“沙箱環境”，配送的服務業屬性要求使用者、商家、騎手深度參與服務過程，因此演算法的線上試錯成本極高。對於模擬平臺的建設上，我們刪減掉排程系統的細枝末節，粗粒度的構建了一套微型排程系統，並透過發單回放、使用者、商家、騎手實體建模、騎手行為模擬等方法模擬線上場景。每次模擬會產出演算法的KPI報告，實現演算法效果的離線預估。

演算法資料平臺

演算法策略的效果，主要依賴於演算法模型和特徵資料的質量。為此我們圍繞模型和特徵，打造了一站式演算法資料平臺，提供從資料清洗、特徵提取，模型訓練、線上預測到演算法效果評估的全方位資料閉環解決方案，為機器學習和深度學習演算法模型在配送各個業務線落地提供支撐。

LBS平臺

LBS平臺早在配送業務的起步階段就開始實施，隨著演算法場景的不斷髮展，LBS不斷深化點線面空間能力，為配送排程、時間預估、定價等業務場景提供支撐，打造了任務地圖、路徑規劃、語音導航、熱力圖等產品。

結語

美團配送系統架構的演進過程，架構師團隊長期關注技術驅動業務、明確領域職責與邊界等關鍵問題，同時架構的演進過程也是不斷考慮ROI的權衡取捨過程。技術的持續發展不斷提升體驗、規模，降低運營成本，而架構在裡面解決的問題是化繁為簡，將複雜問題拆解為簡單的問題並透過領域專家逐級各個擊破。隨著規模的持續增長，業務的持續創新會給系統架構提出越來越高的挑戰，系統架構設計將是我們長期研究的一個課題。

作者簡介

永俊，美團資深技術專家，配送業務系統團隊負責人。長期從事配送系統質量保證、運營體系建設、系統架構升級等方向。