今天很榮幸給大家介紹 58 速運(yùn)從艱苦創(chuàng)業(yè)到成為同城貨運(yùn)行業(yè)領(lǐng)頭人的整個(gè)系統(tǒng)演進(jìn)過程。

為企業(yè)提供成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)、網(wǎng)站優(yōu)化、營銷型網(wǎng)站、競價(jià)托管、品牌運(yùn)營等營銷獲客服務(wù)。成都創(chuàng)新互聯(lián)擁有網(wǎng)絡(luò)營銷運(yùn)營團(tuán)隊(duì)，以豐富的互聯(lián)網(wǎng)營銷經(jīng)驗(yàn)助力企業(yè)精準(zhǔn)獲客，真正落地解決中小企業(yè)營銷獲客難題，做到“讓獲客更簡單”。自創(chuàng)立至今，成功用技術(shù)實(shí)力解決了企業(yè)“網(wǎng)站建設(shè)、網(wǎng)絡(luò)品牌塑造、網(wǎng)絡(luò)營銷”三大難題，同時(shí)降低了營銷成本，提高了有效客戶轉(zhuǎn)化率，獲得了眾多企業(yè)客戶的高度認(rèn)可！

簡單來說我們的業(yè)務(wù)是做同城貨運(yùn)，比如您去買一個(gè)大型家具，自己的家用車肯定是裝不下的，這時(shí)你可能需要找路邊的小型面包車或者金杯車來幫你搬運(yùn)。

一般來講，很容易遇到黑車，而且價(jià)格不標(biāo)準(zhǔn)，我們做的這個(gè)行業(yè)就是將這種傳統(tǒng)的黑車行業(yè)進(jìn)行線上化，在產(chǎn)品形態(tài)上可理解為滴滴打車的出租車版。

本次分享內(nèi)容主要分為4個(gè)部分：

• 創(chuàng)業(yè)之初：快速迭代試錯(cuò)
• 高速發(fā)展：穩(wěn)定、高效
• 智能時(shí)代：效率、精準(zhǔn)
• 總結(jié)

創(chuàng)業(yè)之初：快速迭代試錯(cuò)

58 速運(yùn)在 2014 年是作為 58 集團(tuán)下 20 多個(gè)孵化業(yè)務(wù)中的其中一個(gè)，那個(gè)時(shí)期基本上是平均三個(gè)星期一個(gè)業(yè)務(wù)孵化上線，當(dāng)時(shí)有 20 多個(gè)業(yè)務(wù)孵化同時(shí)進(jìn)行。這個(gè)時(shí)間我們不斷的試錯(cuò)，不斷去尋找 58 同城新的增長點(diǎn)。

從上圖中，大家可以看到，我們所有的服務(wù)都是基于一個(gè)數(shù)據(jù)庫來運(yùn)行的，這個(gè)系統(tǒng)之間只需要通過一些簡單的 tag 標(biāo)記就可以區(qū)分開業(yè)務(wù)，系統(tǒng)迭代非常快。

對于新孵化的業(yè)務(wù)，我們增加了一些簡單的業(yè)務(wù)邏輯就能實(shí)現(xiàn)這個(gè)產(chǎn)品的快速上線，我們在兩周內(nèi)實(shí)現(xiàn)了速運(yùn)用戶、商家的 APP 以及后端的產(chǎn)品上線。

派單-石器時(shí)代

這時(shí)的系統(tǒng)架構(gòu)是非常簡單的，我們稱之為“石器時(shí)代”，當(dāng)時(shí)所有的訂單調(diào)度的邏輯放在一個(gè) Jar 包，然后通過 MQTT 服務(wù)將訂單推送到司機(jī)的 APP 上。

當(dāng)時(shí)的訂單調(diào)度（也是我們最初級的訂單調(diào)度方案）是一個(gè)訂單搜索附近的司機(jī)，然后由近到遠(yuǎn)的距離將訂單推送出去，司機(jī)搶單后即中單。因?yàn)樵趧?chuàng)業(yè)階段，我們需要吸引客戶、司機(jī)，對于每單都會(huì)有補(bǔ)貼。

