docker compose本身不支持自动扩缩容，需结合监控脚本与docker compose up --scale命令实现基于cpu、请求量等负载指标的轻量级弹性伸缩，仅适用于无状态服务（如listmonk app），并须搭配反向代理和健康检查确保可用性。
Docker Compose 本身不内置自动扩缩容能力，但可以通过组合监控、脚本和原生命令，构建轻量级、可落地的基于业务负载的弹性伸缩方案。关键不是“全自动”，而是“自动触发 + 可控执行”，尤其适合中小规模 listmonk、JupyterHub 或 Web API 类无状态服务。
明确适用前提：哪些服务能扩，哪些不能
弹性伸缩只对无状态服务有效——比如 listmonk 的 app 服务、Web 前端、API 网关。有状态组件（如 PostgreSQL、Redis）不能随意增减实例，否则会导致数据不一致或连接中断。
- 确认你的服务在 docker-compose.yml 中未设置
container_name（否则scale会冲突） - 确保应用支持多实例并行运行（例如通过外部消息队列或数据库协调任务）
- HTTP 类服务必须搭配反向代理（如 Nginx、Traefik），否则新增容器无法被流量命中
用 up --scale 实现启动即扩容，避免 legacy 命令
docker compose scale 已被标记为 Legacy，官方推荐统一使用 docker compose up --scale。它更可靠，能自动处理依赖，并兼容 deploy 配置。
- 直接启动 3 个 web 实例：
docker compose up -d --scale web=3 - 动态调整并重载配置：
docker compose up -d --scale worker=5 --force-recreate - 多个服务同时设定：
docker compose up -d --scale api=4 --scale processor=2
注意：--scale 会覆盖 compose 文件中 deploy.replicas 的值，适合按需临时扩容，也便于 CI/CD 流水线调用。
接入真实负载指标，触发自动伸缩
真正“基于负载”的核心是采集指标 + 判断阈值 + 执行命令。不需要 Kubernetes，用 Prometheus + 自定义 shell 脚本即可闭环：
- 在服务中暴露
/metrics（如 listmonk 支持 Prometheus 格式指标） - 部署 Prometheus 抓取指标，重点关注：
container_cpu_usage_percent、http_requests_total、queue_length - 写一个定时检查脚本（例如每 30 秒执行一次）：
if [ $(curl -s http://prometheus:9090/api/v1/query?query=avg_over_time(container_cpu_usage_percent%7Bcontainer%3D%22app%22%7D[2m])) -gt 75 ]; then docker compose up -d --scale app=4 elif [ $(curl -s http://prometheus:9090/api/v1/query?query=avg_over_time(container_cpu_usage_percent%7Bcontainer%3D%22app%22%7D[5m])) -lt 30 ]; then docker compose up -d --scale app=1 fi
规避常见坑点：网络、数据、一致性
扩缩容不是“多起几个容器”那么简单，以下细节决定是否真正可用：
-
服务发现：Docker Compose 默认网络支持 DNS 轮询（
app解析为所有 app 容器 IP），但应用层需支持重试与超时，避免请求打到刚启动尚未就绪的实例 -
健康检查：在 compose 文件中添加
healthcheck，确保新容器 ready 后才纳入流量 - 共享状态：邮件队列、用户会话等必须外置（如用 Redis 存 session、用 PostgreSQL 存发送任务），禁止本地文件存储
- 缩容安全：缩容前建议先 drain（如停止接收新任务），避免正在处理的邮件或 notebook 被中断
