It has been nearly 3 years since the anyRTC 4.0 service was launched. After this period of operation analysis and various feedbacks from customers, it has evolved to version 4.3 through updating and iteration. Compared with the previous architecture, the upgraded version 4.3 has made major adjustments, integrating many existing business architectures.
one. RTM signaling service
In this RTM upgrade, the architecture is slightly adjusted to increase the capacity of the entire system. At present, RTM has several large regions, including Asia, mainland China, Southeast Asia, America, Australia, Europe, and Africa.
This upgrade is to increase scalability. IMS is used as an access node, and all nodes can be expanded horizontally. With the increase in the number of users and business volume, IMS edge nodes can be increased at will, while core nodes M and R cannot be scaled arbitrarily, because they retain a certain state. We use a consistent hash sharding method to generate a 32-bit random number for all user accounts, and put these numbers into a On the ring, each server generates a set of random numbers, which are evenly distributed on the ring. In this way, all messages will be mapped to the server whose hash value is smaller than its own.
The allocated number of all nodes can be dynamically increased and decreased. If a core server fails or goes offline, it can be redistributed to other servers. In fact, some core nodes in the message core, except the edge node IMS, have done similar fragmentation.
two. RTC streaming service
RTC version 4.3 upgrade changes a lot. The original three core services of signaling management service, streaming service, streaming service, and routing service are removed, which simplifies the complex logic of the original RTC complex signaling interaction, room management, and streaming broadcast.
1. Stream push node SNode
Responsible for RTC client access, authentication, stream push, room/channel management, audio and video stream broadcast notification, active reporting of streams to RNode, etc. Support horizontal expansion.
2. Streaming node GNode
Responsible for RTC client pull flow, single node 10,000 channels concurrent. Support horizontal expansion.
3. Routing node RNode
The focus of this upgrade is that routing nodes are responsible for forwarding audio and video streams, including intra-area forwarding and cross-area forwarding. At the same time, it supports self-organizing network, full connection between autonomous domains and autonomous domains, each node has its own routing table, and each node will periodically broadcast its own routing table to other nodes. For example, A knows how much delay it takes to reach B, C, and D. After a round of broadcasting, B, C, and D will know how much delay they will have to reach other nodes if they pass through A. Each node will choose a route with a shorter delay for transmission. This algorithm is somewhat similar to the BGP algorithm. Of course, the actual strategy will definitely not be so simple, because if all nodes adopt the same strategy, the traffic may converge to certain nodes, which will impact these nodes during the peak traffic period. We have implemented a set of very Complex strategies for load balancing.
three. RTK intercom service
The intercom service is a new service added in version 4.3. It is a set of Internet intercom services that separate the voice intercom from the RTC business and operate independently.
1. RTK access service
Intercom access service, distributed deployment, nearby access, SDK and WebRTC access, speech synthesis, etc.
2. RKM management service
Intercom management service, room management, signaling broadcast, microphone grabbing, interrupt, media broadcast, etc.
The overall structure of the intercom service is simple and clear, using the signaling system in RTM, and supports horizontal and horizontal expansion in terms of capacity, which can easily cope with high-concurrency voice intercom scenarios.
