高可用 Docker 镜像仓库需多节点 Registry/Harbor 实例 + 共享存储（S3/Ceph）+ L4/L7 负载均衡（Nginx/HAProxy）+ 高可用 PostgreSQL/Redis 集群，配合健康检查、会话保持与监控闭环。
实现 Docker 镜像仓库的高可用与负载均衡，核心是打破单点依赖，让服务不因一台机器宕机或网络中断而瘫痪。关键不在堆机器，而在组件解耦、流量可控、数据可靠。
选对架构模式：多节点 + 共享存储 + 负载均衡
单节点 Registry 或 Harbor 本质是“脆弱单点”，生产环境必须升级为集群架构。典型组合是：
- 多个 Registry 或 Harbor 应用实例（至少 2 台，推荐 3 台起）
- 统一后端存储（如 Ceph、S3、NFS），所有实例读写同一份镜像数据
- 前置 L4/L7 负载均衡器（如 HAProxy 或 Nginx），负责分发请求并做健康检查
- 独立高可用数据库（PostgreSQL 集群）和缓存（Redis 集群），支撑 Harbor 的元数据服务
配置负载均衡器：不只是轮询，更要懂健康状态
单纯把请求平均打到各节点不够——得让负载均衡器“会判断”。例如用 Nginx 做反向代理时：
- 启用
/v2/_catalog接口探活，每 5 秒检测一次 Registry 是否可响应 - 使用
least_conn策略，优先转发给当前连接数最少的节点 - 配置
max_fails=3 fail_timeout=30s，连续失败 3 次就暂时剔除节点 - 加
sticky cookie或基于 IP 的会话保持，避免 manifest 请求被分散到不同节点导致校验失败
保障数据层不拖后腿：存储与元数据都要冗余
应用层再冗余，如果镜像文件只存在某台机器的硬盘上，还是白搭。重点在两层：
- 镜像存储：禁用本地目录挂载，改用对象存储（S3/Ceph）或分布式文件系统（GlusterFS）。Harbor 官方推荐 S3，Registry 原生支持 S3 后端
- 元数据存储：Harbor 的 PostgreSQL 和 Redis 必须部署集群。PostgreSQL 用 Patroni 实现自动故障转移，Redis 用哨兵或 Cluster 模式，避免用户权限、项目配置等信息丢失
进阶要点：动态扩缩容与监控闭环
高可用不是静态部署完就结束，而是持续运行中的自我调节：
- 接入 Prometheus + Grafana，监控各节点 QPS、延迟、错误率、磁盘 IOPS、连接数
- 设定自动扩容阈值：当集群整体 QPS > 80% 容量，或错误率持续超 0.5%，触发新增 Registry 实例
- 缩容需谨慎：只有在低负载（
- 搭配 Harbor 的镜像复制功能，跨机房部署主从仓库，实现地域级容灾
