
一台服务器上运行 60 个容器
一个裸金属服务器运行数十到数百个 Hoody 容器。KSM 和 BTRFS 去重使边际成本接近零。
半夜在结对调试,对面那台热点撑不住一次 Zoom。两边都有 shell。ffmpeg 抓麦克风,curl PUT 到一条管道路径,另一边 curl 然后播放字节。无 SDK、无信令、无会议。
$ ffmpeg -f alsa -i default \
-c:a libopus -f ogg - \
| curl -T - https://pipe.containers.hoody.com/api/v1/pipe/voice$ curl https://pipe.containers.hoody.com/api/v1/pipe/voice
| mpv --no-video -无信令、无 SDK、无 Zoom
ffmpeg 把你的麦克风编码成 opus 写到 stdout。curl 把 stdin PUT 到 /api/v1/pipe/voice。任何人 GET 同一条路径就能在发送端产出时收到字节。管道为发送端最多保留接收端五分钟,转发 Content-Type,不存储任何东西。
ffmpeg -f alsa -i default -c:a libopus -f ogg - 读你的麦克风,编码到 opus,写到 stdout。
curl -T - 把 stdin PUT 到 /api/v1/pipe/voice。管道在同一条路径上等接收端,最多五分钟。
他们的终端跑 curl https://.../api/v1/pipe/voice。管道把发送端和接收端配上,开始流。
他们那边的 curl 接 aplay 或 mpv。音频边到边播,字节对字节。ctrl-C 结束通话。
管道转发 Content-Type,在对端连上之前最多保留五分钟,使用 HTTPS——没有比你 shell 已经会说的协议更花哨的东西。
无回声消除、无抖动缓冲、无花哨 DSP。这是 SRE 结对调试时用的那种语音通道:精简、低开销、稳。会议平台堆的每一层,这套管道对儿都直接没有。
同一套"麦克风走 HTTP"的机制,根据管道另一端是谁,可以有三种读法。
你已经在生产事故里敲了三条命令。开 Zoom 比修这个 bug 还久。你这边 ffmpeg | curl,对面 curl | mpv——可以一边 tail 日志一边说话。
手机热点撑不住视频通话。一条 32 kbps opus 流走 HTTP 没问题。对面打开一个 URL 听就行——他们甚至不需要麦克风也能参与。
服务器上什么都不存。两台机器上都没有第三方 app。管道纯流式——字节穿过去,ctrl-C 一按就消失。
音频只是字节。字节只是一条管道。
每对工程师都会攒一堆语音工具。每一个都假设要开会、要账号,或要自建信令服务器。管道 URL 不假设其中任何一项。
下次有人说"开个会快速过一下吗",改打开一条管道。