1 消息推送簡介

1.1 什麼是消息推送

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

 

1.2 消息推送的價值

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

 

• 提升新用户次日留存，低成本促活，對平台的短期留存率影響顯著。

• 提升老用户活躍度，push 可以通過外部提醒起到拉活的作用。很多內容平台類 App 的用户 push 首次啟動佔比可達 10%以上，因此 push 對 DAU 的增量貢獻不容小覷。

• 流失用户召回，當用户流失後，若 push 權限未關閉，通過消息推送的方式，有可能重新喚醒用户。

2 背景和痛點

消息中心為得物 App 提供了強大，高效的用户觸達渠道，其中 push 對於得物 DAU 的貢獻有可觀的佔比，這也就意味着每一條推送消息都是一次與用户溝通的寶貴機會，所以推送的穩定性成為我們關注的首要問題，那麼我們遇到的以下痛點就亟待解決。消息中心沒有明確消息推送的耗時標準，業務和技術之間存在 gap，業務方對於推送的消息什麼時候到達沒有明確的心理預期。從技術上來講消息推送各個節點的耗時不明確，無法對各個節點的耗時做針對性的優化，這也就需要我們針對消息推送的節點耗時進行監控。消息推送的穩定性依賴於第三方的推送通道，而三方通道對於我們來講就是個黑盒子，如何做到三方通道異常及時發現並止損也是需要考慮的問題。在我們正常的迭代過程中有時候不可避免的會出現些異常或者有壞味道的代碼，這些問題能不能及時發現、及時止損，能不能及時告警出來。

3 監控的實踐

3.1 SLA 監控簡介

SLA（Service-Level Agreement），也就是服務等級協議，指的是系統服務提供者（Provider）對客户（Customer）的一個服務承諾。這是衡量一個大型分佈式系統是否“健康”的常見方法。在開發設計系統服務的時候，無論面對的客户是公司外部的個人、商業用户，還是公司內的不同業務部門，我們都應該對自己所設計的系統服務有一個定義好的 SLA。因為 SLA 是一種服務承諾，所以指標可以多種多樣。最常見的四個 SLA 指標，可用性、準確性、系統容量和延遲。

 

對於消息推送而言，我們主要關注的是消息能否及時可靠的送達給用户，也就是 SLA 中關注的時效性和穩定性的問題。目前消息中心針對實效性和穩定性的開發已經完成並初顯成效，下面主要針對時效性和穩定性的監控做一些介紹。

 

3.2 系統架構圖

3.3 時效性監控

3.3.1 節點的拆分

 

如何做到時效性的無死角監控，那麼我們就要對消息推送的整個流程進行拆分，把整個流程拆分成若干個獨立且無依賴的可監控節點。從消息系統流轉圖中可以看到，整個推送流程是清晰明瞭的，消息的的推送主要會經歷推送鑑權、用户查詢、防疲勞過濾、防重複過濾等的邏輯處理，考慮到每個業務邏輯的處理是相互獨立且無依賴的，那我們就可以根據具體的業務處理邏輯進行節點的拆分，這樣就可以做到拆分無遺漏，監控無死角，拆分後的具體節點如下：

 

3.3.2 節點耗時的計算

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

 

 

備註：節點耗時的計算：記錄節點消息推送到達的時間，並計算節點推送耗時，例如防疲勞耗時=T7(antiFatigueConsumeTime)-T6(checkrepeatConsumeTime)節點阻塞量的計算：記錄節點消息推送的瞬時阻塞量， 例如防疲勞節點阻塞量 = 防疲勞的總量-防疲勞已經處理的量

3.3.3 節點指標的制定

既然需要監控的節點已經拆分明確了，那針對這些節點我們監控哪些指標才是有意義的呢。

 

• 目前消息推送高峯耗時較長，各業務域對於消息的到達時間也沒有明確的心理一個預期，另外消息中心也無法感知推送在整個鏈路各個節點的耗時情況，無法針對節點耗時做到有針對性的優化，所以節點的推送量和推送耗時就是我們需要重點關注的指標。

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

 

考慮到消息推送是有優先級的並且區分單推和批量推，所以我們要針對不同的優先級和推送方式設置不同的標準，消息推送耗時的具體標準如下。

 

3.3.4 技術方案的實現

為了能感知到消息推送中發生的異常和耗時情況，這就需要我們標準化監控指標和監控的節點。其中耗時指標可以感知節點的耗時和代碼的壞味道，阻塞量可以監控到節點的堆積情況，推送成功率可以感知節點的推送異常等。另外節點拆分後我們可以很快定位到異常發生的具體位置，經過拆分監控的主要節點包括鑑權、風控、用户查詢、防疲勞、防重複、廠商調用等。

 

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

