跳转到内容
类型解锁
阶段生产环境
难度中等
工作分享流
用于后端开发者
用于开发团队
服务管道
服务容器
为何选 HoodyHTTP 原生
为何选 Hoody容器经济学
类型解锁
阶段生产环境
难度中等
工作分享流
用于后端开发者
用于开发团队
服务管道
服务容器
为何选 HoodyHTTP 原生
为何选 Hoody容器经济学
类型解锁
阶段生产环境
难度中等
工作分享流
用于后端开发者
用于开发团队
服务管道
服务容器
为何选 HoodyHTTP 原生
为何选 Hoody容器经济学
类型解锁
阶段生产环境
难度中等
工作分享流
用于后端开发者
用于开发团队
服务管道
服务容器
为何选 HoodyHTTP 原生
为何选 Hoody容器经济学
PIPE · 容器到容器

无需 broker 的容器间 IPC

服务 A 把输出管道到一条路径。服务 B 从同一条路径拉。管道在两个容器之间实时转发字节。无 Redis、无消费组、无需照看的 broker 守护进程。

阅读 pipe 文档

管道如何取代 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 接收。字节哪里都不落盘——它们从生产者跨过线路到消费者,管道在途中转发。

加第三个读取者。再加第四个。

当 logger 或 metrics collector 也要同样的事件时,把 ?n 加大,再加一条 curl。无 broker 配置、无消费组、无要轮换的鉴权密钥。新读取者就这么存在了。

pipe/jobs · 读取者?n=4 · 全员扇出
  • + 新增
    consumer-aloggermetricsaudit
    curl ?n=4 — 加入扇出
  • = 不变
    producer
    service-a | curl -T - ?n=4
  • − 移除
    redisconsumer-group.ymlbroker.conf
    无 broker、无配置

一个慢读取者只对生产者施加背压;它不会阻塞其他读取者。每条路径最多 256 个读取者。

URL 还给你的,broker 当年拿走的

broker 之所以存在,是因为两个容器没法直接对话。有了管道,它们可以了。broker 加上去的所有东西——鉴权、客户端、运维——一并消失。

  • 无守护进程要运维

    无需部署、监控或升级。管道就是平台;URL 就是唯一的 API。

  • Bearer 鉴权,而非 broker 凭据

    一个 Hoody token,按项目作用域。无每 broker 一份的用户名、密码或 ACL 文件。

  • 同一根线,任意语言

    凡是会说 HTTP 的都能生产或消费——bash、Python、Go、手机、浏览器。无需客户端库。

  • 无持久化状态

    消息只存在于在途中,不在静止处。无磁盘可填、无保留策略、无对队列数据的 GDPR 疑问。

  • 背压就是协议

    当最慢的消费者跟不上时,TCP 自然减慢生产者。没有滞后仪表盘——因为根本没有滞后,只有流速。

  • 容器之间保持解耦

    生产者和消费者从不看到对方的 IP。它们共享一个 URL。任一方搬到另一台主机都不必重连。

broker 就是 URL。URL 就是 broker。

中间这一层坍缩了。曾经那个带凭据、客户端和运维手册的有状态守护进程,如今变成一条路径。架构图少了一个方框。

原来有
  • redis 集群鉴权、副本、故障转移
  • consumer-group.ymloffset、分区
  • 每个服务里的 broker SDK每种语言一份客户端库
现在有
/api/v1/pipe/jobs

一个 URL、一条 curl、一个 HTTP 动词

阅读 pipe 文档

这取代了什么

团队在一个容器需要把字节交给另一个时通常会上的基础设施。每一种都加一个守护进程、一份配置和一轮 on-call。管道一项都不收。

  • Redis pub/sub守护进程、鉴权、每种语言的客户端
  • RabbitMQ为在途字节运维一个集群
  • NATS又一种协议、又一个 sidecar
  • ZeroMQ每个服务里都装库,没有 URL
  • 自建路由守护进程得自己养着的定制服务
  • gRPC 流式服务schema、代码生成、双向 TLS 开销
  • Apache Kafka 消息代理为根本不留的消息加一层存储

为了让两个容器对话就架个 Redis?还是共享一个 URL。

查看 pipe API

阅读其他内容