mPaaS 服務端核心組件：消息推送 MPS 架構及流程設計

0. 前言

根據《開篇 | mPaaS 服務端核心組件體系概述》的介紹，咱們已經知道 mPaaS 的 MPS 服務主要提供了專業的移動消息推送方案，能夠針對不一樣的場景提供多種推送類型，知足用戶的個性化推送需求，並集成了蘋果、華爲、小米、OPPO、VIVO、FCM 等多個廠商渠道的推送功能。在提供控制檯快速推送能力的同時，MPS 也提供了服務端接入方案，方便用戶快速集成移動終端推送功能，與用戶保持互動，從而有效地提升用戶留存率，提高用戶體驗。

本文將進一步介紹 MPS 服務端的架構設計和核心業務處理流程，首先看一下 MPS 在mPaaS 中的定位：

經過上圖可知 MPS 推送服務爲 mPaaS 體系內直接與客戶端通信的核心必備基礎組件之一，其基礎原理爲基於 TCP 長鏈接通道進行「消息通知」相關業務數據傳輸。

目前螞蟻體系內全部 App 均已接入了消息推送服務，並經過歷代架構演進、對接統一接入網關、統一使用螞蟻自研 mmtp 傳輸協議，造成現在可支持多 App，總量用戶量超過十億，天天推送數十億消息通知的基礎服務。

爲知足多種異構客戶端，以及其餘行業 App 標準管控需求，MPS 一樣支持 http2 標準協議，併爲支持輕量化部署也依然保留了獨立接入網關(mcometgw)，可在根據實際部署場景以及客戶端所繼承的網絡 SDK 選擇對應的接入網關。

• 注 1: Spanner 是螞蟻集團基於 Nginx 二次開發而來的一個系統。主要承擔 SSL 卸載、HTTP、TCP 接入層負載均衡的功能，是螞蟻集團的流量入口系統之一。經過規範的配置文件部署和自研 Nginx 模塊，Spanner 能夠支持 LDC 架構下的流量 Zone 間轉發、藍綠髮布、容災切換等功能；

• 注 2: mcometgw 爲 MPS 團隊在接入 Spanner 以前的接入網關，一樣也是基於Nginx 二次開發，其協議處理只能與 MPS 服務對接，沒法與 MGS，MSS 等其餘mPaaS 組件對接。

在接入層，除消息通知自身所需的接入網關外，依然須要 mPaaS 移動網關(MGS)配合服務，其主要做用爲：客戶端經過 RPC 進行設備註冊、用戶綁定、以及第三方渠道的關係綁定。另外，目前還獨立使用了日誌網關 MDAP，其主要目的爲：按照既定規範採集和上傳客戶端行爲日誌埋點，用於監控分析系統進行相關數據分析與報表製做；考慮到日誌的優先級與使用頻率考慮，以及與主業務鏈路進行網絡隔離方面設計，目前日誌依然採用了短鏈接（http/https）的方式上傳，客戶端日誌上報後，會經過部署在應用服務上的日誌採集工具與消息隊列投遞至數據倉庫或其餘數據分析系統進行分析、報表製做以及監控報警（相關流程和處理框架非本文重點，可參考 ELK 等設計）。

在此之上所介紹的爲螞蟻的自建渠道，而爲了支持國內各大手機產商的管控需求以及支持螞蟻國際標準接入，MPS 同時也支持了華爲、小米、魅族、OPPO、VIVO、FCM 和蘋果的 APNS 等渠道推送，並對後端業務系統保持透明，可以讓業務系統專一於完成業務功能，無需關注終端機型。

接着，咱們將介紹下 MPS 服務端的幾個核心業務流程。

1. 設備建連、註冊、綁定用戶流程

由 MPS 的基礎原理所需，客戶端與服務端之間必需要有一條穩定 TCP 物理鏈接。（注：TCP 鏈接維持主要經過心跳機制保障，如何保證快速建聯，以及如何保持鏈接的穩定性後續將專門的網絡優化相關文章介紹）

所以，全部故事的開頭，都是由創建 TCP 鏈接開始。隨 TCP 鏈接創建以後客戶端網絡 SDK 即開始上報一些基礎信息，如：客戶端產品 ID，版本號，操做系統，操做系統版本，機型等等，其目的是爲了後端能夠作更多的邏輯判斷、支持多維度的推送，MPS 會保存一份鏈接信息至緩存（ 注：可根據實際部署環境適配多種類型緩存：Redis、memcache 或者阿里體系內的 OCS、TAIR、Tbase 等等），此外在接入網關也會保存一分內存數據，爲後續全網推送作準備。

對於須要用到第三方推送的終端設備，MPS 客戶端 SDK 會根據終端類型註冊三方渠道的惟一 ID，隨後經過 RPC 一併調用到 MPS 服務端，MPS 則會根據客戶端的基礎信息生成設備的惟一 ID，並將三方渠道 ID 與 MPS 設備之間的關係持久化至 DB 層（ 注：目前主要支持 MySQL 和 OceanBase，爲支持億級用戶，持久層必然須要分庫、分表 ），至此，原則上 MPS 基於設備維度和基於第三方渠道的消息推送均已可知足。

