注册中心宕机了，服务之间还能正常调用吗？

简化版

大多数情况下能继续调用——因为服务消费者会把从注册中心获取的服务地址列表缓存在本地内存。注册中心宕机后，消费者用本地缓存的地址依然能找到提供者、正常发起调用，只是无法感知新的变化（新实例上线发现不了、下线的实例不能及时剔除）。这是一种优雅降级设计：注册中心不在关键调用链路上，它挂了只影响「服务列表的更新」，不影响「已缓存地址的调用」。所以注册中心宕机不是灾难，服务能扛一段时间，前提是消费者实现了本地缓存（Nacos、Eureka、Dubbo 都有）。

详细版

为什么能继续调用：

正常时：Consumer 从注册中心拉取地址 → 缓存到本地 → 调用 Provider
                                          ↑ 直连，注册中心不参与实际调用

注册中心宕机后：
  Consumer 用【本地缓存的地址】 → 继续直连调用 Provider ✓（正常）
  但：新 Provider 上线 → 注册不了 → Consumer 发现不了 ✗
      Provider 下线 → 列表不更新 → Consumer 可能调到死实例（靠客户端容错重试兜底）

关键点：

注册中心不在数据调用链路上：它只负责「告诉消费者地址」，实际调用是消费者直连提供者。
本地缓存：消费者缓存服务列表，注册中心挂了仍可用。
影响的是「变化感知」：无法注册新实例、无法及时剔除死实例。
配合客户端容错：调用失败重试其他实例，减轻「调到死实例」的影响。

完整版教学

一、关键认知：注册中心不在调用链路上

很多人以为「注册中心挂了，服务就调不通了」——这是误解。要理解为什么能继续调用，先搞清楚注册中心在整个调用中扮演什么角色：

注册中心只做一件事：告诉消费者「你要调的服务，有哪些实例、地址是什么」。
消费者拿到地址后，是直接连接提供者发起调用的——实际的请求数据不经过注册中心。

换句话说，注册中心是**「问路的」，不是「送信的」。你问过一次路、记住了地址，之后就算问路的人不在了，你照样能按记住的地址走过去。所以注册中心不在关键的数据调用链路**上，它的宕机不会直接切断服务间的调用。

二、本地缓存：消费者的”记事本”

消费者能在注册中心宕机后继续调用，关键在于本地缓存：

消费者从注册中心拉取到服务的实例地址列表后，会把这份列表缓存在本地内存（有的还会持久化到本地磁盘文件，重启也不丢）。
之后每次调用，消费者优先用本地缓存的地址，而不是每次都去问注册中心。
所以注册中心宕机时，消费者手里还有一份「地址记事本」，照样能找到提供者调用。

主流框架都实现了本地缓存：

Nacos：客户端缓存服务列表，还会写本地快照文件（failover 目录），Nacos 挂了用缓存/快照。
Eureka：Consumer 本地缓存注册表。
Dubbo：会把注册信息缓存到本地磁盘文件，注册中心不可用时从缓存加载。

三、宕机期间的影响：无法感知”变化”

注册中心宕机不影响「用已有地址调用」，但会影响「感知服务列表的变化」：

新实例上线，发现不了：这期间如果提供者扩容、上了新实例，因为注册不进去（注册中心挂了），消费者的缓存里没有这些新地址，用不上新实例（新实例白白闲置）。
实例下线，剔除不及时：如果某个提供者实例宕机了，注册中心挂着没法更新列表，消费者缓存里还留着这个死实例的地址，可能会调用到它导致失败。

所以宕机期间是「吃老本」——用宕机前那一刻的服务列表快照运行，新变化都感知不到。只要注册中心宕机时间不长、服务拓扑相对稳定，影响就不大。

四、如何降低”调到死实例”的影响：客户端容错

宕机期间最实际的风险是「缓存里有死实例，调用它会失败」。这靠客户端容错机制兜底：

失败重试（Failover）：调用某个实例失败后，自动重试列表里的其他实例。所以即使碰到一个死实例，重试到健康实例即可成功。
实例剔除/熔断：客户端负载均衡器可以临时标记调用失败的实例为不可用，暂时不再选它（本地的健康感知）。
超时控制：设置合理超时，避免卡在死实例上太久。

