OWT Server整体架构分析

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. 这样模块化和强隔离的架构保证了错误隔离，一个组件中产生的异常不会传染影响其他组件，另外各个组件在运行时也都可以单独进行升级替换。