1. 项目整体设计与思路拆解

1.1 为什么是 SRS，为什么用 Docker

做音视频流媒体的朋友，对 SRS（Simple Realtime Server）应该不陌生。它是一个开源的实时流媒体服务器，支持 RTMP、HLS、WebRTC、HTTP-FLV、SRT 等主流的推拉流协议，单机并发能力非常可观，一台配置普通的云服务器就能扛住几千路直播流。相比 NexPlayer、Red5、Janus 那类重组件，SRS 属于轻量又抗造的类型，很多直播、监控、在线课堂、可视对讲的方案里都有它的身影。

SRS 的部署方式历来有两种主流路线：一种是直接下载编译好的二进制包，在裸机上跑；另一种就是本文要讲的 Docker 部署。用 Docker 跑 SRS 最大的价值，不是“省去编译时间”这么简单，而是让你从“维护一个服务进程”变成“维护一个容器”。进程会挂、会冲突、会把环境搞乱，容器不会。尤其是音视频这摊子事，依赖库特别多，ffmpeg、openssl、srt、ssl 的版本一不对就编译到怀疑人生。Docker 镜像把这些依赖全部锁死，换台机器拉个镜像，起来就是一样的服务，这个确定性对线上系统来说太重要了。

1.2 这套方案解决的核心问题

先说清楚我们要解决的问题。不管你是做直播平台、在线教育、安防监控，还是企业内部培训系统，音视频链路基本都长这样：推流端采集画面，编码成流，推到流媒体服务器，服务器负责协议转换和分发，播放端拉流观看。最痛的点往往集中在三个地方：推拉流协议的兼容性、延迟的控制、以及部署迁移的复杂度。

Docker 化部署 SRS 解决的正是第三点，同时从架构上为前两点提供了稳定底座。比如你的播放端是 Web 页面，需要走 WebRTC 低延迟路线；你的推流端是 OBS，习惯推 RTMP；你的移动端看 HLS 最稳妥。这些协议 SRS 一个实例全能处理，Docker 镜像里已经把相关模块都编译进去了，不需要你自己去产线折腾依赖。部署一次，后面扩容直接复制容器编排，是典型的“一次配置，随处运行”。

1.3 适用场景与读者画像

这篇内容适合几类人。第一类是刚接触流媒体的小白，对 RTMP、HLS、WebRTC 这些协议有点概念，但是被编译环境劝退过，想快速搭一个能用的流媒体服务来验证自己的播放器或者推流工具。第二类是做音视频应用开发的工程师，比如你在开发一个在线教育系统或者智慧门店的项目，需要有个流媒体服务对接业务，不想在这一步投入太多运维精力。第三类是运维同学，需要评估 SRS 在 Docker 容器里的运行表现、做端口规划、做资源限制，这篇里的实操细节可以直接作为初始参考。

2. 环境准备与 Docker 安装的前置要求

2.1 Windows 和 macOS 下的 Docker Desktop 注意事项

很多朋友玩着玩着就卡在了最前面：Docker 装不上、起不来。最常见的就是 Docker Desktop 提示 virtualization support not detected，或者启动失败。这个问题说白了就是你的宿主机没开启虚拟化，或者没有正确启用 Windows 的 WSL2 后端。

解决思路是：先确认 BIOS 里 Intel VT-x（或 AMD-V）已开启，然后在 Windows 功能里勾选“适用于 Linux 的 Windows 子系统”和“虚拟机平台”，打开管理员 PowerShell 执行 wsl --version 确认 WSL 版本在 1.2 以上。这些做完之后再把 Docker Desktop 的 Settings 里 Use WSL 2 based engine 勾上，90% 的启动失败都跟 WSL2 内核没对上有关。

macOS 这边主要注意 Intel 和 Apple Silicon 的镜像差异，早期版本需要关注 Rosetta 兼容，但现在的 Docker Desktop 已经不太需要用户操心了，装好就能用。真正要留意的反而是磁盘空间，Docker Desktop 默认的虚拟磁盘会越用越大，跑几个镜像几十 G 就没了，建议提前在 Settings 的 Resources 里限制一下磁盘镜像大小和内存上限。

2.2 Linux 服务器安装 Docker 与镜像加速配置

生产环境我强烈建议直接用 Linux 服务器。CentOS 7、Ubuntu 20.04 以上都行，安装 Docker 本身就是几条命令的事。Ubuntu 上推荐用官方脚本：

