很高興有這次機會，跟大家分享一下我們 58 速運微信小程序的事件。我是后端平臺的負責人，從 2017 年底開始負責我們 58 速運的微信小程序的開發工作。

本次分享主要從以下幾個方面來進行：

• 58 速運模式
• 小程序的意義
• 小程序架構實戰
• 總結

58 速運模式

58 速運是覆蓋中國及東南亞地區的同城貨運平臺，2018 年開始了全新的速運 2.0 時代：

速運模式

司機通過司機加盟的流程加入到我們，登錄司機端 APP，就可以開始接單了；而用戶通過 APP 或者是用戶端的 H5 登錄上去，可以跟司機下單，我們的推送系統經過一系列的算法，推送給附近的司機，然后司機搶單，到達目的地，將賬單發送給用戶，用戶確定定單、收款，這個過程就結束了。

小程序的意義

那么問題來了，有了我們司機端的 APP 和用戶端，為什么還要做微信小程序呢，它對我們的 58 速運究竟有什么意義呢？

首先來解釋一下什么是速運的 2.0。

在舊的 1.0 時代，司機只能通過加盟接單，并且想要成功接單還需要一系列的審核流程，因為我們要保證服務質量，之后再登錄我們的 APP 才能完成。

我們對司機有一系列的審核、管理工作。用戶登錄我們的 APP 以后，只能給我們的平臺司機下單。

速運 2.0 就是要把這個中心化的過程打破，要做去中心化的過程。

司機只要登錄了司機端的微信小程序就能夠接單，不用加盟；用戶登錄微信小程序，就能給所有的司機下單，不管這個司機是否在我們的平臺注冊過。

小程序的架構實戰

現有架構

這是現有的架構，如上圖：

• 接入層有安卓、iOS、H5；
• 服務層就是司機端服務、用戶端服務，定單服務、派單服務；
• 數據層比如說 ES、DB 等等。

可以看到，我們的服務層都是一個個大而全的系統，業務發展的過程中，前期的業務功能并不復雜，一個系統一個服務就能夠滿足我們所有的業務現狀，而且開發起來也比較快。

當我們的業務達到了一定的量級之后，這一個大而全的服務就會阻礙我們業務的發展，我們很多的團隊在維護一個服務，就會出現很多的問題。

比如說我們開發的過程中就會有上線沖突；當業務達到一定的量級之后，DB 壓力也很大。我們現在正在進行的一項工作就是對服務和 DB 的一個拆分。

小程序功能

架構肯定是為業務而設計的，那么我們的小程序有哪些功能？

對于用戶來說，首先就是有一個會員商品的售賣；其次，用戶只要購買了我們的會員商品，就會有一些會員等級；此外還有收藏司機的功能、用推廣碼下單的功能，如果用戶掃描了這個碼，就可以直接給司機下單。

那么針對司機來說有哪些功能？就是登錄了微信小程序后會有一個二維碼，司機可以自主接單。

面對這些功能，我們的思路是：

• 避免大而全，我們就要對這些功能進行一個個的拆分，拆分成一個個的服務；
• 從簡單的開始著手，逐步進行細化的過程；
• 微服務的架構，方便后續的拓展和維護。

會員服務和用戶等級

來分析一下會員服務和用戶等級。為什么把它們兩個一塊兒說？因為它們的核心功能點比較相似：

• 會員服務就是買了會員商品后會有的等級和特權；
• 而如果用戶一個月下單數達到一定的階段，就會有用戶的等級和特權。

它們的核心功能點就是級別的展示、授權以及定期的發券。

首先是 Web 層，還有服務層。有升級就有降級，針對降級，我們使用的是定時任務來處理。

如果你單機部署，那這臺機器掛了怎么辦？如果是部署多臺，那同時跑了怎么辦？

我們有一個自研的基于 ZK 的調度平臺，在跑的時候，首先會出一個臨時節點，說明自己在跑，當機器掛掉之后，節點就消失；另一個到達時間節點的時候，就會在另外的一個機器上面跑，保證一個時間點只能有一個機器在跑這個 Job。

我們的用戶等級升級是要求比較高的，比如說用戶買了一個商品，立馬就希望等級升上去。我們使用了一個消息隊列，保證我們收到消息之后，立馬把用戶的等級升上去。

還有定時發券的場景，我們使用了延時消息，我們在用戶發券之后去判斷是否還需要發券，如果還需要的話，就接著發一個延時消息。

用戶等級服務的核心功能點之一，是根據用戶當月的訂單數來實時地更新用戶等級。

一般情況下，統計當月的訂單數，都是使用定時任務每隔一段時間去計算。但是，因為我們對實時性要求較高，這樣做并不合適。