這個(gè)階段面臨的痛點(diǎn)如下：

• 系統(tǒng)不穩(wěn)定，一個(gè)慢 SQL，全業(yè)務(wù)受影響，這里舉個(gè)非常普遍的例子，其他業(yè)務(wù)線小伙伴在上線時(shí)，不小心寫了一個(gè)慢 SQL，一個(gè)慢 SQL 就會(huì)把數(shù)據(jù)庫的所有連接占滿，導(dǎo)致所有的業(yè)務(wù)全部掛掉了，當(dāng)時(shí)聽到的最多的反饋是：什么情況，怎么你們又掛了。
• 多業(yè)務(wù)并存，訂單表索引多，性能下降，當(dāng)時(shí)有很多個(gè)業(yè)務(wù)在同時(shí)孵化，多業(yè)務(wù)并存，每一個(gè)業(yè)務(wù)都會(huì)根據(jù)它自己的業(yè)務(wù)需求在訂單表中建立索引，結(jié)果索引越來越多，整體的性能也越來越差。
• 訂單字段冗余，新增和修改字段非常痛苦。每個(gè)業(yè)務(wù)都有特殊的業(yè)務(wù)字段，單標(biāo)數(shù)據(jù)量已經(jīng)到達(dá)了***，每增加一個(gè)字段和修改一個(gè)字段，都需要耗費(fèi)很長的時(shí)間，而且會(huì)造成鎖庫導(dǎo)致系統(tǒng)異常。
• 業(yè)務(wù)增長迅猛，數(shù)據(jù)庫已成瓶頸，58 速運(yùn)整體的訂單增長非常迅速，在成立三個(gè)月以后，每天的單已達(dá)到了1 萬+，系統(tǒng)性能已成為瓶頸。

針對以上痛點(diǎn)，我們做了***次的技術(shù)引進(jìn)——遷庫、集群拆分。

***次技術(shù)演進(jìn)：遷庫、集群解耦

為什么要遷庫？誰痛誰知道！不想受到其他業(yè)務(wù)小伙伴的影響，就要做到解耦。

一個(gè)最簡單的方案就是停服，把所有的服務(wù)停掉，然后把數(shù)據(jù)庫抽離出來，相對來講這是成本最簡單的。

但是停服會(huì)產(chǎn)生的影響：

• 凌晨時(shí)間業(yè)務(wù)仍然有訂單，會(huì)影響到用戶訪問。
• 需要給用戶發(fā)公告。
• 停服遷移如果失敗，無法向業(yè)務(wù)方解釋，會(huì)喪失信任。

我們采用的方案：將訂單表單獨(dú)地拆離出來，放在單獨(dú)的數(shù)據(jù)庫里，兩個(gè)數(shù)據(jù)庫之間使用雙向同步。

雙向同步需要解決的問題：

• 主鍵沖突：速運(yùn)的訂單會(huì)標(biāo)記一個(gè)比較特殊的標(biāo)記 ID（如 80 開頭標(biāo)記為速運(yùn)，其他業(yè)務(wù)都是 10 開頭的），與其他的業(yè)務(wù)線區(qū)分開發(fā)，這樣就可以保證它在雙向同步時(shí)不會(huì)出現(xiàn)主鍵沖突的問題。
• 更新覆蓋：update 的操作在同步的過程中因?yàn)闀r(shí)間差的問題可能存在寫覆蓋的情況，我們采用訂單日志的記錄，遷庫完成后做數(shù)據(jù)的校驗(yàn)。

經(jīng)過多次的遷移，將原有的數(shù)據(jù)庫按照業(yè)務(wù)劃分成了訂單庫、結(jié)算庫、配置庫和軌跡庫等，每個(gè)數(shù)據(jù)庫會(huì)根據(jù)業(yè)務(wù)量容量的大小來配置數(shù)據(jù)庫物理機(jī)的內(nèi)核、內(nèi)存，減少成本。

高速發(fā)展：穩(wěn)定、高效

2015 年我們進(jìn)入了高速發(fā)展的階段，市場上出現(xiàn)了藍(lán)犀牛、1 號(hào)貨的、云鳥的等多個(gè)強(qiáng)勁的競爭對手。各方都是爭分奪秒，一個(gè)系統(tǒng)、功能，我需要抓緊把它給迭代上來，誰也不能比誰落后。

