AKStream.Next · 文档中心

部署前规划

部署前规划

本页用于安装前评审。先形成一张可执行的部署表，再进入安装向导。

flowchart LR
    A[设备数、并发、录像天数] --> B[计算节点、带宽和磁盘]
    B --> C[确定单机或多节点拓扑]
    C --> D[列出端口、域名、证书和负责人]
    D --> E[评审通过后再安装]

先做五个决定

1. 部署拓扑

场景 建议起点 需要额外确认
演示、开发、少量通道 单机 All-in-One 数据也要持久化，不能把临时容器目录当生产
单站点生产 控制面、MediaServer、MySQL 可分盘或分机 录像盘吞吐、备份窗口、进程守护
多站点或跨网 控制节点 + 多媒体节点 每节点对外媒体地址、路由、时钟与故障域
已有独立媒体服务 AKStream.Next 接入远程媒体节点 API secret、WebHook、版本和网络双向可达

当前不默认承诺控制面多实例 Active/Active 的所有任务都可无条件并行消费，也不保证已有媒体会话在节点故障时无损迁移。需要高可用时，先定义数据库、控制面、媒体面分别怎样恢复。

2. 操作系统与架构

标准发布目标包括 Linux x64/ARM64、Windows x64/ARM64、macOS Intel/Apple Silicon。业务程序、MediaServer 和 FFmpeg 必须匹配目标系统与 CPU 架构。标准包之外的 Linux ARM32 需要自行发布并准备同架构依赖。

3. 数据库

首次向导可配置 MySQL、PostgreSQL、SQL Server 或 SQLite；正式部署前仍应按当前版本和现场规模做验证。生产多节点不要使用单机文件数据库共享。准备：

  • 数据库地址、端口、库名和专用账号；
  • 建库/建表权限与运行期最小权限的边界；
  • 字符集、时区、连接上限与备份策略；
  • 从 AKStream.Next 主机到数据库的真实网络测试。

不要把密码写进部署记录、命令历史或截图。

4. 存储

把不同数据的寿命分开：

  • Config 与 Data/Security：小但关键，必须备份并限制权限。
  • 数据库：保存业务真相、任务、录像索引与审计。
  • 录像根：容量最大，应独立监控字节、inode、写入延迟与增长率。
  • 裁剪输出：临时 IO 高，设置单独的保留与清理策略。
  • 日志：启用滚动和总量上限，避免与录像争抢系统盘。

容量估算不要只乘码率。还要预留文件系统开销、分片峰值、索引滞后、裁剪临时空间和安全余量。

5. 网络与域名

至少画出三类访问关系：

  1. 管理员/业务系统到 WebUI/API；
  2. 摄像机或上下级平台到协议与 RTP 端口；
  3. 最终播放器到 HLS、FLV、RTSP、RTMP 或 WebRTC 地址。

反向代理只解决 HTTP/HTTPS/WSS，不会自动代理 SIP、RTP、RTSP、RTMP 和全部 WebRTC 媒体。详见 端口、域名、HTTPS 与 NAT。

容量基线

在决定 CPU、内存和磁盘前，填写以下量：

  • 已纳管通道数、预计同时在线流数和峰值新建流速率；
  • 并发观看人数及使用的播放协议；
  • 并发录像路数、平均码率、分片时长和保留天数；
  • GB28181 注册量、Catalog 规模、RTP 端口范围；
  • RTC 房间、发布者、订阅者和 TURN 中继比例；
  • 协议轮询、事件、WebHook、录像扫描和日志保留强度。

用目标设备和目标码流做基准测试。授权额度是业务上限，不等于服务器容量。

安装前评审清单

  • 稳定的节点 ID、主机名、时区和 NTP 已确定。
  • 数据库与录像目录的责任人、备份和恢复目标已确定。
  • 所需端口的来源网段、目标网段和协议已列清。
  • HTTPS 证书与域名路径已确定；公网 RTC 已决定是否部署 TURN。
  • 使用的摄像机型号、固件、协议版本和测试通道已准备。
  • 回滚所需的旧包、配置、数据库和密钥备份位置已确定。

完成后进入 安装并管理服务。