物流系統的難題
菜鳥的物流系統脫胎於天貓、共享交易，系統之間存在着"打斷腿連着皮"的緊密的聯繫，多年來雙方配合默契，承擔着整個泛電商業務最核心的鏈路。
隨着集團業務的蓬勃發展，線上購物更加深入人心，在每年雙十一訂單峯值紀錄不斷被打破的背後，技術投入和成本也在不斷增加，特別是近幾年，支付的能力提升已經漸漸可以和下單持平，這對物流系統的壓力也越來越大。交易和物流兩者間密不可分的技術臍帶逐步變成了纏繞在菜鳥腳上的鏈條。
雙十一的巨大成本壓力
僅分析2015年雙十一峯值背後的業務數據，其中0點起創建的訂單，在前一個小時完成發貨的訂單僅有幾十萬,相比支付訂單量可以說九牛一毛，可以看出，支撐大流量高併發的訂單創建，並非物流領域自身業務的剛需驅動，而更多的是爲了保障交易-支付-物流鏈路的穩定。
再從業務場景上來看，物流在雙十一是以單據驅動的核心業務，即發貨。發貨對應的是實物的實操業務，需要大量的人力物力投入，這種物理空間上的線下協同能力，具有流量相對平穩，無明顯峯值的特點，整個業務流程複雜、業務執行週期長、參與角色較多。從用戶的核心訴求來說，用戶只關心交易訂單是否成功創建，而物流訂單是否能馬上創建出來，並不是剛需。
因此，如果交易訂單的創建峯值每年持續上漲，物流系統就需要對等部署同樣的機器來保證同步鏈路的順利執行，從物流業務的特點來說，這不是必須的，對一個非剛需的場景，每年投入大量的成本來保證同步鏈路，是非常不明智的，物流系統的架構升級已經刻不容緩。
RocketMQ——菜鳥架構師的選擇
這也是菜鳥的系統架構師王維在 2016 年雙十一前面對的最大挑戰，那一年雙十一的訂單創建峯值要從 15 年的 18 w 漲到 30 w。他要做一次意義重大的升級，讓交易和菜鳥的業務能更清晰的劃清業務模型和鏈路，讓天貓快速激增的系統流量不再讓菜鳥系統追趕，讓菜鳥能專注去完成物流領域內的事情，讓天貓交易能更專注的保障交易鏈路的穩定。
在雙十一訂單峯值的要求下， DB 和 REDIS 顯然不能滿足異步解耦的要求，因此王維將目光鎖定在了 RocketMQ 上，一個在阿里集團內部廣泛使用的分佈式消息中間件。
RocketMQ 在阿里巴巴已經經受了雙十一多年的的洗禮，服務性能已經是世界領先水平，可以支持用戶億級的堆積，同時客戶端也提供完善的 SDK 讓用戶能做到精確的控速消費，在架構解耦和削峯填谷上，有明顯的優勢。
使用 RocketMQ 做異步解耦，物流訂單中心在滿足自身領域業務的前提下，只要保持一個較高水位平穩消化支付的交易訂單流量，無需承受交易支付的高峯，既可以減少大量的人力物力成本投入，可以規避同步依賴時的穩定性風險。兩個系統保持良好的溝通，更加專注做好自己的事。簡單說，如果交易創建的峯值是50w/s, 持續20分鐘，如果物流系統通過 RocketMQ 控制消費速度，比如保證8w/s的消費，那麼也可以在2小時內消費完所有的數據，對用戶來說，整個過程也是無損無感的。
與消息中間件團隊深度合作，充分利用 MQ 削峯填谷的作用後，在 2016 年雙十一前，通過 2 個的月的開發、測試、驗證、灰度等工作後，王維成功推動了菜鳥系統架構從電商高併發向更加貼合物流作業的特點轉型。16 年後，在電商持續攀高的下單峯值背景下(4倍增長)，菜鳥物流系統峯值 QPS 保持不變，節省了大量技術成本，並且爲未來多年的成本降低奠定了基礎。
作者信息：
周禮，花名：不銘，阿里雲智能技術專家 。主要負責阿里雲消息中間件的研發工作，關注分佈式消息服務、雲原生等技術方向。
本文縮略圖：icon by 白小強
Tips：
# 點下“在看”❤️
# 然後，公衆號對話框內發送“Nacos”，試試手氣？????
# 本期獎品是超級受歡迎的《碼出高效》一本 。