微服务服务发现面试题：注册中心、本地缓存、健康检查与上下线
本页只放面试标准回答和原理跳转。完整注册、订阅、本地缓存、优雅上下线、旧实例排查和 Demo 见服务发现主线。
高频问题
| 问题 | 标准回答 | 原理页 |
|---|---|---|
| 注册中心到底做什么 | 注册中心属于控制面，维护服务名到实例列表的映射，包括IP、端口、健康状态、权重、区域和版本metadata。它不转发每次业务请求，调用方通常拿到本地实例快照后由LoadBalancer选择实例并直连目标。 | 心智模型、控制面和数据面 |
| 为什么调用方不每次都查注册中心 | 每次实时查询会让注册中心进入业务请求链路，增加延迟并形成瓶颈。本地缓存能提高性能、降低注册中心压力，并在注册中心短暂不可用时继续使用已有快照。代价是实例列表会短暂陈旧。 | 本地快照 |
| 调用方每次请求都会更新本地实例快照吗 | 不会。每次业务请求通常只是读取当前快照并交给LoadBalancer选址；快照刷新由后台服务发现客户端负责，例如Nacos订阅推送、Eureka定期拉取、Consul Blocking Query、K8s EndpointSlice Watch或Mesh xDS推送。这样避免注册中心进入每次请求链路，但会有短暂陈旧窗口。 | 是否每次更新快照 |
| 怎么保证每次请求都是最新可用的 | 严格不能保证每次请求都拿到全局最新且绝对可用的实例，因为注册传播、客户端缓存、LB选址和连接池排空都是异步的，实例被选中后也可能立刻故障。工程上保证“当前视角下尽量可用”：读本地最新快照，按健康、权重、版本、机房和灰度过滤，连接失败或读请求超时在Deadline和重试预算内换实例；写请求必须有幂等键和事实查询。 | 每次请求尽量可用 |
| 本地服务列表怎么保证最新 | 不能保证任意瞬间绝对最新，只能通过订阅推送、定期拉取、本地缓存过期、健康过滤、Readiness摘流、优雅下线和连接池回收让它尽快收敛。注册中心更新、客户端替换快照和连接排空都是异步过程。 | 新鲜度边界 |
| 注册中心挂了服务还能调用吗 | 要分情况。运行中的调用方如果已有本地快照，且目标实例数据面可达，短时间可能继续调用；但新实例注册、故障摘除、规则变更、新消费者启动会受影响。本地缓存为空或全是坏实例时仍会失败。 | 控制面和数据面、本地快照 |
| 注册中心有实例为什么Feign仍无实例 | 控制台有实例只说明注册中心服务表存在。调用方可能连接了不同namespace/group/cluster，本地快照未刷新，实例不健康或权重0，灰度/zone过滤后为空，服务名大小写不一致，或者连接池仍复用旧地址。 | 调旧实例排查 |
| 服务下线后为什么还会被调用 | 下线存在传播窗口。Readiness变化、注册中心更新、消费者刷新本地快照、LoadBalancer停止选择、HTTP连接池释放旧连接和在途请求完成不是同一瞬间。生产必须做先摘流、等传播、等在途、再关闭进程。 | 优雅下线 |
| 心跳正常是否代表服务健康 | 不代表。心跳只能说明进程、连接或SDK还能向注册中心报告，不能证明Tomcat线程池、DB连接池、Redis、下游接口和核心业务都正常。健康治理要结合Readiness、业务探针、实例级P99、错误率和资源池。 | 心跳和健康 |
| Readiness和Liveness区别 | Readiness表示实例当前是否应该接新流量，失败后应摘流但不一定重启；Liveness表示进程是否需要重启。把非核心依赖都放进Liveness会导致依赖抖动时应用被反复重启。 | 健康模型 |
| Nacos、Eureka、Consul、K8s发现有什么区别 | Eureka典型是客户端定期拉取并偏AP；Nacos常用订阅推送加本地缓存；Consul可用Health API和Blocking Query；Kubernetes由EndpointSlice、DNS、kube-proxy/eBPF和连接共同生效。它们都存在传播窗口，证据和排查路径不同。 | 组件差异 |
| Nacos为什么可能返回不健康实例 | 可能和保护阈值、空列表保护、本地缓存或连接池窗口有关。保护机制为了避免健康误判导致所有实例被摘空，可能保留更宽候选或最后快照。它提高可用性，但不能保证每个实例健康，调用方仍要短超时、熔断、慢实例降权和幂等兜底。 | Nacos保护机制 |
| 如果调到了旧服务怎么办 | 先确认旧地址、旧版本、旧连接、旧配置还是旧规则；再用Trace查目标IP和版本，查注册中心事实、本地快照、LB过滤、连接池和灰度标签。只读请求可容忍短窗口；写请求不能重放到新版本，要按幂等号查询事实后补偿。 | 旧实例Runbook、处理策略 |
| 服务发现和负载均衡是什么关系 | 服务发现提供候选实例列表，负载均衡在候选列表上进行健康、版本、区域、权重过滤并选择一个实例。候选集错误时，再好的算法也没用；算法正确也不能解决连接池复用、长连接倾斜和旧快照窗口。 | 心智模型、负载均衡 |
| 灰度发布为什么依赖metadata | 灰度需要根据version、zone、weight、tenant等metadata过滤候选实例。Gateway负责生成可信灰度标签，Feign或RPC Filter透传标签，LoadBalancer按metadata选实例。metadata错误会导致灰度串流量或无实例。 | Metadata灰度 |
| 优雅下线怎么做 | 先把Readiness置为不可用或权重置0，等待注册中心、Endpoint和调用方缓存传播，再停止接收新请求并等待在途请求完成，然后关闭MQ消费者、定时任务、连接池和Web容器。K8s要配合preStop和terminationGracePeriod。 | 优雅下线 |
| 新实例Ready后为什么不能立即满流量 | Ready只说明基本检查通过，不代表JIT、缓存、连接池、类加载和业务依赖已经预热。立即满流量可能让新实例P99升高甚至被熔断。应低权重慢启动，观察错误率、P99和资源池后逐步加权。 | 慢启动 |
| 服务发现要监控哪些指标 | 看注册实例数、健康实例数、本地快照年龄、候选过滤结果、No instance次数、每实例QPS和P99、连接数和连接年龄、重试Attempt、注册中心推送延迟、Endpoint或xDS版本。 | 观测指标 |
场景题：注册中心控制台有库存服务，但订单服务报无实例
先确认订单服务和库存服务是否在同一namespace、group、cluster，服务名是否一致；再看库存实例健康状态、权重是否为0、metadata是否被灰度规则过滤；然后看订单服务本地快照是否刷新、LoadBalancer候选列表是否为空。不能只看控制台有实例就认为发现链路没问题。
场景题：服务下线后仍有请求打进来
这是典型传播窗口问题。下线应先Readiness失败或权重置0，让新请求不再进入；等待注册中心和调用方缓存刷新，再等待在途请求完成，最后关闭进程。若仍有请求，检查HTTP/2或Keep-Alive连接复用、Gateway缓存、K8s EndpointSlice传播、preStop时长和客户端重试。
项目回答模板
我们把注册中心当控制面，不让它转发业务请求。服务启动后注册IP、端口、版本、区域和权重，消费者订阅服务并维护本地不可变快照；调用时LoadBalancer按健康、版本、zone和权重过滤候选，再由HTTP Client发请求。上线时低权重慢启动，下线时先Readiness摘流、等缓存传播和连接排空，再停消费者和进程。若调到旧实例，用Trace、注册中心事实、本地快照、连接池和灰度标签逐层定位；写请求用幂等号查询事实后补偿。
本章小结
服务发现面试不能只说“注册到Nacos，然后Feign调用”。要讲清控制面和数据面、本地缓存为什么存在、为什么不能瞬时最新、调到旧服务怎么排查，以及优雅上下线怎样把风险收住。