訊息推送簡介

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 監控指標制定

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

在做廠商監控之前，我們就已經遇到了廠商通道推送跌零的情況，這種情況下整個推送通道都掛掉了，我們要及時通知廠商進行修復，所以廠商推送跌零告警和廠商餘量監控是必須的。
從現有資料來看，廠商的推送成功率、回執成功率、點選率都穩定在一定的的區間。如果廠商推送的指標資料偏離這個區間則說明推送有異常，所以推送成功率、回執成功率、點選率的監控是必須的。
另外從業務請求傳送的使用者數來看，每天的訊息推送基本是穩定的，相對應的廠商的回執數量和點選數量也是穩定的，那麼對廠商推送成功的數量，回執的數量和點選的數量監控也有一定的參考意義。

業務側請求傳送的使用者數：