SRS Origin Cluster 原厂集群部署与源码解析：基于 srs-proxy 负载均衡的多 Origin 媒体架构

SRS Origin Cluster 原厂集群部署与源码解析：基于 srs-proxy 负载均衡的多 Origin 媒体架构

【免费下载链接】srsSRS is a simple, high-performance, AI-driven real-time media server supporting RTMP, WebRTC, HLS, HTTP-FLV, HTTP-TS, SRT, MPEG-DASH, and GB28181, with codec support for H.264, H.265, AV1, VP9, AAC, Opus, and G.711.项目地址: https://gitcode.com/GitHub_Trending/sr/srs

SRS Origin Cluster 是 SRS 为承载大规模并发流而设计的多 Origin 服务器集群方案：由一组 Go 编写的 srs-proxy 代理服务器作为统一入口，将 RTMP、HTTP-FLV、HLS、WebRTC、SRT 等协议请求负载均衡到一组 SRS Origin 服务器上。本文以仓库文档 origin-cluster.md 为主线，完整覆盖从构建、三种协议集群部署、环境变量配置、鉴权、注册 API 到 K8s 部署架构的全部内容，并结合本仓库中的 srs-proxy 源码（入口、引导、环境配置、负载均衡、系统 API）深入讲解其底层实现原理。

概述：什么是 Origin Cluster

SRS Origin Cluster（原厂集群）是一组用于承载大量流的 Origin 服务器集合。与旧版集群不同，SRS 7.0+ 的新版 Origin Cluster 由**代理服务器（srs-proxy）与原厂服务器（SRS Origin）**组成：代理服务器扮演负载均衡器，把客户端的推流与拉流请求转发给后端的 Origin 服务器：

+--------------------+ +-------+ SRS Origin Server + + +--------------------+ + +-----------------------+ + +--------------------+ + SRS Proxy(Deployment) +------+-------+ SRS Origin Server + +-----------------------+ + +--------------------+ + + +--------------------+ +-------+ SRS Origin Server + +--------------------+

Origin Cluster 通过横向扩容 Origin 服务器提升系统承载能力。例如：使用 200 台后端 SRS Origin 服务器，可支撑 100 个 WebRTC 推流端（每个推流端 200 个观看者），合计 20,000 个连接。如果将该集群部署在拥有大量 CPU 核心的服务器上，它将成为一个非常强大的媒体服务器。

说明：代理服务器与 Origin 服务器的关系是代理转发而非边缘缓存。从源码注释可以看到，RTMP 代理"Unlike the edge server, it will not cache the stream, but just proxy the stream to backend"（rtmp.go），即代理服务器不缓存流，只做流的中转分发。

你还可以部署多台代理服务器、代理到其他媒体服务器（如 nginx-rtmp），或与边缘集群（Edge Cluster）配合使用，详见下文 部署架构设计 一节。

代理服务器几乎支持 SRS 的全部协议，包括 RTMP、HTTP-FLV、HLS、WebRTC 与 SRT，详见 协议支持。

构建 srs-proxy

构建代理服务器需要安装Go 1.18+。克隆仓库后执行：

git clone https://github.com/ossrs/srs.git cd srs && make

构建成功后得到可执行二进制bin/srs-proxy。也可以先执行go mod download下载依赖再构建。

从本仓库的 Makefile 可以看到构建规则：

build: fmt bin/srs-proxy bin/srs-proxy: cmd/proxy/*.go internal/**/*.go @mkdir -p bin go build -o bin/srs-proxy ./cmd/proxy

即make会把 cmd/proxy/main.go 编译为bin/srs-proxy。入口非常简单：创建 ProxyBootstrap 后调用Start启动整个代理进程。

未来该项目计划提供 Docker 镜像，并将代理服务器集成进 Oryx 项目。目前仓库根目录已包含 oryx 与 Dockerfile，可自行构建镜像。

与旧版 Origin Cluster（Legacy）的关系

从 SRS 7.0 起，新版 Origin Cluster 基于代理服务器，而不再使用旧版基于 MESH（服务器互连）的 SRS 服务器集群。如果需要使用旧版 Origin Cluster，请切换到 SRS 6.0 及之前的版本。

文档明确指出，SRS 6.0 之前的旧集群通过 MESH 让 Origin 服务器互相连接，这种架构并不理想；新版改用"代理 + 相互独立的 Origin"架构后系统更加健壮。

