承接《mPaaS 服務端核心元件》系列，本篇文章圍繞移動同步服務（Mobile Sync Service）展開架構解析。MSS 是移動開發平臺 mPaaS 的核心基礎服務元件之一，源自於螞蟻金服集團內面向移動應用從服務端到客戶端進行海量資料推送的全鏈路解決方案。
該系列已推送內容請參考文章尾部推薦。
核心概念解讀：移動同步服務 MSS
MSS 的核心概念為：
- 通過一個安全的資料通道 TCP+SSL，及時、準確、有序地將伺服器端的業務資料，主動的同步（SYNC）到客戶端 App，可被定義為：一個客戶端與服務端之間的可靠訊息中介軟體。
傳統的 RPC 已立足網際網路行業幾十年，也能滿足絕大部分業務場景和功能需求。但現階段隨著移動網際網路的全面普及和昇華，無論是 App 的規模還是使用者對於 App 實時響應的要求都已進入了一個新的階段。
傳統的請求響應因 RPC 自身特性，存在許多的不足，典型的如：
-
客戶端 App 在特定的場景下需要呼叫 RPC 請求來獲取最新的資料，而服務端（雲端）實際沒有或僅有少量資料發生變化；
-
當客戶端啟動時，不同的業務模組，業務功能因設計上的獨立，需要分別進行 RPC 請求來完成各自業務的資料拉取；
-
當服務端（雲端）有業務資料發生變化時，客戶端無法實時感知，或只能定時輪詢 RPC 介面來定期檢查變化；
-
從技術角度，傳統 RPC 大多基於 http(s) 的短連線進行資料互動，連線上即使使用 keepalive 等特性也無法長期保持連線，無法做到鏈路持續複用，請求建立連線，證書交換，加解密等對網路耗時及效能都會帶來不小的損耗。
由此，為了解決或優化這些問題，MSS 應運而生，其核心特性有：
-
可靠同步：所謂可靠，是針對業務要求的 QoS（Quality of Service）等級為必達的業務場景而言，SYNC 保證只要使用者在該資料有效期內活躍並且匹配業務推送要求的條件（客戶端版本號、作業系統型別等多個維度），就一定會讓客戶端同步到業務推送的資料。
-
增量有序：MSS 保證同一個通道內到達客戶端的訊息順序一定是與業務伺服器呼叫 MSS 伺服器的順序是一致的，並且所有訊息以增量方式同步至客戶端。
-
高實時性：當客戶端連線的網路狀況良好，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，稱為同步點（亦可以被理解成資料版本號）。
- 典型場景一：長連線建立時，同步積壓資料
假定，客戶端有三個業務：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 三個業務。
- 典型場景二：客戶端線上時，實時推送資料
假定客戶端線上，TCP 長連線依舊存活著，Biz3 業務伺服器請求把一個資料同步到客戶端，MSS 伺服器給它的oplog 編號為 35，先持久化至資料庫。
服務端判斷出客戶端到服務端的長連線線上，把編號為 35 這條 oplog 推送給客戶端。
客戶端收到編號為 35 這條 oplog 後，向服務端 ACK 回執報告已經收到了。此時同步再次暫時到達一個穩定狀態。同時，在客戶端，SYNC SDK 把收到的新資料通知給 Biz3 業務。
移動同步服務 MSS 架構優勢
究其特性和原理，MSS 可體現出獨有的優勢：
-
增量推送：增量推送業務資料，可有效減少冗餘資料的傳輸，極大降低網路傳輸成本。
-
合併推送：客戶端初始化成功時，服務端可一次性推送多個業務資料，避免了不同業務模組各自進行的 RPC 請求。
-
減少請求：當服務端無增量業務資料時，將不會消耗任何客戶端 RPC 請求成本，減少業務的冗餘 RPC。
-
提高時效：當服務端發生資料變化時，可在最短時間內將資料直接推送至客戶端，無需等待客戶端 RPC 請求時響應。
-
提升體驗：資料在使用者無直接感知情況下推送，在渲染客戶端介面之前，資料已到位，降低了使用者等待時間。
移動同步服務 MSS 架構解析
- 業務&MSS&客戶端：
業務服務僅需與 MSS 伺服器端互動，介面成功呼叫之後，後續資料同步的過程全權由 MSS 來接管，業務系統接入成本非常低。
MSS 客戶端 SDK 與業務模組之間同樣有類似的機制來保證資料可靠、唯一，並確保業務模組能被接收到。
- MSS 與接入閘道器：
在之前的文章中曾經提到螞蟻統一接入閘道器（Accgw）：
Accgw 承接進行了 TLS 解除安裝、配置管控、動態 UPSTREAM 路由、MMTP 協議解析、資料包壓縮、連線保持、流量管控、以及負載均衡等職責，而 MSS（SYNC）即為 UPSTREAM 路由的其中一個渠道，因此，Accgw 所擁有的超級能力完全被 MSS（SYNC）所應用。
- MSS 與 MMTP&HTTP2：
MMTP，全稱 Mayi Mobile Transport Protocol，即螞蟻移動傳輸協議，是基於 TCP 協議研發的私有協議。該協議將網路資料包劃分為兩類幀：指令幀和資料幀。
指令幀主要實現網路系統內部的控制，包含為了降低裝置功耗而設計的智慧心跳、方便連結排程的控制指令幀、客戶端網路配置幀等；資料幀則用於傳輸真正的業務資料。MMTP 擁有極簡資料大小、高安全、高擴充套件以及極致的效能，MSS（SYNC）的資料傳輸同樣也是基於 MMTP；
除此之外，為適應行業標準，MSS 一樣在複用 MMTP 資料協議的基礎上支援了 HTTP2 鏈路。
總結
MSS（SYNC）在螞蟻集團內部已經服務於包括支付寶客戶端、螞蟻財富、香港版支付寶、口碑獨立客戶端、口碑商戶客戶端等多個超級 App，也應用於螞蟻國際的印度尼西亞、菲律賓、馬來西亞、澳門星匯銀行等多個國際站點，支撐的業務範圍幾乎已涵蓋螞蟻所有版塊，從支付、社交、營銷、智慧客服到財富、信用、保險、再到智慧釋出、智慧運維等。
與此同時，SYNC 也參與了集團內多年雙十一、雙十二、新春紅包大促活動，經過多年的優化和提煉，目前已經具備了億級線上、百萬級 TPS 線上推送能力，在集團內部日推送訊息量達到千億級別的巨大規模，已然成為集團 App 不可或缺的核心基礎能力，也是 mPaaS 服務端核心元件的一記重拳。
| 移動開發平臺 mPaaS 三款元件重磅上線螞蟻金服開放平臺：
- 公測期，歡迎體驗試用。支付寶掃碼或登入開放平臺
往期閱讀
《螞蟻金服 mPaaS 服務端核心元件體系概述：移動 API 閘道器 MGS》
《螞蟻金服 mPaaS 服務端核心元件：億級併發下的移動端到端網路接入架構解析》
《mPaaS 服務端核心元件：訊息推送 MPS 架構及流程設計》
關注我們公眾號，獲得第一手 mPaaS 技術實踐乾貨
釘釘群：通過釘釘搜尋群號“23124039”
期待你的加入～