1、消息推送簡介

1.1 什么是消息推送

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

1.2 消息推送的價值

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

• 提升新用戶次日留存，低成本促活，對平臺的短期留存率影響顯著。
• 提升老用戶活躍度，push可以通過外部提醒起到拉活的作用。很多內容平臺類App的用戶push首次啟動占比可達 10%以上，因此push對DAU的增量貢獻不容小覷。
• 流失用戶召回，當用戶流失后，若push權限未關閉，通過消息推送的方式，有可能重新喚醒用戶。

2、背景和痛點

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

• 消息中心沒有明確消息推送的耗時標準，業(yè)務和技術之間存在gap，業(yè)務方對于推送的消息什么時候到達沒有明確的心理預期。
• 從技術上來講消息推送各個節(jié)點的耗時不明確，無法對各個節(jié)點的耗時做針對性的優(yōu)化，這也就需要我們針對消息推送的節(jié)點耗時進行監(jiān)控。
• 消息推送的穩(wěn)定性依賴于第三方的推送通道，而三方通道對于我們來講就是個黑盒子，如何做到三方通道異常及時發(fā)現(xiàn)并止損也是需要考慮的問題。
• 在我們正常的迭代過程中有時候不可避免的會出現(xiàn)些異常或者有壞味道的代碼，這些問題能不能及時發(fā)現(xiàn)、及時止損，能不能及時告警出來。

3、監(jiān)控的實踐

3.1 SLA監(jiān)控簡介

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

對于消息推送而言，我們主要關注的是消息能否及時可靠的送達給用戶，也就是SLA中關注的時效性和穩(wěn)定性的問題。目前消息中心針對實效性和穩(wěn)定性的開發(fā)已經(jīng)完成并初顯成效，下面主要針對時效性和穩(wěn)定性的監(jiān)控做一些介紹。

3.2 系統(tǒng)架構圖

3.3 時效性監(jiān)控

3.3.1 節(jié)點的拆分

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

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

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

備注：

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

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

3.3.3 節(jié)點指標的制定

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

• 目前消息推送高峰耗時較長，各業(yè)務域對于消息的到達時間也沒有明確的心理一個預期，另外消息中心也無法感知推送在整個鏈路各個節(jié)點的耗時情況，無法針對節(jié)點耗時做到有針對性的優(yōu)化，所以節(jié)點的推送量和推送耗時就是我們需要重點關注的指標。
• 節(jié)點的阻塞量可以讓我們及時感知到推送中存在的積壓問題，在大促期間，消息的推送量也會達到一個高峰，消息目前是否有堆積，處理的速度是否跟的上，是否需要臨時擴容，那么節(jié)點的阻塞量就成了一個比較有意義的參考指標。

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

3.3.4 技術方案的實現(xiàn)

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

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

3.3.5 結果

消息推送實效性監(jiān)控做完之后，對服務節(jié)點耗時異?？梢约皶r感知，同時也完成了關鍵節(jié)點耗時的指標化，可以明確的看到所有節(jié)點在各個時間的耗時情況，同時也對消息推送針對各個節(jié)點的的優(yōu)化起到了指導作用。

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

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

3.4 廠商推送監(jiān)控

3.4.1 監(jiān)控指標制定

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

• 在做廠商監(jiān)控之前，我們就已經(jīng)遇到了廠商通道推送跌零的情況，這種情況下整個推送通道都掛掉了，我們要及時通知廠商進行修復，所以廠商推送跌零告警和廠商余量監(jiān)控是必須的。
• 從現(xiàn)有數(shù)據(jù)來看，廠商的推送成功率、回執(zhí)成功率、點擊率都穩(wěn)定在一定的的區(qū)間。如果廠商推送的指標數(shù)據(jù)偏離這個區(qū)間則說明推送有異常，所以推送成功率、回執(zhí)成功率、點擊率的監(jiān)控是必須的。
• 另外從業(yè)務請求發(fā)送的用戶數(shù)來看，每天的消息推送基本是穩(wěn)定的，相對應的廠商的回執(zhí)數(shù)量和點擊數(shù)量也是穩(wěn)定的，那么對廠商推送成功的數(shù)量，回執(zhí)的數(shù)量和點擊的數(shù)量監(jiān)控也有一定的參考意義。

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

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

3.4.2 技術方案實現(xiàn)

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

3.4.3 結果

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

4、帶來的收益

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

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

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

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

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

4.2 服務性能的提升

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

5、展望未來

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

• 考慮到業(yè)務預的推送量和推送時間是穩(wěn)定的，那么我們可以針對業(yè)務維度添加推送數(shù)據(jù)的監(jiān)控，及時感知上游推送數(shù)據(jù)的變化。
• 其次我們可以針對各個節(jié)點的推送異常、漏斗轉化率、服務性能等做監(jiān)控，進一步豐富消息平臺的監(jiān)控體系。
• 對于消息推送來講也要考慮推送的轉化率問題，那么卸載、屏蔽等指標也是我們需要監(jiān)控的點，通過這些業(yè)務指標及時感知推送的效果，做到精細化的管控。

6、總結

消息平臺監(jiān)控上線后帶來的收益還是比較可觀的，包括多次異常的及時發(fā)現(xiàn)和止損，還有發(fā)現(xiàn)多個個可以優(yōu)化的性能點，實現(xiàn)了服務高峰吞吐量的翻倍，同時也解決了我們現(xiàn)在遇到的以下痛點。

• 時效性明確的給到了不同優(yōu)先級的耗時標準，避免了業(yè)務和技術之間的gap，業(yè)務方對于推送的耗時也有了明確的心理預期。
• 時效性使得節(jié)點耗時的性能問題可以一目了然，通過對現(xiàn)有節(jié)點耗時問題的優(yōu)化，消息服務的吞吐量實現(xiàn)了翻倍的提升。
• 廠商穩(wěn)定性監(jiān)控使得廠商異常可以及時感知，其中廠商穩(wěn)定性監(jiān)控上線后發(fā)現(xiàn)多起廠商推送的異常，并做到了及時的解決和止損。
• SLA時效性和廠商穩(wěn)定性上線后，消息中心可以及時感覺到推送鏈路的異常和代碼的壞味道，特別是對于新上線的代碼，如果存在異?？梢约皶r感知。