做国产系统上的流媒体服务，绕不开“装软件”这道坎。银河麒麟V10 SP1本身是个好系统，跑常规业务一点问题没有，但一用到开源的流媒体中间件就露怯了：官方源里没有SRS，社区里能翻到的rpm包基本都是给CentOS或者Ubuntu打的，拿到麒麟上不是缺依赖就是glibc版本对不上。SRS（Simple Realtime Server）做直播、监控转码、视频会议这种低延迟场景非常好用，国内开源社区活跃度也高，可作为麒麟生态的一块拼图始终没人补上。这篇博文从我实际交付的一个项目出发，完整记录如何在银河麒麟V10 SP1上从源码编译SRS，再用rpmbuild打成原生安装包，一步步讲清楚spec怎么写、构建环境怎么搭、装完怎么配、踩过的坑怎么绕。适合正在做国产化替代技术预研的运维，以及需要在麒麟环境里部署流媒体服务的开发同学参考。
1. 为什么要在银河麒麟上折腾SRS：场景与痛点拆解
1.1 银河麒麟的生态现状与“安装软件难”的真实原因
银河麒麟V10 SP1这套系统，底层和CentOS 7系列同源，rpm包管理器、systemd、firewalld这些基础设施都是通的。但“同源”不等于“通用”，实际用下来有几个很折磨人的差异点。
第一，软件源的维护节奏跟不上社区。银河麒麟官方的软件仓库主要聚焦在办公、安全、运维这些政企场景，像SRS、ffmpeg、nginx-rtmp这类偏流媒体的包，基本不会出现在源里。你在CentOS上习惯的yum install一条龙思路，在麒麟上常常会得到No package SRS available的提示。
第二，第三方rpm包存在“隐性不兼容”。网上不是没有自称支持Kylin的包，但它们多半是基于CentOS 7或者通用x86_64架构打的。装上之后常见的问题包括：依赖解析时提示某个libxxx.so版本不对，或者二进制能起来但运行几分钟就异常退出。根源在于银河麒麟在合入CentOS代码时替换了不少基础库的版本，尤其是openssl、glibc和zlib这几个高频依赖库。直接用别人的包，相当于穿别人的鞋走自己的路，合不合脚只有跑了才知道。
第三，图形化软件商店的问题比命令行更隐蔽。麒麟桌面版自带一个软件商店，操作体验确实友好，可搜索仓库不全、组件缺失时直接报错误代码#0002的情况经常遇到。而且商店里的软件版本通常滞后，对SRS这种迭代快的项目，你想要的特性可能根本没有。
所以结论很简单：在银河麒麟上，稳妥的方案永远是先确认你这套系统的确切小版本号，再决定是找源码自己编译还是打rpm包。这也是我写这篇内容的原因——既然官方不给包，那就自己动手，还能把整个构建过程固化成一个可复用的产物。
1.2 SRS是什么，为什么它值得你在国产系统上跑起来
SRS全称Simple Realtime Server，是国人开源的高性能流媒体服务器，单C++进程就能承载RTMP、HTTP-FLV、HLS、WebRTC、SRT在内的主流流媒体协议。相比Nginx配RTMP模块那种“拼装车”方案，SRS是专门为流媒体设计的发动机，延迟控制、协议转换、集群扩展这些能力都是内置的。
SRS在国产化场景里的价值非常具体。比如企业内部做培训直播，用SRS加ffmpeg就能搭一套完整的推流和分发链路，不用买昂贵的商业直播云服务。再比如安防监控项目，海康大华的摄像头普遍支持RTMP推流，SRS配合HTTP-FLV协议可以在Web端直接低延迟播放，这是很多政务类项目的基础需求。SRS还有WebRTC能力，能做基于浏览器的视频会议，对于不允许数据出内网的环境非常合适。
技术层面，SRS的部署形态很轻。编译完只是一个可执行文件加一个配置文件，没有数据库、没有中间件依赖，跑起来内存占用也就几十MB。这种特性注定了它在国产系统上有很强的适配潜力，只要你能解决“获取”这一步，运行基本没有大坑。
1.3 用RPM打包还是直接编译：方案选型分析
很多人在看到“源码编译”四个字时会下意识选择./configure && make，跑起来就能用了。但对一个正在做交付的项目来说，直接编译有几个软肋：只在一台机器上有效，换台机器就要重新编译一次；没有版本记录和校验，出了问题说不清用的哪版代码；卸载更是麻烦，二进制和配置文件散在各处删不干净。
相对正确的做法是把SRS包装成rpm。rpm包带来的好处很明确：第一，安装和卸载都是原子操作，不会在系统里留下莫名其妙的残留文件；第二，rpm -qa能查到版本号，rpm -V能校验文件完整性，这对通过等保测评和项目验收非常关键；第三，构建一次，批量交付，完全是生产力的提升。如果你的项目要交付给多个现场，这个优势会被放大到极致。
打个比方，直接编译是自己在家做顿饭，rpm打包是开个预制菜工厂。前期多花点时间搭建生产线，后面每个现场都是“解冻加热”的事。这篇博文后面写的所有内容，都是围绕“开工厂”这个思路来的。
2. 打包前的准备：环境、工具与源码获取
2.1 确认系统版本与架构
动手之前，先把目标机器的系统信息摸清楚。这一步最容易被忽略，但恰恰是决定后续能否顺利的关键。
进入终端，执行以下命令：
cat /etc/os-release uname -m我手头这台机器的输出大致是：
NAME="Kylin" VERSION="V10 (SP1)" KERNEL_VERSION="4.19." ARCH="x86_64"确认架构的目的很纯粹：SRS的rpm包和架构强相关，x86_64的包不能装到aarch64（鲲鹏、飞腾）机器上，提前确认可以避免在导出包时打错平台。
如果目标环境是aarch64架构也不用慌，下文所有步骤除了编译参数可能短暂切换外，流程完全一致。只要保证在aarch64的机器上完成构建，打出来的rpm包自然就是aarch64版本。
另外建议顺手确认一下系统里自带的openssl和glibc版本，这会直接影响SRS编译时是否要额外处理依赖：
openssl version ldd --version | head -1银河麒麟V10 SP1自带的openssl通常是1.1.1系列，glibc在2.28以上。这两个条件对于SRS 5.0来说是充足且兼容的，不用担心“源码能编译但依赖跑不起来”的尴尬。
2.2 安装构建工具链
SRS是用C++写的，构建工具链必须齐全。在银河麒麟上通过rpm仓库安装，一条命令搞定：
sudo yum install -y gcc gcc-c++ make autoconf automake libtool pkg-config这里有个容易踩的坑：gcc和gcc-c++是两个不同的包，只装gcc不装gcc-c++，SRS的C++代码会直接报g++: command not found，然后configure脚本卡在编译检测环节。
如果你的现场机器不能联网，需要在有网的机器上下载全部依赖rpm包，再离线安装。建议在构建机上一次性安装好，并使用一个通用的构建目录，后续可以反复使用。
2.3 获取SRS源码与版本选择
SRS的官方代码托管在GitHub上，国内访问不稳定是常态，建议直接用Gitee镜像或官方提供的release压缩包。
选择版本时要看好发布时间线和功能特性。SRS 4.0是长期稳定的分支，适合生产环境；SRS 5.0在WebRTC和SRT方面有更新，对低延迟场景更友好。这次打包以SRS 5.0.0为例，流程在4.x上完全通用。
下载并处理源码包：
wget https://github.com/ossrs/srs/archive/refs/tags/v5.0.0.tar.gz -O srs-5.0.0.tar.gz tar zxf srs-5.0.0.tar.gz cd srs-5.0.0从这一步开始，后面所有操作都在/home/build这个目录下进行，把源码、spec文件、构建产物都组织好，避免文件散落各处。
提示：rpmbuild默认会从
~/rpmbuild/SOURCES目录读取源码包，因此建议提前把整个rpmbuild目录结构创建好。另外建议把源码包重命名为SRS-5.0.0.tar.gz这样的标准格式，减少spec文件中的变量转换麻烦。
3. 手把手打包RPM：从spec编写到产出安装包
3.1 RPM打包的基础知识与目录约定
理解rpm打包，先要理解它背后那套“厨房流水线”的设计。rpmbuild工具工作时会使用一个标准目录树：
~/rpmbuild/SOURCES/：存放源码压缩包和补丁文件~/rpmbuild/SPECS/：存放spec文件，它是打包的“菜谱”~/rpmbuild/BUILD/：解压源码并执行编译的临时工作目录~/rpmbuild/BUILDROOT/：安装过程的临时根目录，模拟软件安装到系统里的文件布局~/rpmbuild/RPMS/：最终产出的二进制的rpm包~/rpmbuild/SRPMS/：产出的源码rpm包
初始化目录树很简单：
mkdir -p ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS} cp srs-5.0.0.tar.gz ~/rpmbuild/SOURCES/ cd ~/rpmbuild/SPECSspec文件是这个流程的核心。它定义了软件叫什么、版本是多少、依赖哪些库、编译做什么、安装怎么进行。对新手来说spec看着像一种配置语言，其实它内部就是一段段shell脚本加上变量替换，理解了这一点就不难写了。
3.2 编写SRS的spec文件
这一步是整个打包流程的重头戏。我直接给出一个实际验证可用的spec模板，然后逐段解释关键点。
新建srs.spec文件：
Name: srs Version: 5.0.0 Release: 1%{?dist} Summary: Simple Realtime Server for Kylin License: MIT URL: https://github.com/ossrs/srs Source0: %{name}-%{version}.tar.gz BuildRequires: gcc, gcc-c++, make, autoconf, automake, libtool Requires: glibc, openssl, zlib %description SRS is a high-performance live streaming server supporting RTMP, HTTP-FLV, HLS, SRT, and WebRTC protocols. This package builds, installs, and configures SRS on Kylin V10 SP1 systems. %prep %setup -q %build ./configure --prefix=/usr/local/srs make -j$(nproc) %install rm -rf %{buildroot} install -d %{buildroot}/usr/local/srs/bin install -d %{buildroot}/usr/local/srs/conf install -m 755 objs/srs %{buildroot}/usr/local/srs/bin/srs cp -a conf/* %{buildroot}/usr/local/srs/conf/ install -d %{buildroot}/usr/lib/systemd/system cat > %{buildroot}/usr/lib/systemd/system/srs.service <<'EOF' [Unit] Description=SRS Streaming Server After=network.target [Service] Type=simple ExecStart=/usr/local/srs/bin/srs -c /usr/local/srs/conf/srs.conf Restart=on-failure LimitNOFILE=65536 [Install] WantedBy=multi-user.target EOF %files /usr/local/srs/bin/srs /usr/local/srs/conf/ /usr/lib/systemd/system/srs.service %preun if [ $1 -eq 0 ]; then /usr/bin/systemctl stop srs.service 2>/dev/null || true /usr/bin/systemctl disable srs.service 2>/dev/null || true fi %postun if [ $1 -ge 1 ]; then /usr/bin/systemctl daemon-reload fi逐个拆解：
BuildRequires声明构建时需要的工具链包，Requires声明运行时依赖。这里把openssl和zlib列为运行时依赖，是因为SRS二进制动态链接了这两个库，%{buildroot}是rpmbuild提供的临时安装目录，所有要打包的文件都必须先放到这个目录下，后续rpmbuild会自动把它映射为系统真实路径。
%preun和%postun两个脚本段非常关键。它们解决了升级和卸载时的服务管理问题：卸载时停止并禁用服务，升级后重新加载systemd配置。不加这两段，卸载rpm包以后SRS进程可能还在跑，升级以后新的服务文件也不会自动生效。
有一个细节值得注意：spec文件里的%setup -q会自动解压Source0指定的SRS-5.0.0.tar.gz，且默认要求解压后的目录名和%{name}-%{version}匹配，也就是srs-5.0.0。如果源码包的目录名不是这个格式，需要在%setup后加上-n 实际目录名参数。
3.3 执行rpmbuild并解决构建依赖
spec写好后，进入构建环节：
cd ~/rpmbuild/SPECS rpmbuild -ba srs.spec-ba参数表示同时构建二进制rpm包和源码rpm包。如果只想构建二进制包，可以换-bb，不过在确认spec可用的阶段，建议直接用-ba，因为SRPM本身就是一种很好的交付备份。
第一次运行大概率不会顺风顺水，常见情况有这么几种。
如果提示gcc: error或某个头文件找不到，通常是BuildRequires没列全。SRS的configure脚本会检测系统里常见的开发库，缺了会直接禁用对应功能，表面上看还能编译，但产出的二进制会有功能缺陷。稳妥做法是先把上文2.2节列的工具链全部装上，然后重新构建。
如果make阶段卡住不动且CPU占用只有100%，不是死机，只是编译慢。SRS的C++代码量很庞大，纯单线程编译一台4核虚拟机大约要10到20分钟。make -j$(nproc)这个参数已经用上了所有核心，耐心等即可。
构建成功后，去~/rpmbuild/RPMS/x86_64/目录下找产物：
ls -lh ~/rpmbuild/RPMS/x86_64/应该能看到SRS-5.0.0-1.el7.x86_64.rpm这样的文件，体积一般在几MB到十几MB之间。
提示：如果你用的是银河麒麟V10 SP1，
%{?dist}这个宏在spec里会被替换为.ky10之类的标识符，这是正常现象。如果你的spec没有对dist宏做专门的版本要求，不要试图去删掉它。
3.4 验证生成的RPM包
构建完成后，没装之前先做一次“干货检查”，用rpm内置工具验证包内容：
rpm -qpl ~/rpmbuild/RPMS/x86_64/SRS-5.0.0-1.*.x86_64.rpm这条命令会列出包内所有文件，核对一下是否包含/usr/local/srs/bin/srs、/usr/local/srs/conf/和/usr/lib/systemd/system/srs.service这三个关键部分。
再验一下包的完整性和签名信息：
rpm -K ~/rpmbuild/RPMS/x86_64/SRS-5.0.0-1.*.x86_64.rpm没配置GPG签名时它会输出NOTRUST字样，这不影响安装使用。如果后续要作为正式交付物发给现场，建议配置一把签名密钥，再给rpm包加上签名。
也可以干脆用rpm2cpio解包看看里面的文件是不是与预期一致。这一步在验证自建包时尤其有用，因为fpm等工具打出来的包时常存在目录权限问题，rpmbuild原生产出的包很少出现这种毛病。
极限验证是在一台干净的全新银河麒麟虚拟机里执行安装测试。这一步建议无论如何都做一遍，它能把所有潜在的运行依赖问题暴露在交付之前。
4. 安装、运行与部署SRS的完整流程
4.1 安装并初始化SRS服务
rpm包拿到现场机器上之后，安装非常简单：
sudo rpm -ivh SRS-5.0.0-1.*.x86_64.rpm如果想要更直观的进度显示，也可以用yum本地安装：
sudo yum install -y ./SRS-5.0.0-1.*.x86_64.rpm两种方式效果一样。但因为我们的spec里写了systemd服务文件和%preun卸载脚本，推荐用rpm方式安装，这样卸载时的清理逻辑能跑完整。
安装完成后，先手动启动一次看看能不能正常运行：
sudo systemctl start srs systemctl status srs如果一切正常，你会看到active (running)状态，同时SRS默认监听1935端口（RTMP）和1985端口（HTTP API）。确认一下：
ss -lntp | grep -E '1935|1985'如果启动失败，先看日志再试别的手段：
journalctl -u srs -n 50这里要特别说明一个坑：SRS默认的配置文件里可能没有配置HTTP-FLV的监听端口，也就是说即使进程起来了，你也只能推流不能直接在浏览器里拉HTTP-FLV流。所以安装之后的第一件事不是急着推流，而是先把符合你业务场景的配置写好，见下一节。
4.2 配置SRS的HTTP-FLV与WebRTC推拉流
演示一下典型配置。编辑/usr/local/srs/conf/srs.conf：
listen 1935; max_connections 1000; daemon off; srs_log_tank console; http_api { enabled on; listen 1985; } vhost __defaultVhost__ { http_remux { enabled on; mount [vhost]/[app]/[stream].flv; } hls { enabled on; hls_path /var/lib/srs/live; hls_fragment 2; } rtc { enabled on; } }重载配置并重启：
sudo systemctl restart srs接着用ffmpeg推一路测试流。先准备一个视频文件，或者直接用摄像头采集：
ffmpeg -re -i /path/to/test.mp4 -c copy -f flv rtmp://127.0.0.1:1935/live/test推送时能看到ffmpeg输出持续增加的帧数，说明数据正在写入SRS。另一边用浏览器或ffplay拉流：
ffplay http://127.0.0.1:8080/live/test.flv如果网络通、配置对，视频会正常播放。如果拉到的是黑屏或一直缓冲，不用急着怀疑SRS，先把推流的编码参数和延迟设置检查一遍，这个问题在5.3节单独展开。
4.3 开机自启动与防火墙放行
SRS进程设为开机自启动在任何生产环境都是必须的：
sudo systemctl enable srs内网环境还涉及防火墙放行。银河麒麟V10 SP1默认启用firewalld，需要手动放行几个端口：
sudo firewall-cmd --permanent --add-port=1935/tcp sudo firewall-cmd --permanent --add-port=1985/tcp sudo firewall-cmd --permanent --add-port=8080/tcp sudo firewall-cmd --reload端口选择必须和你实际的配置匹配：1935是RTMP推流端口，1985是HTTP API端口，8080是HTTP-FLV拉流端口。如果你的配置里改了端口或增加了HTTPS监听，记得同步在防火墙里放行。
5. 常见问题与排查技巧实录
5.1 构建阶段的典型报错
构建这块我前后踩了很多坑，把高频问题整理出来供自查。
第一类是工具链问题。最常见的报错是g++: command not found，原因是只装了gcc没装gcc-c++。SRS的C++代码量大，对C++标准的依赖高，这个包不能省。
第二类是内存不足。在虚拟机里编译SRS时，make -j$(nproc)偶尔会触发OOM Killer，直接把编译进程杀掉，现象就是终端突然回到命令行提示符，整个目录树里没有生成objs/srs。如果你的构建机内存小于2G，建议肉眼数一下CPU核数，然后手动指定低并行度编译：
make -j2第三类是源码包源问题。从GitHub直接下载的release包在国内网络环境下经常出现下载一半断掉、tar解压报CRC错误的情况。更稳妥的解法是先从Gitee镜像或一个稳定的HTTP源下载，校验文件大小和解压结果后再放到SOURCES目录。
第四类是selinux的干扰。银河麒麟自带SELinux且默认开启，编译阶段影响不大，但如果在~目录之外的位置编译，某些目录的SELinux上下文会导致许可被拒。建议直接在用户主目录下搭建rpmbuild目录树，不要放在/opt或/data等自定义目录。
5.2 运行阶段的问题定位
构建通过只是万里长征第一步，运行阶段的问题更隐蔽。
启动报segmentation fault是最让人头疼的。遇到这种问题先在/usr/local/srs/conf/srs.conf里把daemon off和srs_log_tank console打开，让SRS以前台方式运行，这样日志会直接打到终端，能快速定位到具体是哪个模块初始化失败。如果是默认配置下段错误，多半和硬件指令集有关，检查一下CPU是否为老型号，必要时换一台机器验证。
服务起不来但手动执行二进制能通行，这是systemd服务文件最常见的坑。排查时先用journalctl -u srs -n 50看日志，再确认ExecStart里写的路径对不对。我们在spec里安装到/usr/local/srs/bin/srs，注意确认这里和spec中的路径完全一致，不要出现“spec安装到/opt，服务文件却指向/usr/local”这种低级错误。
还有一种高频问题：端口占用。如果在命令历史中曾经用./objs/srs直接跑过SRS，再次systemctl start srs时就会报address already in use。解决方法：
sudo pkill -f /usr/local/srs/bin/srs sudo systemctl start srs另外注意，对于生产环境，日志目录要提前建好。HLS配置里如果写了/var/lib/srs/live这个路径，需要手动创建并确认目录权限，否则运行时报mkdir failed: Permission denied，看起来像编译问题，实际上就是用户态目录权限的事。
5.3 与ffmpeg推流延迟相关的调优
很多人都会遇到“ffmpeg推流到SRS存在延迟”这个问题，关键要分清延迟是“网络累积”还是“编码缓冲”。
先明确一个原则：SRS本身在局域网内的转发延迟是毫秒级的，肉眼感知到延迟基本来自推流端的编码器延迟和GOP缓存。ffmpeg默认的编码参数为了体积优化，会缓冲大量帧，加上-re参数控制读取速度后，延迟就会被放大。
一份实测有效的低延迟推流参数如下：
ffmpeg -re -i input.mp4 \ -c:v libx264 -preset ultrafast -tune zerolatency \ -g 50 -keyint_min 50 -sc_threshold 0 \ -c:a aac -ar 44100 -b:a 128k \ -f flv rtmp://127.0.0.1:1935/live/test解释一下几个关键参数：-preset ultrafast牺牲部分压缩率换取编码速度，-tune zerolatency关闭编码器内部的延迟缓冲，-g 50把关键帧间隔控制在2秒左右（25fps下就是每2秒一个关键帧），这直接决定了延迟的上限。如果只要低延迟不关心画质，可以用这个组合。
SRS端也有两个值得开的参数。一是在RTMP监听配置下增加rtmp_server { tcp_nodelay on; }，二是HTTP-FLV传输时建议直接使用115端口旁的HTTP协议，并配置gop_cache为on，让播放器可以在任意时刻加入而不必等关键帧。
对于WebRTC场景，延迟比HTTP-FLV更低，但要注意带宽和网络穿透。SRS WebRTC需要开UDP端口，默认在8000区间段。如果没有把控好UDP通路的连通性，WebRTC会在信令完成后卡死在连接交换阶段。
6. 进阶玩法与个人经验总结
6.1 用SRS搭建内部直播系统的扩展思路
打包只是入口，SRS真正吸引人的是它可以支撑一套完整的内部直播体系。
比较典型的玩法是“摄像头+RTMP推流+SRS+HTTP-FLV播放”。在分公司机房部署一台银河麒麟服务器，安装好SRS rpm包，各场地的摄像头统一推送RTMP流到这台服务器，员工通过浏览器访问http://server:8080/live/cam01.flv就能实时查看。这个方案比采购商业视频平台便宜得多，而且SRS支持虚拟主机，一个实例可以划分多个业务域。
另一个玩法是结合OBS做培训直播。OBS内置RTMP推流功能，主播端指定rtmp://server:1935/training/main，观众端用浏览器打开对应HTTP-FLV地址。SRS的HTTP API可以提供在线统计，比如当前并发数、总推流时长，方便培训管理员实时了解状况。
如果你有多个SRS节点，还能做源站和边缘站的集群。SRS原生的Origin模式可以配置回源拉流，边缘节点按需从源站拉取流并缓存。这个架构在跨地域时非常有用，源站部署在总部机房，边缘节点部署在各地分公司，观众全部就近接入。rpm包在这种多节点部署场景下优势明显：每个节点都一样，用统一的rpm包安装升级，不折腾人。
对于在线教育的低延迟互动场景，SRS WebRTC能搭配WHIP建立会话。浏览器端直接推送WebRTC流，SRS接收后转成RTMP或SRT分发，让师生在纯浏览器环境下完成互动，无需装任何插件。
6.2 版本管理与升级策略
自建rpm包要放进版本管理，不能只活在构建机的~/rpmbuild里。后面的实践经验值得参考。
源码包、spec文件、构建脚本整体纳入Git仓库。每次升级SRS版本时，只改spec里的Version字段，重新构建产出一个新版本的rpm包。这样你的交付物天然具备“一号对应一版”的可追溯性，现场出了问题可以直接对到源码提交。
升级路径要谨慎。SRS的配置格式在4.x到5.x之间有不小变化，如果现场跑的是4.x，升到5.x时不要直接rpm升级，建议先备份配置、再装新包、最后按官方文档做配置迁移。好在rpm升级机制支持%preun脚本，它会在升级时保留配置文件，但为了安全，还是手动备份一份最稳妥。
6.3 关于日常维护的几点心得
最后分享几条在银河麒麟上维护SRS的经验，都是常规文档里不写的东西。
日志管理。SRS运行日志如果用默认的console输出，会在systemd journal里积累大量数据，建议把srs_log_tank file和srs_log_file配置指到独立文件，并用logrotate做轮转。如果不做轮转，一个高并发节点半个月就能把磁盘吃满。
备份习惯。/usr/local/srs/conf/目录在rpm升级时不会被覆盖，这是rpm的常规行为。但正因如此，如果你每次升级完都重新改配置，导致配置漂移，时间久了会出现“线上跑的很新，但系统里的配置文件还是半年前那版”的情况。建议每次升级前把当前conf目录同步到Git仓库里打个tag，作为现场配置快照。
性能监控。SRS自带一个/api/v1/summaries的HTTP接口，可以直接拿来对接Prometheus或自定义的监控面板。虽然这个接口是给控制台用的，但字符串解析一下就能拿到推流时长、连接数、带宽数据，比自己写脚本抓日志高效得多。
我自己在实际项目里最深刻的体会是：rpm打包一旦做通，后续的每台服务器部署都变成了一件轻松事，本质上把“流媒体方案在国产系统上怎么落地”这个open question，变成了一套可以重复复制的标准化答案。尤其是现在国产化替代的项目越来越多，掌握这个技能值回票价。如果你也遇到了银河麒麟上SRS装不上、找不到包的问题，希望这篇内容能帮你少走一些弯路，早点把精力放回业务本身。