這個(gè)階段我們存在的問題：

• 補(bǔ)貼大戰(zhàn)，大量無效補(bǔ)貼，運(yùn)營成本高，各大競爭對手投放大量的訂單補(bǔ)貼（高達(dá) 30 元+），使得整體運(yùn)營成本呈現(xiàn)水漲高船的趨勢。
• 快速迭代多人維護(hù)一套工程，效率差，Bug 頻發(fā)，最開始創(chuàng)業(yè)時(shí)團(tuán)隊(duì)只有幾個(gè)人，工程都集中在幾個(gè)集群中，后面擴(kuò)大到 30 多個(gè)人時(shí)，大家都集中在這些集群上去開發(fā)，平均每天都要進(jìn)行多次上線，遇到了個(gè)最核心、最痛點(diǎn)的問題，代碼合并，合并代碼就意味著出錯(cuò)的幾率大大提升，當(dāng)時(shí) Bug 率很高。
• 業(yè)務(wù)高速發(fā)展，數(shù)據(jù)量急速增長，我們在 2015 年時(shí)，訂單增長了好幾倍，同時(shí)每個(gè)訂單大概會(huì)推送給 50 多個(gè)司機(jī)，這個(gè)數(shù)據(jù)量級，數(shù)據(jù)量高速的增長。
• 運(yùn)營分析需求越來越復(fù)雜，另外運(yùn)營需要對現(xiàn)在的市場和用戶進(jìn)行分析，整體的運(yùn)營需求分析逐漸復(fù)雜。

這時(shí)我們進(jìn)行了第二次技術(shù)演進(jìn)，我們稱之為“進(jìn)行了奔跑中的火車換輪子”，我們進(jìn)行了服務(wù)化解耦；緩存、分庫分表，提升系統(tǒng)性能；接入大數(shù)據(jù)平臺(tái)，進(jìn)行復(fù)雜需求的分析。

第二次技術(shù)演進(jìn)：奔跑中的火車換輪子

派單-鐵器時(shí)代

我們將所有的系統(tǒng)都按服務(wù)模塊進(jìn)行了拆分，比如說結(jié)算、充值、推送、司機(jī)任務(wù)等，現(xiàn)在大概已有 20+ 個(gè)服務(wù)，每個(gè)服務(wù)都有獨(dú)立的數(shù)據(jù)庫，有獨(dú)立的負(fù)責(zé)人。

這樣就可以做到我自己的代碼我自己來寫，別人都不允許去插手。

此外我們進(jìn)行了推送的多通道化，從上圖可以看到，我們針對每個(gè)司機(jī)選取了兩種推送通道，同時(shí)我們也建議大家在做推送消息時(shí)采取這種方案。

拿小米的手機(jī)來說，“小米”推送通道的到達(dá)率是***的，但小米的通道在華為的手機(jī)上，到達(dá)率不如“個(gè)推”的推送到達(dá)率高。

我們就會(huì)根據(jù)司機(jī)的機(jī)型來選取一個(gè)到達(dá)率***的三方通道。同時(shí)在設(shè)計(jì)上不能有單點(diǎn)，假如說小米的通道出現(xiàn)了問題，那我們的服務(wù)就不可用了，司機(jī)接收不到訂單，用戶的需求就沒法得到滿足。

所以我們還有一個(gè)自研渠道 TCP 通道，這個(gè) TCP 通道除了和我們?nèi)酵ǖ雷鲆粋€(gè)雙通道?；钔猓€可以做一些數(shù)據(jù)的上傳。

這時(shí)的訂單調(diào)度，被稱為探索階段，初期的距離推送效果有限，誰搶到誰就中單，司機(jī)的服務(wù)質(zhì)量我們沒有辦法去評判，補(bǔ)貼也是大眾化的。

所以我們自己研究了一個(gè)按象限推送的方法：

