很高興有這次機(jī)會(huì)，跟大家分享一下我們 58 速運(yùn)微信小程序的事件。我是后端平臺(tái)的負(fù)責(zé)人，從 2017 年底開始負(fù)責(zé)我們 58 速運(yùn)的微信小程序的開發(fā)工作。

本次分享主要從以下幾個(gè)方面來進(jìn)行：

• 58 速運(yùn)模式
• 小程序的意義
• 小程序架構(gòu)實(shí)戰(zhàn)
• 總結(jié)

58 速運(yùn)模式

58 速運(yùn)是覆蓋中國(guó)及東南亞地區(qū)的同城貨運(yùn)平臺(tái)，2018 年開始了全新的速運(yùn) 2.0 時(shí)代：

速運(yùn)模式

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

小程序的意義

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

首先來解釋一下什么是速運(yùn)的 2.0。

在舊的 1.0 時(shí)代，司機(jī)只能通過加盟接單，并且想要成功接單還需要一系列的審核流程，因?yàn)槲覀円ＷC服務(wù)質(zhì)量，之后再登錄我們的 APP 才能完成。

我們對(duì)司機(jī)有一系列的審核、管理工作。用戶登錄我們的 APP 以后，只能給我們的平臺(tái)司機(jī)下單。

速運(yùn) 2.0 就是要把這個(gè)中心化的過程打破，要做去中心化的過程。

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

小程序的架構(gòu)實(shí)戰(zhàn)

現(xiàn)有架構(gòu)

這是現(xiàn)有的架構(gòu)，如上圖：

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

可以看到，我們的服務(wù)層都是一個(gè)個(gè)大而全的系統(tǒng)，業(yè)務(wù)發(fā)展的過程中，前期的業(yè)務(wù)功能并不復(fù)雜，一個(gè)系統(tǒng)一個(gè)服務(wù)就能夠滿足我們所有的業(yè)務(wù)現(xiàn)狀，而且開發(fā)起來也比較快。

當(dāng)我們的業(yè)務(wù)達(dá)到了一定的量級(jí)之后，這一個(gè)大而全的服務(wù)就會(huì)阻礙我們業(yè)務(wù)的發(fā)展，我們很多的團(tuán)隊(duì)在維護(hù)一個(gè)服務(wù)，就會(huì)出現(xiàn)很多的問題。

比如說我們開發(fā)的過程中就會(huì)有上線沖突；當(dāng)業(yè)務(wù)達(dá)到一定的量級(jí)之后，DB 壓力也很大。我們現(xiàn)在正在進(jìn)行的一項(xiàng)工作就是對(duì)服務(wù)和 DB 的一個(gè)拆分。

小程序功能

架構(gòu)肯定是為業(yè)務(wù)而設(shè)計(jì)的，那么我們的小程序有哪些功能？

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

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

面對(duì)這些功能，我們的思路是：

• 避免大而全，我們就要對(duì)這些功能進(jìn)行一個(gè)個(gè)的拆分，拆分成一個(gè)個(gè)的服務(wù)；
• 從簡(jiǎn)單的開始著手，逐步進(jìn)行細(xì)化的過程；
• 微服務(wù)的架構(gòu)，方便后續(xù)的拓展和維護(hù)。

會(huì)員服務(wù)和用戶等級(jí)

來分析一下會(huì)員服務(wù)和用戶等級(jí)。為什么把它們兩個(gè)一塊兒說？因?yàn)樗鼈兊暮诵墓δ茳c(diǎn)比較相似：

• 會(huì)員服務(wù)就是買了會(huì)員商品后會(huì)有的等級(jí)和特權(quán)；
• 而如果用戶一個(gè)月下單數(shù)達(dá)到一定的階段，就會(huì)有用戶的等級(jí)和特權(quán)。

它們的核心功能點(diǎn)就是級(jí)別的展示、授權(quán)以及定期的發(fā)券。

首先是 Web 層，還有服務(wù)層。有升級(jí)就有降級(jí)，針對(duì)降級(jí)，我們使用的是定時(shí)任務(wù)來處理。

如果你單機(jī)部署，那這臺(tái)機(jī)器掛了怎么辦？如果是部署多臺(tái)，那同時(shí)跑了怎么辦？

