http://www.infoq.com/cn/news/2018/07/yunmanman-arch

絕大多數(shù)人應(yīng)該都用過滴滴、Uber 等叫車 App，所以在線叫車已經(jīng)成為日常出行的一種方式。而運(yùn)滿滿是貨車和貨源的模式，和滴滴有相似之處，也存在很多差異。貨車司機(jī)以往是去線下的配貨站找貨，現(xiàn)在在運(yùn)滿滿 App 上就可以尋找周邊貨源。

目前運(yùn)滿滿有 520W 司機(jī)和 125W 貨主用戶。貨運(yùn)行業(yè)有其特殊性，我們也很榮幸能采訪到運(yùn)滿滿 CTO 王東老師，從運(yùn)滿滿最初的架構(gòu)迭代，到技術(shù)中臺(tái)的搭建，到當(dāng)前的 AI 技術(shù)的應(yīng)用，整體上了解貨運(yùn)平臺(tái)的技術(shù)積累。同時(shí)，王東老師也會(huì)在 7 月 6 日的深圳 ArchSummit 全球架構(gòu)師技術(shù)峰會(huì)上演講《如何打造活力、持續(xù)創(chuàng)新的研發(fā)團(tuán)隊(duì)》話題。

王東說，之前一個(gè)司機(jī)從南京拉貨到上海，需要在上海卸貨之后再去配貨站找貨，而且能看到的貨源也僅限于與該配貨站關(guān)系好的工廠貨物，很多因素會(huì)導(dǎo)致司機(jī)要多等待半天到一天，以至于經(jīng)常會(huì)空駛回南京。

基于運(yùn)滿滿平臺(tái)，司機(jī)能看到整個(gè)上海到南京的貨源情況，甚至從上海周邊到南京周邊的貨源，這就提升了司機(jī)的選擇余地，極大的降低了空駛，也提高了車貨匹配的效率，在熱門線路貨主發(fā)出送貨需求幾分鐘之內(nèi)就能找到對(duì)應(yīng)的司機(jī)。

現(xiàn)在平臺(tái)上的大部分運(yùn)單運(yùn)費(fèi)并沒有從運(yùn)滿滿平臺(tái)內(nèi)走，運(yùn)滿滿通過提供額外的保障，一體化服務(wù)的優(yōu)勢(shì)來(lái)吸引用戶在線上完成運(yùn)費(fèi)的支付過程。

與此同時(shí)，王東還說，運(yùn)滿滿正研究無(wú)人駕駛在干線物流領(lǐng)域的應(yīng)用，已經(jīng)組建了無(wú)人駕駛事業(yè)部，集團(tuán)也為用戶提供了全方位如 ETC，油，保險(xiǎn)，貸款等服務(wù)。

現(xiàn)在這一切看上去都很美好，但是回望來(lái)時(shí)的路，不甚感慨，滅掉了很多問題，但還有更多的問題需要消滅。

一直在打“遭遇戰(zhàn)”

2017 年運(yùn)滿滿和貨車幫合并后成立滿幫集團(tuán)，整個(gè)集團(tuán)不論是業(yè)務(wù)體系還是技術(shù)體系都在飛速發(fā)展。為了更好的為司機(jī)和貨主服務(wù)，集團(tuán)各個(gè)業(yè)務(wù)、團(tuán)隊(duì)開始融合。融合的過程中，業(yè)務(wù)上既要滿足不停歇的新業(yè)務(wù)需求，還要不斷地升級(jí)系統(tǒng)以確保穩(wěn)定性。合并之后和貨車幫的技術(shù)團(tuán)隊(duì)很好的配合一起來(lái)完成這件事是一個(gè)挑戰(zhàn)。結(jié)果只用了 3 個(gè)月就實(shí)現(xiàn)了系統(tǒng)融合并上線，雙方團(tuán)隊(duì)的匠心精神充分展現(xiàn)。

