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