得物從零構(gòu)建億級消息推送系統(tǒng)的送達穩(wěn)定性監(jiān)控體系技術(shù)實踐

Posted on 2024-01-25 11:27 Jack Jiang 閱讀(366) 評論(0) 編輯收藏

本文由得物技術(shù)暖樹分享，有修訂和改動。

1、引言

本文分享的是得物針對現(xiàn)有的消息推送系統(tǒng)的消息送達耗時、實時性、穩(wěn)定性等方面問題，從零到一構(gòu)建完整的消息推送質(zhì)量監(jiān)控體系和機制的技術(shù)實踐。

技術(shù)交流：

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》
- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發(fā)布于：http://www.52im.net/thread-4614-1-1.html）

2、消息推送的作用

2.1 什么是消息推送

消息推送每天都在我們的手機上發(fā)生，如下圖所示，除非你的手機沒有安裝App或關(guān)閉了通知欄權(quán)限。

2.2 消息推送的價值

從用戶的生命周期來看，消息推送對于提高App活躍度、提升用戶粘性和用戶留存率都起到了重要作用。

比如：

1）提升新用戶次日留存，低成本促活，對平臺的短期留存率影響顯著；
2）提升老用戶活躍度，push可以通過外部提醒起到拉活的作用；
3）流失用戶召回，當(dāng)用戶流失后，若push權(quán)限未關(guān)閉，通過消息推送的方式，有可能重新喚醒用戶。

對于第 2）點，很多內(nèi)容平臺類App的用戶push首次啟動占比可達 10%以上，因此push對DAU的增量貢獻不容小覷。

3、業(yè)務(wù)背景和技術(shù)痛點

消息中心為得物App提供了強大，高效的用戶觸達渠道。其中push對于得物DAU的貢獻有可觀的占比，這也就意味著每一條推送消息都是一次與用戶溝通的寶貴機會。所以推送的穩(wěn)定性成為我們關(guān)注的首要問題。

那么我們遇到的以下痛點就亟待解決：

1）消息中心沒有明確消息推送的耗時標(biāo)準(zhǔn)，業(yè)務(wù)和技術(shù)之間存在gap，業(yè)務(wù)方對于推送的消息什么時候到達沒有明確的心理預(yù)期。

2）從技術(shù)上來講消息推送各個節(jié)點的耗時不明確，無法對各個節(jié)點的耗時做針對性的優(yōu)化，這也就需要我們針對消息推送的節(jié)點耗時進行監(jiān)控。

3）消息推送的穩(wěn)定性依賴于第三方的推送通道，而三方通道對于我們來講就是個黑盒子，如何做到三方通道異常及時發(fā)現(xiàn)并止損也是需要考慮的問題。

4）在我們正常的迭代過程中有時候不可避免的會出現(xiàn)些異常或者有壞味道的代碼，這些問題能不能及時發(fā)現(xiàn)、及時止損，能不能及時告警出來。

4、穩(wěn)定性監(jiān)控體系

SLA（Service-Level Agreement），也就是服務(wù)等級協(xié)議，指的是系統(tǒng)服務(wù)提供者（Provider）對客戶（Customer）的一個服務(wù)承諾。這是衡量一個大型分布式系統(tǒng)是否“健康”的常見方法。

在開發(fā)設(shè)計系統(tǒng)服務(wù)的時候，無論面對的客戶是公司外部的個人、商業(yè)用戶，還是公司內(nèi)的不同業(yè)務(wù)部門，我們都應(yīng)該對自己所設(shè)計的系統(tǒng)服務(wù)有一個定義好的SLA。因為SLA是一種服務(wù)承諾，所以指標(biāo)可以多種多樣。

最常見的四個SLA指標(biāo)：

1）可用性；
2）準(zhǔn)確性；
3）系統(tǒng)容量；
4）延遲。

對于消息推送而言，我們主要關(guān)注的是消息能否及時可靠的送達給用戶，也就是SLA中關(guān)注的時效性和穩(wěn)定性的問題。

目前消息中心針對實效性和穩(wěn)定性的開發(fā)已經(jīng)完成并初顯成效。

系統(tǒng)架構(gòu)圖：

下面主要針對時效性和穩(wěn)定性的監(jiān)控做一些介紹。

5、時效性監(jiān)控的技術(shù)實現(xiàn)

5.1 節(jié)點的拆分

如何做到時效性的無死角監(jiān)控，那么我們就要對消息推送的整個流程進行拆分，把整個流程拆分成若干個獨立且無依賴的可監(jiān)控節(jié)點。

