結(jié)合之前文章

-?類Uber/滴滴分單引擎中應(yīng)用到的技術(shù)原理 (1)

繼續(xù)深入一層推導(dǎo)‘分單引擎’面臨的問題

回顧上一節(jié)，提到了此類‘分單引擎’ 核心需要解決的問題是：完成叫車訂單的分配。策略上的核心原則是：“站在全局視角，盡量去滿足盡可能多的出行需求，保證乘客的每一個叫車需求都可以更快更確定的被滿足，并同時盡力去提升每一個司機(jī)的接單效率，讓總的接駕距離和時間最短。”

那么，進(jìn)行合理推斷，業(yè)務(wù)上需要解決的核心問題如下：

- 如何且何時去觸發(fā)乘客訂單和司機(jī)之間的匹配計算進(jìn)而完成派單（除了派單這種模式，何種場景下會使用搶單模式）才能滿足乘客乘車需求？

- 考慮不同乘客的訂單需求（接乘體驗、效率）、司機(jī)自身的需求（如，有的司機(jī)只想接回家順路單、司機(jī)只在限行區(qū)域內(nèi)行駛、司機(jī)只聽預(yù)約單），那么如何保障在各種業(yè)務(wù)場景都正確性的前提下，來找目標(biāo)函數(shù)下的最優(yōu)解？

- 從打分分配過程來看，目標(biāo)函數(shù)考慮的因素不僅考慮乘客與司機(jī)之間的導(dǎo)航距離，還會考慮到司機(jī)的服務(wù)等級分、價格、供需緊張程度等多種因素。那么，如何在效率指標(biāo)和成本等指標(biāo)之間做出權(quán)衡？

- 在垂直的子場景下，優(yōu)化子場景的目標(biāo)，從而間接支撐核心目標(biāo)，如動態(tài)定價、供需調(diào)度（基于供需熱力圖，給司機(jī)發(fā)空單調(diào)度司機(jī)到需求密度更好的地區(qū)）、分場景派單（機(jī)場、火車站的派單距離會長一些，且進(jìn)行公平派單 - 先來后到的原則）、不同運力層之間互轉(zhuǎn)（運力不足等情況下，快車單給專車）

... ...

基于問題推斷總結(jié)這類‘分單引擎’的邊界

可以預(yù)見，繼續(xù)推導(dǎo)下去，需要解決的業(yè)務(wù)問題還有很多，但嘗試對這類‘分單引擎’做一個總結(jié)和定位的話，應(yīng)該有如下幾個要點：

- 職責(zé)：在合適的時刻，把合適的訂單，分配給合適的司機(jī)

- 主要的業(yè)務(wù)目標(biāo)：兼顧業(yè)務(wù)運營上的需要，保障體驗和全局效率最優(yōu)

? ? - 猜測來看，從業(yè)務(wù)運營上，應(yīng)該會分各類不同的場景，且圍繞不同場景，定義出更具體的成本、體驗、效率的指標(biāo)，足見‘分單引擎’是實現(xiàn)業(yè)務(wù)運營目標(biāo)的重要抓手

- 系統(tǒng)上的目標(biāo)：支撐全國各個城市（跨城）訂單最優(yōu)分配，保障系統(tǒng)對于業(yè)務(wù)規(guī)則類需求和策略類需求能夠快速擴(kuò)展開發(fā)落地、系統(tǒng)架構(gòu)具備根據(jù)容量規(guī)模的橫向擴(kuò)展能力以及性能保障

? ? - 邏輯結(jié)構(gòu)上，需要能夠?qū)⒎謫蔚恼麄€過程進(jìn)行抽象，拆分成相對固定的模塊/步驟。圍繞模塊/步驟，再嵌入可插拔的規(guī)則擴(kuò)展實現(xiàn)。如，

? ? ? ? - 通過規(guī)則引擎來支撐上述所需要的為保障分單業(yè)務(wù)正確性的各類業(yè)務(wù)規(guī)則；

? ? ? ? - 通過策略引擎讓算法同學(xué)基于統(tǒng)一的同一套數(shù)據(jù)結(jié)構(gòu)可以按場景去疊加各種尋優(yōu)策略來找到最優(yōu)匹配（如，二分圖，乘客與司機(jī)可以為兩個頂點集合，通過計算各種邊的權(quán)重，以找到圖的最大匹配））；

? ? - 核心系統(tǒng)架構(gòu)上，需要有，

? ? ? ? - 實現(xiàn)‘延遲分單’的定時器

? ? ? ? - 有能夠進(jìn)行全局資源監(jiān)控和管理的資源管理器?

? ? ? ? - 有對分單計算任務(wù)和資源匹配的任務(wù)調(diào)度器

? ? ? ? - 有用于具體執(zhí)行分單匹配計算的任務(wù)計算節(jié)點服務(wù)。且在任務(wù)執(zhí)行過程中，可以根據(jù)任務(wù)計算量，動態(tài)決定拆分一個大任務(wù)成多個可并行執(zhí)行的小任務(wù)，然后再聚合結(jié)果

? ? ? ? - 存儲著司機(jī)位置、訂單數(shù)據(jù)等高效的索引存儲系統(tǒng)

? ? ? ? ... ...

一種簡化版的分單引擎的架構(gòu)

從上圖可以看出，一次分單計算的任務(wù)類似一次Hadoop 中MapReduce的批量的執(zhí)行計算任務(wù)過程（結(jié)合Yarn 資源調(diào)度管理來說）：

- 定時觸發(fā)生成的Job中，所有需要匹配計算的訂單和司機(jī)數(shù)據(jù)，類似于MR程序要處理的數(shù)據(jù)；只是真正執(zhí)行的程序不像MR Jar 那樣，可以在Hadoo環(huán)境下，執(zhí)行時再通過HDFS動態(tài)加載執(zhí)行（即移動計算式的方式）。這里，執(zhí)行的匹配計算邏輯，都預(yù)先啟動在各個分單計算節(jié)點當(dāng)中；

- 提交的任務(wù)根據(jù)需要計算的任務(wù)負(fù)載，從資源管理器匹配可以滿足其需求的資源（包括master 機(jī)器信息以及可以進(jìn)行并行執(zhí)行子任務(wù)的Slave 機(jī)器信息）。根據(jù)任務(wù)的大小，如Yarn中所支持的能力（Uber 模式和non-uber 模式），可以實現(xiàn)動態(tài)判定對小任務(wù)類的匹配邏輯都執(zhí)行在一個機(jī)器資源中并一起順序執(zhí)行，而大任務(wù)類的匹配計算（訂單和司機(jī)之間的匹配過濾、打分等邏輯）則由資源管理器預(yù)先分配好哪些機(jī)器可以用于執(zhí)行具體的匹配計算任務(wù)（包括指定一個Master節(jié)點和多個Slave 節(jié)點），在Master 節(jié)點中可以根據(jù)預(yù)先配置的分片閾值，拆分成多個分片，在并行執(zhí)行完之后，再回到Master 節(jié)點執(zhí)行最終的司機(jī)派單計算；

- 每個任務(wù)計算執(zhí)行節(jié)點，定期上報自己的資源使用情況。Yarn中是通過Container 的抽象概念，綜合了CPU、內(nèi)存等多維度的資源模型；而基于統(tǒng)一的資源管理器和無狀態(tài)的分單計算節(jié)點集群（被資源管理所管理），并結(jié)合任務(wù)大小自動決策資源分配，將使得資源可以在充分利用的情況下，并支持水平擴(kuò)容；