為了30分鐘配送，盒馬工程師都有哪些“神操作”？

盒馬是基于規(guī)?；蜆I(yè)務(wù)復(fù)雜度兩個(gè)交織，從IT到DT，從原產(chǎn)地到消費(fèi)者而形成的端到端的平臺(tái)，而盒馬配送更是集成IOT、智能化、自動(dòng)化等到線下作業(yè)，同時(shí)受不可抗力因素雨雪冰霧、道路交通、小區(qū)設(shè)施等讓配送系統(tǒng)的穩(wěn)定性更加雪上加霜，如何保障線下配送作業(yè)的穩(wěn)定性，讓騎手快樂，更讓用戶開心是盒馬配送永恒的話題。

三大規(guī)范

整個(gè)盒馬技術(shù)部對(duì)線上/線下作業(yè)生產(chǎn)之關(guān)注，代碼質(zhì)量之高、故障處理之嚴(yán)，讓我們工程師在反復(fù)反復(fù)地肯定自己的同時(shí)又不斷地否定自己，在開發(fā)中設(shè)計(jì)重構(gòu)系統(tǒng)，在生產(chǎn)之中檢驗(yàn)系統(tǒng)。經(jīng)過線上/線下冰與火的歷練，我們淬煉出了一套穩(wěn)定性的方法論，概括起來就12個(gè)字：研發(fā)規(guī)范、架構(gòu)規(guī)范、穩(wěn)定性規(guī)范。

無規(guī)矩，無以成方圓

首先是研發(fā)規(guī)范，且看下圖：

這個(gè)圖管它叫做7層漏斗模型（努力畫出漏斗，畫圖功夫不行，淺色的箭頭表示漏斗），7層是指PRD評(píng)審、技術(shù)方案評(píng)審、TC評(píng)審、編碼、測試&代碼Review、灰度發(fā)布、運(yùn)維。為什么是漏斗模型呢？因?yàn)槲覀兺ㄟ^這7層經(jīng)過層層篩選，將阻礙線下流程的重大故障全部在這7層兜住。

PRD評(píng)審：我們有個(gè)需求池，所有的需求都先扔到這個(gè)池子里面，每兩周有個(gè)運(yùn)營雙周會(huì)，從中篩選出優(yōu)先級(jí)高、緊急程度高的需求開始進(jìn)行PRD評(píng)審（倒排項(xiàng)目除外），所有的PRD評(píng)審都有PD組織，從項(xiàng)目或者需求的價(jià)值認(rèn)識(shí)上達(dá)成一致，在評(píng)審的過程中研發(fā)同學(xué)從PRD中尋找名詞進(jìn)行領(lǐng)域建模和抽象。整個(gè)需求和項(xiàng)目需要識(shí)別到技術(shù)風(fēng)險(xiǎn)，遵循“不被別人搞死、不搞死別人”的原則，識(shí)別核心鏈路和非核心鏈路；測試同學(xué)從中識(shí)別風(fēng)險(xiǎn)點(diǎn)和測試功能點(diǎn)，為后面TC評(píng)審做好準(zhǔn)備。

技術(shù)方案評(píng)審：PM組織研發(fā)、測試和PD總共參與，研發(fā)同學(xué)按照事先分配好的研發(fā)模塊進(jìn)行技術(shù)串講，同時(shí)和PD、甚至電話業(yè)務(wù)同學(xué)共同達(dá)成產(chǎn)品兜底方案和業(yè)務(wù)兜底方案。人都會(huì)犯錯(cuò)，何況是人寫出來的代碼，我們要擁抱bug，但更要識(shí)別到潛在的風(fēng)險(xiǎn)進(jìn)行兜底。

TC評(píng)審：一般在技術(shù)評(píng)審?fù)瓿珊蟮膬商靸?nèi)會(huì)進(jìn)行TC評(píng)審，主要功能的覆蓋點(diǎn)、技術(shù)方案潛在的坑、非功能角度的業(yè)務(wù)降級(jí)方案、性能的QPS\RT、接口的可測性的評(píng)估、測試環(huán)境、測試數(shù)據(jù)等，最后給出可靠的上線時(shí)間。

編碼：首先遵循集團(tuán)的編碼規(guī)則，然后就是防御性編程，業(yè)務(wù)系統(tǒng)可能80%的代碼都在考慮異常情況下如何保證高可用。系統(tǒng)異常、業(yè)務(wù)異常的處理，上線時(shí)門店灰度方案（一個(gè)門店出問題，不影響整個(gè)盒馬門店），緩存機(jī)制、柔性可用、重試機(jī)制、事務(wù)處理、串并行、打日志等等。

