我是来自声网的SDK资深架构师，负责整个前端API。声网在全球部署了软件定义的实时网 SD-RTN™，它为开发者提供了实时音视频专用网络服务。之前有一位演讲人说 API 很重要。确实是这样的。
我会从这 4 个方面简要介绍一下我们的架构经验：
1.RTC 场景现在面临的问题和挑战；
2.重点介绍一下架构和API的设计和思想；
3.如何对架构上进行重构或代码改进，从而更好地控制媒体和网络；
4.为了 SDK 的低延迟、高性能、高并发，我们做了哪些探索。
考虑到大家对 RTC 领域不是太了解，我先简单介绍一下。其实它是一个很传统的实时音视频场景，现在最主流的技术是由谷歌提供 WebRTC，利用它，你可以通过浏览器与另一个人进行实时音视频的通话。声网也参考了一些 WebRTC 的设计，从最开始的一对一通话，然后到一对一多通话，到现在一个频道可以支持上百万的用户，其中也有很多技术挑战。
问题与挑战
首先，从场景角度讲，我们会遇到的问题和挑战有哪些呢？
- 传统的 RTC 场景：现在我们可以看到很多场景，例如说 4K 高清视频，如果传统的SDK不做改善的话，传输一个 4K 视频，对它的内存、CPU等各方面都会带来极大的挑战。
- 娱乐社交和在线教育：现在不光需要打开 Web 浏览器、摄像头，还需要打开本地的播放器，传输本地播放器的内容。
- 云游戏加速：现在很多厂商还在开发云游戏，游戏运行于服务端，数据以音视频、指令等形式传输至手机，手机仅仅负责渲染，其中最大的挑战就是延时，如果从服务端到手机的传输延时超过 200ms 的话，游戏体验会变得很差，这就需要一个类似于声网的实时码流加速传输网络。
- SIP/PSTN：SIP传统的网络电话，在全球有大量的业务需求，通过网络的流量来达到整个 RTC 的效果。
- WebRTC 加速：如果在中国和美国之前通过公网 P2P 沟通，却缺少一个底层网络网和SDK的介入的话，其实是很难工作的。一个没有任何 QoS（服务质量）保障的连接，通话会很糟。
这些都是我们在 RTC 领域会遇到的场景，而 WebRTC 一类的开源引擎是远不能达到我们对场景的技术要求的，需要一个具备网络传输、音视频编解码等能力的 SDK 来实现。
点击查看原文>