S17-B02 · 服务注册与发现

适用读者：配过 Eureka/Nacos 但说不清"它到底存了什么"的人。
前置：S17-B01。
覆盖旧文：557(612) 917(77) 2410(326) 916(79) = 1,094 点。
覆盖扩展：E-S17-003（AP vs CP 注册中心）。
上一篇：S17-B01 · 微服务是什么、带来哪些挑战
下一篇：S17-B03 · 服务调用。

1. 一句话结论

注册中心只是一张"服务名 → 实例列表"的表，加上一套"心跳/健康检查"来维护它。选型的核心是"网络分区时，你要可用还是要一致"。

服务名: user-service
  ├── 10.0.0.5:8080  (健康)
  └── 10.0.0.7:8080  (健康)

2. 三个动作

动作	谁做	说明
注册	服务实例	启动时写入自己的地址
心跳/续约	服务实例	定期证明"我还活着"
拉取/订阅	调用方	拿地址列表并缓存

"为什么调用方要缓存"：每次调用都查注册中心会把它变成瓶颈与单点——所以客户端缓存 + 变更推送（长轮询/订阅）。

3. AP 还是 CP（E-S17-003）

系统	一致性取向	分区时行为
Eureka	AP	保留旧列表（可能调到已死实例）
Nacos	可配（AP/CP）	按配置
ZooKeeper	CP	少数派不可用（拒绝写入）

判据："注册中心暂时不可用时，业务要继续跑还是要停？" 继续跑 → AP（Eureka/Nacos AP）；宁可停也不能拿到错数据 → CP（ZK）。

"调到已死实例怎么办"：靠客户端重试 + 熔断（A01）兜底——这就是 AP 的代价与配套。

4. 健康检查的两种机制

机制	说明
客户端心跳	实例主动上报（Eureka）
服务端探测	注册中心主动探（Nacos 临时/持久实例）

"心跳多久、剔除多久"：太短 → 网络抖动误剔除；太长 → 死实例残留。经验：心跳 5–10s，剔除 3 次失败。

5. 与 DNS/负载均衡的关系

层	作用
注册中心	服务级发现（含元数据/权重）
DNS	主机级解析
负载均衡器（Nginx/LB）	流量分发

"有了 K8s Service 还需要注册中心吗"：K8s 内可用 Service/DNS；跨集群/非 K8s 环境才需要独立注册中心。

6. 五个误区

误区	真相
"注册中心挂了服务就不可用"	客户端有缓存（AP 系）
"Eureka 比 Nacos 好/差"	取舍不同（AP vs 可配）
"ZooKeeper 适合做注册中心"	CP 系，分区时可能拒服务
"心跳越频繁越好"	增加负担且易误判
"有 K8s 就不需要注册中心"	取决于是否跨集群

7. 自检

注册中心的三个动作？
为什么客户端要缓存地址列表？
AP 与 CP 注册中心的取舍？
心跳与剔除时间的权衡？
K8s Service 能替代注册中心吗？

8. 下一篇

S17-B03 · 服务调用：RPC、负载均衡与 Dubbo

发现讲完，下一篇讲"拿到地址之后怎么调"：代理、序列化、负载均衡。

本篇属于系列《S17 · 分布式与消息队列》。旧文来源：A-557/917/2410/916；扩展点 E-S17-003。