Docker容器高可用架构需消除单点故障、实现自动恢复与持续访问，依赖编排工具（Swarm/K8s）、健康检查、网络存储设计、依赖组件集群化协同保障。
配 Docker 容器高可用架构，核心是消除单点故障、实现自动恢复、保障服务持续可访问。不是堆机器，而是靠设计+配置+可观测性协同工作。
选对编排工具：Swarm 或 Kubernetes
单靠 docker run 启动容器无法实现高可用，必须用集群编排系统：
-
Docker Swarm：轻量、原生集成、学习成本低。生产建议至少 3 个管理节点（奇数），通过 Raft 共识保证控制面不宕机；工作节点可动态增减，服务设
replicas: 3即自动跨节点部署三副本 -
Kubernetes：功能更全，适合复杂微服务场景。用
Deployment管理 Pod 副本，配合LivenessProbe和ReadinessProbe触发自动重启或摘流 - 避免用
docker-compose up直接跑多容器——它只在单机生效，节点挂了整个服务就中断
健康检查必须配，且要合理
光有副本不够，系统得“知道”容器是不是真健康。Docker 原生 HEALTHCHECK 是基础：
- 写在 Dockerfile 里：
HEALTHCHECK --interval=30s --timeout=5s --retries=3 --start-period=60s CMD curl -f http://localhost:8080/actuator/health || exit 1 -
--start-period很关键：给 Spring Boot 等应用留出初始化时间，避免启动中就被误判失败 - 编排层（Swarm/K8s）会读取这个状态，连续失败后自动重建容器，而不是等进程僵死才响应
网络与存储不能裸奔
高可用不只是容器活，还要确保通信通、数据不丢：
-
网络：跨主机通信必须用
overlay网络（Swarm）或CNI插件（K8s）；服务间调用用服务名（如http://user-service:8080），靠内置 DNS 自动解析，别硬写 IP -
存储：有状态服务（如数据库、Redis）必须挂载外部存储。Swarm 用共享卷驱动（如 NFS、Ceph），K8s 用
PersistentVolume；本地bind mount或默认bridge卷 = 单点故障 - 对外暴露：加一层负载均衡（Nginx / HAProxy / 云 SLB），把流量分到多个 Registry 或 API 节点，别让客户端直连某台容器 IP
配置中心和数据库要集群化
容器可以漂移，但依赖组件不能是单点：
- Nacos/Eureka/ZooKeeper 必须起 ≥3 节点集群，共用同一 MySQL（开启主从或高可用部署），
cluster.conf手动写全地址，所有节点NACOS_AUTH_TOKEN和 identity 密钥严格一致 - MySQL、PostgreSQL 别放容器里跑单例。推荐 RDS 高可用版，或自建 MHA/Patroni 集群；容器只连它，不托管它
- 私有镜像仓库（Registry/ Harbor）至少双节点 + 对象存储（S3/OSS）后端，前端走 LB，避免推送镜像时因单节点故障失败
