消息推送平臺高可用實踐（下）

本文來自網易雲社區

做者：李弈遠

消息推送平臺現已爲幾十個產品提供推送服務，同時在線用戶鏈接數超過300w，日收發消息量達幾千萬，對消息的實時性和可靠性均提出了較高的要求。上篇 從架構設計和部署方案角度介紹了消息推送平臺的高可用保障，下面將從監控層面介紹系統服務質量保障。
推送系統的服務質量能夠從幾個方面來考量，直觀看來，從系統開發人員的角度，主要關注於系統的負載、穩定性、性能和異常狀況下系統可用性等，接入推送系統的產品方則更多關心推送的效果，如一次廣播最終被多少用戶接收到等，而普通用戶則看重響應體驗，如可否第一時間收到對方發送的消息以及消息有沒有丟失等。實際上，上述這些質量要點是相互影響且互爲一體的，爲此推送服務從如下幾個層面對系統的服務質量進行實時監控和評估。

1 服務器資源監控

服務器資源監控主要對服務器的cpu、內存、io、網絡等資源的使用狀況進行監控。因爲推送平臺部署用到了物理機和雲主機，故須要同時對這二者的資源負載進行監控，另外一方面，不一樣服務對服務器負載的關注點也不一樣，如redis服務器主要關注內存和io的負載狀況，接入點服務器主要關注cpu和內存負載等。
服務器資源監控的報警策略通常採用設置閥值的方式進行。
幾乎全部產品都會對上述資源負載進行監控，故在此不作累述。

2 進程監控

推送平臺主要監控的進程有Tomcat進程、RabbitMQ進程、Redis進程、NodeJs進程等，除監測進程存活狀態及CPU、內存外，監控項還包括：

• Tomcat進程：請求數、處理線程數、處理時間、JVM GC等；

• RabbitMQ進程：消息生產速度、消息消費速度、隊列中堆積消息數目等；

• Redis進程：請求鏈接數、命中率、處理命令數等；

• NodeJS進程：GC等；

進程監控的報警策略通常採用監聽進程存活狀態以及設置閥值的方式進行。

3 應用級監控

應用層監控取決於服務特定業務邏輯，推送平臺的應用層監控主要能夠分爲如下幾類：

• 終端鏈接：接入產品各種終端的長鏈接數目等；

• 消息推送：接入產品的各種消息推送數/速度、實際到達各種終端的消息數/速度等；

• 接口調用：接入產品服務端和終端訪問推送平臺對外API的次數/響應時間等；

因爲推送平臺有多套部署環境，某些環境涉及上百個部署節點，且已接入數十個產品的多種終端類型，故一個監控項可能從好幾個維度才能進行完整定義，且須要按照指定的一個或多個維度進行聚合。
以終端鏈接監控爲例：

value=200,env=online,host=push2.photo.163.org,serverId=push2lxc10,platform=android,product=news.163.com

表示某一時刻鏈接到線上環境物理機push2.photo.163.org的LXC節點push2lxc10上的新聞產品（news.163.com）android終端長鏈接數目爲200。 但最終監控結果可能須要按照不一樣的維度來顯示，譬如：

• 某一個LXC節點上的Android終端長鏈接總數

• 某一臺物理機上全部終端類型長鏈接總數

• 某個產品的全部終端類型長鏈接總數

• 某個產品的Android終端長鏈接總數

• ......

爲此，須要對聚合維度進行定義：

Aggregation-Keys={serverId,host,env+product,env+product+platform},......

因爲應用級監控和服務業務邏輯有關，因此不適合採用設置閥值的報警方式，能夠考慮變化率報警方式，例如，某個產品當前時刻Android終端長鏈接總數比前五天同一時刻長鏈接總數的平均值低20%，能夠認爲服務存在異常，觸發報警。

4 7*24自動化測試

上述應用級監控主要監測單個零散的業務邏輯功能點是否正常，沒有就整個業務流程運行情況進行監控，爲此可使用機器人和實際終端7*24自動化運行完整功能測試用例，覆蓋各種終端的典型應用場景。若應用場景業務流程某個環節用例測試失敗，則觸發報警。
推送平臺現有的自動化測試用例覆蓋了Android、IOS、Web、PC終端從註冊、綁定到獲取在線/離線消息、解綁的整個業務交互流程。

5 SLA

SLA全稱服務品質協議，是服務提供者和用戶之間的一個正式合同，用來保證系統服務質量，如性能、穩定性、響應速度等達到定義的品質。例如，消息推送平臺的SLA部分指標爲：

• 系統可用時間大於99.9%；

• 99%點對點消息到達時間<1S；

• 獨立部署產品全域廣播至100w用戶<30S；

• Android SDK長鏈接心跳月流量<500k；

• ......

SLA的關鍵在於可測量，不然無從驗證是否達到了承諾的服務質量。推送平臺因爲請求異步執行及移動互聯網的特性，SLA測量存在必定的難度。以點對點消息到達時間爲例，測量須要考慮的因素有：

• 推送平臺對產品是個黑盒系統，難以從產品方獲取數據；

• 推送平臺做爲一個高可用系統，每一個組成模塊都有多個節點，接入點更是多達上百個，難以覆蓋全部節點和路徑；

• 用戶終端使用的移動網絡環境存在不肯定性；

• 直接在用戶終端注入統計代碼對流量/電量和產品體驗的影響；

• 終端因爲網絡環境上報統計數據有丟失可能；

• ......

上述因素將致使SLA測不許而失去意義。爲此，考慮採起模擬採樣方案，具體描述以下：

1. 創建一個SLA專用產品域，與其餘產品共用線上環境；

2. 針對每種終端類型在雲主機上模擬必定數目的終端鏈接，終端連接數目>10*接入點數目，每一個終端鏈接具備不一樣的deviceId，但模擬相同的用戶帳號，並以固定時間間隔主動進行重連；

3. 模擬產品服務端以固定時間間隔推送消息；

4. 統計消息推送路徑各組成部分的耗時；

5. 以此域的服務質量統計數據做爲SLA指標的驗證依據；

6. 根據統計數據輸出90%/95%/99%圖表，並創建報警；
   

6 效果統計

上述監控措施爲系統的服務質量和快速運維響應提供了較爲完善的基礎，可是尚沒法解決接入產品最爲關心的一個問題，即推送的實際效果如何。例如，一次廣播有多少用戶是在線收到的，在多長時間內收到的，又有多少用戶是離線收到的，最終在廣播TTL時間內一共成功推送給了多少用戶，又如，某個產品的私信TTL時間爲一週，那某天發送的私信有多少是當天就被用戶收到，次日至第七天又分別有多少被用戶收到，從而爲調整TTL設置提供依據等。
爲此推送平臺根據不一樣的統計需求，基於數據上報、日誌輸出等方式，經過BI等計算統計結果，並提供接口供產品方調用獲取，以對推送效果進行評估，進而調整推送策略和內容。

網易雲大禮包：https://www.163yun.com/gift

本文來自網易雲社區，經做者李弈遠受權發佈。

相關文章：
【推薦】 30分鐘，讓你完全明白Promise原理