curl -fsSL https://get.docker.com | bash
systemctl enable --now docker
docker version

这个脚本会自动配置好 apt 源并安装 docker-ce、containerd、docker compose plugin。注意一点，国内直连 Docker Hub 经常抽风，拉镜像动不动就超时，一定要配置镜像加速器。打开 /etc/docker/daemon.json ，填入如下内容：

{
  "registry-mirrors": [
    "https://docker.m.daocloud.io",
    "https://hub-mirror.c.163.com"
  ]
}

配置完执行 systemctl restart docker 让配置生效。镜像加速的效果非常直观，原本可能要等几分钟的 SRS 镜像，几十秒就能拉下来。这不是什么花活，是给后续所有 Docker 操作打底的关键一步。

2.3 权限与防火墙的前置检查

Linux 下 Docker 的权限问题也值得提前说。默认情况下，只有 root 用户和 docker 组的用户能执行 docker 命令，普通用户直接敲 docker ps 会报 permission denied。解决办法是把当前用户加进 docker 组：

sudo usermod -aG docker $USER
newgrp docker

这个操作要注意安全边界，能进 docker 组的用户基本等同于有 root 权限，所以只在小团队信任环境里用。然后就是防火墙和 SELinux。cloud 服务器的安全组规则要放行 TCP 1935（RTMP）、TCP/UDP 8000（WebRTC）、TCP 8080（HTTP-FLV/HLS）、TCP 1985（HTTP API）。如果系统用的 firewalld，执行：

sudo firewall-cmd --permanent --add-port=1935/tcp
sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --permanent --add-port=1985/tcp
sudo firewall-cmd --permanent --add-port=8000/tcp
sudo firewall-cmd --permanent --add-port=8000/udp
sudo firewall-cmd --reload

这块如果漏了，后面推流拉流不通，排查起来会非常痛苦，所以一定要前置确认。

3. Docker 部署 SRS 的完整实操过程

3.1 拉取镜像和启动容器的准确操作

SRS 官方在 Docker Hub 上有镜像，而且维护得很勤快，直接拉下来就能跑。现在的情况是官方推荐的镜像名已经统一到了 ossrs/srs:5 ，也就是 SRS 5.0 系列的发行版。这个版本对 WebRTC、HLS、SRT 等多种协议的支持已经很成熟，直接选它不用犹豫。

先拉镜像，再快速跑一个默认配置的容器测试：

docker pull ossrs/srs:5
docker run --rm -p 1935:1935 -p 1985:1985 -p 8080:8080 -p 8000:8000/udp -p 8000:8000/tcp --name srs ossrs/srs:5

这个命令的端口映射逻辑要讲清楚。1935 是 RTMP 推拉流的默认端口，OBS 推流、VLC 拉 RTMP 都走它。1985 是 SRS 的 HTTP API 端口，后面你用 curl 查服务器状态、查在线流、触发回调都靠它。8080 是 HTTP 服务端口，HLS 切片播放、HTTP-FLV 拉流、WebRTC over HTTP 的请求都走这里。8000 是WebRTC 专用的 UDP 端口，很多新手在 WebRTC 播放黑屏时第一反应是去查转码，其实八成是这端口没放行。

--rm 参数意味着容器停止会自动删除，适合测试。 --name srs 给容器起个名字，方便后面进行 docker exec 和 docker logs 操作。

3.2 验证服务是否正常运行

容器起来之后，先看日志确认 SRS 启动过程没有异常：

docker logs -f srs

正常日志结尾会出现类似 SRS is ready 或者监听地址列表的输出。然后用 API 接口验证状态：

curl http://localhost:1985/api/v1/versions

返回 JSON 里能看到 SRS 的版本号和编译选项。再访问一下 HTTP 播放地址测试静态文件：

curl -I http://localhost:8080/

能返回 200 和 HTTP 头，基本说明 HTTP 模块在正常工作。

这里有个实操心得：不要在还没确认 API 和 HTTP 端口正常之前就急着去推流。音视频链路是串行依赖的，推流端、服务端、播放端任何一环断了，你都会看到播放端黑屏或者转圈，但问题根源往往不在你正在排查的那一端。先把服务端状态确认好，把端口全部验证一遍，后续定位问题就直接锁定推流端和播放端，省一半时间。

3.3 docker-compose 方式部署更符合生产习惯