測試&代碼Review：首先研發(fā)完成自測并冒煙通過，正式提測，當(dāng)然在編碼的過程中也會(huì)進(jìn)行代碼Review，那時(shí)的代碼Review管它叫線上Review，通過Aone的功能提交給相關(guān)同學(xué)進(jìn)行Review；整個(gè)測試結(jié)束后上線前我們會(huì)聚集到一起進(jìn)行代碼圍觀Review，這個(gè)階段也會(huì)完成系統(tǒng)依賴順序、發(fā)布順序、回滾順序，每個(gè)人的位置。

灰度發(fā)布：首先我們嚴(yán)格遵守盒馬研發(fā)紅線，按照發(fā)布窗口進(jìn)行發(fā)布，同時(shí)為了將風(fēng)險(xiǎn)降到最低，針對(duì)不同的業(yè)務(wù)做不同的發(fā)布時(shí)間點(diǎn)，比如O2O場景下午2點(diǎn)準(zhǔn)時(shí)發(fā)布，B2C場景晚上8點(diǎn)半準(zhǔn)時(shí)點(diǎn)火；針對(duì)不同的門店進(jìn)行灰度，發(fā)布完成后就立馬通過SLS查看原始錯(cuò)誤日志，A3查看錯(cuò)誤統(tǒng)計(jì)日志，EagleEye查看QPS/RT，CloudDBA查看DB性能/慢SQL等全面盯屏30分鐘以上。一般我們覺得風(fēng)險(xiǎn)比較大的，在發(fā)布時(shí)會(huì)只發(fā)2臺(tái)機(jī)器，第二天觀察沒有任何問題再全部上線，如果有問題就直接上去Kill掉這兩臺(tái)機(jī)器。

運(yùn)維：每次發(fā)布后第二天早起盯屏是非常關(guān)鍵，尤其是配送涉及不同運(yùn)力商、運(yùn)力類型等作業(yè)的校驗(yàn)方式不同，在早上運(yùn)力類型豐富是最容易出問題，也最容易發(fā)現(xiàn)問題。一旦有問題，誰先第一個(gè)發(fā)現(xiàn)先問題就會(huì)立馬在群里釘釘電話所有人，若是跨團(tuán)隊(duì)的會(huì)單獨(dú)拉小群電話所有人，對(duì)于問題的定位我們設(shè)置專門的同學(xué)，有人看SLS，有人看EagleEye，有人看A3，有人看Xflush，有人看CloudDBA，有人對(duì)外發(fā)聲安撫騎手，一個(gè)人統(tǒng)一指揮，大家分工明確，整個(gè)問題處理起來就像一個(gè)人。

不把雞蛋放在一個(gè)籃子

盒馬配送目前有50+系統(tǒng)，其中核心應(yīng)用有20+，那么這么多系統(tǒng)如何既保穩(wěn)定又能協(xié)作？且看下圖：

項(xiàng)目化：盒馬配送從剛開始按照項(xiàng)目維度構(gòu)建整個(gè)系統(tǒng)，能夠滿足盒馬用戶的個(gè)性化需求，這種在人少的情況下開發(fā)起來很快，也能快速的迭代。

產(chǎn)品化：隨著業(yè)務(wù)需求越來越多，這種開發(fā)方式越來越拖慢整個(gè)項(xiàng)目節(jié)奏，尤其是需求的靈活多變，這個(gè)時(shí)候產(chǎn)品化的方式隨之而來，我們在去年5月份的引入了NBF的規(guī)則中心、各種Setup，將運(yùn)營邏輯和業(yè)務(wù)邏輯區(qū)別開來等各種配置化，快速支持需求的變化。

服務(wù)化：去年8月份的時(shí)候和點(diǎn)我達(dá)、鄰趣、蜂鳥等三方進(jìn)行對(duì)接，對(duì)接的過程比較痛苦，我們發(fā)現(xiàn)業(yè)務(wù)邏輯主要是在盒馬場景下，三方的場景需要做一些定制，這個(gè)時(shí)候我們開始考慮整個(gè)線下作業(yè)不變業(yè)務(wù)規(guī)則和基于場景的業(yè)務(wù)規(guī)則，將不變業(yè)務(wù)規(guī)則下沉作為我們的后臺(tái)，基于場景的業(yè)務(wù)規(guī)則放到我們的中臺(tái)，形成后臺(tái)解釋業(yè)務(wù)概念、業(yè)務(wù)狀態(tài)和業(yè)務(wù)規(guī)則，中臺(tái)做統(tǒng)一權(quán)限校驗(yàn)、場景化的業(yè)務(wù)邏輯、數(shù)據(jù)網(wǎng)關(guān)、整個(gè)降級(jí)限流可以上浮到中臺(tái)來，完成對(duì)各運(yùn)力商的流控，慢慢孵化出上面的架構(gòu)規(guī)范。這一過程比較痛苦，我們既要追趕業(yè)務(wù)，又把34個(gè)核心的L0服務(wù)梳理業(yè)務(wù)邏輯、接口參數(shù)的合理性、外部依賴等重新升級(jí)一遍，新老服務(wù)平滑遷移對(duì)業(yè)務(wù)無感，最后注冊到NBF上，通過NBF鏈接起所需的各域能力去表達(dá)業(yè)務(wù)。

