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中的信令体系,容量方面支持横向水平扩容,轻松应对高并发语音对讲场景。