固然，業務對於消推送的訴求，通常是基於業務結果，須要對指定用戶推送通知。所以，MPS 必須支持經過用戶 ID 路由推送的能力，於是延伸到客戶端，就須要有一個用戶與設備關係綁定的過程，正如上圖中的用戶綁定步驟，待流程完成後，MPS 已具有各類維度推送的基本條件，靜待業務調用。

2. 業務調用、消息推送過程

目前 MPS 主要支持兩種調用模式：

1. 業務系統接口調用；
2. mPaaS控制檯頁面調用。

通常業務流程已接口調用觸發爲主，平常驗證和羣發、廣播等流程則可經過控制檯來直接操做。對於客戶端消息通知內容，通常客戶端須要進行嚴格管控，所以 MPS 提供了推送模板管理的功能，可在 mPaaS 控制檯進行操做，例如：配置可一個「支付寶收款#amount#元。」的模板，模板中只有 amount 變量可替換，其餘內容均爲固定，接口調用時也只需傳輸 amount 屬性。

如此，管理人員可有效的控制和規範推送消息內容。此外，當推送內容須要變動時，只需維護模板，業務系統徹底不作任何變更便可按照新的消息內容推送通知。所以，在 MPS 的服務端流程中便多了一個模板渲染的步驟（同步支持語音播報模板，客戶端可根據語音類型消息，進行語言替換後播報聲音通知）。

在很是多的業務場景中，當業務發生時用戶未必在線，也未必有網絡。所以，在 MPS 中全部消息均會被持久化。業務發生時，MPS 會嘗試作一次推送（第三方渠道推送或自建的TCP 鏈接推送）。自建渠道中，會經過查詢緩存來判斷用戶的終端是否有 TCP 鏈接，若是存在則推送，客戶端收到推送消息後，會給服務端回執，服務端便可更新消息狀態。若是推送失敗，或者回執丟失，用戶在下一次創建鏈接時，會從新接受消息通知，同時客戶端會進行邏輯去重。

3. 多維度廣播消息通知推送

客戶端 App 運營每每須要進行大規模的營銷活動，MPS 全網消息通知，是提醒用戶活動開始的，促使用戶打開 App 的有效手段。同時，全網通知在不少時候也須要按照特定的規則進行控制範圍（如：操做系統類型，機型，版本等），所以 MPS 也添加了多維度推送的支持。

廣播推送主要分：自建渠道和第三方渠道推送兩種模式。

• 自建渠道，在前端觸發廣播任務時，MPS 封裝好推送內容與業務所需規則後，便可由接入網關來遍歷內存中的鏈接列表，並匹配特定維度來推送至客戶端（如圖中：最左側流程）。

• 第三方渠道模式，則需採用循環遍歷綁定關係獲取三方渠道 ID 來推送，對於億級用戶的 App 而言，快速的遍歷全部用戶，是對活動最強有力的支持，所以 MPS 依賴了分佈式調度任務來確保集羣各服務都參與到推送過程當中來：分佈式任務目前採用 3+1 的方式：

第一步：

調度中心平常狀況會按照固定的頻率（支持 crontab 表達式）來檢測是否有待處理的廣播任務，爲避免重複觸發和冗餘推送，檢測過程是單任務，經過單機檢測（如：圖中 step1: 隨機調度的是 MPS-B 服務器）。

第二步：

當 MPS-B 服務器，檢測到有待處理廣播任務後，開始進行任務分片（分片數=總用戶數 % 集羣中機器數 % 計劃每一個任務執行的用戶數），並對每一個任務分配任務 ID，並將任務模型返回給分佈式調度中心。

第三步：

分佈式調度任務中心，接收到分片任務列表後，將總任務趨於均衡的分配給集羣中每臺機器（MPS-A....MPS-N）同時攜帶任務 ID 和任務模型，各服務器領取到各自任務後，開始根據任務模型中的屬性各自處理。

第四步：

最終將消息通知挨條調用至第三方渠道，後面的工做則交給產商提供的消息中心與客戶端處理。

至此，MPS 消息推送最主要的處理流程基本介紹完畢，只要按照這個邏輯與客戶端配合把代碼堆起來，系統就可應運而生了。其中，在推送路由過程當中適當的加入策略模式、三方渠道推送管理中加入工廠模式等設計，也可讓系統作的更好看。更進一步，系統須要支持 LDC(Logical Data Center) 架構，支持多機房，多可用區（Zone）部署，以知足容災等穩定性需求，在相似這種部署方式下系統內部調用關係，分佈式調度任務控制等邏輯也須要進行適當的調整。

經過本節內容，但願給你們通篇介紹 MPS 的基礎架構技術，若是有問題歡迎你們微信後臺留言，或登陸消息推送具體文檔頁（ t.cn/EtnB6Gu ）瞭解更多。

往期閱讀

《開篇 | 螞蟻金服 mPaaS 服務端核心組件體系概述》

《螞蟻金服 mPaaS 服務端核心組件體系概述：移動 API 網關 MGS》

《螞蟻金服 mPaaS 服務端核心組件：億級併發下的移動端到端網絡接入架構解析》

《支付寶 App 構建優化解析：經過安裝包重排布優化 Android 端啓動性能》

《支付寶 App 構建優化解析：Android 包大小極致壓縮》

關注咱們公衆號，得到第一手 mPaaS 技術實踐乾貨

釘釘羣：經過釘釘搜索羣號「23124039」

期待你的加入～