美團即時物流的分散式系統架構設計

摘要： 本文根據美團資深技術專家宋斌在ArchSummit架構師峰會上的演講整理而成。 背景 美團外賣已經發展了五年，即時物流探索也經歷了3年多的時間，業務從零孵化到初具規模，在整個過程中積累了一些分散式高併發系統的建設經驗。最主要的收穫包括兩點： 即時物流業務對故障和高延遲的容...

本文根據美團資深技術專家宋斌在ArchSummit架構師峰會上的演講整理而成。

背景

美團外賣已經發展了五年，即時物流探索也經歷了3年多的時間，業務從零孵化到初具規模，在整個過程中積累了一些分散式高併發系統的建設經驗。最主要的收穫包括兩點：

1. 即時物流業務對故障和高延遲的容忍度極低，在業務複雜度提升的同時也要求系統具備分散式、可擴充套件、可容災的能力。即時物流系統階段性的逐步實施分散式系統的架構升級，最終解決了系統宕機的風險。

2. 圍繞成本、效率、體驗核心三要素，即時物流體系大量結合AI技術，從定價、ETA、排程、運力規劃、運力干預、補貼、核算、語音互動、LBS挖掘、業務運維、指標監控等方面，業務突破結合架構升級，達到促規模、保體驗、降成本的效果。

本文主要介紹在美團即時物流分散式系統架構逐層演變的進展中，遇到的技術障礙和挑戰：

• 訂單、騎手規模大，供需匹配過程的超大規模計算問題。
• 遇到節假日或者惡劣天氣，訂單聚集效應，流量高峰是平常的十幾倍。
• 物流履約是線上連線線下的關鍵環節，故障容忍度極低，不能宕機，不能丟單，可用性要求極高。
• 資料實時性、準確性要求高，對延遲、異常非常敏感。

美團即時物流架構

美團即時物流配送平臺主要圍繞三件事展開：一是面向使用者提供履約的SLA，包括計算送達時間ETA、配送費定價等；二是在多目標（成本、效率、體驗）優化的背景下，匹配最合適的騎手；三是提供騎手完整履約過程中的輔助決策，包括智慧語音、路徑推薦、到店提醒等。

在一系列服務背後，是美團強大的技術體系的支援，並由此沉澱出的配送業務架構體系，基於架構構建的平臺、演算法、系統和服務。龐大的物流系統背後離不開分散式系統架構的支撐，而且這個架構更要保證高可用和高併發。

分散式架構，是相對於集中式架構而言的一種架構體系。分散式架構適用CAP理論（Consistency 一致性，Availability 可用性，Partition Tolerance 分割槽容忍性）。在分散式架構中，一個服務部署在多個對等節點中，節點之間通過網路進行通訊，多個節點共同組成服務叢集來提供高可用、一致性的服務。

早期，美團按照業務領域劃分成多個垂直服務架構；隨著業務的發展，從可用性的角度考慮做了分層服務架構。後來，業務發展越發複雜，從運維、質量等多個角度考量後，逐步演進到微服務架構。這裡主要遵循了兩個原則：不宜過早的進入到微服務架構的設計中，好的架構是演進出來的不是提前設計出來的。

分散式系統實踐

上圖是比較典型的美團技術體系下的分散式系統結構：依託了美團公共元件和服務，完成了分割槽擴容、容災和監控的能力。前端流量會通過HLB來分發和負載均衡；在分割槽內，服務與服務會通過OCTO進行通訊，提供服務註冊、自動發現、負載均衡、容錯、灰度釋出等等服務。當然也可以通過訊息佇列進行通訊，例如Kafka、RabbitMQ。在儲存層使用Zebra來訪問分散式資料庫進行讀寫操作。利用CAT（美團開源的分散式監控系統）進行分散式業務及系統日誌的採集、上報和監控。分散式快取使用Squirrel+Cellar的組合。分散式任務排程則是通過Crane。

在實踐過程還要解決幾個問題，比較典型的是叢集的擴充套件性，有狀態的叢集可擴充套件性相對較差，無法快速擴容機器，無法緩解流量壓力。同時，也會出現節點熱點的問題，包括資源不均勻、CPU使用不均勻等等。

首先，配送後臺技術團隊通過架構升級，將有狀態節點變成無狀態節點，通過平行計算的能力，讓小的業務節點去分擔計算壓力，以此實現快速擴容。

