今天很榮幸給大家介紹 58 速運從艱苦創業到成為同城貨運行業領頭人的整個系統演進過程。

[[213231]]

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

一般來講，很容易遇到黑車，而且價格不標準，我們做的這個行業就是將這種傳統的黑車行業進行線上化，在產品形態上可理解為滴滴打車的出租車版。

本次分享內容主要分為4個部分：

• 創業之初：快速迭代試錯
• 高速發展：穩定、高效
• 智能時代：效率、精準
• 總結

創業之初：快速迭代試錯

58 速運在 2014 年是作為 58 集團下 20 多個孵化業務中的其中一個，那個時期基本上是平均三個星期一個業務孵化上線，當時有 20 多個業務孵化同時進行。這個時間我們不斷的試錯，不斷去尋找 58 同城新的增長點。

從上圖中，大家可以看到，我們所有的服務都是基于一個數據庫來運行的，這個系統之間只需要通過一些簡單的 tag 標記就可以區分開業務，系統迭代非常快。

對于新孵化的業務，我們增加了一些簡單的業務邏輯就能實現這個產品的快速上線，我們在兩周內實現了速運用戶、商家的 APP 以及后端的產品上線。

派單-石器時代

這時的系統架構是非常簡單的，我們稱之為“石器時代”，當時所有的訂單調度的邏輯放在一個 Jar 包，然后通過 MQTT 服務將訂單推送到司機的 APP 上。

當時的訂單調度（也是我們最初級的訂單調度方案）是一個訂單搜索附近的司機，然后由近到遠的距離將訂單推送出去，司機搶單后即中單。因為在創業階段，我們需要吸引客戶、司機，對于每單都會有補貼。

這個階段面臨的痛點如下：

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

針對以上痛點，我們做了***次的技術引進——遷庫、集群拆分。

***次技術演進：遷庫、集群解耦

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

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

但是停服會產生的影響：

• 凌晨時間業務仍然有訂單，會影響到用戶訪問。
• 需要給用戶發公告。
• 停服遷移如果失敗，無法向業務方解釋，會喪失信任。

我們采用的方案：將訂單表單獨地拆離出來，放在單獨的數據庫里，兩個數據庫之間使用雙向同步。

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

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

經過多次的遷移，將原有的數據庫按照業務劃分成了訂單庫、結算庫、配置庫和軌跡庫等，每個數據庫會根據業務量容量的大小來配置數據庫物理機的內核、內存，減少成本。

高速發展：穩定、高效

2015 年我們進入了高速發展的階段，市場上出現了藍犀牛、1 號貨的、云鳥的等多個強勁的競爭對手。各方都是爭分奪秒，一個系統、功能，我需要抓緊把它給迭代上來，誰也不能比誰落后。

這個階段我們存在的問題：

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

這時我們進行了第二次技術演進，我們稱之為“進行了奔跑中的火車換輪子”，我們進行了服務化解耦；緩存、分庫分表，提升系統性能；接入大數據平臺，進行復雜需求的分析。

第二次技術演進：奔跑中的火車換輪子

派單-鐵器時代

我們將所有的系統都按服務模塊進行了拆分，比如說結算、充值、推送、司機任務等，現在大概已有 20+ 個服務，每個服務都有獨立的數據庫，有獨立的負責人。

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

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

拿小米的手機來說，“小米”推送通道的到達率是***的，但小米的通道在華為的手機上，到達率不如“個推”的推送到達率高。

我們就會根據司機的機型來選取一個到達率***的三方通道。同時在設計上不能有單點，假如說小米的通道出現了問題，那我們的服務就不可用了，司機接收不到訂單，用戶的需求就沒法得到滿足。

所以我們還有一個自研渠道 TCP 通道，這個 TCP 通道除了和我們三方通道做一個雙通道?；钔猓€可以做一些數據的上傳。

這時的訂單調度，被稱為探索階段，初期的距離推送效果有限，誰搶到誰就中單，司機的服務質量我們沒有辦法去評判，補貼也是大眾化的。

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

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