最開始運(yùn)滿滿的系統(tǒng)架構(gòu)設(shè)計(jì)比較簡(jiǎn)單：單體應(yīng)用，一個(gè) war 包包含了所有服務(wù)端接口，沒有做服務(wù)化拆分，各模塊嚴(yán)重耦合。隨著業(yè)務(wù)量快速增長(zhǎng)，在高峰時(shí)段系統(tǒng)訪問量快速攀升，系統(tǒng)不斷出現(xiàn)問題甚至宕機(jī)，很難診斷出問題在哪里。后來(lái)啟動(dòng)了服務(wù)化拆分、中心化建設(shè)。同時(shí)技術(shù)架構(gòu)上開始大量使用緩存，以及數(shù)據(jù)庫(kù)讀寫分離。App 重構(gòu)項(xiàng)目、安全攻堅(jiān)項(xiàng)目、運(yùn)維自動(dòng)化項(xiàng)目、Docker 化項(xiàng)目、穩(wěn)定性體系項(xiàng)目也緊隨其后。

系統(tǒng)架構(gòu)迭代

第一次迭代是“服務(wù)化拆分”。運(yùn)滿滿初期是一個(gè)單體應(yīng)用，隨著業(yè)務(wù)的發(fā)展開始隱隱暴露出研發(fā)效率與穩(wěn)定性難以權(quán)衡的痛點(diǎn)，為避免業(yè)務(wù)進(jìn)入高速發(fā)展時(shí)期對(duì)技術(shù)團(tuán)隊(duì)帶來(lái)的沖擊，研發(fā)團(tuán)隊(duì)啟動(dòng)了服務(wù)化拆分項(xiàng)目。對(duì)于系統(tǒng)的更新，我們從研發(fā)效率與穩(wěn)定性兩個(gè)基本要求出發(fā)，分析關(guān)鍵路徑，隔離業(yè)務(wù)變化與資源體量，整體規(guī)劃面向分布式系統(tǒng)的全鏈路監(jiān)控。從系統(tǒng)復(fù)雜度、服務(wù)分級(jí)，以及業(yè)務(wù)領(lǐng)域?qū)F(tuán)隊(duì)配合度的要求這幾個(gè)方面，對(duì)團(tuán)隊(duì)進(jìn)行盤點(diǎn)、重組和擴(kuò)充。這個(gè)過程雖然花了很多時(shí)間與精力去分析系統(tǒng)，洞察團(tuán)隊(duì)，但事實(shí)證明這為后續(xù)的工作奠定了堅(jiān)實(shí)的基礎(chǔ)。

第二次迭代是“穩(wěn)定性保障體系與業(yè)務(wù)服務(wù)中臺(tái)”。在運(yùn)滿滿系統(tǒng)全量服務(wù)化后，研發(fā)效率、性能、穩(wěn)定性得到了巨大的提升，業(yè)務(wù)也在這個(gè)階段進(jìn)入了高速爆發(fā)期。然而，隨著服務(wù)化大幅增加了系統(tǒng)復(fù)雜度，線上故障的定位難度與恢復(fù)時(shí)長(zhǎng)也隨之提高。研發(fā)團(tuán)隊(duì)圍繞著故障預(yù)演、發(fā)現(xiàn)、止損、定位與恢復(fù)規(guī)劃并落地了統(tǒng)一流控熔斷降級(jí)、流量調(diào)度、動(dòng)態(tài)分組、自動(dòng)化破壞性測(cè)試、全鏈路 Trace、線上變更事件流等能力，大幅降低了故障數(shù)量與恢復(fù)時(shí)長(zhǎng)。

同樣，系統(tǒng)復(fù)雜度的提升給研發(fā)效率也造成了不小的沖擊，大量業(yè)務(wù)服務(wù)中存在相似或相同的邏輯，隨著對(duì)業(yè)務(wù)領(lǐng)域的逐漸深入，我們規(guī)劃并逐步沉淀業(yè)務(wù)服務(wù)中臺(tái)，以數(shù)據(jù)模型抽象化配置化，業(yè)務(wù)邏輯引擎化的思路， 使大量前端業(yè)務(wù)系統(tǒng)的共性與差異化轉(zhuǎn)變?yōu)橹信_(tái)調(diào)用的選項(xiàng)參數(shù)，以及配置能力的使用。比如用戶平臺(tái)、貨源平臺(tái)、推薦排序平臺(tái)。

大道至簡(jiǎn)的分布時(shí)代應(yīng)對(duì)策略

