快狗打車智能化演進之路

若是讓你從 0 組建一個智能化派單系統，日訂單量爲 40W，你敢接單嗎？你會怎麼作？作過的人都會說簡單，沒有作過的人卻連想都不敢想，其實技術上並無太大的差距，差就差在「作過一次」的經驗。聽別人講述本身的經歷，也是積攢經驗的一種好方法。咱們曾邀請快狗打車高級經理胡顯波講述他的職業生涯，他講述了快狗打車的派單系統從 0 到智能化的演進。

石器時代

單一拆分數據庫、業務解耦

因爲快狗打車是 58 同城當時孵化的 N 個業務線之一，而且短短三週就已上線，最初的版本包含了用戶側 App、商家 App、管理後臺三個模塊。

上圖所示的是業務孵化期總體系統架構，採用的是的單一數據庫模式，與其餘業務公用數據庫，節省成本，這樣作是爲了快速驗證市場對業務接受度。

上圖所示是業務孵化期的派單系統，能夠理解爲一個單元運做。系統核心部分是 OrderPushJar，訂單建立、推送等派單邏輯都在這裏進行處理。

這個階段訂單調度原理很簡單，就是由推送框架 MQTT，把訂單推送給設定範圍內全部司機，司機憑手速接單，單單都有補貼旨在快速搶佔市場，這對平臺而言是龐大的浪費。

快狗打車上線以後，市場反響很是好，業務也在短短三個月增加了一萬單。但此時數據庫達到瓶頸，字段冗餘、數據庫索引有效性等問題凸顯，沒辦法支持多業務的發展，某個子業務作上線下線等操做時，「同源」業務也會受到影響。

上圖是針對數據庫瓶頸的解決方案，把快狗打車的數據庫，從耦合的業務數據庫中拆分出來。方案中採用雙向同步模式來業務不停服的狀況下進行數據遷移。

總體遷移後，快狗打車總體系統大體分紅訂單、結算、配置、軌跡等模塊，每個模塊都有對應單獨數據庫，這樣就很好的避免了業務之間的耦合，軌跡服務數據庫出現異常，並不會影響其餘業務流程。

鐵器時代

雙推送通道、象限推送

2015 年，快狗打車進入高速發展階段，市面上也出現了不少同類競品，如藍犀牛、1 號貨的及雲鳥等。市場爭奪戰進入白熱化階段，快狗打車採用大量訂單補貼的方式來提高市場佔有率，產品方面也是爭分奪秒的進行迭代，搶佔市場先機。

上圖是業務高速發展時期的系統架構。App、PC 及其餘第三方渠道進入到 OrderCenterServer（訂單中心），OrderCenterServer 會根據具體職責進入業務的模塊化，分紅了像結算、支付、推送、司機任務等模塊。

爲保證訂單可以儘快被司機接收到以及保證消息推送到達率，快狗打車採用自研 TCP 通道與 GeTui 和 MiPush 等三方通道相結合。根據司機的手機品牌擇優選擇 GeTui 或 MiPush 通道，加上自研的 TCP 通道，保證消息的到達率。

這個階段訂單調度原是按照不一樣的象限方式進行予以推送，訂單產生時會先在附近 X 千米範圍以內，尋找知足該需求的司機，進行推單。若是無人搶單便加部分補貼，激發司機的搶單意願。

如上圖所示，會採用象限推送的模式，若是沒人搶單，就增長部分補貼，延象限進行推送，若是搶單人數達到必定上限，就回下降部分補貼。

在指派司機的環節，根據搶單司機的距離、好評率、歷史訂單完成率等核心評估指標進行擇優指派，這種簡單的方法既減小了平臺派發無效補貼的浪費，又有效避免了憑速度搶單的惡意競爭，進而提高了整個平臺的訂單完成率。

智能時代

大數據平臺引入到智能化

2016 年，快狗打車成爲行業佼佼者，進入了平穩期，這時更多考慮的是平臺補貼如何高效，起到真正補貼的做用、如何儘可能知足用戶的需求、如何分配司機的收益。

進而效率提高成爲這一年的總體目標，主要作了引入大數據平臺、智能派單算法和智能分流框架等內容。

Ste.1數據收集

如上圖，App 用戶使用數據、H5 端日誌操做，Server 端用戶請求日誌等數據進行收集並經過日誌中心組進行上報，聚集到日誌中心，利用 Flume 和 Kafka 同步到大數據平臺。DB 則是經過 DTS 和 Canal 形式，也引入到大數據平臺。

Ste.2智能模型訓練

如上圖，是智能模型的訓練邏輯。底層是收集信息：

l 訂單的信息，包括：始發地、目的地、以及價格。

l 用戶的信息，包括：用戶位置、以及對於價格的敏感度。

l 司機的信息，包括：接單的意願等。

l 客戶和司機的關係信息，包括：二者可以相匹配的標準。

l 總體訂單的推送和接單場景等信息。

憑藉着歸一化&分桶、XGBoost、特徵組合、編碼等大數據手段，進行模型訓練，目前擁有約 80 萬的數據模型用於總體的業務流程。

