音视频直播--技术架构

前言

今天和大家讲一下音视频直播技术架构。之前的关注点主要放在客户端如何采集音频数据上，经过这两天的思考，我觉得应该先给大家讲一下音视频直播技术架构，这样更容易从整体上理解视频直播技术是如何运转的，之后再逐步的介绍每一个主题。

简单的音视频直播架构

这种架构非常的简单，利用已经有的CDN网络如阿里，帝联，蓝讯等，自己再搭建一个信令服务器，这样就将服务层搭建好了。

共享者首先向信令服务器发送共享音视频指令，之后通过 Camera 或 摄像头采集数据，数据经编码后通过RTMP协议将流推送给CDN网络。

接收端向信令服务器发指令，获取共享者共享的流名称，然后通过流名称从CDN网络拉取音视频流，再经过解码后渲染在屏幕上。

实时交互的音视频直播架构

这种架构与上一种比要复杂不少，其中最主要的差别是增加了自有网络。客户端通过 UDP 进行数据传输，这样可以大大减少由于网络及CDN结构导致的音视频延迟问题。

共享者共享音视频时，都是通过UDP协议上传到自有网络服务器上。如果有其它参与人要与共享者进行实时互动，那么参与者也是通过UDP连接到自有网络，这样才能达到实时互动的效果。

共享者的音视频数据上传到自有网络后，还要通过专门的服务将数据流转成RTMP流推到CDN网络，这样对于大多数不参与时实互动的用户就可以从CDN获取数音视频数据了。

这种架构既可以满足实时互动的需求，也可以满足大批用户只观看不互动的需求。

解决高负载大并发问题

为了解决实时互动大负载，高并发的问题，需要增加资源管理服务器，实时监测各服务的资源。第次当用户共享音视频时，资源管理器都可以分配最佳的服务器给共享用户使用，并且服务器资源可以根据需要横向扩容。

注意 为了增加执行效率，服务端基本都是用 C/C++ 程序编写。

小结

实时互动直播是未来的直播趋势，大看可以看一下我另一篇文章音视频直播漫谈中的介绍。有了这个架构我们后面就可以逐步的给大家讲解每个主题。如 Android、IOS、windows、mac下如何进行音视频数据采集，如何进行编码，是采用硬编还是使用软编?它们各自有什么优势，如何使用 opengl 进行渲染，如何进行网络优化等等。