因?yàn)樾袠I(yè)特殊性，缺少前車之鑒的參考，王東說，他們確實(shí)遇到了很多挑戰(zhàn)，一些看似合理的產(chǎn)品邏輯與平臺(tái)規(guī)則，在用戶看來(lái)卻沒法解決他們的問題，反應(yīng)很強(qiáng)烈。在一切摸著石頭過河的階段，對(duì)技術(shù)架構(gòu)的快速應(yīng)變能力是相當(dāng)大的考驗(yàn)，客戶端在這個(gè)問題上凸顯尤為嚴(yán)重。客戶端發(fā)版到用戶最終更新需要一個(gè)長(zhǎng)周期，如果完全依賴靜態(tài)發(fā)版，版本更新周期內(nèi)所有問題基本束手無(wú)策。為了快速響應(yīng)業(yè)務(wù)變化，運(yùn)滿滿對(duì)客戶端動(dòng)態(tài)能力建設(shè)下了很大的功夫，例如 React，動(dòng)態(tài)降級(jí) H5，安卓插件化，無(wú)痕打點(diǎn)。這需要大量的客戶端標(biāo)準(zhǔn)化工作以及完備的基礎(chǔ)能力建設(shè)，并且還需要建立對(duì)應(yīng)的管理平臺(tái)增加各能力管理的易用性。

另外，用戶群體內(nèi)大多數(shù)人對(duì)智能手機(jī)了解不夠，例如 Push 收不到，沒聲音等手機(jī)設(shè)置問題都需要客服去協(xié)助解決。為此，我們?cè)诳蛻舳藘?nèi)置了強(qiáng)大的問題自診斷工具，針對(duì)安卓系統(tǒng)的碎片化問題，這類工具的研發(fā)需要對(duì)癥下藥定制進(jìn)行適配，達(dá)到的效果也很喜人，上線后每周此類問題的咨詢量降低了兩個(gè)數(shù)量級(jí)。為了降低管理成本與人員成本，這種快速應(yīng)變能力在服務(wù)端同樣重要，這正是業(yè)務(wù)服務(wù)中臺(tái)能力的體現(xiàn)，非常重要。

大放異彩的算法技術(shù)

算法技術(shù)在車貨之間進(jìn)行匹配，最大程度降低空駛率，節(jié)省時(shí)間，提升效率上發(fā)揮了重大作用。那它和普通的車人匹配性質(zhì)有何不同呢？

王東說，這就要談到匹配的場(chǎng)景和特色。車貨匹配在廣義上，也是撮合交易的一種。如同電商、打車。在平臺(tái)產(chǎn)品上的展現(xiàn)形態(tài)，也以推薦、排序、訂單匹配為主。但車貨匹配有極其獨(dú)特的特點(diǎn)，比如貨源是無(wú)庫(kù)存的唯一品和非標(biāo)準(zhǔn)品。“唯一品”指的是每宗貨源幾乎各不相同，運(yùn)輸方案、時(shí)間各有變化，而且一次性成交后就立刻下線，完全不同于商城的熱點(diǎn)商品推薦原則。非標(biāo)準(zhǔn)品是指，貨源對(duì)車輛是有要求的，而且在不同時(shí)間、線路、種類上計(jì)價(jià)方式也不同。這一點(diǎn)也和打車出行場(chǎng)景的車人匹配有著重大差異。日常出行的車人匹配的場(chǎng)景是局部區(qū)域在較短時(shí)間窗口內(nèi)滿足供需，而車貨匹配則是長(zhǎng)時(shí)間大區(qū)域內(nèi)的匹配 -- 畢竟貨運(yùn)計(jì)劃可以長(zhǎng)達(dá)一個(gè)月，車輛的行駛里程遠(yuǎn)大于日常打車場(chǎng)景。

算法技術(shù)，確實(shí)是以在這種強(qiáng)約束條件下取系統(tǒng)最優(yōu)為目標(biāo)的。迭代過程中，伴隨算法的框架也做了大規(guī)模的升級(jí)，從數(shù)據(jù)采集存儲(chǔ)、計(jì)算，到 T+1、T+0 的服務(wù)。實(shí)際上，算法解決了匹配方面的這幾個(gè)子問題：車貨基礎(chǔ)相關(guān)性（CTR 模型），貨源路線和司機(jī)畫像，司機(jī)的預(yù)估行駛距離和時(shí)間（ETA 模型），區(qū)域內(nèi)供需關(guān)系預(yù)測(cè)和價(jià)格模型，路線 / 貨源相似性等。算法上，我們?cè)陔x線部分使用 XgBoost 來(lái)處理基礎(chǔ)相關(guān)性，用 RNN 做行駛時(shí)間預(yù)估，用 LSTM 來(lái)做時(shí)間序列預(yù)測(cè)，在線學(xué)習(xí)我們用基于 FTRL 獨(dú)立發(fā)展的自研算法來(lái)處理。

