注册中心宕机后服务还能互相调用吗？
简化版
注册中心宕机后，已经运行的服务通常还能继续互相调用，因为消费者会在本地缓存服务实例列表，业务请求不需要每次访问注册中心。但新实例注册、旧实例下线感知、服务列表更新和配置变更会受到影响。
因此注册中心故障时，系统能不能继续稳定运行，取决于客户端本地缓存、实例健康过滤、超时重试、熔断降级和注册中心恢复后的同步能力。
详细版
注册中心属于控制面，不应该在每次业务请求的数据面链路上。消费者启动后会从注册中心拉取或订阅服务列表，并保存在本地。注册中心短暂不可用时，消费者可以继续使用本地已有列表调用提供者。
但这并不代表没有影响。故障期间新增实例无法被发现，宕机实例可能无法及时摘除，下线实例可能继续存在于消费者缓存里，服务扩缩容和发布会受到影响。如果消费者没有健康检查和失败实例避让，就可能持续调用坏实例。
面试中要回答得有边界：已缓存的旧服务列表可以支撑存量调用，但服务发现的动态更新能力下降。注册中心恢复后，客户端要重新拉取全量列表或校验版本，避免长期使用过期缓存。
完整版教学
一、先区分控制面和数据面
注册中心负责控制面：服务注册、实例列表、健康状态、变更通知。业务服务之间真正的请求调用属于数据面。
正常情况下：
控制面：消费者 ↔ 注册中心，获取服务列表
数据面：消费者 → 提供者，直接发起业务请求注册中心宕机影响的是控制面，不应该直接切断所有数据面调用。如果设计成每次业务请求都查注册中心，那注册中心就会成为严重单点。
二、为什么已经运行的服务还能调用
消费者通常会缓存服务列表。比如消费者之前已经知道 order-service 有三个实例，那么注册中心短暂不可用时，它仍然可以从本地缓存中选择实例调用。
这也是服务发现客户端必须做本地缓存的原因。没有本地缓存，注册中心一抖动，所有消费者都无法找到服务，故障会被放大。
本地缓存通常保存在内存里，有些客户端还会保存磁盘缓存，便于重启后兜底。
三、注册中心宕机会影响哪些能力
影响主要体现在动态变化上：
- 新实例注册不上，扩容容量不能被消费者发现。
- 宕机实例无法及时摘除，消费者可能继续调用坏地址。
- 正常下线实例无法及时通知消费者，发布风险上升。
- 服务元数据变更无法传播，比如权重、版本、灰度标签。
- 新启动消费者可能无法拉取初始服务列表。
所以注册中心故障不是立刻让所有调用失败，而是让服务发现逐渐变“陈旧”。时间越长，风险越高。
四、客户端需要哪些容错能力
客户端不能只依赖注册中心剔除坏实例。注册中心故障期间，客户端更要靠自身容错。
关键能力包括：
- 请求超时：避免卡在坏实例上。
- 失败重试：换其他实例尝试。
- 熔断降级：下游整体异常时快速失败。
- 失败实例临时剔除：本地避让连续失败的实例。
- 本地缓存过期策略：缓存不能无限期盲目信任。
- 后台重连：注册中心恢复后尽快同步。
这些能力共同决定注册中心故障时系统能撑多久、撑得多稳。
五、新服务启动是薄弱点
已经运行的服务有本地缓存，新启动的服务可能没有。如果注册中心宕机时启动一个新消费者，它可能拿不到任何服务列表。
解决方式包括：
- 使用磁盘缓存保存上次服务列表。
- 发布系统在注册中心异常时暂停大规模发布。
- 核心服务保留静态兜底地址，但要谨慎维护。
- 注册中心多节点和跨机房部署，降低完全不可用概率。
发布和扩缩容通常最依赖注册中心，所以故障期间应避免继续做大规模变更。
六、注册中心恢复后要做全量校验
注册中心恢复后，客户端不能只等下一次增量通知。因为故障期间可能丢失了很多实例变化。
更稳妥的做法是重新拉取全量服务列表，或者用版本号、时间戳、摘要校验本地缓存和服务端状态是否一致。发现不一致后，更新本地缓存。
恢复阶段也要注意流量冲击。大量客户端同时重连注册中心可能造成二次冲击，因此重连和全量拉取要加入退避和随机抖动。
七、面试回答建议
回答这道题可以这样说：注册中心宕机后，存量服务一般还能基于本地缓存继续调用，但新注册、下线感知、列表更新会受影响；客户端必须有缓存、超时、重试、熔断和失败实例避让；注册中心恢复后要全量同步。
这比简单说“能”或“不能”更准确。分布式系统里的答案通常要带边界条件。
八、常见追问和落地边界
面试官经常会追问注册中心故障能撑多久。这个没有固定时间，取决于服务实例变化频率、本地缓存新鲜度、调用方容错能力和业务发布动作。如果故障期间没有实例变化，可能撑很久；如果正在大规模发布或扩缩容，风险会快速升高。
另一个落地建议是注册中心异常时暂停发布。因为发布会制造实例上下线，而注册中心正好负责传播这些变化。故障期间继续滚动发布，可能让消费者缓存和真实实例状态偏差越来越大。
还要区分注册中心部分故障和完全故障。部分节点故障时，客户端可以切换到其他注册中心节点；网络分区时，某些机房可能只能看到本地旧数据；完全故障时，所有动态更新都停止。不同故障级别下，系统表现不同，排查时要看客户端连接的是哪个注册中心节点、最后一次刷新时间和当前本地实例列表。
九、常见误区与追问
这道题要紧扣「注册中心故障容错」本身回答，不能把它混成泛泛的服务注册与发现套话。面试官通常会沿着“为什么需要、流程怎么走、失败怎么兜、代价是什么”继续追问，所以回答要覆盖注册、心跳、健康检查、实例缓存、路由选择和注册中心故障兜底。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 注册中心故障时调用链不应立刻中断，客户端要依赖本地缓存、已有连接、降级策略和恢复同步 | 不要停在名词解释 |
| 流程机制 | 注册中心异常 -> 客户端读取本地缓存 -> 继续按旧列表调用 -> 失败实例本地剔除 -> 后台重连注册中心 -> 恢复后刷新全量列表 | 要说清触发点、状态变化、确认点和失败兜底 |
| 工程取舍 | 注册中心不可用 5 分钟，如果服务实例本身还正常，消费者应继续用最后一次成功拉取的实例列表 | 服务发现降低地址治理成本，但会引入缓存陈旧、摘除延迟、注册中心可用性和客户端行为一致性问题 |
注册中心故障容错 面试拆解：
1. 注册中心异常
2. 客户端读取本地缓存
3. 继续按旧列表调用
4. 失败实例本地剔除
5. 后台重连注册中心
6. 恢复后刷新全量列表记忆钩子：先给结论，再拆流程，再讲数字例子和失败边界；回答「注册中心故障容错」时要围绕题目问法收束，不要把相邻概念堆成一段没有重点的名词清单。
- 误区：注册中心挂了服务调用一定全挂。 成熟客户端会缓存实例列表，短时间内可继续调用已有服务。
- 误区：缓存实例列表没有风险。 缓存会变旧，可能调用已下线实例，所以要配合失败剔除和重试。
- 误区：注册中心只要单节点够用。 注册中心是关键依赖，服务端也要集群和故障演练。
- 追问：缓存多久合适？ 要结合实例变更频率和故障容忍度，不能无限相信旧列表。
- 追问：注册中心恢复后做什么？ 全量刷新、对比版本、清理无效实例，并观察错误率。
- 追问：如何避免启动依赖注册中心？ 允许读取本地快照启动，后台异步连接注册中心。
十、加强记忆
注册中心像通讯录服务器。服务器挂了，手机里已有通讯录还能打电话；但新号码拿不到，坏号码删不掉，通讯录越来越旧。
所以答案是：短时间能靠缓存撑住，长时间要看容错和恢复同步能力。