微服务注册中心高可用核心是“挂了也不瘫痪”，需从架构设计（多节点集群跨az部署）、客户端容错（推空保护、本地缓存、合理超时）、数据一致性（nacos持久化mysql、eureka依赖自我保护、r-nacos强化wal）、监控告警与预案四方面协同实现。
微服务注册中心高可用部署，核心目标不是“永不宕机”，而是“挂了也不瘫痪”——即部分节点故障时，服务注册、发现、心跳续约等关键能力仍可持续，避免全链路雪崩。实现这一点，需从架构设计、部署策略、客户端容错、数据一致性四个层面协同发力。
多节点集群部署是基础
单点注册中心是最大风险源，必须淘汰。主流方案都要求至少3个节点起步： - Eureka：采用对等复制（peer-to-peer）模式，各节点互相注册。例如 peer1 指向 peer2 和 peer3，peer2 指向 peer1 和 peer3，形成环状同步网络。配置中通过eureka.client.serviceUrl.defaultZone 显式声明其他节点地址。
- Nacos / R-Nacos：基于 Raft 协议构建强一致集群（CP 模式），自动选举 Leader，写请求只由 Leader 处理，读请求可由任意节点响应。3 节点集群可容忍 1 个节点宕机；5 节点可容忍 2 个。
- Consul：同样使用 Raft，节点间通过 gossip 协议传播状态，支持多数据中心联邦。
- 部署时建议跨可用区（AZ），例如同一地域下选 3 个不同 AZ，避免机房级故障导致整体失联。
客户端必须具备本地容错能力
注册中心再稳，网络抖动或短暂不可达仍会发生。客户端不能“一空就崩”： - 开启推空保护（Push Empty Protection）：当注册中心返回空服务列表时，客户端不立即清空本地缓存，而是沿用上一次有效列表继续调用。Spring Cloud Nacos 中配置spring.cloud.nacos.discovery.namingPushEmptyProtection=true。
- 启用本地健康缓存：客户端在内存中持久化服务实例列表，并定期刷新。即使注册中心完全不可达数分钟，业务仍可基于缓存中的健康实例运行。
- 设置合理的心跳与超时参数：例如 Nacos 客户端默认心跳间隔 5 秒、服务剔除阈值 15 秒；Eureka 默认续约间隔 30 秒、失效时间 90 秒。生产环境可根据网络质量微调，避免误剔或延迟感知。
数据持久化与一致性保障
注册中心状态若仅存在内存中，重启即丢失，高可用无从谈起： - Nacos 必须对接 MySQL 等持久化存储，确保服务元数据和配置在集群重启后可恢复；开启集群模式后，Raft 日志也需落盘。 - Eureka 本身不持久化，依赖客户端自我保护+快速重注册机制弥补。因此更依赖客户端的健壮性与重试逻辑，不适合强一致性要求场景。 - R-Nacos 在 Rust 实现中强化了 Raft 日志可靠性与 WAL（Write-Ahead Log）机制，写入确认前强制刷盘，降低数据丢失风险。监控、告警与预案闭环
高可用不仅是技术部署，更是运维闭环： - 对每个注册中心节点监控三项核心指标：JVM 内存/CPU、Raft Leader 状态（是否频繁切换）、服务实例注册总数与健康率。 - 当某节点进入UNAVAILABLE 或 OUT_OF_SERVICE 状态时，自动触发告警并通知值班人。
- 预置降级预案：如注册中心集群整体异常，可临时启用 DNS 服务发现或静态配置兜底（需配合灰度开关控制）。
不复杂但容易忽略。