虽然一条 docker run 就能把 SRS 跑起来，但生产环境我更建议用 docker-compose 把配置固化下来。好处有两个：第一，端口、挂载、环境变量这些配置随项目仓库走，换机器不用手敲命令；第二，后续想要加 MySQL、Redis、Nginx 之类的基础服务，一个 compose 文件统一编排，省事太多了。

下面是我常用的 SRS compose 配置骨架：

version: "3.8"

services:
  srs:
    image: ossrs/srs:5
    container_name: srs
    restart: always
    ports:
      - "1935:1935"
      - "1985:1985"
      - "8080:8080"
      - "8000:8000/tcp"
      - "8000:8000/udp"
    volumes:
      - ./srs.conf:/usr/local/srs/conf/srs.conf
      - ./objs:/usr/local/srs/objs
    environment:
      - TZ=Asia/Shanghai
    command: ["./objs/srs", "-c", "conf/srs.conf"]

注意这里的卷挂载逻辑。 ./srs.conf 映射的是 SRS 的配置文件，这样你修改配置后只需要 docker restart srs 就能生效，不用重新构建镜像。 ./objs 映射的是 SRS 的工作目录，里面会存 HLS 切片、DVR 录像等文件，必须挂载到宿主机，否则容器销毁后数据全没了。TZ 环境变量设置时区，避免日志时间差八小时，排查问题时这些细节会让你少做很多无用功。

4. 推流、拉流与联调实战

4.1 用 OBS 推 RTMP 流

环境准备好了，接下来做一次完整的推拉流联调。我习惯先拿 OBS 当推流端做基准测试，因为它跨平台、配置直观，出了问题最容易定位是不是服务端的问题。OBS 安装后，在“设置 - 推流”里填入：

• 服务：自定义
• 服务器： rtmp://172.17.0.1/live
• 推流码： test

这里的 IP 要换成你 SRS 所在机器的实际 IP。比如你在 windows 上用 Docker Desktop 跑 SRS，局域网内 IP 是 192.168.1.100，那就填 rtmp://192.168.1.100/live 。码是自定义的，主要用来区分不同应用或不同直播间，SRS 默认 vhost 就是 live ，stream 名称随便叫，这里用 test 。

点击“开始推流”，然后立刻在浏览器打开 http://你的IP:8080/players/srs_player.html ，这个页面是 SRS 自带的播放器调试页，输入 rtmp://你的IP/live/test 就能播放。如果首屏能出来画面，说明链路已经通了。这里有个经验：第一次推流成功后，不要急着切 WebRTC，先把 RTMP 全链路验证完，再逐步加需求，这样每次只引入一个变量，出问题不会慌。

4.2 用 ffplay / VLC 拉流验证不同协议

服务端跑起来之后，拉流侧的验证可以用 ffplay 快速测，也可以用 VLC 看可视化画面。我个人更推荐 ffplay，因为它的错误日志非常直接，能告诉你协议握手卡在哪一步。

ffplay -fflags nobuffer -analyzeduration 1000000 rtmp://192.168.1.100/live/test
ffplay http://192.168.1.100:8080/live/test.flv
ffplay http://192.168.1.100:8080/live/test.m3u8

这三条命令分别验证 RTMP、HTTP-FLV、HLS 三种播放协议。注意第三条 HLS 地址，SRS 默认配置下开启 HTTP 服务后会自动对 live 这个 vhost 下的流做 HLS 切片，所以 m3u8 地址是能直接访问的。实际测试中要注意，HLS 有切片延迟，通常有 5-10 秒的播放滞后，这是协议机制，不用纠结，低延迟需求走 WebRTC 或 HTTP-FLV 即可。

VLC 拉流的操作就更简单了，打开网络串流，粘贴对应地址就能播。VLC 的好处是能看到实时的编码信息，比如分辨率、码率、帧率，适合在联调时判断是不是编码端的问题。比如你推了 4K 流，播放器卡成幻灯片，VLC 的“媒体信息”里能看到视频编码是 HEVC 还是 H.264，就能快速判断是不是播放器不支持解码。

4.3 WebRTC 低延迟播放的配置要点

RTMP 通之后，下一步就是 WebRTC 的低延迟播放。SRS 5.x 对 WebRTC 的支持已经比较完善了，但部署时要特别注意 UDP 端口和公网 IP 的配置。WebRTC 推流时，SRS 需要监听 UDP 8000 端口作为媒体传输通道，同时信令协商走的是 8080 端口的 HTTP 接口。

