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

本文來自網易雲社區

做者：李弈遠

消息推送平臺爲公司內部和第三方應用提供統一消息推送服務，支持廣播、私信、組播、附件等多種消息推送方式，覆蓋IOS、Android、PC、Web等多種終端，並根據應用特定需求制定各類解決方案。
平臺支持水平擴展，支持C5000K高併發下的實時消息推送，經過動態負載均衡、隔離部署、LXC虛擬化和監控報警等多種機制確保系統 的高可用，經過高可用消息隊列、自動重連和ACK等機制實現消息可靠性（QoS1），並提供SDK方便產品和應用接入。
本文將在介紹消息推送服務相關功能/非功能特性的基礎上，就係統爲實現高可用進行的架構設計及部署方案進行探討。

1、系統特性

1.1 功能特性

• 提供服務端SDK和各種終端SDK簡化產品接入

• 對接入的產品服務端和終端進行安全認證

• 支持跨產品消息推送

• 支持廣播、私信、組播、附件推送等多種消息推送方式

• 根據自定義條件篩選終端用戶進行推送

• 支持IOS、Android、Web、PC、智能設備等多種終端

• 針對典型應用場景的各類解決方案

• 對接入的各產品進行統一配置管理

• 對推送效果進行統計

• 系統運行時監控及異常報警

  
  

  1.2 非功能特性

  
  

• 消息可靠性知足QoS1

• 各類消息推送方式互不阻塞

• 具有快速水平擴展能力

• 系統高可用，無單點故障

• 異常隔離不擴散

• 消息推送路徑跟蹤及快速故障診斷

• 服務質量實時監測

• 易運維

• 支持C5000K高併發

• 終端流量電量損耗低於同類產品

• 高性能

  
  

  2、架構設計

  
  

  
  

  2.1 系統架構圖

• 
  

  
  

  2.2 架構說明

  
  

  消息推送平臺主要包括以下子系統：

  
  

• Push Server：負責接收產品服務端發送的消息，並轉發給高可用消息隊列。鏈接創建過程當中，採用鏈接池、超時檢測、自動重連、單鏈接多channel等多種機制確保消息發送穩定性和性能

• 高可用消息處理中心：基於RabbitMQ實現高可用消息隊列服務，負責根據消息接收終端和消息發送模式對消息進行路由，基於負載均衡支持水平擴展，基於持久化、confirm/ack、HA、流控等機制實現高可用，基於二級路由策略隔離不一樣類型消息避免阻塞

• 調度服務：負責從消息隊列中獲取消息進行解析，根據消息類型獲取接收者信息，並投遞給其所在的接入點

• 消息存儲：基於Redis爲終端鏈接、終端上報數據、消息內容、離線消息等提供存儲訪問服務，採用基於Sharding的Master-Slave方案實現高可用

• 接入點：負責管理和維護用戶終端長鏈接，並將消息最終投遞給用戶終端。基於負載均衡支持水平擴展，採用LXC多結點部署、客戶端重連、進程假死檢測、重連退避等機制實現服務隔離和高可用

• 終端SDK：提供給各種終端，如Android、IOS、PC、Web等，提供API簡化其接入流程和複雜度，負責接收接入點下推的消息，並通知對應的APP進行處理。基於長鏈接、心跳退避、自動重連、ack、鏈路複用等機制確保消息的可靠接收，並減小了流量和電量等消耗

• 過濾服務：負責存儲終端上報的數據，並根據過濾條件篩選目標用戶列表，過濾條件支持邏輯組合和黑名單功能

• 權限認證服務：基於OAuth簽名認證機制對產品服務端發送消息和用戶終端接收消息進行安全認證，避免消息被篡改及冒名發送/接收等

• 統計服務：對廣播、附件等推送模式的推送效果，如實際接收用戶數目、發送時間等進行統計，以評估系統運行情況，同時提供給產品方進行參考

• 監控報警服務：負責從服務器資源、應用層、服務質量等多個層面對系統的運行狀況進行運行時監控和異常報警，實現對系統故障的及時診斷和恢復，以確保服務的7*24小時正常運行

• 管理服務：對接入推送服務的產品進行配置管理，如分配密鑰對，設置產品接入終端類型，管理產品間消息互通權限，設置產品羣組信息獲取接口等

  
  

  3、部署方案

  推送平臺子系統的實現涉及多種編程語言和模型，由此部署方式也各不相同，如下將就幾個主要子系統的部署方式進行說明。

  
  

  3.1 Push Server

  Push Server基於Tomcat搭建http接口服務，其部署方式爲典型的web服務部署方案，即LVS+Nginx+Tomcat實現負載均衡和高可用，其中Tomcat部署在雲主機上，便於快速水平擴展和垂直擴展。

  
  

  3.2 高可用消息處理中心

  高可用消息隊列基於RabbitMQ搭建。RabbitMQ提供了集羣服務，但並不支持負載均衡。雖然鏈接到RabbitMQ集羣的任意節點均可以訪問集羣中的任意消息隊列，但一個消息隊列只存儲在一個物理節點上，其它節點只存儲該隊列的元數據，這使得當隊列裏只有一個隊列時，系統性能受限於單個節點的網絡帶寬和主機性能，且存在單點故障。
  高可用消息隊列服務在兼容AMQP協議的基礎上開發了分佈式代理層MQProxy實現負載均衡，客戶端的消息生產和消費請求先經過LVS或HAProxy分流到MQProxy節點，再由MQProxy分流到後端多個RabbitMQ結點。整個集羣採用無狀態設計，MQProxy及後端的RabbitMQ結點均可以水平擴展。
  推送平臺對消息可靠性極高，爲此消息生產和消費採起了confirm+ack模式，隊列部署採起持久化+HA模式，目前配置爲單副本，爲節省服務器資源，副本採起兩兩互爲備份方式。

  
  

  
  

  3.3 接入點

  接入點採用非阻塞事件驅動編程語言nodejs處理高併發長鏈接。因爲nodejs採用單進程模式運行，所以在多核服務器上須要部署多個進程才能充分利用服務器資源。爲了實現進程間隔離，並減小性能損耗，系統採用LXC半虛擬化方式對進程進行部署，前端則利用LVS-DR模式實現負載均衡。

• 下篇將從監控等層面詳細介紹推送平臺系統是如何進行服務質量保障的。

 

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

 

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

相關文章：
【推薦】 HBase最佳實踐-管好你的操做系統
【推薦】 深刻解析SQL Server高可用鏡像實現原理