3.3.5 結果

消息推送實效性監控做完之後，對服務節點耗時異常可以及時感知，同時也完成了關鍵節點耗時的指標化，可以明確的看到所有節點在各個時間的耗時情況，同時也對消息推送針對各個節點的的優化起到了指導作用。時效性節點監控：

 

 

時效性節點告警：

 

3.4 廠商推送監控

3.4.1 監控指標制定

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

 

• 在做廠商監控之前，我們就已經遇到了廠商通道推送跌零的情況，這種情況下整個推送通道都掛掉了，我們要及時通知廠商進行修復，所以廠商推送跌零告警和廠商餘量監控是必須的。

• 從現有數據來看，廠商的推送成功率、回執成功率、點擊率都穩定在一定的的區間。如果廠商推送的指標數據偏離這個區間則説明推送有異常，所以推送成功率、回執成功率、點擊率的監控是必須的。

• 另外從業務請求發送的用户數來看，每天的消息推送基本是穩定的，相對應的廠商的回執數量和點擊數量也是穩定的，那麼對廠商推送成功的數量，回執的數量和點擊的數量監控也有一定的參考意義。

 

業務側請求發送的用户數：

 

 

廠商監控告警：

 

3.4.2 技術方案實現

廠商每天有數億的消息推送，這也就意味着廠商的監控不能嵌在主流程中處理。廠商的監控代碼要從主流程邏輯中剝離出來，避免監控拖垮主流程，同樣避免監控異常影響到推送的主流程。針對廠商推送的監控，目前使用的是有界內存隊列實現。

 

3.4.3 結果

消息推送廠商監控上線之後，可以及時感知到廠商推送的異常信息，對於廠商推送的異常和廠商規則的更改等可以做到及時的感知。

 

 

4 帶來的收益

4.1 異常的及時發現

監控上線後及時發現了發現了廠商推送線程關閉失敗，廠商推送跌零、廠商營銷消息規則更改、廠商通道偶發不可用等問題，並做到了及時的止損。

 

• 在時效性監控上線之後，發現了因廠商推送線程創建關閉失敗導致線程數逐漸上升問題，避免了線上故障的發生。

 

 

• 廠商異常導致推送跌零，監控發現後及時通知到廠商並止損。

 

 

• 發現廠商營銷消息規則更改的異常，並及時經梳理各大廠商文檔後發現除了多個廠商通道在未來一個月內也會有規則的更改，消息平台及時適應了廠商規則，接入廠商系統通道，做到了及時止損。

 

 

4.2 服務性能的提升時效性監控上線後發現了多個服務可以優化的點，其中多個廠商和推送節點在高峯推送時耗時較高，很明顯節點耗時和廠商推送 SDK 連接池和連接時間參數需要優化。優化後消息推送整體的吞吐量實現了翻倍的提升。

5 展望未來

由於時間問題，目前消息監控只做了時效性和廠商推送穩定性相關的監控，但是監控上線後帶來的收益還是比較可觀的，可以預見的是監控的構建在未來必將帶給我們更大的收益，後續我們可以從以下點豐富現有監控。

 

• 考慮到業務預的推送量和推送時間是穩定的，那麼我們可以針對業務維度添加推送數據的監控，及時感知上游推送數據的變化。

• 其次我們可以針對各個節點的推送異常、漏斗轉化率、服務性能等做監控，進一步豐富消息平台的監控體系。

• 對於消息推送來講也要考慮推送的轉化率問題，那麼卸載、屏蔽等指標也是我們需要監控的點，通過這些業務指標及時感知推送的效果，做到精細化的管控。

6 總結

消息平台監控上線後帶來的收益還是比較可觀的，包括多次異常的及時發現和止損，還有發現多個個可以優化的性能點，實現了服務高峯吞吐量的翻倍，同時也解決了我們現在遇到的以下痛點。

 

• 時效性明確的給到了不同優先級的耗時標準，避免了業務和技術之間的 gap，業務方對於推送的耗時也有了明確的心理預期。

• 時效性使得節點耗時的性能問題可以一目瞭然，通過對現有節點耗時問題的優化，消息服務的吞吐量實現了翻倍的提升。

• 廠商穩定性監控使得廠商異常可以及時感知，其中廠商穩定性監控上線後發現多起廠商推送的異常，並做到了及時的解決和止損。

• SLA 時效性和廠商穩定性上線後，消息中心可以及時感覺到推送鏈路的異常和代碼的壞味道，特別是對於新上線的代碼，如果存在異常可以及時感知。