在浏览器打开 SRS 自带的 WebRTC 播放页 http://你的IP:8080/players/rtc_player.html ，输入 webrtc://你的IP/live/test ，就能拉流。如果画面出不来，优先排查浏览器是否支持 WebRTC，然后看服务器日志里有没有 UDP 端口协商失败的报错。这里有个很重要的实战细节： SRS 官方文档建议在 WEBRTC 服务配置里设置 server_udp_port 和 client_udp_port ，并确保防火墙放行了这段 UDP 端口范围 。如果只是在 Docker 端口映射里暴露了 8000，但云安全组没有放行 UDP 8000，WebRTC 会一直处于连接中状态。

WebRTC 的延迟正常跑在 300-800ms 之间，比 RTMP 的 2-5 秒体验好很多。但要看清楚它的适用边界，WebRTC 对弱网环境更敏感，在网络差的地方，与其卡顿黑屏，不如切回 HTTP-FLV 或 HLS，图个稳定播放。这也是为什么正规直播平台很少只依赖一种协议的原因，服务端多协议兼容，客户端按策略选择。

4.4 外网访问与端口映射的规划

本地联调通了，发布到公网服务器上时，只要把配置里的 IP 换成公网 IP，再把对应的端口加入安全组规则，基本就能跑通。但有几个细节容易被忽略：一是 RTMP 是非加密协议，生产环境建议用 SRT 或 RTSPS 加 TLS 的方式加密推流；二是 WebRTC 依赖 UDP 端口较多，安全组千万别只开 TCP；三是如果有反向代理层，比如 Nginx 代理 8080 端口的 HTTP 接口，要注意 WebSocket 的 Upgrade 头要透传，否则信令交互会挂在 WebSocket 握手阶段。

外网拉流的带宽消耗也要提前心里有数。一路 2Mbps 码率的直播流，如果有 100 个观众同时看，消耗的带宽就是 200Mbps，很多云服务器的带宽上限根本扛不住。这种情况下 SRS 的 Edge 集群模式、CDN 分发或者转码降码率才是正解。但这就属于进阶玩法了，先把单机单流跑通再说。

5. 进阶配置与典型场景落地

5.1 通过配置文件控制转封装、鉴权与回调

SRS 跑起来太容易了，真正让大家头疼的是把它调整成贴合业务的样子。最核心的管理入口就是 srs.conf 配置文件。我给你梳理几个高频场景的配置片段。

HTTP-FLV 与 HLS 同时开启 ：

listen              1935;
max_connections     1000;
daemon              off;
srs_log_tank        console;

http_api {
    enabled         on;
    listen          1985;
}

http_server {
    enabled         on;
    listen          8080;
    dir             ./objs/nginx/html;
}

vhost __defaultVhost__ {
    rtmp {
        enabled     on;
    }
    http_remux {
        enabled     on;
        mount       [vhost]/[app]/[stream].flv;
    }
    hls {
        enabled     on;
        hls_path    ./objs/nginx/html;
        hls_fragment 2;
        hls_window   10;
    }
}

这段配置里的 http_remux 是 SRS 的 HTTP-FLV 实时转封装模块，简单来说就是把 RTMP 流转封装成 FLV 格式，通过 HTTP 分发给浏览器播放器。 hls_fragment 2 表示每个 HLS 切片时长 2 秒， hls_window 10 表示播放窗口 10 秒，这两个参数配合起来可以控制 HLS 延迟和兼容性。

推流鉴权和 http callback ：

vhost __defaultVhost__ {
    rtmp {
        enabled         on;
        server_ip       0.0.0.0;
    }
    http_hooks {
        enabled         on;
        on_publish      http://your-api-server-domain/api/srs/callback/on_publish;
        on_play         http://your-api-server-domain/api/srs/callback/on_play;
        on_unpublish    http://your-api-server-domain/api/srs/callback/on_unpublish;
    }
}

这里 on_publish 就是推流鉴权的钩子，当有人推流时 SRS 会向这个地址发一个 POST 请求，里面带着流名、应用名、请求 IP、token 参数等，你的后端服务收到回调后做校验，返回 0 表示允许，返回非 0 表示拒绝。如此就能做到“只有携带合法 token 的客户端才能推流”，非常实用。

静态推流 ：

有些业务场景不需要有人实时推流，而是希望服务端直接拉取一路源流（比如摄像头 RTSP），再转成各种协议分发给用户。SRS 5.x 的 ffmpeg 模块可以做到：