所以我們使用了接收訂單完成的 MQ 來實時進行計算。我們的做法是，先根據 MQ 實時更新每天的訂單數，保證每天的訂單數可查，同時更新每月的訂單數。

通常情況下，在更新當月的訂單數之前或者是之后，只需要清除一次緩存就行了，但是我們清除了兩次，為什么？

用戶訪問了自己的用戶等級，可能會出現一種情況就是用戶看到的這個數據并不對，數據不一致。使用雙緩存清除法能解決這個問題。流程如下圖所示：

商品服務

會員商品服務的典型場景有四種：

• 讀多寫少；
• 商品不可變；
• 針對單個的商品和用戶是有一個限購的條件的；
• 商品有可能會有一些庫存的限制。

比如說我就想賣 100 個，針對這個場景我們能不能很簡單的一個 Web、一個服務加上存儲就搞得定呢？如果商品賣出去了，緩存是不是就失效了？

我們如何保證商品緩存的時效性？如果我的庫存這一塊兒出現了問題，那是不是商品會受到影響？比如說庫存導致我們的服務掛了，那商品直接看不到……

針對這些問題，我們處理的方式：

• 首先就是將這個可變的數據隔離，將商品服務不做成一個服務；
• 針對消息一經發布不可變，而且訪問量很大的問題，可以通過加緩存來緩解壓力；
• 至于怎么保持庫存的一致性，就是用 CAS 樂觀鎖來保證庫存服務的效率。

司機的 GPS 服務

我們是一個同城貨運平臺，大部分的場景是用戶下單，司機接單。我們有 100 萬的注冊司機，要保證司機實時的 GPS 位置準確，2 秒鐘上傳一次 GPS，這個請求量是特別大的。

但 GPS 的服務對我們的實時性的要求又非常高，所以 MySQL 的壓力非常大，如果再上一個層次，MySQL 肯定扛不??；如果放在緩存里面，又有另外的問題，也就是緩存無法搜索的情況；還有怎么樣提高處理效率的問題。

針對這幾個問題，我們的做法：

使用了生產者消費者模式，生產者發送 MQ 給消費者，消費者本身是一個 Job。接到消息后，先進行時效性的判斷，如果超時，直接丟棄。

如果沒有超時，異步調用 GPS 服務。GPS 服務接到調用后，先放到一個隊列里面，然后后臺有一個線程，批量地進行 ES 的存儲。

訂單服務

現狀：

我們碰到的問題，主要是老訂單因為業務的發展對我們的小程序已經不太適用；老訂單的服務根據前臺的業務進行了一個分表的處理，后臺是一個單表，我們后臺的單表查詢會非常的慢。

前后臺是采用了 canal 的方式同步的，最大的時候前后臺訂單有 6 個小時的同步，目前訂單已經是 40 萬的數據了。之前前臺的訂單服務、后臺的訂單服務包括訂單的 ES 服務，很多人在調用的時候其實根本不知道調用哪些服務。

我們的思路，第一，訂單服務要統一成一個；第二，我們要采用分庫的方式來實現。

一般有水平拆分和垂直拆分：

第一想到的就是能不能把我們的數據進行一個隔離，比如說按照時間段做一個垂直的，2017 年的放一個庫，2018 年的放一個庫。

第二，水平的拆庫拆表。首先用戶肯定要查詢自己的訂單列表的，司機也需要查詢，然后大部分的場景其實是司機的查看訂單詳情，還有我們公司自己的后臺的運營人員，有一些復雜的查詢。

那么如何確定我們的分庫方案？

按照時間緯度的優點是訂單分到最新時間段的庫，直接查就行了，缺點在于如何確定時間緯度，一個月、一個季度或者是一兩年。

還有一個問題就是說，如果確定了時間緯度之后，訂單還有大的增長怎么辦？我們的庫是提前建好還是動態申請，資源上面也要權衡。

水平拆分，訂單如果再有一個上升的階段，就直接橫向擴展了。我們也要解決跨庫查詢，也需要訂閱方案。

我們 85% 的查詢是根據訂單的 ID 來查詢的，比如說大部分的司機搶單，查看訂單詳情；用戶下單查看詳情之類的。

接下來會有 10% 的用戶查看自己的 ID，我到底下了哪些單，或者是歷史的訂單是什么樣子的。

還有 4% 是根據司機的場景來查詢，只是偶爾空閑的時候他才會查自己今天搶多少單，最后只有 1% 的后臺復雜查詢，所以可以往后考慮。

如果需要滿足 85% 的場景，根據用戶 ID 來取模行不行？但是問題是司機 ID 的列表查詢怎么來解決呢？方案就是索引表。

我需要查詢任務，根據業務和訂單 ID 來建立索引表，就可以查到所有的訂單，然后能確定每一個庫，就能搞定場景。

