本文是美團永俊老師的分享。
寫在前面
美團配送自成立以來，業務經歷了多次跨越式的發展。業務的飛速增長，對系統的整體架構和基礎設施提出了越來越高的要求，同時也不斷驅動着技術團隊深刻理解業務、準確定位領域模型、高效支撐系統擴展。如何在業務高速增長、可用性越來越高的背景下實現系統架構的快速有效升級？如何保證複雜業務下的研發效率與質量？本文將爲大家介紹美團配送的一些思考與實踐。
配送業務
從物流到同城即時配送
物流行業的發展離不開商業的發展，近些年，商業的變革爲物流發展創造了新的機會。電商的興起有效帶動了快遞行業的飛速發展，直接造就了順豐、四通一達這樣的快遞公司。而近年來O2O商業模式的興起，尤其是外賣、生鮮等到家場景的發展促進了同城即時配送的快速發展。
與物流領域下的其他分支不同，同城即時配送具有如下特點:
-
時效快：美團外賣平均送達時間28min。
-
距離短：配送距離多數爲3~5km範圍，較大的擴展到同城範圍。
-
隨機性強：取貨點、交付點具有時間與空間的隨機性，預測與規劃難度相對較高。
同城即時配送業務的發展契機
行業的流程再造一般離不開兩個因素：
-
內因：技術或基礎設施取得重大突破
-
外因：用戶消費升級或市場發生重大變化
技術方面，AI與大數據的應用逐步普及，基於人工智能可以對配送難度、ETA、騎手能力精確評估。GPS的快速發展與GIS廠商能力的不斷開放，使得基於LBS的應用大大降低了開發成本。基礎設施方面，得益於國家的持續投入，移動網絡的質量不斷提升，成本逐年下降，也間接促使智能手機幾乎實現了全民覆蓋。
市場方面，由於中國人口具有超大規模性的特點，人羣聚集度高，外賣等到家場景在各大城市尤其是一線城市的需求持續增強。用戶對於外賣的安全、時效、配送員的服裝、禮貌用語等都有更高的要求。
在這兩個因素的共同作用下，促成了同城即時配送行業的發展。而對於同城即時配送業務而言，履約能力與運營效率是研發團隊要重點解決的兩個問題：
-
履約能力保證：實現平臺對運單調度的實時把控，具備供需調控能力。
-
運營效率提升：加強對配送騎手的管控能力，提升配送全業務的運營效率，持續降低成本。
技術挑戰
美團配送系統的本質——機器與海量騎手協作，服務於全國用戶和商家的大規模協作系統。技術的挑戰本質上源於業務的痛點，具體體現爲線上的強履約能力要求與線下的強運營能力要求。技術上的挑戰也同樣來源於線上和線下兩個方面：
-
線上履約的SLA要求更高。配送業務需要兼顧用戶、商家、騎手三端利益，任何一次宕機的影響都可能是災難性的。如果體驗不好，用戶會說，爲什麼我付了錢，卻還餓肚子？商家會說，這是因爲出了餐沒人取；但是對騎手來說，會覺得自己付出了時間與勞動，卻沒有獲得足夠的收益。
-
線下的業務複雜性更高。多條業務線管理模式不同，對於如何兼顧系統在共性和差異化上有很大挑戰。

