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

 

 

 

 

背景

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

即時物流業務對故障和高延遲的容忍度極低，在業務複雜度提高的同時也要求系統具有分佈式、可擴展、可容災的能力。即時物流系統階段性的逐步實施分佈式系統的架構升級，最終解決了系統宕機的風險。圍繞成本、效率、體驗覈心三要素，即時物流體系大量結合 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 須要重點解決的難題。最後，就是單元化以後，從集羣爲單位的運維到以單元爲單位的運維，也給美團業務部署能力帶來很大的挑戰。

Java高級架構師大綱圖

 

 

 

 

 

 

 

 

 

 

 

 

 

若是想提高本身的，看看上圖大綱能知道你如今還處於什麼階段要向那些方面發展？

同時小編已將上圖知識大綱裏面的內容打包好了......

怎麼領取呢？

要求：

轉發 ！轉發 ！以後關注我，後臺私信回覆關鍵詞：「666」便可領取