我們有一個(gè)自研的基于 ZK 的調(diào)度平臺(tái)，在跑的時(shí)候，首先會(huì)出一個(gè)臨時(shí)節(jié)點(diǎn)，說明自己在跑，當(dāng)機(jī)器掛掉之后，節(jié)點(diǎn)就消失；另一個(gè)到達(dá)時(shí)間節(jié)點(diǎn)的時(shí)候，就會(huì)在另外的一個(gè)機(jī)器上面跑，保證一個(gè)時(shí)間點(diǎn)只能有一個(gè)機(jī)器在跑這個(gè) Job。

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

還有定時(shí)發(fā)券的場(chǎng)景，我們使用了延時(shí)消息，我們?cè)谟脩舭l(fā)券之后去判斷是否還需要發(fā)券，如果還需要的話，就接著發(fā)一個(gè)延時(shí)消息。

用戶等級(jí)服務(wù)的核心功能點(diǎn)之一，是根據(jù)用戶當(dāng)月的訂單數(shù)來實(shí)時(shí)地更新用戶等級(jí)。

一般情況下，統(tǒng)計(jì)當(dāng)月的訂單數(shù)，都是使用定時(shí)任務(wù)每隔一段時(shí)間去計(jì)算。但是，因?yàn)槲覀儗?duì)實(shí)時(shí)性要求較高，這樣做并不合適。

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

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

用戶訪問了自己的用戶等級(jí)，可能會(huì)出現(xiàn)一種情況就是用戶看到的這個(gè)數(shù)據(jù)并不對(duì)，數(shù)據(jù)不一致。使用雙緩存清除法能解決這個(gè)問題。流程如下圖所示：

商品服務(wù)

會(huì)員商品服務(wù)的典型場(chǎng)景有四種：

• 讀多寫少；
• 商品不可變；
• 針對(duì)單個(gè)的商品和用戶是有一個(gè)限購(gòu)的條件的；
• 商品有可能會(huì)有一些庫(kù)存的限制。

比如說我就想賣 100 個(gè)，針對(duì)這個(gè)場(chǎng)景我們能不能很簡(jiǎn)單的一個(gè) Web、一個(gè)服務(wù)加上存儲(chǔ)就搞得定呢？如果商品賣出去了，緩存是不是就失效了？

我們?nèi)绾伪ＷC商品緩存的時(shí)效性？如果我的庫(kù)存這一塊兒出現(xiàn)了問題，那是不是商品會(huì)受到影響？比如說庫(kù)存導(dǎo)致我們的服務(wù)掛了，那商品直接看不到……

針對(duì)這些問題，我們處理的方式：

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

司機(jī)的 GPS 服務(wù)

我們是一個(gè)同城貨運(yùn)平臺(tái)，大部分的場(chǎng)景是用戶下單，司機(jī)接單。我們有 100 萬的注冊(cè)司機(jī)，要保證司機(jī)實(shí)時(shí)的 GPS 位置準(zhǔn)確，2 秒鐘上傳一次 GPS，這個(gè)請(qǐng)求量是特別大的。

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

針對(duì)這幾個(gè)問題，我們的做法：

使用了生產(chǎn)者消費(fèi)者模式，生產(chǎn)者發(fā)送 MQ 給消費(fèi)者，消費(fèi)者本身是一個(gè) Job。接到消息后，先進(jìn)行時(shí)效性的判斷，如果超時(shí)，直接丟棄。

如果沒有超時(shí)，異步調(diào)用 GPS 服務(wù)。GPS 服務(wù)接到調(diào)用后，先放到一個(gè)隊(duì)列里面，然后后臺(tái)有一個(gè)線程，批量地進(jìn)行 ES 的存儲(chǔ)。

訂單服務(wù)

現(xiàn)狀：

我們碰到的問題，主要是老訂單因?yàn)闃I(yè)務(wù)的發(fā)展對(duì)我們的小程序已經(jīng)不太適用；老訂單的服務(wù)根據(jù)前臺(tái)的業(yè)務(wù)進(jìn)行了一個(gè)分表的處理，后臺(tái)是一個(gè)單表，我們后臺(tái)的單表查詢會(huì)非常的慢。

