絕大多數人應該都用過滴滴、Uber 等叫車 App，所以在線叫車已經成為日常出行的一種方式。而運滿滿是貨車和貨源的模式，和滴滴有相似之處，也存在很多差異。貨車司機以往是去線下的配貨站找貨，現在在運滿滿 App 上就可以尋找周邊貨源。
目前運滿滿有 520W 司機和 125W 貨主用戶。貨運行業有其特殊性，我們也很榮幸能採訪到運滿滿 CTO 王東老師，從運滿滿最初的架構迭代，到技術中臺的搭建，到當前的 AI 技術的應用，整體上了解貨運平臺的技術積累。同時，王東老師也會在 7 月 6 日的深圳 ArchSummit 全球架構師技術峰會上演講《如何打造活力、持續創新的研發團隊》話題。
王東說，之前一個司機從南京拉貨到上海，需要在上海卸貨之後再去配貨站找貨，而且能看到的貨源也僅限於與該配貨站關係好的工廠貨物，很多因素會導致司機要多等待半天到一天，以至於經常會空駛回南京。
基於運滿滿平臺，司機能看到整個上海到南京的貨源情況，甚至從上海周邊到南京周邊的貨源，這就提升了司機的選擇餘地，極大的降低了空駛，也提高了車貨匹配的效率，在熱門線路貨主發出送貨需求幾分鐘之內就能找到對應的司機。
現在平臺上的大部分運單運費並沒有從運滿滿平臺內走，運滿滿通過提供額外的保障，一體化服務的優勢來吸引用戶在線上完成運費的支付過程。
與此同時，王東還說，運滿滿正研究無人駕駛在幹線物流領域的應用，已經組建了無人駕駛事業部，集團也為用戶提供了全方位如 ETC，油，保險，貸款等服務。
現在這一切看上去都很美好，但是回望來時的路，不甚感慨，滅掉了很多問題，但還有更多的問題需要消滅。
一直在打“遭遇戰”
2017 年運滿滿和貨車幫合併後成立滿幫集團，整個集團不論是業務體系還是技術體系都在飛速發展。為了更好的為司機和貨主服務，集團各個業務、團隊開始融合。融合的過程中，業務上既要滿足不停歇的新業務需求，還要不斷地升級系統以確保穩定性。合併之後和貨車幫的技術團隊很好的配合一起來完成這件事是一個挑戰。結果只用了 3 個月就實現了系統融合並上線，雙方團隊的匠心精神充分展現。
最開始運滿滿的系統架構設計比較簡單：單體應用，一個 war 包包含了所有服務端接口，沒有做服務化拆分，各模塊嚴重耦合。隨著業務量快速增長，在高峰時段系統訪問量快速攀升，系統不斷出現問題甚至宕機，很難診斷出問題在哪裡。後來啟動了服務化拆分、中心化建設。同時技術架構上開始大量使用緩存，以及數據庫讀寫分離。App 重構項目、安全攻堅項目、運維自動化項目、Docker 化項目、穩定性體系項目也緊隨其後。
系統架構迭代
第一次迭代是“服務化拆分”。運滿滿初期是一個單體應用，隨著業務的發展開始隱隱暴露出研發效率與穩定性難以權衡的痛點，為避免業務進入高速發展時期對技術團隊帶來的衝擊，研發團隊啟動了服務化拆分項目。對於系統的更新，我們從研發效率與穩定性兩個基本要求出發，分析關鍵路徑，隔離業務變化與資源體量，整體規劃面向分佈式系統的全鏈路監控。從系統複雜度、服務分級，以及業務領域對團隊配合度的要求這幾個方面，對團隊進行盤點、重組和擴充。這個過程雖然花了很多時間與精力去分析系統，洞察團隊，但事實證明這為後續的工作奠定了堅實的基礎。
第二次迭代是“穩定性保障體系與業務服務中臺”。在運滿滿系統全量服務化後，研發效率、性能、穩定性得到了巨大的提升，業務也在這個階段進入了高速爆發期。然而，隨著服務化大幅增加了系統複雜度，線上故障的定位難度與恢復時長也隨之提高。研發團隊圍繞著故障預演、發現、止損、定位與恢復規劃並落地了統一流控熔斷降級、流量調度、動態分組、自動化破壞性測試、全鏈路 Trace、線上變更事件流等能力，大幅降低了故障數量與恢復時長。
同樣，系統複雜度的提升給研發效率也造成了不小的衝擊，大量業務服務中存在相似或相同的邏輯，隨著對業務領域的逐漸深入，我們規劃並逐步沉澱業務服務中臺，以數據模型抽象化配置化，業務邏輯引擎化的思路， 使大量前端業務系統的共性與差異化轉變為中颱調用的選項參數，以及配置能力的使用。比如用戶平臺、貨源平臺、推薦排序平臺。
大道至簡的分佈時代應對策略
因為行業特殊性，缺少前車之鑑的參考，王東說，他們確實遇到了很多挑戰，一些看似合理的產品邏輯與平臺規則，在用戶看來卻沒法解決他們的問題，反應很強烈。在一切摸著石頭過河的階段，對技術架構的快速應變能力是相當大的考驗，客戶端在這個問題上凸顯尤為嚴重。客戶端發版到用戶最終更新需要一個長週期，如果完全依賴靜態發版，版本更新週期內所有問題基本束手無策。為了快速響應業務變化，運滿滿對客戶端動態能力建設下了很大的功夫，例如 React，動態降級 H5，安卓插件化，無痕打點。這需要大量的客戶端標準化工作以及完備的基礎能力建設，並且還需要建立對應的管理平臺增加各能力管理的易用性。
另外，用戶群體內大多數人對智能手機瞭解不夠，例如 Push 收不到，沒聲音等手機設置問題都需要客服去協助解決。為此，我們在客戶端內置了強大的問題自診斷工具，針對安卓系統的碎片化問題，這類工具的研發需要對症下藥定製進行適配，達到的效果也很喜人，上線後每週此類問題的諮詢量降低了兩個數量級。為了降低管理成本與人員成本，這種快速應變能力在服務端同樣重要，這正是業務服務中臺能力的體現，非常重要。
大放異彩的算法技術
算法技術在車貨之間進行匹配，最大程度降低空駛率，節省時間，提升效率上發揮了重大作用。那它和普通的車人匹配性質有何不同呢？
王東說，這就要談到匹配的場景和特色。車貨匹配在廣義上，也是撮合交易的一種。如同電商、打車。在平臺產品上的展現形態，也以推薦、排序、訂單匹配為主。但車貨匹配有極其獨特的特點，比如貨源是無庫存的唯一品和非標準品。“唯一品”指的是每宗貨源幾乎各不相同，運輸方案、時間各有變化，而且一次性成交後就立刻下線，完全不同於商城的熱點商品推薦原則。非標準品是指，貨源對車輛是有要求的，而且在不同時間、線路、種類上計價方式也不同。這一點也和打車出行場景的車人匹配有著重大差異。日常出行的車人匹配的場景是局部區域在較短時間窗口內滿足供需，而車貨匹配則是長時間大區域內的匹配 -- 畢竟貨運計劃可以長達一個月，車輛的行駛里程遠大於日常打車場景。
算法技術，確實是以在這種強約束條件下取系統最優為目標的。迭代過程中，伴隨算法的框架也做了大規模的升級，從數據採集存儲、計算，到 T+1、T+0 的服務。實際上，算法解決了匹配方面的這幾個子問題：車貨基礎相關性（CTR 模型），貨源路線和司機畫像，司機的預估行駛距離和時間（ETA 模型），區域內供需關係預測和價格模型，路線 / 貨源相似性等。算法上，我們在離線部分使用 XgBoost 來處理基礎相關性，用 RNN 做行駛時間預估，用 LSTM 來做時間序列預測，在線學習我們用基於 FTRL 獨立發展的自研算法來處理。
從結果來說，發貨信息上線的瞬間，就能準確預測潛在的車主，並進行正確的推送，40% 的貨源在 30 分鐘內就能建立司機到貨主的聯繫，60% 的貨源在 2 小時之內成交。大大節省了司機找貨的時間成本。而且運滿滿還提供了大量回程甚至多路徑中轉回程的推薦。這些都對匹配效率，降低空駛起到了重要作用。
機器學習和深度學習的廣泛採用
運滿滿利用大規模的數據採集，實時運算，藉助機器學習和深度學習技術，建立了全網最優為目標的匹配和調度方案，大幅提升運輸效率（匹配，速度，節油）。
其平臺的使用流程為：貨主通過 App 發佈貨源信息，司機通過 App 篩選出符合運輸條件的貨源。由於在線貨源的數量巨大，司機需要瀏覽大量貨源，或頻繁切換篩選條件才能找到真正合適的貨源。因此開發了實時貨源推薦系統和基於車輛貨源供需的調度系統，來提高司機的搜貨效率以及提升平臺整體的成交率。除了個性化匹配外，實時性也是推薦的重點考慮要素。
具體技術細節，運滿滿使用 Xgboost 來預測車 - 貨的基礎相關性，實際是一個 CTR 和 CVR 混布模型，其中部署了在線實時系統，自研了一套基於 FTRL 算法的在線學習算法，將用戶實時的行為數據結果和 Xgboost 的離線結果共同訓練而得，點擊預測的準確率超過 90%。但是“全網最優”的概念並不代表匹配速度最快。
貨源尤其如此，有明顯的好貨與壞貨的區分，因此要兼顧“效率 + 公平 + 業務目標”。比如在一個階段內以 30 分鐘反饋為業務目標。此外，還要考慮運輸計劃和車輛調度。又涉及到路線調度、ETA、供需預測等範疇。比如 ETA 是基於如下的 ETA cost 場景：為貨主尋找合適的車輛，是不能通過周邊車輛的直線距離來計算成本的，也要考慮限行、道路情況、天氣季節、車輛狀態來綜合計算。那麼在這裡使用 RNN 來處理分裂後數千特徵的輸入，對到達時間的成本進行預測就是非常有效的一種方法。
因為以“全網最優”為目標，所以我們需要整合各個子系統以及相關的算法模型，如下：
數據和算法產生了很大的經濟價值也是很直觀的：
當前分佈式系統是大勢所趨，Google、Facebook 等大型系統架構也是以分佈式系統架構為基礎。過去二十年，整個分佈式系統架構演進史是從 C/S→B/S→分佈式系統→網格計算→雲計算，包括目標、定位、場景，影響深遠。
閱讀更多 程序員之言 的文章
