docker compose本身不支持跨物理机部署，它专为单机多容器编排设计；实现跨主机服务扩展必须使用docker swarm或kubernetes等集群编排平台，其中swarm最轻量且与docker生态无缝衔接。
Docker Compose 本身不支持跨物理机部署，它专为单机多容器编排设计。想实现跨物理机的微服务高速互联，必须脱离 Compose 原生能力，转向 Docker Swarm 或 Kubernetes 等集群编排平台——其中 Swarm 是最轻量、与 Docker 生态无缝衔接的方案。
用 Swarm 替代 Compose 实现跨主机网络
Swarm 内置 overlay 网络，专为跨节点通信而设。它在各物理机上启动一个用户态代理（docker daemon 的内置模块），通过 VXLAN 封装数据包，在底层物理网络之上构建逻辑二层网络。所有加入同一 overlay 网络的服务容器，无论位于哪台机器，都能直接用服务名通信，且自动完成 DNS 解析和负载均衡。
- 初始化 Swarm 集群：在首台机器运行
docker swarm init --advertise-addr，获得 join token - 其他物理机执行
docker swarm join --token <token><manager-ip>:2377</manager-ip></token>加入集群 - 在 manager 节点创建 overlay 网络：
docker network create -d overlay --attachable mynet - 部署服务时指定该网络：
docker service create --network mynet --name api nginx
服务发现与健康路由不能靠 Compose 默认机制
Compose 的内置 DNS 只在单机 default 网络内有效，跨主机后完全失效。Swarm 则在控制平面维护全局服务注册表，每个服务名（如 api）会被解析为一组活跃任务的虚拟 IP（VIP），请求自动轮询分发到所有副本容器。即使某台物理机宕机，剩余节点上的副本仍可继续提供服务，DNS 记录也会在几秒内刷新。
- 避免在应用代码中硬写容器 IP 或依赖 localhost —— 容器内 localhost 永远指向自己
- 服务间调用统一使用
http://<service-name>:<port></port></service-name>格式，由 Swarm DNS 统一解析 - 对延迟敏感的场景，可启用 DNS RR（Round Robin）模式，或配合 Traefik / Nginx 作为边缘网关做更精细的路由
网络性能优化的关键配置
Overlay 网络虽方便，但 VXLAN 封装会带来轻微开销。实际生产中可通过以下方式保障高速互联：
- 确保所有物理机时间同步（NTP），避免 TLS 握手失败或证书校验异常
- 在内核参数中开启
net.ipv4.conf.all.forwarding=1和net.bridge.bridge-nf-call-iptables=0，减少 iptables 链路跳转 - 使用
--endpoint-mode dnsrr启动服务，让客户端直连容器 IP（绕过 VIP），适用于已集成服务发现 SDK（如 Spring Cloud）的应用 - 对数据库等有状态服务，建议搭配
placement constraints固定运行节点，减少跨机 IO 延迟
为什么不能“改造 Compose”来跨主机
Compose 的设计哲学是“单机开发友好”，其网络模型基于本地 bridge + 内嵌 DNS，所有服务名解析都发生在本机 docker daemon 内部。即便手动在多台机器上运行多个 Compose 项目，并试图用外部 etcd 或 Consul 做服务发现，你也无法绕过两个根本限制：
- 没有统一的网络控制面，容器间无法直接二层互通，只能走三层（如 host 网络或暴露端口），失去服务名通信能力
- 没有跨节点调度器，扩缩容、滚动更新、故障自愈等功能全部缺失
强行拼凑不仅复杂度陡增，还会引入大量运维盲区。Swarm 是 Docker 官方提供的、开箱即用的跨主机解决方案，学习成本低，迁移路径清晰——把 docker-compose.yml 改写为 docker stack deploy 所需的格式，几乎只需调整网络声明和部署策略字段。
