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

做過的人都會說簡單，沒有做過的人卻連想都不敢想，其實(shí)技術(shù)上并沒有太大的差距，差就差在“做過一次”的經(jīng)驗(yàn)。

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

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

石器時(shí)代

單一拆分?jǐn)?shù)據(jù)庫、業(yè)務(wù)解耦

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

 

上圖所示的是業(yè)務(wù)孵化期整體系統(tǒng)架構(gòu)，采用的是的單一數(shù)據(jù)庫模式，與其他業(yè)務(wù)公用數(shù)據(jù)庫，節(jié)省成本，這樣做是為了快速驗(yàn)證市場對業(yè)務(wù)接受度。

 

上圖所示是業(yè)務(wù)孵化期的派單系統(tǒng)，可以理解為一個(gè)單元運(yùn)作。系統(tǒng)核心部分是 OrderPushJar，訂單創(chuàng)建、推送等派單邏輯都在這里進(jìn)行處理。

 

這個(gè)階段訂單調(diào)度原理很簡單，就是由推送框架 MQTT，把訂單推送給設(shè)定范圍內(nèi)所有司機(jī)，司機(jī)憑手速接單，單單都有補(bǔ)貼旨在快速搶占市場，這對平臺而言是龐大的浪費(fèi)。

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

 

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

整體遷移后，快狗打車整體系統(tǒng)大致分成訂單、結(jié)算、配置、軌跡等模塊，每一個(gè)模塊都有對應(yīng)單獨(dú)數(shù)據(jù)庫，這樣就很好的避免了業(yè)務(wù)之間的耦合，軌跡服務(wù)數(shù)據(jù)庫出現(xiàn)異常，并不會影響其他業(yè)務(wù)流程。

鐵器時(shí)代

雙推送通道、象限推送

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

 

上圖是業(yè)務(wù)高速發(fā)展時(shí)期的系統(tǒng)架構(gòu)。App、PC 及其他第三方渠道進(jìn)入到 OrderCenterServer(訂單中心)，OrderCenterServer 會根據(jù)具體職責(zé)進(jìn)入業(yè)務(wù)的模塊化，分成了像結(jié)算、支付、推送、司機(jī)任務(wù)等模塊。

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

 

這個(gè)階段訂單調(diào)度原是按照不同的象限方式進(jìn)行予以推送，訂單產(chǎn)生時(shí)會先在附近 X 公里范圍之內(nèi)，尋找滿足該需求的司機(jī)，進(jìn)行推單。如果無人搶單便加部分補(bǔ)貼，激發(fā)司機(jī)的搶單意愿。

如上圖所示，會采用象限推送的模式，如果沒人搶單，就增加部分補(bǔ)貼，延象限進(jìn)行推送，如果搶單人數(shù)達(dá)到一定上限，就回降低部分補(bǔ)貼。

在指派司機(jī)的環(huán)節(jié)，根據(jù)搶單司機(jī)的距離、好評率、歷史訂單完成率等核心評估指標(biāo)進(jìn)行擇優(yōu)指派，這種簡單的方法既減少了平臺派發(fā)無效補(bǔ)貼的浪費(fèi)，又有效避免了憑速度搶單的惡意競爭，進(jìn)而提升了整個(gè)平臺的訂單完成率。

智能時(shí)代

大數(shù)據(jù)平臺引入到智能化

2016 年，快狗打車成為行業(yè)佼佼者，進(jìn)入了平穩(wěn)期，這時(shí)更多考慮的是平臺補(bǔ)貼如何高效，起到真正補(bǔ)貼的作用、如何盡量滿足用戶的需求、如何分配司機(jī)的收益。

進(jìn)而效率提升成為這一年的整體目標(biāo)，主要做了引入大數(shù)據(jù)平臺、智能派單算法和智能分流框架等內(nèi)容。

第一步：數(shù)據(jù)收集

 

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

第二步：智能模型訓(xùn)練

 

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

• 訂單的信息，包括：始發(fā)地、目的地、以及價(jià)格。
• 用戶的信息，包括：用戶位置、以及對于價(jià)格的敏感度。
• 司機(jī)的信息，包括：接單的意愿等。
• 客戶和司機(jī)的關(guān)系信息，包括：兩者能夠相匹配的標(biāo)準(zhǔn)。
• 整體訂單的推送和接單場景等信息。

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

接下來，通過具體場景來詮釋大數(shù)據(jù)的智能化派單系統(tǒng)的應(yīng)用，涉及主要場景有計(jì)價(jià)、推單、中單等。

場景一：計(jì)價(jià)

先分享計(jì)價(jià)場景，是因?yàn)闊o論是打車用戶還是司機(jī)，對于價(jià)格都是很敏感的。

 

具體說來：用戶先上來詢價(jià)，根據(jù)詢價(jià)信息給予用戶一定的優(yōu)惠 A 元，同時(shí)也要據(jù)此來補(bǔ)貼司機(jī) B 元，另外，在定價(jià) C 元的基礎(chǔ)上，快狗打車還要通過一定的抽傭 D 元，來保證平臺的運(yùn)營。

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

 

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

 

根據(jù)上述兩個(gè)計(jì)價(jià)模型，不難發(fā)現(xiàn)：為了保證訂單的完成率，至少要保證兩個(gè)司機(jī)的搶單：通過對司機(jī)和用戶的行為分析，要掌握司機(jī)對于訂單大致的接受價(jià)位;同時(shí)，也會通過整體的接單司機(jī)數(shù)量，來反過來驗(yàn)證該模型的有效性。

 

