OWT Server整体架构分析

目录

相关文章：

  1. Ubuntu环境安装OWT Server[Open WebRTC Toolkit]
  2. Docker环境安装OWT Server[Open WebRTC Toolkit]
  3. OWT Server整体架构分析 [Open WebRTC Toolkit]
  4. OWT Server信令分析 (上) [Open WebRTC Toolkit]
  5. OWT Server信令分析 (下) [Open WebRTC Toolkit]
  6. OWT Server进程结构和JS代码处理流程 [Open WebRTC Toolkit]
  7. OWT Server REST API

1. OWT Server架构

  1. OWT Server秉承模块化的架构原则，根据组件的功能可以分为五大块，如下图所示。

1. 信令组件

  1. 信令组件，负责和客户端进行信令交互。
    1. WebRTC Portal负责和WebRTC客户端进行信令交互。
    2. SIP Portal负责和SIP客户端进行信令交互。

2. 媒体对接组件

  1. 媒体对接组件，负责把媒体数据接入到系统内，以及把媒体数据接出到其他系统。
    1. WebRTC Agent负责和WebRTC客户端进行媒体数据的传输。
    2. SIP Agent负责和SIP客户端进行媒体数据的传输。
    3. Streaming Agent负责RTSP/RTMP/HLS/Dash流的输入输出。
    4. Recording Agent负责服务端录制。

3. 媒体处理组件

  1. 媒体处理组件，负责音视频数据的转码、合并、分析等处理。
    1. Audio Agent负责音频转码和混音。
    2. Video Agent负责视频转码和合成。
    3. Analytics Agent则提供了一些服务端的音视频流分析功能，并且支持自定义插件进行分析处理。

4. 呼叫控制组件

  1. 呼叫控制组件，负责房间、用户的控制和管理，比如加入房间、发布音视频流、订阅音视频流等，都是由Conference Agent进行处理的。

5. 支持组件

  1. 支持组件包括：
    1. OWT Server即便在单机运行时也是按照集群形式管理的，Cluster Manager就是一个简单的集群管理器。
    2. 创建房间、获取用户信息和流信息之类的功能都是通过RESTful API的形式提供的接口，而这些接口都由Management API进行提供。
    3. Management Console是管理员控制台，提供了一个网页服务。
    4. OWT Server需要持久化的数据都保存在MongoDB中，各个组件之间的通信则是利用基于RabbitMQ的RPC调用来实现的。
  2. 上面这些组件部署时都是独立的进程，实际上部署时各个组件都是独立的目录，它们既可以都运行在同一台服务器上，也可以运行在不同的服务器上。
  3. 这样模块化和强隔离的架构保证了错误隔离，一个组件中产生的异常不会传染影响其他组件，另外各个组件在运行时也都可以单独进行升级替换。