• 首先我先推送一個(gè)很短的距離，比如說我先把一公里以內(nèi)的所有司機(jī)都推送一遍，這時(shí)我是不給補(bǔ)貼的，當(dāng)推完一公里以后沒有人搶，或者是搶的人非常的少，我會(huì)按象限去推。
• 在***個(gè)象限，我給一塊錢補(bǔ)貼，如果沒人搶，第二個(gè)象限給兩塊錢補(bǔ)貼，第三個(gè)象限給三塊錢，這樣逐步地去增加。
• ***當(dāng)司機(jī)搶了單，我們會(huì)根據(jù)司機(jī)的好評、完成率這些方面選擇一個(gè)***質(zhì)的司機(jī)。

分庫分表

前面提到數(shù)據(jù)庫性能已經(jīng)成為瓶頸了，所以這里以一個(gè)用戶服務(wù)給大家講一下我們的分庫分表是怎么做的：

• 業(yè)務(wù)初期，我們一個(gè)庫可以完成支撐所有的訪問。
• 隨著數(shù)據(jù)量的增長，我們做了一些讀寫的分離，把一些讀取 SQL 放在從庫上，但這里給大家一個(gè)建議——訂單狀態(tài)的讀取盡量不要在從庫上讀，網(wǎng)絡(luò)一抖動(dòng)，你的訂單狀態(tài)就很可能會(huì)出現(xiàn)不一致情況。
• 加上從庫，當(dāng)表的數(shù)據(jù)量達(dá)到***，查詢的性能依然會(huì)下降，這樣我們就需要去做水平拆分和垂直拆分。

水平拆分比較簡單，大家也容易理解，而垂直拆分就是比如說我把一個(gè)用戶 10 個(gè)最常用的屬性放到一個(gè)組表里，把不常用的屬性放到另外一張表里面去，這樣可以減少 I/O 的操作，也可以提高整體的產(chǎn)品性能。

• 數(shù)據(jù)庫水平拆分以后，再給拆分后的庫增加從庫。

在這里水平拆分要重點(diǎn)提一下，就是如果資源允許，水平拆分還是建議分庫。

數(shù)據(jù)庫的性能瓶頸也是會(huì)受到硬件設(shè)備和網(wǎng)絡(luò) IO 的影響，如果訪問量持續(xù)增加，數(shù)據(jù)庫還是會(huì)成為瓶頸。

我們的水平拆分有兩種方法：

范圍法：用戶 ID 在 1K 萬以下的放到一個(gè)庫，1K 萬~2KW 以上的放到另外一個(gè)庫，這樣切分簡單，擴(kuò)容也方便，但是會(huì)存在數(shù)據(jù)庫之間的負(fù)載不均勻。

哈希法：根據(jù)用戶 ID 進(jìn)行哈希運(yùn)算，切分簡單，整體負(fù)載比較均衡，平滑遷移可能是需要我們?nèi)ソ鉀Q的難點(diǎn)。

拆分后的問題：

• 部分查詢變慢了：非 patition key 查詢，需要遍歷全部庫，做完水平拆分以后，我們遇到了一個(gè)新的問題，實(shí)用 Patition key 水平拆分，非 patition key 查詢需要掃庫，性能反而變慢了。
• 運(yùn)營需求無法實(shí)現(xiàn)：各種維度統(tǒng)計(jì)，沒辦法聯(lián)表查詢，運(yùn)營小伙伴原來在單庫的時(shí)候，因?yàn)閺?fù)雜 SQL 跑的特別慢，導(dǎo)致無法統(tǒng)計(jì)特別情況，分完庫以后，他連 Join 都用不了，更無法查詢統(tǒng)計(jì)了。

問題分析，“任何脫離業(yè)務(wù)架構(gòu)的設(shè)計(jì)都在耍流氓”：

• 我們拿數(shù)據(jù)庫的 Binlog 日志看了一下，根據(jù)用戶 ID 的訪問大概是占 99%，根據(jù)用戶姓名、手機(jī)號(hào)、Email 的這些屬性的查詢大概只有在 1% 的量。
• 運(yùn)營會(huì)根據(jù)年齡、性別、頭像、登錄時(shí)間、注冊時(shí)間這些復(fù)雜的數(shù)據(jù)去做統(tǒng)計(jì)和分析。

