共计 2621 个字符，预计需要花费 7 分钟才能阅读完成。
作者：王豫宁(颜冉)
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 化的方向持续摸索，通过就近接入，边缘部署等形式，进一步缩短链路，晋升用户体验。
关注【阿里巴巴挪动技术】，阿里前沿挪动干货 & 实际给你思考！
