转载

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，也应用于蚂蚁国际的印度尼西亚、菲律宾、马来西亚、澳门星汇银行等多个国际站点，支撑的业务范围几乎已涵盖蚂蚁所有版块，从支付、社交、营销、智能客服到财富、信用、保险、再到智能发布、智能运维等。