高可用必须采用多节点集群模式而非单容器部署；如minio需4节点分布式部署并启用纠删码，nacos需3节点共用mysql，kafka需3 broker+3 zookeeper，redis需哨兵或cluster架构，且所有节点须网络互通、时间同步、独立存储。
靠单个容器跑服务，根本谈不上高可用。真要扛住故障、持续提供服务，得靠多节点协同、自动故障转移和合理冗余设计。
必须用集群模式，不能只起一个容器
单容器挂了，服务就断了——这是常态。高可用的前提是至少 3 个以上独立运行的实例，分布在不同宿主机或可用区。比如：
- Nacos 配置中心要三节点集群，共用同一 MySQL，且所有节点 NACOS_AUTH_TOKEN 和 identity 密钥完全一致
- MinIO 分布式部署至少 4 节点，满足“任意 2 个宕机仍可读写”，每个节点挂载独立存储卷
- Kafka 推荐 3 Broker + 3 ZooKeeper，每个 Broker 设唯一 broker.id 和正确的 advertised.listeners
- Redis 高可用需主从 + 哨兵（Sentinel）或 Redis Cluster，哨兵本身也建议至少 3 个实例
网络与状态同步是关键支撑
节点之间必须能稳定通信，否则集群形同虚设：
- 创建专用 Docker 网络（如
nacos-cluster-net或minio-net），避免默认桥接网络的 DNS 解析不稳定 - 所有节点时间必须同步（NTP 服务强制启用），尤其 MinIO 和 Kafka 对时钟偏移敏感
- 用
extra_hosts或自定义 DNS 显式配置节点主机名映射，不依赖外部 DNS - Swarm 模式下，Manager 节点间通过 Raft 协议同步状态，需开放 2377、7946、4789 端口
数据持久化和配置一致性不能妥协
容器重启不丢状态，配置改一处全生效，才是生产级可用：
- 所有有状态组件（MySQL、Redis、Kafka、MinIO）必须挂载宿主机目录或网络存储卷，禁止用临时文件系统
- 配置文件统一管理，比如 Nacos 的
cluster.conf、Kafka 的server.properties、Redis 的redis.conf和sentinel.conf都应通过 volume 挂载 - 环境变量（如数据库地址、密码、token）全部通过
-e或.env文件注入，避免硬编码在镜像里 - MySQL 推荐 MGR（Group Replication）或主从 + Keepalived，而不是单点主库
入口层必须做负载均衡和健康检查
用户流量进来第一关，决定了整个集群是否真正“对外可用”：
- 用 Nginx 或 HAProxy 做七层代理，upstream 配置多个后端地址，并启用
max_fails和fail_timeout - 结合 Keepalived 实现 VIP 漂移，让入口 IP 不因某台 LB 宕机而失效
- 对后端服务做主动健康探测（如 Nginx 的
health_check或自定义 check 脚本） - Swarm 内置 Ingress 网络可自动做服务发现和轮询，但对外仍需前置 LB 分流到多个 Manager/Worker 节点