有了这些客户端容错，即使缓存里混入个别死实例，实际调用的成功率仍能保证。

五、这体现的设计思想：注册中心 AP + 优雅降级

这个「注册中心挂了服务还能调」的特性，体现了两个设计思想：

注册中心倾向 AP、且不在关键链路：注册中心的作用被有意设计成「非关键路径」——它挂了只影响服务发现的更新，不影响已有调用。这是为什么注册中心宕机不是灾难。
本地缓存做优雅降级：把注册中心的数据缓存在消费者本地，注册中心成了「锦上添花」而非「命根子」。这是分布式系统「依赖不可用时优雅降级」的典型实践。

当然，注册中心宕机仍是要尽快恢复的（否则新扩容用不上、死实例剔除不掉，时间长了会积累问题），所以注册中心自身也要集群部署做高可用。本地缓存是「注册中心短时不可用」的缓冲，不是让注册中心可以随便挂。

六、常见误区与追问

这道题面试时最容易丢分的地方，是把「注册中心宕机后服务是否还能调用」答成一段泛泛的组件介绍。更稳的答法是先给结论，再沿着服务注册与发现链路拆清楚流程，最后补上异常场景、数字边界和选型取舍。

回答层次	要讲清的内容	容易漏掉的边界
核心定义	已有消费者通常还能靠本地缓存继续调用，新的注册、发现和变更通知会受影响	不要停在名词解释
流程机制	消费者启动时拉取服务列表 -> 本地保存实例缓存 -> 注册中心宕机 -> 消费者继续用缓存调用 -> 缓存过期或实例变化无法及时感知	说明谁触发、谁存储、谁通知、谁兜底
工程取舍	例如客户端已缓存 3 个 order-service 实例，即使注册中心短暂宕机，也能继续按缓存列表发起调用	注册信息不是业务数据，短暂不一致通常靠客户端缓存、重试和健康检查兜底

注册中心宕机后服务是否还能调用 面试拆解：
1. 消费者启动时拉取服务列表
2. 本地保存实例缓存
3. 注册中心宕机
4. 消费者继续用缓存调用
5. 缓存过期或实例变化无法及时感知

记忆钩子：先区分注册、发现、心跳、剔除和本地缓存，再说明一致性与可用性的取舍；回答时一定要落到题目中的「注册中心宕机后服务是否还能调用」，不要把相邻中间件的能力混着讲。

误区：注册中心一挂业务调用一定全挂。 成熟客户端会缓存服务列表，已有服务之间通常还能继续调用。
误区：本地缓存可以完全替代注册中心。 缓存只能兜底，无法处理新实例注册、下线通知和长期拓扑变化。
误区：注册中心恢复后不需要处理。 客户端要重新拉取或接收推送，校准本地缓存，避免长期使用旧列表。
追问：哪些能力会受影响？ 新服务注册、服务发现、实例变更推送、健康状态更新都会受影响。
追问：为什么 Eureka 强调客户端缓存？ 它偏 AP 设计，希望注册中心不可用时调用链路仍尽量不断。
追问：怎么提高注册中心容灾能力？ 部署集群、多机房、客户端缓存、合理缓存过期和调用失败重试。

七、加强记忆

注册中心宕机，服务大多仍能正常调用——因为注册中心不在数据调用链路上（它只「告诉地址」，实际调用是消费者直连提供者），且消费者把服务地址缓存在本地内存/磁盘快照（Nacos、Eureka、Dubbo 都有），宕机后用缓存的地址继续调。影响的是**「变化感知」：新实例注册不了/发现不了、死实例剔除不及时（靠客户端容错——失败重试其他实例兜底）。这是「注册中心 AP + 本地缓存优雅降级」的设计——注册中心是「问路的」不是「送信的」，挂了吃老本能扛一段。但仍需集群部署 + 尽快恢复**。口诀：注册中心不在调用链、本地缓存吃老本、挂了只是不能更新、客户端重试保成功。

简化版

详细版