前端解決方案：

• 索引表法：非 Patition key 與 uid 建立索引表，拿非 Patition key 和 uid 做一個(gè)索引表。

這樣我直接通過這個(gè)表和 Patition key 進(jìn)來后先去找一下 uid，這樣就可以找到這個(gè) uid 在哪個(gè)庫，但是增加了一次數(shù)據(jù)庫的查詢。

• 緩存映射法：非 Patition key 與 uid 映射關(guān)系放入緩存，緩存***率高，我們把 Patition key 與 uid 的映射關(guān)系放在緩存里面去，只會(huì)***次比較慢，后面都會(huì)從緩存中取，而且這個(gè)緩存基本上不用淘汰。
• 非 Patition key 生成 uid，根據(jù) Patition key 生成一個(gè) uid，這個(gè)需要一定的生成技巧，同時(shí)這個(gè)可能有主鍵沖突的風(fēng)險(xiǎn)。
• 基因法，根據(jù)非 Patition key 的其中部分基因生成一個(gè)字段，如下圖：

運(yùn)營側(cè)需求解決方案：

• 冗余后臺(tái)庫：通過 MQ/Canal 實(shí)時(shí)同步到后臺(tái)庫，通過 MQ 或者是 Canal 讀取 MySQL 的 binlog，將幾個(gè)前臺(tái)的數(shù)據(jù)庫實(shí)時(shí)地同步到后臺(tái)庫里去，后臺(tái)庫不對前臺(tái)業(yè)務(wù)提供服務(wù)，僅供運(yùn)營側(cè)查詢。

注意這個(gè)后臺(tái)庫是千萬不能用于現(xiàn)場生產(chǎn)的，因?yàn)檫\(yùn)營會(huì)在上面做一些復(fù)雜的慢查詢，數(shù)據(jù)庫的響應(yīng)會(huì)非常慢。

• 外置搜索引擎：ES/Solr/XXXX，接入外鍵索引，如 ES/Solr 提供搜索服務(wù)。
• 大數(shù)據(jù)平臺(tái)，使用大數(shù)據(jù)平臺(tái)，通過 MySQL 的 binlog 和日志上報(bào)，將數(shù)據(jù)讀取到大數(shù)據(jù)平臺(tái)進(jìn)行實(shí)時(shí)地分析，供運(yùn)營查詢。

到了 2016 年，競爭對手基本上已經(jīng)被消滅了，58 速運(yùn)已經(jīng)成為行業(yè)的領(lǐng)頭者了，如何使用更少的補(bǔ)貼獲取***化的收益？

我們有如下幾點(diǎn)反思：

平臺(tái)補(bǔ)貼是不是真的起到了作用，然后我們到底需要補(bǔ)多少錢才能幫助用戶完成訂單？

如何去盡量滿足用戶的需求？每個(gè)新用戶進(jìn)入平臺(tái)是有成本的，一個(gè)用戶的成本在幾十甚至到一百塊左右，如何滿足用戶的需求，讓用戶持續(xù)的留在平臺(tái)中。

平臺(tái)的司機(jī)良莠不齊，司機(jī)的收益應(yīng)如何分配？

第三次技術(shù)演進(jìn)：戰(zhàn)斧項(xiàng)目

我們進(jìn)行了第三次的技術(shù)引進(jìn)，我們稱之為戰(zhàn)斧項(xiàng)目，項(xiàng)目的定義：精準(zhǔn)、高效。

我們做了以下優(yōu)化：

• 策略服務(wù)的細(xì)化
• 智能模型的接入
• 智能的分流框架

智能時(shí)代：效率、精準(zhǔn)

智能模型訓(xùn)練

上圖為智能模型訓(xùn)練圖，首先我們會(huì)將訂單信息、用戶信息、司機(jī)信息、客司關(guān)系信息、訂單總體推送、司機(jī)接單等場景信息統(tǒng)一上傳到大數(shù)據(jù)平臺(tái)。

通過這種歸一化&分桶、XGBoost、特征組合、獨(dú)熱編碼等將這些數(shù)據(jù)分析為特征數(shù)據(jù)。

