StatusDude 用 Docker Compose 做零停机：小团队该学发布纪律，不是反 Kubernetes

StatusDude 这篇文章的钩子，不是“不用 Kubernetes 也能跑生产”。这句话太容易被读成站队。

更有意思的是它给出的规模锚点：每分钟数千次监控检查，3 个区域，每天多次部署。最后落地的东西却很朴素：Docker Compose、约 60 行 HAProxy 配置、10 行部署脚本。

反常点就在这里。它没有用更大的系统解决发布问题，而是退回到更老的工程三件套：多个后端实例、能重派失败请求的负载均衡器、一次只替换一个实例的滚动发布脚本。

Traefik 卡住的不是体验，是滚动发布细节

StatusDude 最初用 Traefik。Docker 场景里，它很顺手：自动发现服务、Docker labels、仪表盘，配置体验也轻。

但一进入 Docker Compose 滚动发布，问题变得具体。

这不是对 Traefik 的全盘否定。限定条件要说清楚：问题出在 StatusDude 描述的 Docker Compose 滚动发布和失败重派场景。

Traefik 的自动发现很舒服，但自动发现不等于发布安全。滚动发布最怕的不是“找不到服务”，而是新旧实例交替时，负载均衡器还把流量送进坏路径。

这对小团队后端和 DevOps 工程师的含义很直接：如果你用 Compose 做生产发布，不要只看路由能不能自动生成。要看失败请求能不能换后端、缩容时路由状态是否滞后、健康检查是否真的挡住了坏实例。

HAProxy 真正补上的，是 redispatch

HAProxy 被换上，不是因为它名字老，而是因为一个关键能力：option redispatch。

StatusDude 的说法里，当请求遇到连接失败、空响应、超时、502/503/504，HAProxy 可以把请求重试到另一个后端，而不是继续打同一个正在退出的容器。

对滚动发布来说，这一下很关键。发布期间一定会有实例退出、启动、变健康、被摘除。系统不怕有坏后端，怕的是负载均衡器认不出坏后端，或者认出来后还不换路。

这套方案可以压缩成三件事：

StatusDude 还叠了三层检查：单请求失败立即重试，实际流量里观察 5xx，主动探测 /health。Docker DNS 每 2 秒重新解析后端 IP，不挂 Docker socket，也不靠动态生成配置。

这套东西不炫。好处也在这里：边界清楚，失败路径短，可解释性强。

不过要留一层审慎。StatusDude 自称零停机、零丢请求，这是它的自述经验，不是独立基准测试。不同服务的启动时间、连接模型、长连接比例、数据库迁移方式，都可能改变结果。

小团队该延后平台化，但不能延后工程纪律

我更在意的不是“Compose 能不能替代 Kubernetes”。这个问题问歪了。

Kubernetes 解决的是另一组问题：复杂调度、权限治理、多租户、自动扩缩容、声明式回滚、跨团队平台化。真需要这些，它不是负担，而是基础设施。

但很多小团队还没走到那一步，就先背上 etcd、Ingress、Controller、Helm、CRD、集群升级和观测栈。系统规模没长起来，平台成本先长起来。

“杀鸡焉用牛刀”不等于拒绝工程纪律。真正该反对的，是为规模幻觉提前付账。

对正在纠结是否过早上 Kubernetes 的技术负责人，这篇文章给的动作不是“立刻换 Compose”。更现实的动作是延后平台采购或集群迁移，把时间花在三件事上：发布脚本是否一次只替换一个实例，负载均衡是否能重派失败请求，健康检查是否能挡住未就绪和正在退出的容器。

对小团队 DevOps 工程师，优先级也很清楚：先补失败路径，再谈平台形态。把 502、404、超时、缩容滞后这些发布期故障逐条压测一遍，比换一套更重的编排系统更有用。

Compose + HAProxy 的边界也不能装作不存在。复杂调度、强多租户、细粒度权限、自动扩缩容、声明式回滚、审计治理、跨团队自治，都不是它的强项。服务一多，脚本会变成隐形平台。人一多，手工约定会变成事故入口。

接下来最该观察的变量只有两个。

一个是回滚和数据库迁移。只替换容器还不够，数据层一旦不可逆，零停机发布就会变成半截工程。

另一个是观测和安全运维。HAProxy 能重派请求，但它不能替你解释所有慢请求、权限边界和配置漂移。小方案省掉的是平台复杂度，不是生产责任。

所以 StatusDude 这篇文章的价值，不是给 Kubernetes 判死刑。它至少说明，在特定规模和清楚边界下，小团队可以不用急着上大平台。

但前提很硬：你不能只省工具，不补纪律。模型看着更强，产品可能更虚；架构看着更大，系统未必更稳。工程里很多硬道理，仍然藏在负载均衡和发布脚本这种旧地方。