分庫分表

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

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

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

• 數據庫水平拆分以后，再給拆分后的庫增加從庫。

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

數據庫的性能瓶頸也是會受到硬件設備和網絡 IO 的影響，如果訪問量持續增加，數據庫還是會成為瓶頸。

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

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

哈希法：根據用戶 ID 進行哈希運算，切分簡單，整體負載比較均衡，平滑遷移可能是需要我們去解決的難點。

拆分后的問題：

• 部分查詢變慢了：非 patition key 查詢，需要遍歷全部庫，做完水平拆分以后，我們遇到了一個新的問題，實用 Patition key 水平拆分，非 patition key 查詢需要掃庫，性能反而變慢了。
• 運營需求無法實現：各種維度統計，沒辦法聯表查詢，運營小伙伴原來在單庫的時候，因為復雜 SQL 跑的特別慢，導致無法統計特別情況，分完庫以后，他連 Join 都用不了，更無法查詢統計了。

問題分析，“任何脫離業務架構的設計都在耍流氓”：

• 我們拿數據庫的 Binlog 日志看了一下，根據用戶 ID 的訪問大概是占 99%，根據用戶姓名、手機號、Email 的這些屬性的查詢大概只有在 1% 的量。
• 運營會根據年齡、性別、頭像、登錄時間、注冊時間這些復雜的數據去做統計和分析。

前端解決方案：

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

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

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

運營側需求解決方案：

• 冗余后臺庫：通過 MQ/Canal 實時同步到后臺庫，通過 MQ 或者是 Canal 讀取 MySQL 的 binlog，將幾個前臺的數據庫實時地同步到后臺庫里去，后臺庫不對前臺業務提供服務，僅供運營側查詢。

注意這個后臺庫是千萬不能用于現場生產的，因為運營會在上面做一些復雜的慢查詢，數據庫的響應會非常慢。

• 外置搜索引擎：ES/Solr/XXXX，接入外鍵索引，如 ES/Solr 提供搜索服務。
• 大數據平臺，使用大數據平臺，通過 MySQL 的 binlog 和日志上報，將數據讀取到大數據平臺進行實時地分析，供運營查詢。

到了 2016 年，競爭對手基本上已經被消滅了，58 速運已經成為行業的領頭者了，如何使用更少的補貼獲取***化的收益？

我們有如下幾點反思：

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

如何去盡量滿足用戶的需求？每個新用戶進入平臺是有成本的，一個用戶的成本在幾十甚至到一百塊左右，如何滿足用戶的需求，讓用戶持續的留在平臺中。

平臺的司機良莠不齊，司機的收益應如何分配？

第三次技術演進：戰斧項目

我們進行了第三次的技術引進，我們稱之為戰斧項目，項目的定義：精準、高效。

我們做了以下優化：

• 策略服務的細化
• 智能模型的接入
• 智能的分流框架

智能時代：效率、精準

智能模型訓練

上圖為智能模型訓練圖，首先我們會將訂單信息、用戶信息、司機信息、客司關系信息、訂單總體推送、司機接單等場景信息統一上傳到大數據平臺。

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

針對分析出來的特征數據，我們需要對它進行訓練，如：訂單價格、訂單距離等特征在整個訂單派單中起到的權重。

因為特征很多，計算出來的權重可能并不是一個***的解，只能說是近優、***的一個解法，通過不斷地迭代優化，最終訓練出來最終的模型。

訂單-模型運用

訂單模型的運用：