針對分析出來的特征數(shù)據(jù)，我們需要對它進(jìn)行訓(xùn)練，如：訂單價(jià)格、訂單距離等特征在整個(gè)訂單派單中起到的權(quán)重。

因?yàn)樘卣骱芏?，?jì)算出來的權(quán)重可能并不是一個(gè)***的解，只能說是近優(yōu)、***的一個(gè)解法，通過不斷地迭代優(yōu)化，最終訓(xùn)練出來最終的模型。

訂單-模型運(yùn)用

訂單模型的運(yùn)用：

• 下單階段：在用戶下單時(shí)，我們會(huì)采用這種用戶訂單定價(jià)的模型，觀察這個(gè)訂單所在的商圈的運(yùn)力飽和度，如果司機(jī)少，而訂單需求多，我們會(huì)進(jìn)行一個(gè)訂單的調(diào)價(jià)。
• 推送階段：系統(tǒng)推送的過程中，會(huì)根據(jù)司機(jī)的接單意愿來撈取。有的司機(jī)喜歡高價(jià)格訂單，有的司機(jī)喜歡短程訂單，有的司機(jī)喜歡去中關(guān)村等。我們會(huì)根據(jù)訂單與司機(jī)意愿的匹配程度進(jìn)行優(yōu)先推送的排序。
• 搶單階段：先預(yù)估這個(gè)訂單的接單人數(shù)，計(jì)算出來訂單的價(jià)值，如果訂單的價(jià)值高（價(jià)格高、地點(diǎn)好）、那么這個(gè)訂單不會(huì)發(fā)放補(bǔ)貼了，同時(shí)會(huì)扣取司機(jī)的一些積分或優(yōu)先搶單次數(shù)等。
• 如果訂單價(jià)值比較低（價(jià)格低、偏遠(yuǎn)地區(qū)），會(huì)給這個(gè)訂單適當(dāng)?shù)卦黾友a(bǔ)貼，來確保訂單的完成。
• 指派階段：當(dāng)司機(jī)搶完單以后，我們會(huì)根據(jù)所有司機(jī)歷史完成訂單的數(shù)據(jù)，取司機(jī)的質(zhì)量，來決定哪個(gè)司機(jī)中單，保證訂單盡可能完成。
• 訂單完成階段：訂單完成了以后預(yù)測這個(gè)用戶的流失概率，如果可能流失，會(huì)送一些券或者其他權(quán)益吸引用戶留在平臺(tái)。

派單-智能時(shí)代

上圖是智能派單時(shí)代的系統(tǒng)架構(gòu)圖。用戶在下完單以后，訂單會(huì)進(jìn)入到我們整體的策略系統(tǒng)，它包含推送系統(tǒng)、補(bǔ)貼系統(tǒng)、價(jià)格系統(tǒng)、任務(wù)系統(tǒng)等。

然后通過特征匹配系統(tǒng)，計(jì)算出一個(gè)***的訂單調(diào)度解，將這個(gè)訂單推送到司機(jī)的單隊(duì)列引擎和訂單的排序策略引擎，最終通過我們的推送服務(wù)將訂單推送給司機(jī)。

策略分流+監(jiān)測

智能系統(tǒng)需要有不同的算法在線上實(shí)驗(yàn)，當(dāng)我們一些新算法研發(fā)完成以后，肯定不能用 100% 的流量在線上進(jìn)行驗(yàn)證算法的可行性，如果有問題，會(huì)對線上業(yè)務(wù)產(chǎn)生影響。

我們一般取 5% 或 10% 的流量在線上驗(yàn)證，根據(jù)用戶手機(jī)號(hào)、設(shè)備碼、用戶屬性等，以及取模、集合等方式。對線上算法驗(yàn)證時(shí)，如何實(shí)時(shí)的監(jiān)測算法的效果，避免錯(cuò)誤算法對線上業(yè)務(wù)造成的影響？

如上圖所示，用戶在 APP 中的每個(gè)步驟、運(yùn)用了哪個(gè)算法，我們都會(huì)將用戶的 ID、采用的算法 ID 通過日志上報(bào)到統(tǒng)計(jì)平臺(tái)。業(yè)務(wù)監(jiān)控平臺(tái)會(huì)實(shí)時(shí)進(jìn)行監(jiān)控，對于出現(xiàn)異常的算法就自動(dòng)關(guān)閉分流。