部署一：RTMP Origin Cluster

RTMP Origin Cluster 的部署分三步：启动代理服务器、部署多个 Origin 服务器、推流与拉流验证。

第一步：启动代理服务器

env PROXY_RTMP_SERVER=1935 PROXY_HTTP_SERVER=8080 \ PROXY_HTTP_API=1985 PROXY_WEBRTC_SERVER=8000 PROXY_SRT_SERVER=10080 \ PROXY_SYSTEM_API=12025 PROXY_LOAD_BALANCER_TYPE=memory ./bin/srs-proxy

说明：这里使用memory类型的内存负载均衡器，适用于单代理场景；如果希望运行多个代理服务器，可将PROXY_LOAD_BALANCER_TYPE切换为redis，让多个代理共享同一份 Origin 注册状态。

第二步：部署三个 Origin 服务器

Origin 服务器通过端口12025（代理的 System API 端口）向代理注册自己：

./objs/srs -c conf/origin1-for-proxy.conf ./objs/srs -c conf/origin2-for-proxy.conf ./objs/srs -c conf/origin3-for-proxy.conf

说明：Origin 服务器之间相互独立、无需同步状态，因此强烈建议在 Kubernetes（K8s）中将其部署为 Deployment。

这三个配置文件在仓库中的实际位置为 trunk/conf/origin1-for-proxy.conf、trunk/conf/origin2-for-proxy.conf、trunk/conf/origin3-for-proxy.conf。以 origin1 为例，其关键配置包括：

三个 Origin 的端口分配如下：

每个 Origin 配置了heartbeat心跳注册块，向代理注册自身信息：