• 下單階段：在用戶下單時，我們會采用這種用戶訂單定價的模型，觀察這個訂單所在的商圈的運力飽和度，如果司機少，而訂單需求多，我們會進行一個訂單的調價。
• 推送階段：系統推送的過程中，會根據司機的接單意愿來撈取。有的司機喜歡高價格訂單，有的司機喜歡短程訂單，有的司機喜歡去中關村等。我們會根據訂單與司機意愿的匹配程度進行優先推送的排序。
• 搶單階段：先預估這個訂單的接單人數，計算出來訂單的價值，如果訂單的價值高（價格高、地點好）、那么這個訂單不會發放補貼了，同時會扣取司機的一些積分或優先搶單次數等。
• 如果訂單價值比較低（價格低、偏遠地區），會給這個訂單適當地增加補貼，來確保訂單的完成。
• 指派階段：當司機搶完單以后，我們會根據所有司機歷史完成訂單的數據，取司機的質量，來決定哪個司機中單，保證訂單盡可能完成。
• 訂單完成階段：訂單完成了以后預測這個用戶的流失概率，如果可能流失，會送一些券或者其他權益吸引用戶留在平臺。

派單-智能時代

上圖是智能派單時代的系統架構圖。用戶在下完單以后，訂單會進入到我們整體的策略系統，它包含推送系統、補貼系統、價格系統、任務系統等。

然后通過特征匹配系統，計算出一個***的訂單調度解，將這個訂單推送到司機的單隊列引擎和訂單的排序策略引擎，最終通過我們的推送服務將訂單推送給司機。

策略分流+監測

智能系統需要有不同的算法在線上實驗，當我們一些新算法研發完成以后，肯定不能用 100% 的流量在線上進行驗證算法的可行性，如果有問題，會對線上業務產生影響。

我們一般取 5% 或 10% 的流量在線上驗證，根據用戶手機號、設備碼、用戶屬性等，以及取模、集合等方式。對線上算法驗證時，如何實時的監測算法的效果，避免錯誤算法對線上業務造成的影響？

如上圖所示，用戶在 APP 中的每個步驟、運用了哪個算法，我們都會將用戶的 ID、采用的算法 ID 通過日志上報到統計平臺。業務監控平臺會實時進行監控，對于出現異常的算法就自動關閉分流。

特征計算

特征數據中有 40 多萬個特征，每個訂單需要推送給很多個司機，需要進行上萬次的運算，需要在幾十毫秒內給出計算結果，如何保證計算的高性能呢？

我們采用的是這種階段性事件驅動的計算方式來***化提高并行計算的能力。

如圖所示，這是我們的計算鏈，里面包含多個 Stage，包含準備階段、轉化階段、取數階段和計算階段。

每一個階段都有自己獨立的線程池，根據每個階段的特征設置核心線程數，同時整個計算鏈做到了可插拔的形式，方便業務調整。

利器-監控平臺

監控可以說是整個架構演進過程中非常重要的部分：

• 再牛逼的算法，也需要穩定的系統來支撐。
• 業務出現異常，我們肯定要***時間知曉。
• 提高問題排查效率，就是在挽救損失。

立體化監控

目前已經做到的監控包含：關鍵字、接口、流量、端口，JVM、CPU、線程、緩存、DB 所有的監控等等，同時還有服務治理，當服務節點發生異常，實時切換。

業務化的指標監控，渠道轉化率、渠道取消率、渠道推送數量、異常訂單數量等等，如果出現異常，***時間預警。

調用跟蹤系統

很多互聯網公司都已經在使用調用跟蹤系統，目的是需要看到 APP 發起的每個請求在整個 Service 后端走過的所有過程，效果如下圖所示，可以監控到每一步所調用的服務和耗時。

總結

***給大家總結了 5 點經驗：

• 不同的階段采用不同的架構，技術的重點跟隨業務轉變。
• 訂單的推送通道，建議使用雙通道，保證推送的到達率。
• 數據庫的水平拆分，在資源允許的情況下，強烈建議分庫。
• 算法線上分流驗證必須要有實時的監控和自動流量切換。
• 監控很重要，***時間發現問題，減少影響。

[[213239]]

胡顯波，58 到家技術經理、58 速運后端架構總負責人。2014 年 7 月加入 58 到家，先后負責 58 到家 APP、58 小時工、58 美甲等，見證了 58 到家飛速發展。2014 年 11 月負責 58 速運整體業務，帶領團隊小伙伴支撐了速運業務日訂單從 0~50W 的飛速增長。