deploy配置仅在Swarm集群生效，定义静态副本数、资源限制和重启策略，不支持自动伸缩；需结合外部监控触发扩缩容，配合network与healthcheck确保新实例正常接入流量。
直接在 docker-compose.yml 里用 deploy 配置伸缩策略，只对启用 Swarm 模式的集群生效——它不是本地单机的自动扩缩容开关，而是告诉 Swarm “这个服务默认该跑几个副本、怎么调度、资源怎么限制”。要真正实现弹性伸缩，还得靠外部监控+命令触发，deploy 只管“静态基线”和“调度约束”。
deploy.replicas：设好初始副本数，不是自动伸缩目标
replicas 定义的是服务启动时的固定实例数，Swarm 会尽力维持这个数量（比如挂掉一个，自动补一个）。但它不会根据 CPU 或队列长度自己加减。常见写法：
-
replicas: 3—— 启动就拉起 3 个 worker 实例，适合稳态负载 - 不写
replicas，改用mode: global—— 每个 Swarm 节点上都跑 1 个副本，适合日志采集、监控代理类任务 - 搭配
placement约束，例如只在有 GPU 标签的节点上部署：placement: {constraints: ["node.labels.gpu == true"]}
deploy.resources：划清资源边界，防争抢、保隔离
量化分析类任务常吃 CPU，但又不能让一个 worker 把整台机器拖垮。用 resources 显式限流：
-
limits: {cpus: '0.8', memory: 1G}—— 单个容器最多用 0.8 核 CPU、1GB 内存 -
reservations: {cpus: '0.2', memory: 512M}—— Swarm 会为它预留至少这些资源，避免启动失败 - 注意：这些值是 per-container 的，和
replicas相乘才是总资源需求
deploy.restart_policy：让故障恢复更可控
worker 容器执行完策略就退出，属于“一次性任务”，不适合用 always 重启。推荐配置：
-
condition: on-failure—— 只有非 0 退出码才重启，避免死循环 -
max_attempts: 3—— 最多重试 3 次，防止反复失败占位 -
delay: 10s—— 重试前等 10 秒，给调度留出缓冲
别漏掉 network 和 healthcheck：影响扩缩容实际效果
伸缩后新实例能否立刻接入流量，取决于网络连通性和健康状态：
- 必须显式定义
networks并确保所有服务（如 Redis、调度服务）在同一 overlay 网络中，否则新 worker 找不到队列 - 加
healthcheck让 Swarm 知道容器是否真就绪：
healthcheck:<br> test: ["CMD", "curl", "-f", "http://localhost:8000/health"]<br> interval: 30s<br> timeout: 10s<br> retries: 3
没通过健康检查的实例，Swarm 不会把它加入 DNS 轮询池，也就不会分到任务
