爲了30分鐘配送，盒馬工程師都有哪些「神操做」？

阿里妹導讀：提到盒馬鮮生，除了新鮮的大龍蝦之外，你們印象最深的就是快速配送：門店附近3千米範圍內，30分鐘送貨上門。

盒馬是基於規模化和業務複雜度兩個交織，從IT到DT，從原產地到消費者而造成的端到端的平臺，而盒馬配送更是集成IOT、智能化、自動化等到線下做業，同時受不可抗力因素雨雪冰霧、道路交通、小區設施等讓配送系統的穩定性更加雪上加霜，如何保障線下配送做業的穩定性，讓騎手快樂，更讓用戶開心是盒馬配送永恆的話題。

三大規範

整個盒馬技術部對線上/線下做業生產之關注，代碼質量之高、故障處理之嚴，讓咱們工程師在反覆反覆地確定本身的同時又不斷地否認本身，在開發中設計重構系統，在生產之中檢驗系統。通過線上/線下冰與火的歷練，咱們淬鍊出了一套穩定性的方法論，歸納起來就12個字：研發規範、架構規範、穩定性規範。

無規矩，無以成方圓

首先是研發規範，且看下圖：

這個圖管它叫作7層漏斗模型（努力畫出漏斗，畫圖功夫不行，淺色的箭頭表示漏斗），7層是指PRD評審、技術方案評審、TC評審、編碼、測試&代碼Review、灰度發佈、運維。爲何是漏斗模型呢？由於咱們經過這7層通過層層篩選，將阻礙線下流程的重大故障所有在這7層兜住。

PRD評審：咱們有個需求池，全部的需求都先扔到這個池子裏面，每兩週有個運營雙週會，從中篩選出優先級高、緊急程度高的需求開始進行PRD評審（倒排項目除外），全部的PRD評審都有PD組織，從項目或者需求的價值認識上達成一致，在評審的過程當中研發同窗從PRD中尋找名詞進行領域建模和抽象。整個需求和項目須要識別到技術風險，遵循「不被別人搞死、不搞死別人」的原則，識別核心鏈路和非核心鏈路；測試同窗從中識別風險點和測試功能點，爲後面TC評審作好準備。

技術方案評審：PM組織研發、測試和PD總共參與，研發同窗按照事先分配好的研發模塊進行技術串講，同時和PD、甚至電話業務同窗共同達成產品兜底方案和業務兜底方案。人都會犯錯，況且是人寫出來的代碼，咱們要擁抱bug，但更要識別到潛在的風險進行兜底。

TC評審：通常在技術評審完成後的兩天內會進行TC評審，主要功能的覆蓋點、技術方案潛在的坑、非功能角度的業務降級方案、性能的QPSRT、接口的可測性的評估、測試環境、測試數據等，最後給出可靠的上線時間。

編碼：首先遵循集團的編碼規則，而後就是防護性編程，業務系統可能80%的代碼都在考慮異常狀況下如何保證高可用。系統異常、業務異常的處理，上線時門店灰度方案（一個門店出問題，不影響整個盒馬門店），緩存機制、柔性可用、重試機制、事務處理、串並行、打日誌等等。

測試&代碼Review：首先研發完成自測並冒煙經過，正式提測，固然在編碼的過程當中也會進行代碼Review，那時的代碼Review管它叫線上Review，經過Aone的功能提交給相關同窗進行Review；整個測試結束後上線前咱們會彙集到一塊兒進行代碼圍觀Review，這個階段也會完成系統依賴順序、發佈順序、回滾順序，每一個人的位置。

灰度發佈：首先咱們嚴格遵照盒馬研發紅線，按照發布窗口進行發佈，同時爲了將風險降到最低，針對不一樣的業務作不一樣的發佈時間點，好比O2O場景下午2點準時發佈，B2C場景晚上8點半準時點火；針對不一樣的門店進行灰度，發佈完成後就立馬經過SLS查看原始錯誤日誌，A3查看錯誤統計日誌，EagleEye查看QPS/RT，CloudDBA查看DB性能/慢SQL等全面盯屏30分鐘以上。通常咱們以爲風險比較大的，在發佈時會只發2臺機器，次日觀察沒有任何問題再所有上線，若是有問題就直接上去Kill掉這兩臺機器。