從消息系統(tǒng)流轉(zhuǎn)圖中可以看到：整個推送流程是清晰明了的，消息的的推送主要會經(jīng)歷推送鑒權(quán)、用戶查詢、防疲勞過濾、防重復(fù)過濾等的邏輯處理，考慮到每個業(yè)務(wù)邏輯的處理是相互獨立且無依賴的，那我們就可以根據(jù)具體的業(yè)務(wù)處理邏輯進行節(jié)點的拆分，這樣就可以做到拆分無遺漏，監(jiān)控?zé)o死角。

拆分后的具體節(jié)點如下：

5.2 節(jié)點耗時的計算

具體的節(jié)點拆分邏輯和耗時邏輯的計算如下圖：

節(jié)點耗時的計算：記錄節(jié)點消息推送到達的時間，并計算節(jié)點推送耗時，例如：防疲勞耗時 = T7(antiFatigueConsumeTime) - T6(checkrepeatConsumeTime)。

節(jié)點阻塞量的計算：記錄節(jié)點消息推送的瞬時阻塞量，例如：防疲勞節(jié)點阻塞量 = 防疲勞的總量 - 防疲勞已經(jīng)處理的量。

5.3 節(jié)點指標(biāo)的制定

既然需要監(jiān)控的節(jié)點已經(jīng)拆分明確了，那針對這些節(jié)點我們監(jiān)控哪些指標(biāo)才是有意義的呢。

1）目前消息推送高峰耗時較長，各業(yè)務(wù)域?qū)τ谙⒌牡竭_時間也沒有明確的心理一個預(yù)期，另外消息中心也無法感知推送在整個鏈路各個節(jié)點的耗時情況，無法針對節(jié)點耗時做到有針對性的優(yōu)化，所以節(jié)點的推送量和推送耗時就是我們需要重點關(guān)注的指標(biāo)。

2）節(jié)點的阻塞量可以讓我們及時感知到推送中存在的積壓問題，在大促期間，消息的推送量也會達到一個高峰，消息目前是否有堆積，處理的速度是否跟的上，是否需要臨時擴容，那么節(jié)點的阻塞量就成了一個比較有意義的參考指標(biāo)。

考慮到消息推送是有優(yōu)先級的并且區(qū)分單推和批量推，所以我們要針對不同的優(yōu)先級和推送方式設(shè)置不同的標(biāo)準(zhǔn)。

消息推送耗時的具體標(biāo)準(zhǔn)如下：

5.4 技術(shù)方案的實現(xiàn)

為了能感知到消息推送中發(fā)生的異常和耗時情況，這就需要我們標(biāo)準(zhǔn)化監(jiān)控指標(biāo)和監(jiān)控的節(jié)點。

其中耗時指標(biāo)可以感知節(jié)點的耗時和代碼的壞味道，阻塞量可以監(jiān)控到節(jié)點的堆積情況，推送成功率可以感知節(jié)點的推送異常等。

另外節(jié)點拆分后我們可以很快定位到異常發(fā)生的具體位置，經(jīng)過拆分監(jiān)控的主要節(jié)點包括鑒權(quán)、風(fēng)控、用戶查詢、防疲勞、防重復(fù)、廠商調(diào)用等。

另外消息中心每天推送大量消息給得物用戶，SLA監(jiān)控任何一個操作嵌入主流程中都可能導(dǎo)致消息推送的延遲。這也就要求監(jiān)控和主流程進行隔離，主流程的歸主流程，SLA 的歸 SLA，SLA 監(jiān)控代碼從主流程邏輯中剝離出來，徹底避免SLA代碼對主流程代碼的污染,這也就要求SLA邏輯計算需要獨立于推送業(yè)務(wù)的主流程進行異步計算，防止SLA監(jiān)控拖垮整個主流程，那么Spring AOP+Spring Event就是最好的實現(xiàn)方式。

5.5 成果

消息推送實效性監(jiān)控做完之后，對服務(wù)節(jié)點耗時異常可以及時感知，同時也完成了關(guān)鍵節(jié)點耗時的指標(biāo)化。

可以明確的看到所有節(jié)點在各個時間的耗時情況，同時也對消息推送針對各個節(jié)點的的優(yōu)化起到了指導(dǎo)作用。

時效性節(jié)點監(jiān)控：

時效性節(jié)點告警：

6、廠商推送監(jiān)控的技術(shù)實現(xiàn)

6.1 監(jiān)控指標(biāo)制定

消息推送接入的有多個推送通道，如何做到對這些通道做到無死角的監(jiān)控，及時感知呢。