heartbeat { enabled on; interval 9; url http://127.0.0.1:12025/api/v1/srs/register; device_id origin1; ports on; }

其中interval 9表示每 9 秒上报一次心跳，url指向代理的 System API 注册接口，ports on表示自动上报各协议监听端口。同时 vhost 内开启了http_remux（HTTP-FLV 转封装）、hls（hls_fragment 10 秒、hls_window 60 秒）、rtc（含rtmp_to_rtc与rtc_to_rtmp转码开关）与srt（srt_to_rtmp）等模块，保证多协议互通。

第三步：推流与拉流验证

向代理服务器推 RTMP 流（推流地址rtmp://localhost/live/livestream）：

ffmpeg -re -i doc/source.flv -c copy -f flv rtmp://localhost/live/livestream

说明：doc/source.flv是仓库自带的测试视频源，位于 trunk/doc/source.flv。

从代理服务器分别用多种协议拉流：

# RTMP 播放 ffplay rtmp://localhost/live/livestream # HTTP-FLV 播放 ffplay http://localhost:8080/live/livestream.flv # HLS 播放 ffplay http://localhost:8080/live/livestream.m3u8

WebRTC 播放可打开代理服务器的 WHEP 播放器页面：http://localhost:8080/players/whep.html。也可以使用 VLC 或其他播放器播放代理服务器上的流。

部署二：WebRTC Origin Cluster

WebRTC Origin Cluster 的代理与 Origin 部署步骤与 RTMP 集群完全一致：

env PROXY_RTMP_SERVER=1935 PROXY_HTTP_SERVER=8080 \ PROXY_HTTP_API=1985 PROXY_WEBRTC_SERVER=8000 PROXY_SRT_SERVER=10080 \ PROXY_SYSTEM_API=12025 PROXY_LOAD_BALANCER_TYPE=memory ./bin/srs-proxy

./objs/srs -c conf/origin1-for-proxy.conf ./objs/srs -c conf/origin2-for-proxy.conf ./objs/srs -c conf/origin3-for-proxy.conf

同样的提示：单代理用 memory 负载均衡，多代理请切换为redis；Origin 相互独立，建议以 Deployment 方式部署在 K8s 中。

WebRTC 场景下的推流与拉流均通过浏览器完成：

• 使用 WHIP 推流器页面（http://localhost:8080/players/whip.html）向代理服务器推 WebRTC 流；
• 使用 WHEP 播放器页面（http://localhost:8080/players/whep.html）从代理服务器播放 WebRTC 流。

跨协议拉流同样可用：

ffplay rtmp://localhost/live/livestream ffplay http://localhost:8080/live/livestream.flv ffplay http://localhost:8080/live/livestream.m3u8

也可以使用 VLC 或其他播放器。

实现提示：代理的 WebRTC 能力依赖 HTTP API 代理与 WebRTC UDP 代理配合。从 api.go 源码可以看到，代理的 HTTP API 服务器注册了/rtc/v1/whip/（推流）、/rtc/v1/whep/（拉流）路由，并兼容旧版/rtc/v1/publish/、/rtc/v1/play/路由（供 srs-bench 使用），将请求转发给 WebRTC 代理服务器处理后回源到 Origin。

部署三：SRT Origin Cluster

SRT Origin Cluster 的代理与 Origin 部署步骤同样相同：

env PROXY_RTMP_SERVER=1935 PROXY_HTTP_SERVER=8080 \ PROXY_HTTP_API=1985 PROXY_WEBRTC_SERVER=8000 PROXY_SRT_SERVER=10080 \ PROXY_SYSTEM_API=12025 PROXY_LOAD_BALANCER_TYPE=memory ./bin/srs-proxy

./objs/srs -c conf/origin1-for-proxy.conf ./objs/srs -c conf/origin2-for-proxy.conf ./objs/srs -c conf/origin3-for-proxy.conf

向代理服务器推 SRT 流（注意 SRT 的streamid语法，m=publish表示推流）：

ffmpeg -re -i ./doc/source.flv -c copy -pes_payload_size 0 -f mpegts \ 'srt://127.0.0.1:10080?streamid=#!::r=live/livestream,m=publish'

从代理服务器拉 SRT 流（m=request表示拉流）：

ffplay 'srt://127.0.0.1:10080?streamid=#!::r=live/livestream,m=request'

同样支持跨协议拉流：

ffplay rtmp://localhost/live/livestream ffplay http://localhost:8080/live/livestream.flv ffplay http://localhost:8080/live/livestream.m3u8

WebRTC 播放依旧使用http://localhost:8080/players/whep.html页面，也可用 VLC 等播放器。

说明：SRT 推流参数中的-pes_payload_size 0用于禁止 PES 载荷拼接，这是 SRT 封装的常见要求；代理服务器通过PROXY_SRT_SERVER（示例中为 10080）接收 SRT 流后回源到 Origin 的srt_server（如 10081/10082/10083）。

代理服务器配置：环境变量详解

srs-proxy 完全通过环境变量配置，同时也支持.env文件（见 env.go 中的loadEnvFile，若进程环境中已有同名变量则不会覆盖.env中的值）。分为四组：

回源后端端口（代理对外监听、转发给 Origin）

以上默认值与源码 env.go 中buildDefaultEnvironmentVariables的默认值完全一致。

代理自身配置

关于默认值的差异说明：文档（origin-cluster.md）将PROXY_LOAD_BALANCER_TYPE默认值标注为redis，但当前仓库源码 env.go 中实际默认值为memory（setEnvDefault("PROXY_LOAD_BALANCER_TYPE", "memory")）。以你实际使用的版本代码为准——单代理可直接用memory，多代理务必显式设置为redis。

Redis 负载均衡器参数

使用redis类型时需设置以下变量：

源码中还支持两个文档之外的扩展变量：PROXY_REDIS_KEY_PREFIX（Redis 键前缀，默认空）与PROXY_ORIGIN_SERVER_TTL（Origin 注册的健康存活期，默认300s），以及代理自身生命周期相关的PROXY_GRACE_QUIT_TIMEOUT（优雅退出超时，默认20s）与PROXY_FORCE_QUIT_TIMEOUT（强制退出超时，默认30s）。

默认后端（调试用）

调试时，代理可以转发到一个默认 Origin 服务器（不要求该后端注册到代理）：

设计意图：默认后端机制面向任意 RTMP 服务器（如 nginx-rtmp），它不需要向代理注册服务，代理会按固定地址回源，便于快速调试或对接第三方媒体服务器。

认证（Authentication）

Origin 注册请求可通过 Bearer Token 鉴权保护，分两侧配置。

代理侧：配置注册 API 鉴权

从源码 env.go 的validate()可以看到强约束：当PROXY_HTTP_API_AUTH_ENABLED=on时，PROXY_HTTP_API_AUTH_TYPE必须为非空且为bearer，同时PROXY_HTTP_API_AUTH_TOKEN必须非空，否则代理启动即报错。

Origin 侧：配置心跳请求鉴权

重要区别：SRS_HEARTBEAT_AUTH_TOKEN是 Origin 访问代理注册接口时携带的凭据，它独立于SRS_HTTP_API_AUTH_TOKEN——后者保护的是 Origin 自身的 HTTP API，两者不要混淆。

实现层面，代理的 System API 使用withHTTPAPIAuth中间件（api.go）校验Authorization: Bearer <token>，并通过crypto/subtle.ConstantTimeCompare进行常量时间比较，避免时序侧信道攻击。

部署架构设计（Design）

基本流模型

Client ----> Proxy Server ---> Origin Servers Client ---> LB --> Proxy Servers --> Origin Servers OBS/FFmpeg --RTMP--> K8s(Service) --Proxy--> SRS(pod A) Browsers --FLV/HLS/SRT--> K8s(Service) --Proxy--> SRS(pod A) Browsers --+---HTTP-API--> K8s(Service) --Proxy--> SRS(pod A) +---WebRTC----> K8s(Service) --Proxy--> SRS(pod A)

代理服务器可以部署在 Kubernetes（K8s）中，将流量路由到 SRS Origin 服务器，充当负载均衡器；不使用 K8s 同样可以部署。

与 K8s 结合的完整部署拓扑

+-----------------------+ +---+ SRS Proxy(Deployment) +------+---------------------+ +-----------------+ | +-----------+-----------+ + + | LB(K8s Service) +--+ +(Redis/MESH) + SRS Origin Servers + +-----------------+ | +-----------+-----------+ + (Deployment) + +---+ SRS Proxy(Deployment) +------+---------------------+ +-----------------------+

关键设计点：

• 多个代理需要同步状态：多代理之间需要通过 Redis 或 MESH 同步状态。MESH 指代理之间互相连接同步状态，在 K8s 中应部署为 StatefulSet；Redis 方案更优——代理可以部署为普通 Deployment，还可借助 Redis 集群实现高可用。
• 多个 Origin 无需同步状态：Origin 在 K8s 中部署为 Deployment，彼此完全独立，系统非常健壮。这与 SRS 6.0 之前用 MESH 互连的旧集群有本质区别（旧架构并不理想）。

单代理 + 多 Origin

如果只需支撑大量流而观看者较少，单代理架构同样有效：

+--------------------+ +-------+ SRS Origin Server + + +--------------------+ + +-----------------------+ + +--------------------+ + SRS Proxy(Deployment) +------+-------+ SRS Origin Server + +-----------------------+ + +--------------------+ + + +--------------------+ +-------+ SRS Origin Server + +--------------------+

说明：代理服务器性能很高且支持多进程；单代理架构适用于"流多、观看者少"的场景。需要更多代理时，直接部署更多代理并连接到同一个 Redis 即可，这套架构可水平扩展。

代理 + 边缘集群：超大规模系统

在该架构之上再叠加 SRS 边缘服务器（Edge），可支撑海量观看者：

+------------------+ +--------------------+ + SRS Edge Server +--+ +-------+ SRS Origin Server + +------------------+ + + +--------------------+ + + +------------------+ + +-----------------------+ + +--------------------+ + SRS Edge Server +--+-----+ SRS Proxy(Deployment) +------+-------+ SRS Origin Server + +------------------+ + +-----------------------+ + +--------------------+ + + +------------------+ + + +--------------------+ + SRS Edge Server +--+ +-------+ SRS Origin Server + +------------------+ +--------------------+

说明：边缘服务器负责承接大量观看者的播放请求，代理负责 Origin 之间的负载均衡。这套系统能构建支持海量流与观看者的超大型媒体系统，但维护复杂度高，仅在必要时使用。另外，代理服务器与 SRS 边缘服务器也可以协同工作，但这并非典型架构。

协议支持（Protocols）

由于 srs-proxy 是全新编写的服务器，并非所有协议都已支持。当前状态：

代理自身的关键特性支持状态：

需要说明：对于媒体集群而言，媒体服务器只是整个系统的一部分，控制与管理面板对维护这套复杂系统同样重要。已支持协议与未支持特性的当前状态，以仓库中 proxy 目录下的各协议实现文件（rtmp.go、http.go、rtc.go、srt.go）为准。

注册 API（Register）

Origin 服务器通过简单的 HTTP API 向代理注册自己，代理据此维护可用的后端服务器列表。注册接口如下：

curl -X POST http://127.0.0.1:12025/api/v1/srs/register \ -H "Connection: Close" \ -H "Content-Type: application/json" \ -H "User-Agent: curl" \ -d '{ "device_id": "origin2", "ip": "10.78.122.184", "server": "vid-46p14mm", "service": "z2s3w865", "pid": "42583", "rtmp": ["19352"], "http": ["8082"], "api": ["19853"], "srt": ["10082"], "rtc": ["udp://0.0.0.0:8001"] }' #{"code":0,"pid":"53783"}

请求体字段说明：

监听端点的格式为port、protocol://ip:port或protocol://:port，例如：

• 1935：TCP 协议，监听 1935 端口及任意 IP
• tcp://:1935：TCP 协议，监听 1935 端口及任意 IP
• tcp://0.0.0.0:1935：TCP 协议，监听 1935 端口及任意 IP
• tcp://192.168.3.10:1935：TCP 协议，监听 1935 端口及指定 IP

从源码看，该接口由 System API 服务器实现（api.go 中的/api/v1/srs/register路由）：它解析请求体后强制校验ip、server、service、pid、rtmp五个字段非空，然后构造OriginServer并调用负载均衡器的Update写入后端列表，最后返回{"code":0,"pid":"<代理进程PID>"}。若开启了鉴权，此路由会先经过withHTTPAPIAuth的 Bearer Token 校验。

使用方式说明：

• SRS 5.0+ 可作为后端，其heartbeat特性（即上文 Origin 配置中的heartbeat块）会自动向代理注册；
• 也可以编写 curl 脚本注册后端，或者开发一个独立的后端管理服务。例如不想改动 nginx-rtmp 代码时，可以用一个独立程序把 nginx-rtmp 注册到代理服务器。

源码视角：代理进程如何工作

以上操作背后，srs-proxy 的启动与请求流转可以从源码中完整还原：

1. 进程入口cmd/proxy/main.go 创建ProxyBootstrap并调用Start；
2. 引导初始化internal/bootstrap/proxy.go 按顺序完成：加载环境变量 → 安装信号处理与强制退出定时器 → 按PROXY_LOAD_BALANCER_TYPE选择 Redis 或内存负载均衡器 → 依次启动RTMP 代理、WebRTC 代理、HTTP API 代理、SRT 代理、System API、HTTP 流代理六个服务器，并阻塞等待退出信号；
3. 负载均衡决策internal/lb/mem.go 中Pick的核心策略是同一流 URL 始终路由到同一台 Origin（picked表缓存），首次选择时从 TTL 存活窗口（默认 300 秒内注册过）内的 Origin 中随机挑选；同时内存版负载均衡器为默认后端启动每 30 秒一次的 keepalive 续期协程；
4. 注册与鉴权System API（api.go）承载/api/v1/srs/register注册路由与/api/v1/versions版本/健康检查路由。

仓库中还提供了端到端验证脚本，如 proxy-e2e-cluster-test.sh、proxy-e2e-redis-test.sh 与 proxy-e2e-test.sh，以及负载均衡与各代理模块的单元测试（internal/lb、internal/proxy 下的*_test.go），可进一步验证本文所述行为。

总结

SRS Origin Cluster 以 srs-proxy 为统一入口，通过"Origin 注册 + 负载均衡 + 协议代理"的方式取代了旧版 MESH 集群，用更简单、更健壮的架构支撑大规模并发推流。无论是单代理 + 多 Origin 的小型集群，还是叠加 Redis 多代理与边缘服务器的超大规模系统，都可以基于本文的环境变量配置、三套协议部署流程与注册 API 快速落地。当前实现已覆盖 RTMP、HTTP-FLV、HTTP-TS、HLS、WebRTC（WHIP/WHEP）与 SRT 六类协议，MPEG-DASH 与 RTSP 支持、代理指标汇总与 Prometheus Exporter 仍在规划之中，值得持续关注仓库更新。

【免费下载链接】srsSRS is a simple, high-performance, AI-driven real-time media server supporting RTMP, WebRTC, HLS, HTTP-FLV, HTTP-TS, SRT, MPEG-DASH, and GB28181, with codec support for H.264, H.265, AV1, VP9, AAC, Opus, and G.711.项目地址: https://gitcode.com/GitHub_Trending/sr/srs