mPaaS 服務端核心組件：移動同步服務 MSS 架構解析

承接《mPaaS 服務端核心組件》系列，本篇文章圍繞移動同步服務（Mobile Sync Service）展開架構解析。MSS 是移動開發平臺 mPaaS 的核心基礎服務組件之一，源自於螞蟻金服集團內面向移動應用從服務端到客戶端進行海量數據推送的全鏈路解決方案。

該系列已推送內容請參考文章尾部推薦。

核心概念解讀：移動同步服務 MSS

MSS 的核心概念爲：

• 經過一個安全的數據通道 TCP+SSL，及時、準確、有序地將服務器端的業務數據，主動的同步（SYNC）到客戶端 App，可被定義爲：一個客戶端與服務端之間的可靠消息中間件。

傳統的 RPC 已立足互聯網行業幾十年，也能知足絕大部分業務場景和功能需求。但現階段隨着移動互聯網的全面普及和昇華，不管是 App 的規模仍是用戶對於 App 實時響應的要求都已進入了一個新的階段。

傳統的請求響應因 RPC 自身特性，存在許多的不足，典型的如：

1. 客戶端 App 在特定的場景下須要調用 RPC 請求來獲取最新的數據，而服務端（雲端）實際沒有或僅有少許數據發生變化；

2. 當客戶端啓動時，不一樣的業務模塊，業務功能因設計上的獨立，須要分別進行 RPC 請求來完成各自業務的數據拉取；

3. 當服務端（雲端）有業務數據發生變化時，客戶端沒法實時感知，或只能定時輪詢 RPC 接口來按期檢查變化；

4. 從技術角度，傳統 RPC 大多基於 http(s) 的短鏈接進行數據交互，鏈接上即便使用 keepalive 等特性也沒法長期保持鏈接，沒法作到鏈路持續複用，請求建立鏈接，證書交換，加解密等對網絡耗時及性能都會帶來不小的損耗。

由此，爲了解決或優化這些問題，MSS 應運而生，其核心特性有：

1. 可靠同步：所謂可靠，是針對業務要求的 QoS（Quality of Service）等級爲必達的業務場景而言，SYNC 保證只要用戶在該數據有效期內活躍而且匹配業務推送要求的條件（客戶端版本號、操做系統類型等多個維度），就必定會讓客戶端同步到業務推送的數據。

2. 增量有序：MSS 保證同一個通道內到達客戶端的消息順序必定是與業務服務器調用 MSS 服務器的順序是一致的，而且全部消息以增量方式同步至客戶端。

3. 高實時性：當客戶端鏈接的網絡情況良好，MSS 推送的實時性是很高的，消息推送耗時幾乎是純網絡傳輸的耗時（1s 以內送達）。當客戶端鏈接的網絡受到主幹網波動、路由器故障、基站信號弱、客戶端存儲滿等不可抗拒因素干擾時，MSS 推送則會待 TCP 長鏈接從新建上之後再進行數據同步。

移動同步服務 MSS 基礎原理

相似於 MySQL 的 binlog 機制，MSS 服務器和客戶端 SDK 之間傳遞的基本數據單元爲 oplog，當業務須要同步一個變動數據到指定的用戶或設備時，業務調用 MSS 接口，MSS 服務端會將業務須要同步的數據變動包裝爲一個 oplog 持久化到數據庫，而後在客戶端在線的時候把 oplog 推送給客戶端。每一個 oplog 擁有一個惟一的 oplog ID，oplog ID 在肯定的用戶、肯定的業務範圍內保證惟一而且單調遞增（按調用順序）。MSS服務端會按照 oplog ID 從小到大的順序把每一條 oplog 都推送至客戶端。

MSS 服務端和客戶端都會記錄客戶端已經收到的最大 oplog ID，稱爲同步點（亦能夠被理解成數據版本號）。

1. 典型場景一：長鏈接創建時，同步積壓數據

假定，客戶端有三個業務：Biz1,Biz2,Biz3。它們各自的同步點爲：8,17,21。

MSS 的服務端對這三個業務分別檢查同步點以後有沒有積壓的 oplog。如圖所示，服務端檢查出來 Biz1 有 ID 爲 23,26 的兩條 oplog 積壓，Biz2 有 ID 爲 24,25,29 的三條 oplog 積壓，Biz3 有 ID 爲 30 的一條 oplog 積壓。

服務端把上一步中查出來的各個業務積壓數據推送給客戶端。