運維：每次發佈後次日早起盯屏是很是關鍵，尤爲是配送涉及不一樣運力商、運力類型等做業的校驗方式不一樣，在早上運力類型豐富是最容易出問題，也最容易發現問題。一旦有問題，誰先第一個發現先問題就會立馬在羣裏釘釘電話全部人，如果跨團隊的會單獨拉小羣電話全部人，對於問題的定位咱們設置專門的同窗，有人看SLS，有人看EagleEye，有人看A3，有人看Xflush，有人看CloudDBA，有人對外發聲安撫騎手，一我的統一指揮，你們分工明確，整個問題處理起來就像一我的。

不把雞蛋放在一個籃子

盒馬配送目前有50+系統，其中核心應用有20+，那麼這麼多系統如何既保穩定又能協做？且看下圖：

項目化：盒馬配送從剛開始按照項目維度構建整個系統，可以知足盒馬用戶的個性化需求，這種在人少的狀況下開發起來很快，也能快速的迭代。

產品化：隨着業務需求愈來愈多，這種開發方式愈來愈拖慢整個項目節奏，尤爲是需求的靈活多變，這個時候產品化的方式隨之而來，咱們在去年5月份的引入了NBF的規則中心、各類Setup，將運營邏輯和業務邏輯區別開來等各類配置化，快速支持需求的變化。

服務化：去年8月份的時候和點我達、鄰趣、蜂鳥等三方進行對接，對接的過程比較痛苦，咱們發現業務邏輯主要是在盒馬場景下，三方的場景須要作一些定製，這個時候咱們開始考慮整個線下做業不變業務規則和基於場景的業務規則，將不變業務規則下沉做爲咱們的後臺，基於場景的業務規則放到咱們的中臺，造成後臺解釋業務概念、業務狀態和業務規則，中臺作統一權限校驗、場景化的業務邏輯、數據網關、整個降級限流能夠上浮到中臺來，完成對各運力商的流控，慢慢孵化出上面的架構規範。這一過程比較痛苦，咱們既要追趕業務，又把34個核心的L0服務梳理業務邏輯、接口參數的合理性、外部依賴等從新升級一遍，新老服務平滑遷移對業務無感，最後註冊到NBF上，經過NBF連接起所需的各域能力去表達業務。

數字化：最底下一層是咱們的用工管理平臺，新零售從企業角度看有兩個核心層面，其一是技術層面「人貨場」的數字化；其二是零售層面的「人貨場」的變革或者革命；用技術驅動零售變革，讓咱們真正能看到整個線下做業流程的好與壞，哪些門店好，哪些門店差，緣由到底在哪裏，如何去優化提供技術依據和支撐，整個數據模型以下圖：

紙上得來終覺淺

任何理論、架構都要不斷接受實踐的檢驗，在錯誤中學習，在錯誤中成長，提出了一套適合線下配送的7路23招打法，以下圖：

第一路：核心和非核心隔離

首先咱們從應用維度進行核心和非核心隔離，核心服務和非核心服務隔離，從數據庫層面咱們作了核心庫和非核心庫隔離，讀寫分離、充分發揮各存儲層的優點，好比核心做業場景咱們採用Mysql，實時聚合分析場景咱們採用ADS，非核心多維度組合查詢場景咱們引入OpenSearch、和離線場景的ODPS，這樣既起到分流的做用，又保護了核心做業場景。如此架構升級，可讓咱們的上嘉同窗進來在一些非核心場景上獨擋一面，充分發揮他們的潛力。

系統交互上咱們採用基於Request/Response模式的HSF水平調用；另一種基於Event-driven模式的消息垂直調用。

對核心服務的依賴上，咱們本着不信任任何外部服務的原則，即便外部服務出問題，咱們依然可以繼續做業，造成以下圖的調用方式：

鏈路開銷大且網絡抖動很容易引發問題，咱們會將其作成一個「航母級」的服務來調用，以下調用：