vhost __defaultVhost__ {
    ffmpeg {
        enabled     on;
        bin         ./objs/ffmpeg/bin/ffmpeg;
        task_http   off;
        tasks {
            keepalive {
                enabled     on;
                input       rtsp://your-camera-ip:554/stream1;
                output      rtmp://127.0.0.1:[port]/live/camera1;
            }
        }
    }
}

SRS 会借由内置或者外部 ffmpeg 拉取这个 RTSP 摄像头流，再推给 SRS 自身的 RTMP 端口，这样就整体纳入了统一分发体系。需要留意的是，SRS 官方镜像里默认不带 ffmpeg，如果要跑这种拉流转发任务，需要额外把 ffmpeg 打包进容器，或者用别的方案实现。

5.2 数据持久化与日志管理

容器化的一个常见问题是数据容易丢。SRS 运行过程中产生的 HLS 切片、DVR 录像文件、日志文件都在容器内部，容器一删就没了。所以《docker run》启动时一定要挂载数据目录。

我这里再强调一遍之前提到的卷挂载方案，并补充日志管理的细节。SRS 的日志默认打到 stdout，可以通过 docker logs 查看，但生产环境我建议把日志接到集中式日志平台或者至少落到宿主机的文件里。搞一个 logrotate 容器，或者干脆在宿主机上用 docker logs srs >> /var/log/srs.log 2>&1 配合 logrotate 轮转，避免磁盘被日志占满。

对 HLS 切片这类持续写入的临时文件，要考虑定期清理。切片文件按 hls_window 参数配置保留最近 N 秒的切片，老切片会被自动删除。但如果你开了 DVR 录制，那录像文件是永久的，要单独规划磁盘空间和备份策略。我见过有人容器跑了三个月，磁盘被录像文件塞爆，整个服务挂掉还找不到原因，就是因为欠了这块考虑。

5.3 资源限制与性能调优

SRS 是纯 C++ 写的，性能非常强悍，但 Docker 容器默认不限制资源，有时会和其他容器抢 CPU 和内存。建议在 docker-compose 里加资源限制：

deploy:
  resources:
    limits:
      cpus: "2.0"
      memory: 2G

SRS 并发能力跟 CPU 核心数、内存大小、网络带宽强相关。单核 CPU、1G 内存的小机器跑 SRS 也能用，但并发个位数级别；4 核 8G 的机器跑 50-100 路并发 RTMP/HTTP-FLV 基本没问题。性能调优的大头在校验和调参，这点就要结合你的具体业务来做了，比如网络超时参数、缓存队列长度、slice 大小，这些属于典型的应用性能分析内容，建议在压测环境多调。

5.4 浏览器播放器接入前端

流媒体服务器就绪后，剩下的就是接入播放器。这块可能不是你最了解的领域，但至少要知道大方向。如果要在浏览器里播放 RTMP 流，必须装 Flash 或者用 obs-studio 类的插件，体验很差。现在的普遍做法是：

• 用 http://ip:8080/live/test.flv 这种 HTTP-FLV 地址，配合 flv.js 播放器，延迟在 1-3 秒，兼容性也不错；
• 追求更低延迟就使用 WebRTC，srs 的播放器 srs_player 内集成了这种能力；
• 移动端和短视频场景，可以直接用 HLS + hls.js 或 native video。

前端播放器的选型我会单写一篇文章，这里给个小结：默认用 HTTP-FLV + flv.js，延迟和兼容性能平衡；对延迟敏感的场景切 WebRTC；H5 移动端优先 HLS。前提是 SRS 服务端把三种协议都开了，这一点配置里已经覆盖了。

6. 常见问题与排查技巧实录

6.1 典型问题速查表

整理一份我踩过坑之后总结的速查表，按症状列出来，方便快速定位问题。

症状	可能原因	解决思路
无法连接服务器，RTMP 握手超时	端口未放行 / 防火墙拦截	检查安全组和本机防火墙是否放行 TCP 1935
API 接口 1985 通了，但播放不了	8080 端口屏蔽	放行 TCP 8080，检查 HLS 路径是否正确
WebRTC 播放黑屏/一直连接中	UDP 8000 未放行 / STUN 协商异常	放行 UDP 8000，确认 client_udp_port 配置可路由
推流成功但 HLS 播放不了	挂载目录权限不足	检查 ./objs 宿主机目录写权限
Docker 启动就退出	配置文件语法错误	查看 docker logs 加载错误行号
同一网段能播放，公网不能播放	云安全组缺端口	检查云控制台安全组规则，和本机防火墙一起确认
过一会流就断了，重推就好	网络漂移 / 推流端码率不稳	检查推流端网络，加 docker run --restart=always 保证容器存活
容器重启后流媒体服务没起来	没有配 restart 策略	compose 文件加上 restart: always
CPU 占满，卡顿	转码占用资源太大	拉起 SRS CPU 限制，考虑关掉转码或升级机器配置
拉流端显示不能 decode	浏览器不支持 HEVC/H.264 编码	推流端编码格式改为 H.264 + AAC，这是兼容性最好的组合