從結(jié)果來(lái)說，發(fā)貨信息上線的瞬間，就能準(zhǔn)確預(yù)測(cè)潛在的車主，并進(jìn)行正確的推送，40% 的貨源在 30 分鐘內(nèi)就能建立司機(jī)到貨主的聯(lián)系，60% 的貨源在 2 小時(shí)之內(nèi)成交。大大節(jié)省了司機(jī)找貨的時(shí)間成本。而且運(yùn)滿滿還提供了大量回程甚至多路徑中轉(zhuǎn)回程的推薦。這些都對(duì)匹配效率，降低空駛起到了重要作用。

機(jī)器學(xué)習(xí)和深度學(xué)習(xí)的廣泛采用

運(yùn)滿滿利用大規(guī)模的數(shù)據(jù)采集，實(shí)時(shí)運(yùn)算，借助機(jī)器學(xué)習(xí)和深度學(xué)習(xí)技術(shù)，建立了全網(wǎng)最優(yōu)為目標(biāo)的匹配和調(diào)度方案，大幅提升運(yùn)輸效率（匹配，速度，節(jié)油）。

其平臺(tái)的使用流程為：貨主通過 App 發(fā)布貨源信息，司機(jī)通過 App 篩選出符合運(yùn)輸條件的貨源。由于在線貨源的數(shù)量巨大，司機(jī)需要瀏覽大量貨源，或頻繁切換篩選條件才能找到真正合適的貨源。因此開發(fā)了實(shí)時(shí)貨源推薦系統(tǒng)和基于車輛貨源供需的調(diào)度系統(tǒng)，來(lái)提高司機(jī)的搜貨效率以及提升平臺(tái)整體的成交率。除了個(gè)性化匹配外，實(shí)時(shí)性也是推薦的重點(diǎn)考慮要素。

具體技術(shù)細(xì)節(jié)，運(yùn)滿滿使用 Xgboost 來(lái)預(yù)測(cè)車 - 貨的基礎(chǔ)相關(guān)性，實(shí)際是一個(gè) CTR 和 CVR 混布模型，其中部署了在線實(shí)時(shí)系統(tǒng)，自研了一套基于 FTRL 算法的在線學(xué)習(xí)算法，將用戶實(shí)時(shí)的行為數(shù)據(jù)結(jié)果和 Xgboost 的離線結(jié)果共同訓(xùn)練而得，點(diǎn)擊預(yù)測(cè)的準(zhǔn)確率超過 90%。但是“全網(wǎng)最優(yōu)”的概念并不代表匹配速度最快。

貨源尤其如此，有明顯的好貨與壞貨的區(qū)分，因此要兼顧“效率 + 公平 + 業(yè)務(wù)目標(biāo)”。比如在一個(gè)階段內(nèi)以 30 分鐘反饋為業(yè)務(wù)目標(biāo)。此外，還要考慮運(yùn)輸計(jì)劃和車輛調(diào)度。又涉及到路線調(diào)度、ETA、供需預(yù)測(cè)等范疇。比如 ETA 是基于如下的 ETA cost 場(chǎng)景：為貨主尋找合適的車輛，是不能通過周邊車輛的直線距離來(lái)計(jì)算成本的，也要考慮限行、道路情況、天氣季節(jié)、車輛狀態(tài)來(lái)綜合計(jì)算。那么在這里使用 RNN 來(lái)處理分裂后數(shù)千特征的輸入，對(duì)到達(dá)時(shí)間的成本進(jìn)行預(yù)測(cè)就是非常有效的一種方法。

因?yàn)橐浴叭W(wǎng)最優(yōu)”為目標(biāo)，所以我們需要整合各個(gè)子系統(tǒng)以及相關(guān)的算法模型，如下：

數(shù)據(jù)和算法產(chǎn)生了很大的經(jīng)濟(jì)價(jià)值也是很直觀的：

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/9252953.html

總結(jié)

以上是生活随笔為你收集整理的运满满的技术架构演进之路的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。