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 主要支援兩種呼叫模式：
- 業務系統介面呼叫；
- 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 服務端核心元件體系概述：移動 API 閘道器 MGS》
《螞蟻金服 mPaaS 服務端核心元件：億級併發下的移動端到端網路接入架構解析》
關注我們公眾號，獲得第一手 mPaaS 技術實踐乾貨
釘釘群：通過釘釘搜尋群號“23124039”
期待你的加入～