作者：王豫宁(颜冉)

RTMS 是 Real Time Message Service 的缩写，基于帧同步的思想，我们实现了一套实时网络通信方案，服务端只转发消息，不做任何逻辑处理，专门适用于对实时性和交互性有很高要求的业务场景。

在实现上，RTMS 在服务端通过提供 SDK 的形式与业务服务器集成部署在一起，减少了东西向的流量转发，不依赖外部存储服务(如分布式缓存,数据库)等，纯内存计算，提供底层的业务网络能力。通过简化设计，大大提高了实时性和稳定性。

业务背景

为提升用户活跃度和黏性，目前支付宝存在很多如蚂蚁森林，蚂蚁庄园，芭芭农场这样的互动产品。在往年 618 和双 11 大促期间，有叠猫猫的互动产品，前年开始的新春五福，又新增了打年兽的玩法等等。但是目前支付宝端内的互动产品的互动性还不够强，用户与用户之间无法同时竞技，交互性和参与感偏低。

在五福走过的第 7 年，新春五福这个大 IP 也急需新的玩法创新来进一步吸引用户。通过调查发现，用户对五福活动新增“互动，PK，对战”的呼声也很高。RTMS 的网络技术能力和五福产品团队设计的联机版打年兽玩法需求非常契合，在 2022 新春五福活动中发挥了重要作用，稳定支撑活动顺利进行。

业务痛点

1、多人实时互动业务场景，处理复杂，实时性差

服务端通常是分布式无状态的微服务架构，客户端请求会经过负载均衡，随机的落到一台业务服务器上进行处理。在多人实时互动场景中，同一个互动“房间”的多个用户请求被随机路由到不同服务器后，为了维护获取“房间”的状态，互动服务提供方不得不依赖分布式缓存或者集中式的数据库进行数据的存储和交换。

同时，为了将处理的结果消息发送到客户端，还需要依赖中心化的消息核心服务来发送。由于客户端长连接分布在不同的服务器上，消息核心需要通过分布式缓存来管理连接信息，为推送时任意消息核心服务器都能够找到特定用户的长连接所在服务器。此外消息核心原本的设计是要保证即使客户端网络不在线也能够最终推送到客户端，所以消息核心会把每一条消息都持久化到数据库。

可以看出，基于传统的网络通信解决方案，业务处理非常复杂，需要多次访问分布式缓存和数据库，服务端内部的东西向流量和请求也比较多，增加了处理复杂度和耗时。虽然保证了消息到达的可靠性，却无法满足互动场景中高频、实时的诉求。

2、大规模随机用户消息订阅场景，处理复杂，耗时冗长

在支付宝目前的股票业务场景中，股票标的众多，在开市交易期间，每个股票标的每分每秒的数据都在不断的发生变化，消息量巨大。用户在查看股票行情时，也会经常不断的切换正在查看的股票标的。每天会有上百万用户同时在查看不同股票标的信息。如何将频繁变化的股票行情数据，准确快速的推送到所有客户端上，是一个难题。

服务端需要实时感知并维护用户和股票标的之间的一对多关系，这个工作非常复杂和麻烦。在有消息产生的时候，需要通过消息核心的服务，遍历用户列表，将相同的消息逐个发送给所有客户端。对于热门标的来说，批量完整调用一次都很费时。随着用户规模的不断攀升，这样的调用方式越来越重，逐渐无法支撑业务的发展。

设计方案

仔细思考这些新的业务形态的诉求，我们重新设计了新的南北向的实时消息推送方案 RTMS，通过定向路由、订阅发布机制、放弃消息持久化、去中心化等新的思路满足了业务对于高实时性、快速大规模扩散的需求。

去中心化 &去持久化

和中心化的消息核心不同，RTMS 完全使用去中心化的方案，连接管理、上行消息路由投递、下行消息的扩散分发通过 SDK 的方式和业务服务同机部署，减少了业务服务和消息核心之间的东西向流量。

此外，这些场景对于消息的实时性要求高，也意味着对收到客户端离线期间产生的消息的诉求下降，因此我们在设计中去掉了服务端对消息的持久化。高频的消息不再持久化不仅提高了整个链路的实时性，也规避了巨大的存储压力。

双向通信

RTMS 的双向通信能力，可以使客户端发送上行请求和服务端处理结果推送到客户端直接在同一条链路上完成，链路更加简化，编程模型更加统一。

上行消息

上行消息，是指客户端发送消息到服务端。上行消息首先会投递到用户自己的上行消息队列中，然后再通过上行消息队列绑定的巡检任务，异步投递到指定的发送目标。

下行消息

下行消息，是指服务端发送到客户端的消息。Meeting 消息和 Topic 消息首先投递到其本身的消息队列中，然后通过巡检任务，异步的将消息投递到用户的下行消息队列。用户下行消息队列也各自有一个巡检任务，再异步的将消息推送到客户端。

定向路由

通过定向路由，我们把逻辑上属于一个“房间”的用户的长连接路由到同一台服务器上的 RTMS SDK 进行处理。

服务端通过一定的机制，生成一个 Token，这个 Token 代表了一台特定服务器的基本信息。不同的客户端，在建立长连接时可以指定这个 Token，负载均衡器识别这个 Token ，把具有相同 Token 的连接路由到同一台服务器上。从而属于一个“房间”的用户的业务逻辑可以集中在单台服务器上处理，降低业务处理复杂度，避免使用集中式的存储，提高消息实时性。

订阅发布模式

RTMS 除了提供基础的按指定用户推送消息的模式外，还提供了 Meeting 和 Topic 两种推送模式，来适应不同的消息扩散场景。

Meeting 模式

Meeting 是对业务上一个“房间”实例的抽象，例如一局联机版打年兽可以对应一个 Meeting，局内的所有用户都共同加入到一个 Meeting 中。一个 Meeting 仅会在单台服务器上，因此 Meeting 内所有用户的上行和下行消息，都可以集中在单台服务器上处理。

Topic 模式

Topic 是对一类相关消息的抽象，例如一个股票标的可以对应一个 Topic，用户可以订阅某个股票标的的 Topic，产生一个订阅关系。

通过集群扩散能力，业务服务端仅需调用接口一次，RTMS 通过消息队列中间件将消息扩散到服务端所有的机器上，进而每台服务器再按照 Topic 的订阅关系将消息分别扩散到所有客户端。

总结 &展望

在消息推送以及端到端的网络通信领域，RTMS 提供的编程模型和设计思路给了业务一种新的选择。在对实时性、交互性有较高要求的场景上，RTMS 能够为业务提供重要的价值，降低处理复杂度，使业务更加聚焦于业务本身。

为进一步提高消息的实时性和大规模扩散能力，RTMS 将向 MESH 化的方向继续探索，通过就近接入，边缘部署等方式，进一步缩短链路，提升用户体验。

关注【阿里巴巴移动技术】，阿里前沿移动干货 &实践给你思考！