用 Rust 写一套直播平台：推流、鉴权、回放，也能当在线教育用
这套东西的出发点很朴素：个人、私域社群和小团队想自己搞直播，现成的选择并不好。
商业直播云按流量计费，做个几十人的内部培训也要走一遍开通流程；开源方案要么只是个媒体服务器（推流拉流之外什么都没有），要么整套太重，为了一个几十人的场景要部署一堆东西。
所以自己写了一套，用 Rust。
做了什么
四块，凑齐了才算一个能用的平台：
1. RTMP 推流 + HLS / FLV 拉流
最经典也最稳的一条链路：主播端用 OBS 推 RTMP 上来，服务端转成 HLS 和 HTTP-FLV 两种格式分发。
为什么两种都要：HLS 兼容性最好、能过 CDN，但天生有几秒到十几秒延迟（切片决定的）；HTTP-FLV 延迟能压到一两秒，代价是要浏览器端配合。让观众按场景选，比强行统一成一种更实用——看回放和大规模分发走 HLS，需要互动的走 FLV。
2. 房间 / 频道与权限控制
不是”谁拿到地址谁就能看”。系统里有房间的概念，每个房间有：
- 推流密钥——没有密钥推不上来，防止别人占用你的频道
- 观看鉴权——房间可以是公开的，也可以要求登录、要求在白名单里
- 角色区分——主播、管理员、普通观众的权限不一样
这一块是它能当教育平台用的关键。 公开直播不需要鉴权，但”只有报名的学员能进这堂课”就必须有。没有权限模型的直播系统，做不了教育。
3. 录制与回放
直播的同时落存档，结束后自动生成可回看的录像。
对教育场景来说这几乎是刚需——上课的人里总有一部分当时来不了。而且录播内容本身会沉淀成资产，一门课录一次能反复用。
工程上要注意的是录制不能拖累直播：转码和写盘走独立的任务，即使存储慢了或者满了，也不能让正在看的人卡住。
4. 聊天 / 弹幕与实时互动
WebSocket 长连接做实时消息。直播场景是弹幕，教育场景就是提问和答疑——形式一样，用途不同。
消息要和房间权限打通：能看这个房间的人才能收到消息，能发言的人才能发。
为什么用 Rust
直播服务端的特点是长连接多、并发高、单条消息小、要一直跑着不能崩。
Rust 在这里的好处很直接：没有 GC 停顿，长时间跑内存占用平稳；类型系统和所有权模型逼着你在编译期就把并发和生命周期的问题处理掉，而不是等到线上半夜连接泄漏。
代价是开发速度慢，尤其是异步那套刚开始很折磨人。但这类”部署上去就要长期无人值守”的服务，我认为值得——运维本职的经验告诉我，半夜爬起来重启服务的成本远高于开发时多花的那几天。
当教育平台用，缺什么
坦白说，它现在是个直播平台，不是完整的教育系统。直播 + 权限 + 回放 + 互动这四样是在线教育的技术底座，但一个真正的教育平台还需要课程编排、报名与订单、作业与测验、学习进度追踪。
不过对很多小团队来说，够用了——内部培训、社群课程、小规模教学，需要的恰恰就是”能开课、能控制谁进来、能回看、能提问”这四件事。
和本职的关系
我做网络和信息化交付十几年，很清楚音视频这条链路上哪些地方会出问题：带宽估算、CDN 回源、丢包重传、码率自适应。写这套东西的时候，判断”这里该不该加一层缓存""这个延迟指标现实不现实”，靠的还是那些经验。
反过来它也补了我一块：以前做 IPTV、做视频监控联网，我是甲方或者集成方，用的是别人的平台；自己从头写一遍之后，再去看厂商方案，能看出哪些是真难点、哪些只是包装。
文章分享
如果这篇文章对你有帮助，欢迎分享给更多人！