很高興有這次機會，跟大家分享一下我們 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 採集之後展現出來就行了。
總結
最後總結一下，準確的理解需求很重要，架構是為業務服務的；碰到一個大的需求，對需求進行拆分，由簡單到複雜的拆分；根據業務需求進行合適的技術選型，任何脫離業務的架構設計都是耍流氓，監控特別的重要，謝謝大家。
張凱，58 速運後端平臺部負責人。7 年開發經驗，涉及 CRM、微信錢包、卡券系統等；參與 58 到家錢包入口的優化拆分改版，保證了系統平穩過渡；參與 58 大促，保證了大促期間卡券系統的穩定運行。現在負責後端平臺的開發工作。
閱讀更多 51CTO傳媒 的文章