但是我們的數據量達到一定的階段，索引表也需要分庫怎么辦？這樣所有的用戶的東西都在一個庫里面，查詢用戶列表的時候就不用分庫了，這樣解決了我們 10% 的問題，那 80% 多的問題怎么解決？就是基因法。

根據用戶 ID 得到的數字，其實就是我們的分庫基因，大家都知道 Java 里面是 64 位的數字，前 40 位用做一個時間，這個時間并不是說我們直接調用系統的當前時間，而是拿 2018 年，拿一個固定的起始時間。

比如說 2018 年 1 月 1 號，再用當前的時間減去起始時間的毫秒數，得到的時間左移 23 位，放到我們的 40 位的位置。

接下來的是我們的機器位，為什么會這樣呢？因為我們的 ID 生成器不可能是在單機上面用的，是在多個機器上面用。

接下來的是我們的分庫基因，還有自動的序列，是為了保證同一毫秒生成的 ID 不會有重復。

比如說同一秒內支持的 ID 生成是 6 萬多個，如果不夠用怎么辦？將時間的秒數量再加一就可以了。

ID 生成搞定了，怎么根據這個生成找到我們所在的庫？下面這個其實就是一個反向的過程，能確定到我們的一個庫。

解決了 95% 的場景，剩下的怎么搞？使用 ES 就行了。

 

因為司機不會實時的去查看自己的訂單，運維人員對訂單的實時性要求也并不高，所以說直接使用 ES 就行了，最后我們的訂單服務就是這個樣子。

做一個總結，就是按照用戶的緯度來分布，訂單 ID 使用 Snowflake 算法生成，訂單中記錄分庫因子，然后復雜查詢使用 ES 來解決。

老舊服務的兼容

這樣的話訂單服務并沒有完，我們還有老舊的服務必須做一個兼容：

針對訂單的寫，我們是做了一個雙寫，寫了新訂單之后，會去同步寫一次老訂單；針對訂單的讀，我們是先查詢新訂單，如果查不到，會在老訂單里面查一遍再返回客戶端；我們對歷史數據也有一套完整的遷移方案。

推送服務的改造

微信小程序還涉及到了推送服務的兩個方面的改造：

因為我們新增了兩種推送模式：

• 一對一的推送，相對來說比較簡單，下單的時候，如果用戶選擇的是一對一推送的，比如說用戶只選了一個司機，我們就默認司機就是中單了，不管這個司機在不在線，如果能推給司機就推給他，如果不能推給他，就給他發一個短信。
• 一對多的推送，省去了推送的算法，用戶選擇多個司機，然后我們的系統根據用戶篩選的司機，挑選出在線的列表，然后全部推送給那些司機，直到司機又搶單就結束了。

這是我們改造之后的一個微信小程序的總體架構圖：

我們分了接入層、業務層、服務層、基礎服務、數據層。接入層就是對每一個服務做了一個劃分，進行了一層業務的評定之類的，反饋給我們的接入層。

我們的程序想要上線，首先要接入我們的服務治理平臺：

我們的服務治理平臺會提供一些功能：

• 動態機器的管理，比如說我們的業務撐不住了，可以通過這個加一點機器；
• 對整個服務的流量的監控；
• 訪問耗時的監控；
• 還有我們的拋棄量監控。

接下來就是接入我們的監控平臺，會有針對的關鍵字監控，也有 URL 的監控，針對不同的監控有一些監控的策略。

最后就是接入我們的 Dtrack 調用鏈，可以知道整個服務之間的調用關系：

如果服務的量級上來了，那么我們可能自己都不知道是調用了哪個服務，它的層次關系靠人已經分不清了。如果接入調用鏈的話，會打印出一個服務的清晰的調用關系。

• 它給我們提供了全局跟蹤，比如說調用了哪些服務，耗時有多少；
• 哪個服務有問題的，會立馬有一個異常的報警；
• 針對服務之間會有清晰調用結構；
• 對整個服務也會有一個效果監測。

它的技術點在哪兒：

我們在框架里面提供了插件，每一次調用的時候，就會形成 traceid，通過框架傳遞下去，每調用一個服務，它的 ID 會 +1。將這些調用關系通過日志打印出來，通過 Flume 采集之后展現出來就行了。

總結

最后總結一下，準確的理解需求很重要，架構是為業務服務的；碰到一個大的需求，對需求進行拆分，由簡單到復雜的拆分；根據業務需求進行合適的技術選型，任何脫離業務的架構設計都是耍流氓，監控特別的重要，謝謝大家。

[[240860]]

張凱，58 速運后端平臺部負責人。7 年開發經驗，涉及 CRM、微信錢包、卡券系統等；參與 58 到家錢包入口的優化拆分改版，保證了系統平穩過渡；參與 58 大促，保證了大促期間卡券系統的穩定運行?，F在負責后端平臺的開發工作。