1）在做廠商監(jiān)控之前，我們就已經(jīng)遇到了廠商通道推送跌零的情況，這種情況下整個推送通道都掛掉了，我們要及時通知廠商進行修復(fù)，所以廠商推送跌零告警和廠商余量監(jiān)控是必須的。

2）從現(xiàn)有數(shù)據(jù)來看，廠商的推送成功率、回執(zhí)成功率、點擊率都穩(wěn)定在一定的的區(qū)間。如果廠商推送的指標(biāo)數(shù)據(jù)偏離這個區(qū)間則說明推送有異常，所以推送成功率、回執(zhí)成功率、點擊率的監(jiān)控是必須的。

3）另外從業(yè)務(wù)請求發(fā)送的用戶數(shù)來看，每天的消息推送基本是穩(wěn)定的，相對應(yīng)的廠商的回執(zhí)數(shù)量和點擊數(shù)量也是穩(wěn)定的，那么對廠商推送成功的數(shù)量，回執(zhí)的數(shù)量和點擊的數(shù)量監(jiān)控也有一定的參考意義。

業(yè)務(wù)側(cè)請求發(fā)送的用戶數(shù)：

廠商監(jiān)控告警：

6.2 技術(shù)方案實現(xiàn)

廠商每天有數(shù)億的消息推送，這也就意味著廠商的監(jiān)控不能嵌在主流程中處理。廠商的監(jiān)控代碼要從主流程邏輯中剝離出來，避免監(jiān)控拖垮主流程，同樣避免監(jiān)控異常影響到推送的主流程。

針對廠商推送的監(jiān)控，目前使用的是有界內(nèi)存隊列實現(xiàn)：

6.3 成果

消息推送廠商監(jiān)控上線之后，可以及時感知到廠商推送的異常信息，對于廠商推送的異常和廠商規(guī)則的更改等可以做到及時的感知。

7、穩(wěn)定性監(jiān)控體系帶來的收益

7.1 異常的及時發(fā)現(xiàn)

監(jiān)控上線后及時發(fā)現(xiàn)了發(fā)現(xiàn)了廠商推送線程關(guān)閉失敗，廠商推送跌零、廠商營銷消息規(guī)則更改、廠商通道偶發(fā)不可用等問題，并做到了及時的止損。

1）在時效性監(jiān)控上線之后，發(fā)現(xiàn)了因廠商推送線程創(chuàng)建關(guān)閉失敗導(dǎo)致線程數(shù)逐漸上升問題，避免了線上故障的發(fā)生。

2）廠商異常導(dǎo)致推送跌零，監(jiān)控發(fā)現(xiàn)后及時通知到廠商并止損。

3）發(fā)現(xiàn)廠商營銷消息規(guī)則更改的異常，并及時經(jīng)梳理各大廠商文檔后發(fā)現(xiàn)除了多個廠商通道在未來一個月內(nèi)也會有規(guī)則的更改，消息平臺及時適應(yīng)了廠商規(guī)則，接入廠商系統(tǒng)通道，做到了及時止損。

7.2 服務(wù)性能的提升

時效性監(jiān)控上線后發(fā)現(xiàn)了多個服務(wù)可以優(yōu)化的點，其中多個廠商和推送節(jié)點在高峰推送時耗時較高，很明顯節(jié)點耗時和廠商推送 SDK 連接池和連接時間參數(shù)需要優(yōu)化。優(yōu)化后消息推送整體的吞吐量實現(xiàn)了翻倍的提升。

8、展望未來

由于時間問題，目前消息監(jiān)控只做了時效性和廠商推送穩(wěn)定性相關(guān)的監(jiān)控，但是監(jiān)控上線后帶來的收益還是比較可觀的，可以預(yù)見的是監(jiān)控的構(gòu)建在未來必將帶給我們更大的收益，后續(xù)我們可以從以下點豐富現(xiàn)有監(jiān)控。

1）考慮到業(yè)務(wù)預(yù)的推送量和推送時間是穩(wěn)定的，那么我們可以針對業(yè)務(wù)維度添加推送數(shù)據(jù)的監(jiān)控，及時感知上游推送數(shù)據(jù)的變化。

2）其次我們可以針對各個節(jié)點的推送異常、漏斗轉(zhuǎn)化率、服務(wù)性能等做監(jiān)控，進一步豐富消息平臺的監(jiān)控體系。

3）對于消息推送來講也要考慮推送的轉(zhuǎn)化率問題，那么卸載、屏蔽等指標(biāo)也是我們需要監(jiān)控的點，通過這些業(yè)務(wù)指標(biāo)及時感知推送的效果，做到精細(xì)化的管控。