Docker Compose本身不支持按负载自动扩缩容，它缺乏内置监控与触发机制，仅提供手动扩缩容能力（如docker compose up --scale），需依赖外部工具链（如Prometheus+Grafana+自定义脚本）实现自动化决策与执行。
Docker Compose 本身不支持按负载自动扩缩容。它没有内置监控、指标采集或触发器机制，无法像 Kubernetes 的 HorizontalPodAutoscaler 那样根据 CPU、请求延迟等实时指标自动增减实例。所谓“自动”必须靠外部工具链补足。
docker compose up --scale 是手动扩缩容，不是自动的
很多人误以为 docker compose up --scale web=5 是“自动”的起点，其实它只是命令行快捷方式：启动时指定副本数，或重建服务时覆盖配置。它不感知负载，也不持续运行。一旦执行完，就静止了——后续流量涨了、CPU飙高了，它不会自己再加一个 web_6。
-
--scale参数只在up命令执行期间生效，重启或重载后需重新指定 - 它不读取任何监控数据，也不做决策，纯属“你让扩，我才扩”
- 生产环境若靠人盯监控 + 手动敲命令扩缩，响应慢、易出错、不可审计
真要按负载自动扩缩，必须引入外部调度层
目前唯一可行路径是把 Docker Compose 当作“底层资源交付单元”，上面架一层能监听指标并调用 docker compose up --scale 的控制器。典型组合是：
- Prometheus（采集容器 CPU、内存、HTTP QPS 等指标）
- Grafana（可视化 + 设置告警阈值）
- 自定义脚本或轻量调度器（如 Python +
subprocess调用docker compose up --scale）
例如：当 Prometheus 告警 avg by (service)(rate(container_cpu_usage_seconds_total{image=~".+"}[2m])) > 0.7 触发时，脚本执行：docker compose up -d --scale web=$(( $(docker ps --filter "name=^web" --format '{{.Names}}' | wc -l) + 1 ))
注意：这种方案仍受限于 Compose 的单机模型，无法跨主机调度；且 replicas 字段在非 Swarm 模式下被忽略，--scale 是唯一可靠入口。
deploy.replicas 在普通 Compose 模式下无效
很多文档写 deploy: { replicas: 3 } 就能起 3 个实例，这是误导。该字段仅在 Docker Swarm 模式下生效；而 Docker Desktop 默认关闭 Swarm，docker compose up 会直接忽略 deploy.replicas，只起 1 个容器。
- 验证方法：启动后执行
docker ps --filter "name=^web" | wc -l，结果为 1 即说明replicas未生效 - Swarm 模式需显式启用：
docker swarm init，但会改变整个 Docker 运行时行为，开发调试成本陡增 - 绝大多数团队用 Compose 就是为了避开 Swarm/K8s 复杂性，所以实际都走
--scale动态路径
对外暴露服务必须配反向代理，DNS 轮询不解决真实负载分发
Docker 内置 DNS 对 web 的解析返回所有 web_1、web_2 IP，但这是轮询（RR），不是健康检查+权重+连接复用。客户端直连 web:80 只在容器内有效；对外网用户，必须加一层 Nginx/Traefik：
- Nginx
upstream块里写server web:80;，靠 Docker DNS 自动发现全部实例 - 每次增减实例后，需
nginx -s reload，否则新容器不进 upstream - Traefik 更省事，开
providers.docker后自动 watch 容器生命周期，但要注意 network 隔离问题
没这层，你扩了 10 个 web 实例，外部用户还是只能打到某一个——因为宿主机 -p 80:80 只映射了一个容器端口，其余 9 个根本没暴露出去。
真正卡住自动扩缩的，从来不是怎么起多个容器，而是谁来决定“现在该扩了”，以及扩完之后流量能不能立刻打到新实例上。这两步，Docker Compose 自己一步都做不了。