數(shù)字化：最底下一層是我們的用工管理平臺(tái)，新零售從企業(yè)角度看有兩個(gè)核心層面，其一是技術(shù)層面“人貨場”的數(shù)字化；其二是零售層面的“人貨場”的變革或者革命；用技術(shù)驅(qū)動(dòng)零售變革，讓我們真正能看到整個(gè)線下作業(yè)流程的好與壞，哪些門店好，哪些門店差，原因到底在哪里，如何去優(yōu)化提供技術(shù)依據(jù)和支撐，整個(gè)數(shù)據(jù)模型如下圖：

紙上得來終覺淺

任何理論、架構(gòu)都要不斷接受實(shí)踐的檢驗(yàn)，在錯(cuò)誤中學(xué)習(xí)，在錯(cuò)誤中成長，提出了一套適合線下配送的7路23招打法，如下圖：

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

首先我們從應(yīng)用維度進(jìn)行核心和非核心隔離，核心服務(wù)和非核心服務(wù)隔離，從數(shù)據(jù)庫層面我們做了核心庫和非核心庫隔離，讀寫分離、充分發(fā)揮各存儲(chǔ)層的優(yōu)勢，比如核心作業(yè)場景我們采用Mysql，實(shí)時(shí)聚合分析場景我們采用ADS，非核心多維度組合查詢場景我們引入OpenSearch、和離線場景的ODPS，這樣既起到分流的作用，又保護(hù)了核心作業(yè)場景。如此架構(gòu)升級(jí)，可以讓我們的上嘉同學(xué)進(jìn)來在一些非核心場景上獨(dú)擋一面，充分發(fā)揮他們的潛力。            

系統(tǒng)交互上我們采用基于Request/Response模式的HSF水平調(diào)用；另外一種基于Event-driven模式的消息垂直調(diào)用。

對(duì)核心服務(wù)的依賴上，我們本著不信任任何外部服務(wù)的原則，即使外部服務(wù)出問題，我們依然能夠繼續(xù)作業(yè)，形成如下圖的調(diào)用方式：  

鏈路開銷大且網(wǎng)絡(luò)抖動(dòng)很容易引起問題，我們會(huì)將其做成一個(gè)“航母級(jí)”的服務(wù)來調(diào)用，如下調(diào)用：

舉個(gè)例子：配送人貨匹配生成笛卡爾積后類似map-reduce進(jìn)行分布式計(jì)算，通過鷹眼鏈路觀察發(fā)現(xiàn)耗時(shí)主要在map到reduce的網(wǎng)絡(luò)耗時(shí)，不在于計(jì)算耗時(shí)，我們將將人貨匹配生成矩陣，平衡網(wǎng)絡(luò)開銷和分布式計(jì)算，最后將108次調(diào)用變?yōu)?次，性能基本提升12倍，如下矩陣：

第二路：及時(shí)發(fā)現(xiàn)問題是穩(wěn)定的一半

服務(wù)級(jí)別-冪等、參數(shù)校驗(yàn)、熔斷、還是靜態(tài)和動(dòng)態(tài)控制超時(shí)時(shí)間、重試次數(shù)來保障服務(wù)級(jí)別的高可用；

系統(tǒng)級(jí)別-流量調(diào)度、研發(fā)紅線、代碼Reivew文化、重大發(fā)布集體上光明頂、流量調(diào)度、A3\EagleEye\SLS\Xflush等的QPS\RT同比環(huán)比的服務(wù)監(jiān)控還是底層的機(jī)器性能監(jiān)控都能保證在第一時(shí)間發(fā)現(xiàn)問題。重大發(fā)布集體上光明頂是我們的一個(gè)文化，記得在雙12前兩周我們對(duì)整個(gè)系統(tǒng)架構(gòu)進(jìn)行了一次升級(jí)，涉及13個(gè)系統(tǒng)又在大促前頂著壓力發(fā)布上線，最終在雙12期間系統(tǒng)整體平穩(wěn)，較雙11各項(xiàng)指標(biāo)毛刺減少，特別是雙12哪幾天的雨雪天氣在站內(nèi)批次積壓嚴(yán)重的情況下，我們的人貨追加服務(wù)較雙11的QPS增加近一倍，但我們的RT卻降低了50%。

