如何运用 Docker Compose 配置服务亲和性优化集群负载分配指南

Docker Compose 不支持 Kubernetes 式的服务亲和性或反亲和性调度，因其仅运行于单机 Docker 引擎，无节点调度能力；可通过共用自定义网络、depends_on、服务名直连及资源限制等机制间接实现逻辑“就近”与隔离，真正跨节点调度需求应切换至 Swarm 或 Kubernetes。

Docker Compose 本身不支持 Kubernetes 那样的服务亲和性（affinity）或反亲和性（anti-affinity）调度策略。它不是编排调度器，而是一个本地多容器应用定义与运行工具。所谓“服务亲和性”在 Compose 场景中并不存在原生概念——没有节点调度、不跨主机分配、也不管理容器在物理/虚拟机上的位置。但开发者常将“让某些服务尽量靠近运行”“避免同类型实例挤在同一容器实例上”等需求，误称为“亲和性”，实际需通过其他机制间接实现。

明确 Compose 的能力边界：没有节点级调度

Docker Compose 运行在单机 Docker 引擎上，默认所有服务容器都部署在同一台宿主机。它不感知“多个节点”，也不参与容器到机器的映射决策。因此：

• 无法设置 node_affinity 或 pod_anti_affinity 类似于 Kubernetes 的规则
• 不能强制某服务只运行在特定 CPU 或内存充足的节点上
• deploy.placement 中的 constraints 仅在 Swarm 模式下生效，且 Compose 独立模式（默认）完全忽略该字段

用网络与依赖模拟逻辑“就近通信”

虽然不能控制物理位置，但可通过服务间通信路径优化逻辑亲和性。例如，让 API 服务优先调用同一网络内的缓存服务，而非跨网络或外部地址：

• 为相关服务定义共用的自定义桥接网络（如 app-net），确保 DNS 解析走内部网络
• 在 docker-compose.yml 中显式声明 depends_on，控制启动顺序，提升初始化协同性
• 避免使用 host.docker.internal 或 172.17.0.1 等硬编码地址，改用服务名（如 redis）直连，利用 Docker 内置 DNS 实现低延迟解析

通过资源限制与命名隔离实现“软亲和”效果

当多个同类服务（如两个不同业务线的 Web 前端）共存时，可借助资源配置和标签减少干扰，达到类亲和目的：

• 为关键服务设置 cpus 和 mem_limit，防止资源争抢影响响应一致性
• 使用 container_name 或 labels 标记服务用途（如 tier: frontend、team: billing），便于后续监控或脚本识别分组
• 对需要强隔离的服务，分别定义独立 networks 并禁用互通，避免非预期通信

真正需要亲和性？请切换到 Swarm 或 Kubernetes

若业务确有跨节点调度需求（比如数据库主从必须分置、AI 计算服务需绑定 GPU 节点），Docker Compose 不是合适工具：

• 启用 Docker Swarm 后，可在 deploy.placement.constraints 中使用 node.labels 控制部署位置
• Kubernetes 提供完整的 affinity/antiAffinity 字段，支持拓扑域、Pod/Node 匹配等精细策略
• Compose 可作为开发阶段原型工具，生产环境建议用 docker stack deploy（Swarm）或 Helm + K8s 替代