美團配送系統架構演進實踐

寫在前面

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

配送業務

從物流到同城即時配送

物流行業的發展離不開商業的發展，近些年，商業的變革爲物流發展創造了新的機會。電商的興起有效帶動了快遞行業的飛速發展，直接造就了順豐、四通一達這樣的快遞公司。而近年來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的權衡取捨過程。技術的持續發展不斷提高體驗、規模，下降運營成本，而架構在裏面解決的問題是化繁爲簡，將複雜問題拆解爲簡單的問題並經過領域專家逐級各個擊破。隨着規模的持續增加，業務的持續創新會給系統架構提出愈來愈高的挑戰，系統架構設計將是咱們長期研究的一個課題。

做者簡介

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

招聘

本文爲美團配送技術團隊的集體智慧結晶，感謝團隊每一名成員的努力付出。若是你對業務分析、領域模型感興趣，歡迎聯繫yinyongjun@meituan.com。