前后臺(tái)是采用了 canal 的方式同步的，最大的時(shí)候前后臺(tái)訂單有 6 個(gè)小時(shí)的同步，目前訂單已經(jīng)是 40 萬的數(shù)據(jù)了。之前前臺(tái)的訂單服務(wù)、后臺(tái)的訂單服務(wù)包括訂單的 ES 服務(wù)，很多人在調(diào)用的時(shí)候其實(shí)根本不知道調(diào)用哪些服務(wù)。

我們的思路，第一，訂單服務(wù)要統(tǒng)一成一個(gè)；第二，我們要采用分庫(kù)的方式來實(shí)現(xiàn)。

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

第一想到的就是能不能把我們的數(shù)據(jù)進(jìn)行一個(gè)隔離，比如說按照時(shí)間段做一個(gè)垂直的，2017 年的放一個(gè)庫(kù)，2018 年的放一個(gè)庫(kù)。

第二，水平的拆庫(kù)拆表。首先用戶肯定要查詢自己的訂單列表的，司機(jī)也需要查詢，然后大部分的場(chǎng)景其實(shí)是司機(jī)的查看訂單詳情，還有我們公司自己的后臺(tái)的運(yùn)營(yíng)人員，有一些復(fù)雜的查詢。

那么如何確定我們的分庫(kù)方案？

按照時(shí)間緯度的優(yōu)點(diǎn)是訂單分到最新時(shí)間段的庫(kù)，直接查就行了，缺點(diǎn)在于如何確定時(shí)間緯度，一個(gè)月、一個(gè)季度或者是一兩年。

還有一個(gè)問題就是說，如果確定了時(shí)間緯度之后，訂單還有大的增長(zhǎng)怎么辦？我們的庫(kù)是提前建好還是動(dòng)態(tài)申請(qǐng)，資源上面也要權(quán)衡。

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

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

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

還有 4% 是根據(jù)司機(jī)的場(chǎng)景來查詢，只是偶爾空閑的時(shí)候他才會(huì)查自己今天搶多少單，最后只有 1% 的后臺(tái)復(fù)雜查詢，所以可以往后考慮。

如果需要滿足 85% 的場(chǎng)景，根據(jù)用戶 ID 來取模行不行？但是問題是司機(jī) ID 的列表查詢?cè)趺磥斫鉀Q呢？方案就是索引表。

我需要查詢?nèi)蝿?wù)，根據(jù)業(yè)務(wù)和訂單 ID 來建立索引表，就可以查到所有的訂單，然后能確定每一個(gè)庫(kù)，就能搞定場(chǎng)景。

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

根據(jù)用戶 ID 得到的數(shù)字，其實(shí)就是我們的分庫(kù)基因，大家都知道 Java 里面是 64 位的數(shù)字，前 40 位用做一個(gè)時(shí)間，這個(gè)時(shí)間并不是說我們直接調(diào)用系統(tǒng)的當(dāng)前時(shí)間，而是拿 2018 年，拿一個(gè)固定的起始時(shí)間。

比如說 2018 年 1 月 1 號(hào)，再用當(dāng)前的時(shí)間減去起始時(shí)間的毫秒數(shù)，得到的時(shí)間左移 23 位，放到我們的 40 位的位置。

接下來的是我們的機(jī)器位，為什么會(huì)這樣呢？因?yàn)槲覀兊?ID 生成器不可能是在單機(jī)上面用的，是在多個(gè)機(jī)器上面用。

接下來的是我們的分庫(kù)基因，還有自動(dòng)的序列，是為了保證同一毫秒生成的 ID 不會(huì)有重復(fù)。

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

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

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

 

因?yàn)樗緳C(jī)不會(huì)實(shí)時(shí)的去查看自己的訂單，運(yùn)維人員對(duì)訂單的實(shí)時(shí)性要求也并不高，所以說直接使用 ES 就行了，最后我們的訂單服務(wù)就是這個(gè)樣子。

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

老舊服務(wù)的兼容

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

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

推送服務(wù)的改造

微信小程序還涉及到了推送服務(wù)的兩個(gè)方面的改造：

因?yàn)槲覀冃略隽藘煞N推送模式：