客戶端收到數據後，把各個業務最大的 oplog ID 上報給服務端，服務端確認客戶端已經收到這些數據。此時 Biz1,Biz2,Biz3，它們各自的同步點爲：26,29,30。服務端確認沒有積壓的數據，同步暫時到達一個穩定的狀態。同時，在客戶端，MSS SDK 把收到的新數據通知給 Biz1,Biz2,Biz3 三個業務。

2. 典型場景二：客戶端在線時，實時推送數據

假定客戶端在線，TCP 長鏈接依舊存活着，Biz3 業務服務器請求把一個數據同步到客戶端，MSS 服務器給它的oplog 編號爲 35，先持久化至數據庫。

服務端判斷出客戶端到服務端的長鏈接在線，把編號爲 35 這條 oplog 推送給客戶端。

客戶端收到編號爲 35 這條 oplog 後，向服務端 ACK 回執報告已經收到了。此時同步再次暫時到達一個穩定狀態。同時，在客戶端，SYNC SDK 把收到的新數據通知給 Biz3 業務。

移動同步服務 MSS 架構優點

究其特性和原理，MSS 可體現出獨有的優點：

1. 增量推送：增量推送業務數據，可有效減小冗餘數據的傳輸，極大下降網絡傳輸成本。

2. 合併推送：客戶端初始化成功時，服務端可一次性推送多個業務數據，避免了不一樣業務模塊各自進行的 RPC 請求。

3. 減小請求：當服務端無增量業務數據時，將不會消耗任何客戶端 RPC 請求成本，減小業務的冗餘 RPC。

4. 提升時效：當服務端發生數據變化時，可在最短期內將數據直接推送至客戶端，無需等待客戶端 RPC 請求時響應。

5. 提高體驗：數據在用戶無直接感知狀況下推送，在渲染客戶端界面以前，數據已到位，下降了用戶等待時間。

移動同步服務 MSS 架構解析

1. 業務&MSS&客戶端：

業務服務僅需與 MSS 服務器端交互，接口成功調用以後，後續數據同步的過程全權由 MSS 來接管，業務系統接入成本很是低。

MSS 客戶端 SDK 與業務模塊之間一樣有相似的機制來保證數據可靠、惟一，並確保業務模塊能被接收到。

2. MSS 與接入網關：

在以前的文章中曾經提到螞蟻統一接入網關（Accgw）：

Accgw 承接進行了 TLS 卸載、配置管控、動態 UPSTREAM 路由、MMTP 協議解析、數據包壓縮、鏈接保持、流量管控、以及負載均衡等職責，而 MSS（SYNC）即爲 UPSTREAM 路由的其中一個渠道，所以，Accgw 所擁有的超級能力徹底被 MSS（SYNC）所應用。

3. MSS 與 MMTP&HTTP2：

MMTP，全稱 Mayi Mobile Transport Protocol，即螞蟻移動傳輸協議，是基於 TCP 協議研發的私有協議。該協議將網絡數據包劃分爲兩類幀：指令幀和數據幀。

指令幀主要實現網絡系統內部的控制，包含爲了下降設備功耗而設計的智能心跳、方便連接調度的控制指令幀、客戶端網絡配置幀等；數據幀則用於傳輸真正的業務數據。MMTP 擁有極簡數據大小、高安全、高擴展以及極致的性能，MSS（SYNC）的數據傳輸一樣也是基於 MMTP；

除此以外，爲適應行業標準，MSS 同樣在複用 MMTP 數據協議的基礎上支持了 HTTP2 鏈路。

總結

MSS（SYNC）在螞蟻集團內部已經服務於包括支付寶客戶端、螞蟻財富、香港版支付寶、口碑獨立客戶端、口碑商戶客戶端等多個超級 App，也應用於螞蟻國際的印度尼西亞、菲律賓、馬來西亞、澳門星匯銀行等多個國際站點，支撐的業務範圍幾乎已涵蓋螞蟻全部版塊，從支付、社交、營銷、智能客服到財富、信用、保險、再到智能發佈、智能運維等。

與此同時，SYNC 也參與了集團內多年雙11、雙12、新春紅包大促活動，通過多年的優化和提煉，目前已經具有了億級在線、百萬級 TPS 在線推送能力，在集團內部日推送消息量達到千億級別的巨大規模，已然成爲集團 App 不可或缺的核心基礎能力，也是 mPaaS 服務端核心組件的一記重拳。

| 移動開發平臺 mPaaS 三款組件重磅上線螞蟻金服開放平臺：

• 公測期，歡迎體驗試用。支付寶掃碼或登陸開放平臺

往期閱讀

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

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

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

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

《mPaaS 核心組件：支付寶如何爲移動端產品構建輿情分析體系？》

《mPaaS 服務端核心組件：移動分析服務 MAS 架構解析》

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

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

期待你的加入～