【51CTO.com原創稿件】如果讓你從 0 組建一個智能化派單系統，日訂單量為 40W，你敢接單嗎?你會怎么做?

做過的人都會說簡單，沒有做過的人卻連想都不敢想，其實技術上并沒有太大的差距，差就差在“做過一次”的經驗。

聽別人講述自己的經歷，也是積攢經驗的一種好方法。我們曾邀請快狗打車高級經理胡顯波講述他的職業生涯，他講述了快狗打車的派單系統從 0 到智能化的演進。

下面是整理的文字版，希望您看了能有所啟發。

石器時代

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

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

 

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

 

上圖所示是業務孵化期的派單系統，可以理解為一個單元運作。系統核心部分是 OrderPushJar，訂單創建、推送等派單邏輯都在這里進行處理。

 

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

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

 

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

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

鐵器時代

雙推送通道、象限推送

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

 

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

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

 

這個階段訂單調度原是按照不同的象限方式進行予以推送，訂單產生時會先在附近 X 公里范圍之內，尋找滿足該需求的司機，進行推單。如果無人搶單便加部分補貼，激發司機的搶單意愿。

如上圖所示，會采用象限推送的模式，如果沒人搶單，就增加部分補貼，延象限進行推送，如果搶單人數達到一定上限，就回降低部分補貼。

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

智能時代

大數據平臺引入到智能化

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

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

第一步：數據收集

 

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

第二步：智能模型訓練

 

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

• 訂單的信息，包括：始發地、目的地、以及價格。
• 用戶的信息，包括：用戶位置、以及對于價格的敏感度。
• 司機的信息，包括：接單的意愿等。
• 客戶和司機的關系信息，包括：兩者能夠相匹配的標準。
• 整體訂單的推送和接單場景等信息。

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

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

場景一：計價

先分享計價場景，是因為無論是打車用戶還是司機，對于價格都是很敏感的。

 

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

那么該如何計算 ABCD 之間的關系呢?顯然，在保證整體搶單率的情況下，應使得 A 和 B 盡可能的小。

 

也就是說，在盡量降低平臺補貼的前提下，根據給定補貼的預算情況，來提高搶單率。

 

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

 

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

場景二：推單

 

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

 

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

平臺通過大規模的邏輯回歸，可以計算出附近司機的接單意愿，進而推送給相應的司機。

場景三:中單

 

在中單場景中，如果有 50 位司機搶單，那么哪位司機的好評率、距離、服務態度、以及是否愿意免費搬運等策略最為切合，誰就能夠“中簽”。

 

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

 

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

場景四：整體運營

 

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

• 在用戶下單時，快狗打車運用訂單的定價模型，來確定用戶是否需要調價、優惠、或是補貼。
• 在系統推送時，快狗打車預測司機的接單意愿，以及推送的順序。
• 在司機搶單時，快狗打車預測整體的接單人數，一旦人數到達上限，就會通過降低訂單補貼等方式進行動態微調。
• 在訂單指派時，快狗打車也會預測司機的完成概率，并獲取司機的質量度。
• 在訂單完成后，快狗打車會預測用戶是否流失，并根據其留存價值，來確定是否給他更多的優惠。

 

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

 

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

 

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

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

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

• 算法需要穩定的系統支撐
• 業務的波動要第一時間知悉
• 提高問題排查效率就是在挽回損失

 

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

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

如果優惠券訂單數為什么突然間在暴漲?補貼訂單數為什么突然之間下降?等等這些核心業務指標監控需要做到實時反饋。

總結

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

• 架構與團隊、業務對齊，保持服務的持續演進，以響應業務的快速變化
• 建議使用雙推送通道，保證推送的到達率
• 監控很重要，第一時間發現問題，減少影響
• 持續提升，團隊的能力，要跟得上業務的節奏

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】