高可用镜像仓库需解耦存储、分离服务、多实例负载、统一状态管理：存储用共享分布式系统，服务层多harbor实例+反向代理，数据库/redis/notary均需冗余，客户端配置多地址与重试机制。
要防止单点故障导致镜像仓库停服，核心思路是解耦存储、分离服务、多实例负载、统一状态管理。高可用不是简单起多个Registry容器，而是让关键组件（镜像存储、元数据、认证、前端访问）各自具备冗余能力。
一、存储层必须独立且高可用
镜像数据不能存在单台机器的本地目录里，否则节点宕机即丢失数据。 - 推荐使用分布式文件系统：CephFS、NFS HA集群、或云厂商提供的共享存储（如AWS EBS with Multi-Attach、阿里云NAS高可用版） - Harbor部署时，将`/data`挂载点指向共享存储路径，所有Harbor实例读写同一份镜像数据 - 避免用Docker Registry原生的本地文件存储模式（`filesystem` driver），它天生不支持多写二、服务层部署多实例+反向代理
Registry或Harbor本身无状态（除部分缓存），可横向扩展： - 启动≥2个Harbor实例（core + portal + jobservice等容器组），运行在不同物理机或可用区 - 前置Nginx或HAProxy做七层负载均衡，健康检查端点设为`/api/v2.0/ping`（Harbor）或`/v2/`（Registry） - 所有实例共用同一个外部数据库（PostgreSQL/MySQL主从）和Redis（用于会话与任务队列）三、关键依赖组件也要高可用
Harbor依赖的后端服务若单点，整个仓库仍会瘫痪： - 数据库：用主从复制+自动故障转移（如Patroni + PostgreSQL，或MySQL Group Replication） - Redis：启用Redis Sentinel或Redis Cluster，避免jobservice任务丢失、登录会话失效 - Notary签名服务（如启用）：同样需多实例+共享MySQL存储，并通过负载均衡暴露4443端口四、客户端配置容错与自动回退
即使服务端高可用，客户端也要减少对单一入口的强依赖： - 在`/etc/docker/daemon.json`中配置多个`insecure-registries`（仅测试环境）或多个`registry-mirrors`（生产建议用HTTPS） - 使用DNS轮询（如`harbor.example.com`解析为多个VIP）配合keepalived实现VIP漂移 - CI/CD脚本中加入重试逻辑：`docker push`失败后延迟重试，或切换备用仓库地址不复杂但容易忽略。