上述優(yōu)惠模型是分析用戶流失率的手段。根據(jù)用戶每天的活躍度，訂單價(jià)值貢獻(xiàn)等，能夠獲悉：可能由于某些原因，用戶存在流失的風(fēng)險(xiǎn)，就應(yīng)該通過平臺發(fā)券的方式將他刺激用戶的回流。

場景二：推單

 

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

 

那么司機(jī)的接單意愿又是從何而來呢?其中包括：訂單與司機(jī)之間的距離、訂單的價(jià)格、小費(fèi)&補(bǔ)貼、以及起點(diǎn)&終點(diǎn)等方面。

平臺通過大規(guī)模的邏輯回歸，可以計(jì)算出附近司機(jī)的接單意愿，進(jìn)而推送給相應(yīng)的司機(jī)。

場景三:中單

 

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

 

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

 

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

場景四：整體運(yùn)營

 

如上圖，是整體運(yùn)用場景。

• 在用戶下單時(shí)，快狗打車運(yùn)用訂單的定價(jià)模型，來確定用戶是否需要調(diào)價(jià)、優(yōu)惠、或是補(bǔ)貼。
• 在系統(tǒng)推送時(shí)，快狗打車預(yù)測司機(jī)的接單意愿，以及推送的順序。
• 在司機(jī)搶單時(shí)，快狗打車預(yù)測整體的接單人數(shù)，一旦人數(shù)到達(dá)上限，就會通過降低訂單補(bǔ)貼等方式進(jìn)行動態(tài)微調(diào)。
• 在訂單指派時(shí)，快狗打車也會預(yù)測司機(jī)的完成概率，并獲取司機(jī)的質(zhì)量度。
• 在訂單完成后，快狗打車會預(yù)測用戶是否流失，并根據(jù)其留存價(jià)值，來確定是否給他更多的優(yōu)惠。

 

上圖展示的是整體派單側(cè)的架構(gòu)。核心在于策略應(yīng)用服務(wù)側(cè)、通用邏輯服務(wù)層，以及底層數(shù)據(jù)服務(wù)側(cè)的劃分。

 

上圖展示的是智能派單的核心流程。左側(cè)的核心模塊是特征數(shù)據(jù)，它經(jīng)由數(shù)據(jù)的收集與訓(xùn)練，得到相應(yīng)的特征數(shù)據(jù)值。通過特征匹配系統(tǒng)，將數(shù)據(jù)應(yīng)用到整體的業(yè)務(wù)系統(tǒng)中。同時(shí)這里的訂單隊(duì)列引擎和司機(jī)隊(duì)列引擎，根據(jù)訂單狀態(tài)的實(shí)時(shí)變化，將訂單推送給司機(jī)。

 

另外，通過業(yè)務(wù)監(jiān)督平臺，來保證新的模型、或算法在上線時(shí)得到相應(yīng)的分流與監(jiān)測。具體而言，根據(jù)用戶的設(shè)備特點(diǎn)，來模擬流量的分配，進(jìn)而實(shí)時(shí)地得到數(shù)據(jù)上報(bào)。

例如：用戶是否僅在詢價(jià)階段完成后就流失了。倘若流失率較高的話，就會通過實(shí)時(shí)報(bào)告將線上新的分流設(shè)置關(guān)閉掉。

接下來分享快狗打車的的監(jiān)控平臺，具體的定義如下三點(diǎn)：

• 算法需要穩(wěn)定的系統(tǒng)支撐
• 業(yè)務(wù)的波動要第一時(shí)間知悉
• 提高問題排查效率就是在挽回?fù)p失

 

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

業(yè)務(wù)指標(biāo)監(jiān)控包含訂單整體波動以及補(bǔ)貼整體波動等。訂單波動就是對附近平均司機(jī)數(shù)量，推單波動進(jìn)行監(jiān)控。補(bǔ)貼波動就是對用戶和司機(jī)的補(bǔ)貼實(shí)時(shí)投放的數(shù)據(jù)進(jìn)行監(jiān)控。這些核心業(yè)務(wù)指標(biāo)監(jiān)控需要做到實(shí)時(shí)反饋，有波動第一時(shí)間告警。

如果優(yōu)惠券訂單數(shù)為什么突然間在暴漲?補(bǔ)貼訂單數(shù)為什么突然之間下降?等等這些核心業(yè)務(wù)指標(biāo)監(jiān)控需要做到實(shí)時(shí)反饋。

總結(jié)

2014 年至今，一路走來快狗打車團(tuán)隊(duì)不斷壯大，業(yè)務(wù)也是不斷地迭代和優(yōu)化，最后總結(jié)如下幾點(diǎn)：

• 架構(gòu)與團(tuán)隊(duì)、業(yè)務(wù)對齊，保持服務(wù)的持續(xù)演進(jìn)，以響應(yīng)業(yè)務(wù)的快速變化
• 建議使用雙推送通道，保證推送的到達(dá)率
• 監(jiān)控很重要，第一時(shí)間發(fā)現(xiàn)問題，減少影響
• 持續(xù)提升，團(tuán)隊(duì)的能力，要跟得上業(yè)務(wù)的節(jié)奏

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】