《美團配送系統架構演進實踐》讀後感

《美團配送系統架構演進實踐》讀後感

《美團配送系統架構演進實踐》對美團配送面臨的技術挑戰和美團配送系統架構之路進行了詳細的講解。

1、技術挑戰

同城即時配送業務的發展迅速，可是配送系統面臨的技術挑戰也很是大。

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

（1）線上履約的SLA要求更高。配送業務須要兼顧用戶、商家、騎手三端利益，任何一次宕機的影響均可能是災難性的。若是體驗很差，用戶會說，爲何我付了錢，卻還餓肚子？商家會說，這是由於出了餐沒人取；可是對騎手來講，會以爲本身付出了時間與勞動，卻沒有得到足夠的收益。

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

2、系統架構演進

美團配送系統架構的演進過程能夠分爲三個階段：

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

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

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

一、MVP階段

試錯階段，須要快速探索業務模式究竟是不是一個方向，這個階段不要指望不少事情都想得很清楚，用戶和市場會快速反饋結果。因此，對於技術團隊而言，這個階段最主要的能力是快。搶奪市場，惟快不破。

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

順便提一下當時團隊的組織形式，研發團隊按項目制組織，你們共同維護一套系統。當時團隊中無QA崗位，由PM、RD共同保證開發質量，一天發佈二十幾回是常態。

二、規模化階段

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

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

（1）總體架構應該如何演化？履約系統與運營系統的邊界在哪裏？

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

（3）運營系統如何解決業務的真正痛點？如何在大量「瑣碎需求」下提高研發效率？

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

三、精細化階段

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

（1）下降試錯成本：構建仿真平臺，打造算法的「沙箱環境」，在線下環境快速評估算法效果。

（2）提高算法特徵迭代效率：構建特徵平臺，統一算法策略迭代框架與特徵數據生產框架，提高特徵數據質量。

（3）提高導航數據質量：持續深耕LBS平臺，提高基礎數據質量，提供位置、導航、空間的應用能力。

仿真平臺

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

算法數據平臺

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

LBS平臺

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