技术分享| anyRTC 服务 4.3 升级

anyRTC 4.0 服务上线已经有近 3 年时间，经过这段时间的运营分析和客户的各种反馈，通过更新迭代的方式，现在已经进化到了 4.3 版本。本次升级的 4.3 版本相比之前的架构做了重大调整，融合了很多现有的业务架构。

一．RTM 信令服务

本次 RTM 升级，对架构进行微调整，增加整个系统的容量。目前 RTM 有几个大区域，有亚洲、中国大陆，东南亚、美洲、澳洲、还有欧洲、非洲几个大区。

本次升级的是增加了可扩展性，IMS 作为接入节点，所有的节点都是可以水平扩展的，随着用户数量增加，业务量的增长，IMS 边缘节点是可以随意增加的，而核心节点 M 和 R 不能做任意的水平扩展，因为他们保留了一定的状态，我们把所有用户的账号用了一个一致性哈希的分片方法来产生一个 32 位的随机数，把这些数放到一个环上，每个服务器各自产生一组随机数，在环上均匀分布。这样所有的消息会被映射到比自己的哈希值小的那一个服务器上面。

所有的节点的分配的数量都是可以动态地增加和减少的。如果有一个核心服务器故障或者下架了，那么它可以重新分布到别的服务器上，实际上消息核心中除了边缘节点 IMS 之外一些核心节点，它们都是做了类似的分片。

二．RTC 流媒体服务

RTC 的 4.3 版本升级改动较大。将原来的信令管理服务移除，推流服务，拉流服务，路由服务三个核心服务，简化了原有的 RTC 复杂的信令交互，房间管理，流广播等复杂的逻辑。

1.推流节点 SNode

负责 RTC 客户端的接入，鉴权，推流，房间/频道管理，音视频流广播通知，主动上报流给 RNode 等。支持水平扩容。

2.拉流节点 GNode

负责 RTC 客户端拉流，单节点万路并发。支持水平扩容。

3.路由节点 RNode

本次升级的重点，路由节点负责音视频流转发，包含区域内转发和垮区转发。同时支持自组网，自治域与自治域之间全连接，每个节点都有自己的路由表，每个节点会定期广播自己的路由表到别的节点。比如 A 知道到自己到 B、C、D 的延迟是多少，一轮广播之后 B、C、D 就会知道自己如果通过 A，到其他节点的延迟会有多少。各节点会选择延时较短的路线传输，这个算法有点类似于 BGP 算法。当然实际策略肯定不会这么简单，因为如果所有节点都采用相同策略，流量可能会汇集到某一些节点上去，在流量高峰期时会对这些节点造成冲击，我们在 4.3 版本中实现了一套很复杂的策略来进行负载均衡。

三．RTK 对讲服务

对讲服务是 4.3 版本新增加的服务，是将语音对讲从 RTC 的业务中独立出来，单独运营的一套互联网对讲服务。

1.RTK 接入服务

对讲接入服务，分布式部署，就近接入，SDK 和 WebRTC 接入，语音合成等。

2.RKM 管理服务

对讲管理服务，房间管理，信令广播，抢麦，打断，媒体广播等。

对讲服务整体架构简洁明了，使用了 RTM 中的信令体系，容量方面支持横向水平扩容，轻松应对高并发语音对讲场景。