OWT Server 整体架构分析

基础模块架构图

按自己的理解用 visio 大体画了一下。

前一篇博客讲过OWT Server是模块化的设计，不同模块可以分开部署，便于新手入门，下面画了OWT Server的一些基础模块（支持WebRTC开会）的框架图，如果把这几个模块搞清楚了，差不多对OWT Server也就理解了。

1. 模块内部的 RPC 调用都是通过 RabbitMQ 消息队列实现的，都不是直接调用，即上图中 所有的虚线都是通过RabbitMQ间接通信的，而不是直接连接。

2. 模块内部流交换（Internal IO）默认用的是 TCP 协议直接交互。

3. 会议房间信息（默认布局和支持的编码格式等）在创建会议的时候存储在 MongoDB 中。

基础模块介绍

模块	功能
Cluster Manager	集群管理模块， 负责监控与调度集群中的其他模块，其他模块启动后会加入集群，并维持约1秒一次的心跳保活。
Conference Agent	会议控制管理模块，所有的会中逻辑，包括但不限于发布和订阅媒体流，静音媒体流等操作。也负责调度其他模块，比如激活一场会议，Conference模块要申请并维护至少一个 Video、Audio 和 WebRTC 模块。
Management API	提供整个系统的对外Restful API，就是一个简单的HTTP服务器，提供创建与删除会议、获取入会token和会议控制等功能的接口。
Portal	是 OWT 系统对接客户端 WebRTC 协议入会的信令模块，使用的WebSocket保持与服务器间的信令交互。
WebRTC Agent	是OWT系统对接客户端WebRTC协议入会的媒体处理模块，主要是接收客户端WebRTC协议过来的媒体流 解包转换为内部流交换封包格式发送给Video/Audio Agent，和反向的媒体流操作。
Video Agent	负责视频混流和视频转码功能，MCU会议模式下，一场会上来好几路视频流，都通过WebRTC 模块发送给Video模块就行混流，然后输出一路视频再发给用户。
Audio Agent	负责音频混流和转码，功能通Video模块。

其他模块介绍

其他模块	功能
Management Console	会议房间配置的Web管理页面，默认端口3300。
Streaming Agent	对接通用流媒体的模块，内部分为 streaming-in 和 streaming-out ，对应 RTSP / RTMP 等格式的拉流和推流。
Recording Agent	录制模块，可以录制任意指定ID的媒体流，保存为 H264 & AAC 编码格式的的 mp4 或者 mkv 文件。与Streaming Agent 类似功能流程，从Video/Audio Agent获取媒体流进行保存。如果完全按照Streaming Agent 的 In 和 Out 思想的话，也应该包含 读取媒体文件的功能，但是它没有，完全可以自己实现。
SIP Portal	对接SIP系统的信令模块。对应支持 WebRTC 协议的Portal模块。
SIP Agent	对接SIP系统的流媒体模块。与WebRTC Agent类似功能。
Analytics Agent	顾名思义 媒体或网络分析用的吧，没用过，不熟悉。

Agent 模块架构

这里说的 Agent 模块指的是 Conference Agent、WebRTC Agent、Video Agent 、Audio Agent、 Streaming Agent、 Recording Agent、 SIP Agent 和 Analytics Agent。可能你刚才就在纳闷为啥这些模块名字都带有agent字样，是的，它们具有同样的设计思想。Agent 有代理人的意思，也就是说这些模块不是“真正干活的”。

所有的 Agent 模块都采用两层工作模型，即agent进程和node进程。node 进程是实际干活的，agent 进程负责创建和管理 node 进程。node 进程与 agent 进程通过管道进行进程间通信。

服务启动后即创建一个 agent 进程，加入集群并定时向Cluster Manager 发送 KeepAlive 消息和汇报机器负载信息。同时创建N个 node 进程预留使用，N由配置文件指定。比如在会议初始化的过程中，1. 负责具体房间的某个Conference node 向 Cluster Manager 申请调度一个Video agent (RPC schedule)，2. 然后Conference node 向这个Video agent申请一个Video node(RPC getNode)。3. 接下来Video agent调用这个Video node的RPC方法进行发布或者订阅视频。