接下來，經過具體場景來詮釋大數據的智能化派單系統的應用，涉及主要場景有計價、推單、中單等。

場景一：計價

先分享計價場景，是由於不管是打車用戶仍是司機，對於價格都是很敏感的。

具體說來：用戶先上來詢價，根據詢價信息給予用戶必定的優惠 A 元，同時也要據此來補貼司機 B 元，另外，在訂價 C 元的基礎上，快狗打車還要經過必定的抽傭 D 元，來保證平臺的運營。

那麼該如何計算 ABCD 之間的關係呢？顯然，在保證總體搶單率的狀況下，應使得 A 和 B 儘量的小。

也就是說，在儘可能下降平臺補貼的前提下，根據給定補貼的預算狀況，來提升搶單率。

根據上述兩個計價模型，不難發現：爲了保證訂單的完成率，至少要保證兩個司機的搶單：經過對司機和用戶的行爲分析，要掌握司機對於訂單大體的接受價位；同時，也會經過總體的接單司機數量，來反過來驗證該模型的有效性。

上述優惠模型是分析用戶流失率的手段。根據用戶天天的活躍度，訂單價值貢獻等，可以獲悉：可能因爲某些緣由，用戶存在流失的風險，就應該經過平臺發券的方式將他刺激用戶的迴流。

場景二：推單

上圖是一個接單的場景。把訂單推送給願意接單的司機，既能下降用戶的等待時間、提高用戶的滿意度，又能經過訂單的成單率，來提高司機的興趣度。

那麼司機的接單意願又是從何而來呢？其中包括：訂單與司機之間的距離、訂單的價格、小費&補貼、以及起點&終點等方面。

平臺經過大規模的邏輯迴歸，能夠計算出附近司機的接單意願，進而推送給相應的司機。

場景三:中單

在中單場景中，若是有 50 位司機搶單，那麼哪位司機的好評率、距離、服務態度、以及是否願意免費搬運等策略最爲切合，誰就可以「中籤」。

此處的服務模型相對較爲簡單，主要涉及到距離、等級、評分、耦合度等指標。

爲了防止一些假司機來擾亂平臺秩序，快狗打車經過：設備交叉、訂單軌跡、客司金額分配、以及虛擬識別等手段，來識別訂單中的做弊機率。若是發現有做弊的訂單，平臺會對用戶和司機予以懲罰。

場景四：總體運營

如上圖，是總體運用場景。

l 在用戶下單時，快狗打車運用訂單的訂價模型，來肯定用戶是否須要調價、優惠、或是補貼。

l 在系統推送時，快狗打車預測司機的接單意願，以及推送的順序。

l 在司機搶單時，快狗打車預測總體的接單人數，一旦人數到達上限，就會經過下降訂單補貼等方式進行動態微調。

l 在訂單指派時，快狗打車也會預測司機的完成機率，並獲取司機的質量度。

l 在訂單完成後，快狗打車會預測用戶是否流失，並根據其留存價值，來肯定是否給他更多的優惠。

上圖展現的是總體派單側的架構。核心在於策略應用服務側、通用邏輯服務層，以及底層數據服務側的劃分。

上圖展現的是智能派單的核心流程。左側的核心模塊是特徵數據，它經由數據的收集與訓練，獲得相應的特徵數據值。經過特徵匹配系統，將數據應用到總體的業務系統中。同時這裏的訂單隊列引擎和司機隊列引擎，根據訂單狀態的實時變化，將訂單推送給司機。

另外，經過業務監督平臺，來保證新的模型、或算法在上線時獲得相應的分流與監測。具體而言，根據用戶的設備特色，來模擬流量的分配，進而實時地獲得數據上報。

例如：用戶是否僅在詢價階段完成後就流失了。假若流失率較高的話，就會經過實時報告將線上新的分流設置關閉掉。

接下來分享快狗打車的的監控平臺，具體的定義以下三點：

l 算法須要穩定的系統支撐

l 業務的波動要快速知悉

l 提升問題排查效率就是在挽回損失

如上圖，是快狗打車側立體化監控部分截屏，涉及關鍵字監控、接口監控、流量，端口、JVM、CPU，線程、緩存、DB 等監控。

業務指標監控包含訂單總體波動以及補貼總體波動等。訂單波動就是對附近平均司機數量，推單波動進行監控。補貼波動就是對用戶和司機的補貼實時投放的數據進行監控。這些核心業務指標監控須要作到實時反饋，有波動快速告警。

若是優惠券訂單數爲何忽然間在暴漲？補貼訂單數爲何忽然之間降低？等等這些核心業務指標監控須要作到實時反饋。

總結

2014 年至今，一路走來快狗打車團隊不斷壯大，業務也是不斷地迭代和優化，總結以下幾點：

l 架構與團隊、業務對齊，保持服務的持續演進，以響應業務的快速變化

l 建議使用雙推送通道，保證推送的到達率

l 監控很重要，快速發現問題，減小影響l 持續提高，團隊的能力，要跟得上業務的節奏

以上文字版根據《大咖·來了》第2期整理，但願您看了能有所啓發。
原視頻連接：http://aix.51cto.com/activity/10010.html?dk=wz