特征計(jì)算

特征數(shù)據(jù)中有 40 多萬個(gè)特征，每個(gè)訂單需要推送給很多個(gè)司機(jī)，需要進(jìn)行上萬次的運(yùn)算，需要在幾十毫秒內(nèi)給出計(jì)算結(jié)果，如何保證計(jì)算的高性能呢？

我們采用的是這種階段性事件驅(qū)動(dòng)的計(jì)算方式來***化提高并行計(jì)算的能力。

如圖所示，這是我們的計(jì)算鏈，里面包含多個(gè) Stage，包含準(zhǔn)備階段、轉(zhuǎn)化階段、取數(shù)階段和計(jì)算階段。

每一個(gè)階段都有自己獨(dú)立的線程池，根據(jù)每個(gè)階段的特征設(shè)置核心線程數(shù)，同時(shí)整個(gè)計(jì)算鏈做到了可插拔的形式，方便業(yè)務(wù)調(diào)整。

利器-監(jiān)控平臺(tái)

監(jiān)控可以說是整個(gè)架構(gòu)演進(jìn)過程中非常重要的部分：

• 再牛逼的算法，也需要穩(wěn)定的系統(tǒng)來支撐。
• 業(yè)務(wù)出現(xiàn)異常，我們肯定要***時(shí)間知曉。
• 提高問題排查效率，就是在挽救損失。

立體化監(jiān)控

目前已經(jīng)做到的監(jiān)控包含：關(guān)鍵字、接口、流量、端口，JVM、CPU、線程、緩存、DB 所有的監(jiān)控等等，同時(shí)還有服務(wù)治理，當(dāng)服務(wù)節(jié)點(diǎn)發(fā)生異常，實(shí)時(shí)切換。

業(yè)務(wù)化的指標(biāo)監(jiān)控，渠道轉(zhuǎn)化率、渠道取消率、渠道推送數(shù)量、異常訂單數(shù)量等等，如果出現(xiàn)異常，***時(shí)間預(yù)警。

調(diào)用跟蹤系統(tǒng)

很多互聯(lián)網(wǎng)公司都已經(jīng)在使用調(diào)用跟蹤系統(tǒng)，目的是需要看到 APP 發(fā)起的每個(gè)請求在整個(gè) Service 后端走過的所有過程，效果如下圖所示，可以監(jiān)控到每一步所調(diào)用的服務(wù)和耗時(shí)。

總結(jié)

***給大家總結(jié)了 5 點(diǎn)經(jīng)驗(yàn)：

• 不同的階段采用不同的架構(gòu)，技術(shù)的重點(diǎn)跟隨業(yè)務(wù)轉(zhuǎn)變。
• 訂單的推送通道，建議使用雙通道，保證推送的到達(dá)率。
• 數(shù)據(jù)庫的水平拆分，在資源允許的情況下，強(qiáng)烈建議分庫。
• 算法線上分流驗(yàn)證必須要有實(shí)時(shí)的監(jiān)控和自動(dòng)流量切換。
• 監(jiān)控很重要，***時(shí)間發(fā)現(xiàn)問題，減少影響。

胡顯波，58 到家技術(shù)經(jīng)理、58 速運(yùn)后端架構(gòu)總負(fù)責(zé)人。2014 年 7 月加入 58 到家，先后負(fù)責(zé) 58 到家 APP、58 小時(shí)工、58 美甲等，見證了 58 到家飛速發(fā)展。2014 年 11 月負(fù)責(zé) 58 速運(yùn)整體業(yè)務(wù)，帶領(lǐng)團(tuán)隊(duì)小伙伴支撐了速運(yùn)業(yè)務(wù)日訂單從 0~50W 的飛速增長。

本文名稱：給奔跑中的火車換輪子，58速運(yùn)訂單調(diào)度系統(tǒng)架構(gòu)大解密
文章來源：http://uogjgqi.cn/article/dposihi.html