一台服务器上运行 60 个容器
一个裸金属服务器运行数十到数百个 Hoody 容器。KSM 和 BTRFS 去重使边际成本接近零。
容器·快照
use-cases / inter-container-ipc-without-the-broker / hero
PIPE · 容器到容器
无需 broker 的容器间 IPC
服务 A 把输出管道到一条路径。服务 B 从同一条路径拉。管道在两个容器之间实时转发字节。无 Redis、无消费组、无需照看的 broker 守护进程。
topology · pipe/orders
实时事件日志
LIVE- 08:59:14·生产者·PUT order-9842 (+47b)
- 08:59:14·pipe·扇出至 2 个消费者
- 08:59:15·billing·GET order-9842 → charge $129
- 08:59:15·analytics·GET order-9842 → ledger
- 08:59:16·生产者·PUT order-9843 (+51b)
POST 进来。GET 出去。中间的跳点是一个 URL。
use-cases / inter-container-ipc-without-the-broker / mechanism
管道如何取代 broker
两个 HTTP 动词,一条路径。任一端都能先连;管道会等对端最多五分钟,然后把字节穿过去。无队列、无 offset、无消费组。
01 · 握手
任一端都能先连
生产者还没起?消费者 GET 等着。消费者还没起?生产者 PUT 等着。管道会保持连接最多五分钟,直到对端出现。
02 · 背压
TCP 连接就是队列
消费者慢的时候,内核就会减慢生产者的流。无队列深度要监控、无高水位要调优。socket 就是缓冲区。
03 · 无状态
送达即遗忘
诚实的取舍:什么都不持久化。要做持久化队列,这条路不合适。但要做容器间的快速扇出,broker 直接消失了。
producer.sh · consumer.sh
# Container A — producer streams jobs to the pipe
service-a | curl -T - https://api.hoody.com/api/v1/pipe/jobs
# Container B — consumer reads from the same path
curl https://api.hoody.com/api/v1/pipe/jobs | service-b
# Either side can connect first.
# The pipe holds the connection up to 5 minutes
# until the counterpart arrives, then streams through.PUT(或 POST)发送。GET 接收。字节哪里都不落盘——它们从生产者跨过线路到消费者,管道在途中转发。
use-cases / inter-container-ipc-without-the-broker / fanout
加第三个读取者。再加第四个。
当 logger 或 metrics collector 也要同样的事件时,把 ?n 加大,再加一条 curl。无 broker 配置、无消费组、无要轮换的鉴权密钥。新读取者就这么存在了。
pipe/jobs · 读取者?n=4 · 全员扇出
- + 新增consumer-aloggermetricsauditcurl ?n=4 — 加入扇出
- = 不变producerservice-a | curl -T - ?n=4
- − 移除redisconsumer-group.ymlbroker.conf无 broker、无配置
一个慢读取者只对生产者施加背压;它不会阻塞其他读取者。每条路径最多 256 个读取者。
use-cases / inter-container-ipc-without-the-broker / advantages
URL 还给你的,broker 当年拿走的
broker 之所以存在,是因为两个容器没法直接对话。有了管道,它们可以了。broker 加上去的所有东西——鉴权、客户端、运维——一并消失。
无守护进程要运维
无需部署、监控或升级。管道就是平台;URL 就是唯一的 API。
Bearer 鉴权,而非 broker 凭据
一个 Hoody token,按项目作用域。无每 broker 一份的用户名、密码或 ACL 文件。
同一根线,任意语言
凡是会说 HTTP 的都能生产或消费——bash、Python、Go、手机、浏览器。无需客户端库。
无持久化状态
消息只存在于在途中,不在静止处。无磁盘可填、无保留策略、无对队列数据的 GDPR 疑问。
背压就是协议
当最慢的消费者跟不上时,TCP 自然减慢生产者。没有滞后仪表盘——因为根本没有滞后,只有流速。
容器之间保持解耦
生产者和消费者从不看到对方的 IP。它们共享一个 URL。任一方搬到另一台主机都不必重连。
use-cases / inter-container-ipc-without-the-broker / punchline
broker 就是 URL。URL 就是 broker。
中间这一层坍缩了。曾经那个带凭据、客户端和运维手册的有状态守护进程,如今变成一条路径。架构图少了一个方框。
原来有
- redis 集群鉴权、副本、故障转移
- consumer-group.ymloffset、分区
- 每个服务里的 broker SDK每种语言一份客户端库
现在有
/api/v1/pipe/jobs
一个 URL、一条 curl、一个 HTTP 动词
use-cases / inter-container-ipc-without-the-broker / replaces
这取代了什么
团队在一个容器需要把字节交给另一个时通常会上的基础设施。每一种都加一个守护进程、一份配置和一轮 on-call。管道一项都不收。
- Redis pub/sub守护进程、鉴权、每种语言的客户端
- RabbitMQ为在途字节运维一个集群
- NATS又一种协议、又一个 sidecar
- ZeroMQ每个服务里都装库,没有 URL
- 自建路由守护进程得自己养着的定制服务
- gRPC 流式服务schema、代码生成、双向 TLS 开销
- Apache Kafka brokers为根本不留的消息加一层存储
use-cases / inter-container-ipc-without-the-broker / cta
为了让两个容器对话就架个 Redis?还是共享一个 URL。
use-cases / inter-container-ipc-without-the-broker / related
阅读其他内容