• 一對(duì)一的推送，相對(duì)來說比較簡(jiǎn)單，下單的時(shí)候，如果用戶選擇的是一對(duì)一推送的，比如說用戶只選了一個(gè)司機(jī)，我們就默認(rèn)司機(jī)就是中單了，不管這個(gè)司機(jī)在不在線，如果能推給司機(jī)就推給他，如果不能推給他，就給他發(fā)一個(gè)短信。
• 一對(duì)多的推送，省去了推送的算法，用戶選擇多個(gè)司機(jī)，然后我們的系統(tǒng)根據(jù)用戶篩選的司機(jī)，挑選出在線的列表，然后全部推送給那些司機(jī)，直到司機(jī)又搶單就結(jié)束了。

這是我們改造之后的一個(gè)微信小程序的總體架構(gòu)圖：

我們分了接入層、業(yè)務(wù)層、服務(wù)層、基礎(chǔ)服務(wù)、數(shù)據(jù)層。接入層就是對(duì)每一個(gè)服務(wù)做了一個(gè)劃分，進(jìn)行了一層業(yè)務(wù)的評(píng)定之類的，反饋給我們的接入層。

我們的程序想要上線，首先要接入我們的服務(wù)治理平臺(tái)：

我們的服務(wù)治理平臺(tái)會(huì)提供一些功能：

• 動(dòng)態(tài)機(jī)器的管理，比如說我們的業(yè)務(wù)撐不住了，可以通過這個(gè)加一點(diǎn)機(jī)器；
• 對(duì)整個(gè)服務(wù)的流量的監(jiān)控；
• 訪問耗時(shí)的監(jiān)控；
• 還有我們的拋棄量監(jiān)控。

接下來就是接入我們的監(jiān)控平臺(tái)，會(huì)有針對(duì)的關(guān)鍵字監(jiān)控，也有 URL 的監(jiān)控，針對(duì)不同的監(jiān)控有一些監(jiān)控的策略。

最后就是接入我們的 Dtrack 調(diào)用鏈，可以知道整個(gè)服務(wù)之間的調(diào)用關(guān)系：

如果服務(wù)的量級(jí)上來了，那么我們可能自己都不知道是調(diào)用了哪個(gè)服務(wù)，它的層次關(guān)系靠人已經(jīng)分不清了。如果接入調(diào)用鏈的話，會(huì)打印出一個(gè)服務(wù)的清晰的調(diào)用關(guān)系。

• 它給我們提供了全局跟蹤，比如說調(diào)用了哪些服務(wù)，耗時(shí)有多少；
• 哪個(gè)服務(wù)有問題的，會(huì)立馬有一個(gè)異常的報(bào)警；
• 針對(duì)服務(wù)之間會(huì)有清晰調(diào)用結(jié)構(gòu)；
• 對(duì)整個(gè)服務(wù)也會(huì)有一個(gè)效果監(jiān)測(cè)。

它的技術(shù)點(diǎn)在哪兒：

我們?cè)诳蚣芾锩嫣峁┝瞬寮?，每一次調(diào)用的時(shí)候，就會(huì)形成 traceid，通過框架傳遞下去，每調(diào)用一個(gè)服務(wù)，它的 ID 會(huì) +1。將這些調(diào)用關(guān)系通過日志打印出來，通過 Flume 采集之后展現(xiàn)出來就行了。

總結(jié)

最后總結(jié)一下，準(zhǔn)確的理解需求很重要，架構(gòu)是為業(yè)務(wù)服務(wù)的；碰到一個(gè)大的需求，對(duì)需求進(jìn)行拆分，由簡(jiǎn)單到復(fù)雜的拆分；根據(jù)業(yè)務(wù)需求進(jìn)行合適的技術(shù)選型，任何脫離業(yè)務(wù)的架構(gòu)設(shè)計(jì)都是耍流氓，監(jiān)控特別的重要，謝謝大家。

[[240860]]

張凱，58 速運(yùn)后端平臺(tái)部負(fù)責(zé)人。7 年開發(fā)經(jīng)驗(yàn)，涉及 CRM、微信錢包、卡券系統(tǒng)等；參與 58 到家錢包入口的優(yōu)化拆分改版，保證了系統(tǒng)平穩(wěn)過渡；參與 58 大促，保證了大促期間卡券系統(tǒng)的穩(wěn)定運(yùn)行?，F(xiàn)在負(fù)責(zé)后端平臺(tái)的開發(fā)工作。