其它招，比如我們在過年期間每天的專人進(jìn)行核心系統(tǒng)的例行檢查，確保系統(tǒng)正常運(yùn)行；在穩(wěn)定性知識(shí)方面，我們內(nèi)外結(jié)合進(jìn)行分享，同時(shí)將別的team的故障都當(dāng)做自己的故障來分析原因和查找我們系統(tǒng)的不足。

第三路：故障預(yù)防

在系統(tǒng)復(fù)雜和業(yè)務(wù)需求不斷導(dǎo)致代碼腐化，我們定時(shí)對(duì)整個(gè)系統(tǒng)進(jìn)行重構(gòu)，將整個(gè)重構(gòu)方案大家達(dá)成一致；在今年系統(tǒng)的混部環(huán)境對(duì)我們也是一個(gè)挑戰(zhàn)，所以我們引入了超時(shí)和重試機(jī)制，特別是做到了運(yùn)行期修改超時(shí)時(shí)間，防止雪崩，每一個(gè)新功能上線時(shí)都會(huì)做故障注入和故障演練，識(shí)別潛在風(fēng)險(xiǎn)。

第四路：故障緩解

我們機(jī)器留有一些buffer以防大促、線程池滿等緊急擴(kuò)容情況下使用，同時(shí)對(duì)高QPS有降級(jí)預(yù)案以防異常情況緊急止血。還是前面提到的業(yè)務(wù)系統(tǒng)一定要有產(chǎn)品和業(yè)務(wù)兜底方案，比如我們在和蜂鳥對(duì)接時(shí)當(dāng)蜂鳥的系統(tǒng)如果出現(xiàn)問題時(shí)，我們服務(wù)端針對(duì)此種情況做了防御性編程，打開開關(guān)讓蜂鳥騎手用飛魚app進(jìn)行作業(yè)，減輕對(duì)用戶的影響面。在穩(wěn)定上，我們不但要自己贏，也要讓合作伙伴贏。

第五路：快速恢復(fù)

回滾是系統(tǒng)發(fā)布后出現(xiàn)異常最有效的止血方案，對(duì)于弱依賴我們通過柔性可用性讓它跳過不阻塞繼續(xù)往下走，當(dāng)出現(xiàn)異常case時(shí)比如履約和配的狀態(tài)不一致我們通過阿波羅后臺(tái)進(jìn)行一鍵修復(fù)，異常緊急訂正預(yù)案、Diamond命令下發(fā)等來快速恢復(fù)。

第六路：快速補(bǔ)償

我們的系統(tǒng)在設(shè)計(jì)的都是無狀態(tài)扁平化，不存在單點(diǎn)，機(jī)器擴(kuò)容是應(yīng)對(duì)某些異常情況的快速止血方案。

第七路：發(fā)布治療

在上述路數(shù)招數(shù)都無法快速止血的情況下只能采用發(fā)布治療，我們有一次突然機(jī)器Load飆高，收到報(bào)警后第一反應(yīng)是機(jī)器問題，但又發(fā)現(xiàn)部分機(jī)器的線程池也快滿了，我們隨即開始擴(kuò)容和機(jī)器重啟，一部分同學(xué)在快速擴(kuò)容，一部分同學(xué)在不停的機(jī)器重啟，其它同學(xué)在迅速查找問題的根本原因，最后通過DUMP發(fā)現(xiàn)是由于引用了一個(gè)Jar，而這個(gè)Jar包里面使用了Java的正則表達(dá)式在解析一個(gè)特殊商品名稱的時(shí)候進(jìn)入了死循環(huán)，找到原因后這種情況只能通過發(fā)布解決，我們迅速達(dá)成一致緊急發(fā)布解決，正是前面一部分同學(xué)的擴(kuò)容和不停的重啟，從而避免了一場故障。

大海航行靠舵手

盒馬配送的穩(wěn)定性靠的是業(yè)務(wù)方、產(chǎn)品、研發(fā)、測試、Web端、App端、RF端、GOC、上下游、算法、IOT、NBF、盒馬安全生產(chǎn)、中間件、網(wǎng)絡(luò)、氣象臺(tái)、雨雪冰霧、道路交通、紅綠燈、小區(qū)設(shè)施、騎手裝備等等各種因素，每一個(gè)組成部分都是至關(guān)重要。穩(wěn)定性的探索我們還在路上，不斷追求極致。