6.2 日志排查的实用方法

SRS 的日志信息量非常大，但初次接触会觉得嘈杂。我习惯的做法是，出问题时第一件事看容器日志最近 50 行，重点盯着会话建立、协议握手、媒体协商相关的关键字：

docker logs srs --tail 100 --follow

比如日志里出现 rtmp: play stream test , 说明有人来拉流了；出现 ignore stale(play->play) 这种就是播放端断开重连频繁。还有一种常见情况是 API 回调报错，日志会打出 HTTP 请求失败的状态码，比如 on_play 回调地址 503，则大概率是业务服务没起来，或者网络不通。

需要额外提醒的是：SRS 的日志格式是 [时间][日志级别][模块] 消息 ，调试阶段把 srs_log_tank 设置成 console（默认就是 console），可以实时看到所有连接的建立和关闭。线上阶段可以切换成 file 模式，并按天轮转，避免日志文件把磁盘撑爆。这个日志级的调优和运维方法，在真实生产环境里几乎天天都会用到。

6.3 我踩过的几个关键坑

第一个坑是 Docker 的端口映射只开了 1935，忘了开 8000 UDP。当时在本地一切正常，部署到云服务器后 WebRTC 怎么都是黑的，排查了整整半天，最后发现安全组规则缺了 UDP 8000。这个坑特别提醒，云厂商的安全组默认是白名单机制，不在列表里的端口一概不通。TCP 规则大多数人都会配，UDP 的经常被漏掉。

第二个坑是 Docker 挂载了编译好的本地 HLS 静态目录，但宿主机目录权限不对，容器里的 SRS 进程是 nobody 用户，写不了切片文件。表现出来就是 HLS 播放地址 404 或者 403，日志里能看到 open /usr/local/srs/objs/nginx/html/xxx.m3u8 failed: Permission denied 。解决方式是宿主机目录 chmod 777 或者把容器内的 UID 映射到宿主机用户，细节不多说了，但这件事务必提前处理。

第三个坑是关于镜像版本的选择。有一阵子直接把 ossrs/srs:latest 当成生产镜像用，结果某天升级后 SRS 配置文件格式不兼容，整个服务启动失败。后来吸取教训：生产环境固定到具体的 minor 版本，比如 ossrs/srs:5.0.123 ，升级前先跑一个测试容器验证配置和功能。版本管理这件事，在容器化时代成本和风险都低，值得养成习惯。

6.4 从单机走向分布式的前瞻建议

当你把 SRS 用 Docker 跑顺之后，肯定会有更进一步的需求，比如双节点容灾、边缘节点分发、多区域就近接入。SRS 官方本身就是这套架构思路的重要参考，它的 Origin/Edge 集群模式就是为这类场景设计的。Docker 环境下用 Docker Compose 把所有节点编排在同一套网络里，或者直接上 Kubernetes 做服务编排，都能平滑过渡。

如果这一步走下去了，建议你把关注点从“端口映射怎么配”转移到“服务发现怎么做、持久化存储选哪类方案、日志和监控怎么统一采集”。这些都是流媒体平台规模化的老生常谈，但每一样都需要提前设计，否则流量一起来，技术债会压得你喘不过气。我个人建议小步快跑：先把单机 Docker 版本的 SRS 用熟练，把推拉流协议、鉴权、回调、HLS 切片这些基础流程吃透，再去照着集群方案同步扩张。这也是我过去几年做音视频业务时一直遵循的路径。

就这个方向来说，SRS 的社区相当活跃，官方文档更新快，问题响应也及时。真正把 Docker 和 SRS 这一套组合吃透后，你会发现流媒体服务从一个“装机配置的苦活”变成了一块“可以灵活编排的标准积木”，后续的扩展和排障都变得清爽很多。希望这篇内容能帮你少走一些我当年走过的弯路，早日跑通自己第一款实时音视频应用。