舉個例子：配送人貨匹配生成笛卡爾積後相似map-reduce進行分佈式計算，經過鷹眼鏈路觀察發現耗時主要在map到reduce的網絡耗時，不在於計算耗時，咱們將將人貨匹配生成矩陣，平衡網絡開銷和分佈式計算，最後將108次調用變爲9次，性能基本提高12倍，以下矩陣：

第二路：及時發現問題是穩定的一半

服務級別-冪等、參數校驗、熔斷、仍是靜態和動態控制超時時間、重試次數來保障服務級別的高可用；

系統級別-流量調度、研發紅線、代碼Reivew文化、重大發布集體上光明頂、流量調度、A3EagleEyeSLSXflush等的QPSRT同比環比的服務監控仍是底層的機器性能監控都能保證在第一時間發現問題。重大發布集體上光明頂是咱們的一個文化，記得在雙12前兩週咱們對整個系統架構進行了一次升級，涉及13個系統又在大促前頂着壓力發佈上線，最終在雙12期間系統總體平穩，較雙11各項指標毛刺減小，特別是雙12哪幾天的雨雪天氣在站內批次積壓嚴重的狀況下，咱們的人貨追加服務較雙11的QPS增長近一倍，但咱們的RT卻下降了50%。

其它招，好比咱們在過年期間天天的專人進行核心系統的例行檢查，確保系統正常運行；在穩定性知識方面，咱們內外結合進行分享，同時將別的team的故障都當作本身的故障來分析緣由和查找咱們系統的不足。

第三路：故障預防

在系統複雜和業務需求不斷致使代碼腐化，咱們定時對整個系統進行重構，將整個重構方案你們達成一致；在今年系統的混部環境對咱們也是一個挑戰，因此咱們引入了超時和重試機制，特別是作到了運行期修改超時時間，防止雪崩，每個新功能上線時都會作故障注入和故障演練，識別潛在風險。

第四路：故障緩解

咱們機器留有一些buffer以防大促、線程池滿等緊急擴容狀況下使用，同時對高QPS有降級預案以防異常狀況緊急止血。仍是前面提到的業務系統必定要有產品和業務兜底方案，好比咱們在和蜂鳥對接時當蜂鳥的系統若是出現問題時，咱們服務端針對此種狀況作了防護性編程，打開開關讓蜂鳥騎手用飛魚app進行做業，減輕對用戶的影響面。在穩定上，咱們不但要本身贏，也要讓合做夥伴贏。

第五路：快速恢復

回滾是系統發佈後出現異常最有效的止血方案，對於弱依賴咱們經過柔性可用性讓它跳過不阻塞繼續往下走，當出現異常case時好比履約和配的狀態不一致咱們經過阿波羅後臺進行一鍵修復，異常緊急訂正預案、Diamond命令下發等來快速恢復。

第六路：快速補償

咱們的系統在設計的都是無狀態扁平化，不存在單點，機器擴容是應對某些異常狀況的快速止血方案。

第七路：發佈治療

在上述路數招數都沒法快速止血的狀況下只能採用發佈治療，咱們有一次忽然機器Load飆高，收到報警後第一反應是機器問題，但又發現部分機器的線程池也快滿了，咱們隨即開始擴容和機器重啓，一部分同窗在快速擴容，一部分同窗在不停的機器重啓，其它同窗在迅速查找問題的根本緣由，最後經過DUMP發現是因爲引用了一個Jar，而這個Jar包裏面使用了Java的正則表達式在解析一個特殊商品名稱的時候進入了死循環，找到緣由後這種狀況只能經過發佈解決，咱們迅速達成一致緊急發佈解決，正是前面一部分同窗的擴容和不停的重啓，從而避免了一場故障。

大海航行靠舵手

盒馬配送的穩定性靠的是業務方、產品、研發、測試、Web端、App端、RF端、GOC、上下游、算法、IOT、NBF、盒馬安全生產、中間件、網絡、氣象臺、雨雪冰霧、道路交通、紅綠燈、小區設施、騎手裝備等等各類因素，每個組成部分都是相當重要。穩定性的探索咱們還在路上，不斷追求極致。

---

本文做者： 三郎

閱讀原文

本文來自雲棲社區合做夥伴「 阿里技術」，如需轉載請聯繫原做者。