系統架構演進
美團配送系統架構的演進過程可以分爲三個階段：
-
MVP階段：業務模式探索，快速試錯，如何具備快速迭代能力。
-
規模化階段：業務成指數級增長，如何既保證業務發展，又解決系統可用性、擴展性、研發效率等問題。
-
精細化階段：業務模式逐步成熟，運營逐步精細化，如何通過產品技術創新驅動業務發展。
MVP階段
試錯階段，需要快速探索業務模式到底是不是一個方向，這個階段不要期望很多事情都想得很清楚，用戶和市場會快速反饋結果。所以，對於技術團隊而言，這個階段最主要的能力是快。搶奪市場，唯快不破。
從系統架構角度，MVP階段只需要做粗粒拆解，我們按照人、財、物三大領域將系統做了初步服務劃分，以保證後續的業務領域都可以從這三個主領域中分離、繼承。
順便提一下當時團隊的組織形式，研發團隊按項目制組織，大家共同維護一套系統。當時團隊中無QA崗位，由PM、RD共同保證開發質量，一天發佈二十幾次是常態。
規模化階段
進入這個階段，業務和產品已經得到了市場的初步驗證，的確找到了正確的方向。同時，業務發展增速也對研發團隊的能力提出了更高的要求，因爲這個階段會有大量緊急且重要的事情湧現，且系統可用性、擴展性方面的問題會逐步凸顯，如果處理不當，就會導致系統故障頻發、研發效率低下等問題，使研發疲於奔命。
這個階段從架構層面我們重點在思考三個方面的問題：
-
整體架構應該如何演化？履約系統與運營系統的邊界在哪裏？
-
履約系統的可用性如何保證？系統容量如何規劃？
-
運營系統如何解決業務的真正痛點？如何在大量“瑣碎需求”下提升研發效率？
解決以上問題的整體思路爲化繁爲簡（理清邏輯關係）、分而治之（專業的人做專業的事）、逐步演進（考慮ROI）。
整體架構設計
在整體架構上，我們將配送系統拆解爲履約系統、運營系統和主數據平臺。
履約系統（圖右上側）的設計上，首先按照用戶側與騎手側做了初步劃分，這樣拆分兼顧了雙端角色和調度流程的統一。例如：用戶側更關注發單的成功率與訂單狀態的一致性，騎手側則更關注派單效果、推單成功率等，整體上解耦了發單、支付、調度等模塊。
運營系統（圖左上側）方面，需求長期多而雜，架構設計上需要先想清楚配送的運營系統應該管什麼、不應該管什麼。在長期的項目開發中，我們從業務戰略與組織架構出發，在明確業務戰略目標和階段策略下，梳理每個業務團隊/崗位的核心職責、考覈目標、組織之間的協作流程，最終整理出現階段配送運營管理的中心爲四個領域：
-
經營規劃：如何科學地定義目標，並保證目標能夠有效達成。
-
業務管理：如何提升每一個業務管理過程的效率與質量。
-
騎手運營：騎手是核心資源，一個城市需要多少騎手、騎手分級是否科學、如何調控需要系統性方案。
-
結算平臺：提高錢的效能，是能否做到成本領先的關鍵。如何把錢用得對、用得準需要長期思考。
除了履約、運營兩個系統的架構設計外，架構設計層面還有一個非常關鍵的問題，即履約、運營系統的邊界與職責如何劃分的問題。個人理解這個問題可能是O2O類業務在規模化階段最關鍵的架構設計問題，如果不能有效解決將爲系統的可用性、擴展性埋下巨大隱患。履約、運營兩個方向的業務需求和技術職責有較大差異，且多數數據的生產都在運營系統，最核心最關鍵的應用在履約系統。雖然各自的領域職責是清晰的，但對於具體的需求邊界上不見得簡單明瞭。對此，我們借鑑了MDM思路，提出了主數據平臺（圖下側）的概念，重點解決履約系統與運營系統的合作與邊界問題。
主數據平臺
主數據是企業信息系統中最基礎的業務單位數據，對於配送而言是組織、崗位、人員、商家、用戶、城市等數據。與之對應的是業務數據，例如：訂單、考勤、薪資等。主數據有兩個最關鍵的特徵：
-
基礎性：業務數據生長在主數據的維度上，例如：訂單數據是用戶、商家兩個主數據實體下的交易數據
-
共享性：各類系統都強依賴於主數據，主數據的變化上游各業務系統需要感知與聯動
主數據管理並非一蹴而就，是伴隨業務發展逐步迭代的。早期系統較簡單，上游系統直接從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的權衡取捨過程。技術的持續發展不斷提升體驗、規模，降低運營成本，而架構在裏面解決的問題是化繁爲簡，將複雜問題拆解爲簡單的問題並通過領域專家逐級各個擊破。隨着規模的持續增長，業務的持續創新會給系統架構提出越來越高的挑戰，系統架構設計將是我們長期研究的一個課題。
=>更多文章請參考：《中國互聯網業務研發體系架構指南》
https://blog.csdn.net/Ture010Love/article/details/104381157
=>更多行業權威架構案例、領域標準及技術趨勢請關注微信公衆號 '軟件真理與光'：