第二是要解決一致性的問題，對於既要寫DB也要寫快取的場景，業務寫快取無法保障資料一致性，美團內部主要通過Databus來解決，Databus是一個高可用、低延時、高併發、保證資料一致性的資料庫變更實時傳輸系統。通過Databus上游可以監控業務Binlog變更，通過管道將變更資訊傳遞給ES和其他DB，或者是其他KV系統，利用Databus的高可用特性來保證資料最終是可以同步到其他系統中。

第三是我們一直在花精力解決的事情，就是保障叢集高可用，主要從三個方面來入手，事前較多的是做全鏈路壓測評，估峰值容量；週期性的叢集健康性檢查；隨機故障演練（服務、機器、元件）。事中做異常報警（效能、業務指標、可用性）；快速的故障定位（單機故障、叢集故障、IDC故障、元件異常、服務異常）；故障前後的系統變更收集。事後重點做系統回滾；擴容、限流、熔斷、降級；核武器兜底。

單IDC的快速部署&容災

單IDC故障之後，入口服務做到故障識別，自動流量切換；單IDC的快速擴容，資料提前同步，服務提前部署，Ready之後開啟入口流量；要求所有做資料同步、流量分發的服務，都具備自動故障檢測、故障服務自動摘除；按照IDC為單位擴縮容的能力。

多中心嘗試

美團IDC以分割槽為單位，存在資源滿排，分割槽無法擴容。美團的方案是多個IDC組成虛擬中心，以中心為分割槽的單位；服務無差別的部署在中心內；中心容量不夠，直接增加新的IDC來擴容容量。

單元化嘗試

相比多中心來說，單元化是進行分割槽容災和擴容的更優方案。關於流量路由，美團主要是根據業務特點，採用區域或城市進行路由。資料同步上，異地會出現延遲狀況。SET容災上要保證同本地或異地SET出現問題時，可以快速把SET切換到其他SET上來承擔流量。

智慧物流的核心技術能力和平臺沉澱

機器學習平臺，是一站式線下到線上的模型訓練和演算法應用平臺。之所以構建這個平臺，目的是要解決演算法應用場景多，重複造輪子的矛盾問題，以及線上、線下資料質量不一致。如果流程不明確不連貫，會出現迭代效率低，特徵、模型的應用上線部署出現數據質量等障礙問題。

JARVIS是一個以穩定性保障為目標的智慧化業務運維AIOps平臺。主要用於處理系統故障時報警源很多，會有大量的重複報警，有效資訊很容易被淹沒等各種問題。此外，過往小規模分散式叢集的運維故障主要靠人和經驗來分析和定位，效率低下，處理速度慢，每次故障處理得到的預期不穩定，在有效性和及時性方面無法保證。所以需要AIOps平臺來解決這些問題。

未來的挑戰

經過覆盤和Review之後，我們發現未來的挑戰很大，微服務不再“微”了，業務複雜度提升之後，服務就會變得膨脹。其次，網狀結構的服務叢集，任何輕微的延遲，都可能導致的網路放大效應。另外複雜的服務拓撲，如何做到故障的快速定位和處理，這也是AIOps需要重點解決的難題。最後，就是單元化之後，從叢集為單位的運維到以單元為單位的運維，業給美團業務部署能力帶來很大的挑戰。

作者簡介

宋斌，美團資深技術專家，長期參與分散式系統架構、高併發系統穩定性保障相關工作。目前擔任即時物流團隊後臺技術負責人。2013年加入美團，參與過美團外賣C端、即時物流體系從零搭建。現在帶領團隊負責排程、清結算、LBS、定價等業務系統、演算法資料平臺、穩定性保障平臺等技術平臺的研發和運維。最近重點關注AIOps方向，探索在高併發、分散式系統架構下，如何更好的做好系統穩定性保障。

招聘資訊

美團配送技術團隊誠招LBS領域、排程履約平臺、結算平臺、AIOps方向、機器學習平臺、演算法工程方向的資深技術專家和架構師。共建全行業最大的單一即時配送網路和平臺，共同面對複雜業務和高併發流量的挑戰，迎接配送業務全面智慧化的時代。歡迎感興趣的同學投送簡歷至 [email protected]，[email protected]。