为什么需要服务注册发现？
- 标签：Spring Cloud、后端、微服务
🏛 业务架构师
服务注册发现解决的是**"调用方如何找到健康的服务实例"**这个分布式系统的基本问题。
没有它时的业务痛点：
- 硬编码地址：扩容一台机器要改所有调用方配置并重启——弹性伸缩无从谈起；
- 故障实例摘除：某实例宕机，调用方还在往"尸体"上发请求——故障半径扩大；
- 环境管理混乱：dev/test/prod 地址各一套，配置地狱。
引入注册中心后的模型：服务启动时自注册（IP+端口+元数据），调用方按服务名查询实例列表，配合健康检查自动摘除故障节点，配合心跳/租约管理存活状态——流量始终流向"活着的、健康的"实例。
业务架构师视角，我强调两点2026 年的现实：
- 上 K8s 后要重新评估这个组件的必要性：K8s Service（+DNS +kube-proxy）本身就提供服务发现与负载均衡——Pod 前置的 Service 名就是稳定的调用地址，很多场景不再需要应用层注册中心。我做过"去 Nacos 注册、保留 Nacos 配置"的架构收敛：少一个组件、少一份 Raft 集群运维、少一类故障。保留应用层注册中心的理由通常剩两个：多语言非 K8s 环境、需要更丰富的元数据路由（灰度标签、同城优先）；
- 注册中心的可用性设计：它自身是关键依赖，Nacos 集群化 + 客户端本地缓存快照（注册中心全挂，服务间调用靠缓存仍可运行）——评估"注册中心宕机时业务能不能跑"是架构评审必答题。
一句话：注册发现服务于弹性与自愈，但实现方式要跟随基础设施演进，不为"标准答案"多养组件。
🏗 系统架构师
根本原因：微服务的调用拓扑是动态的——实例随弹性伸缩增减、随发布滚动替换、随故障宕机移除。任何静态配置（Nginx upstream 写死 IP）都跟不上这个变化速度。
机制：提供方启动注册（IP、端口、元数据），心跳维持在线；消费方拉取实例列表（本地缓存加订阅变更），配合客户端负载均衡选实例调用。
三层演进（架构视角）：
- 应用层注册发现（Nacos/Eureka）：灵活跨环境，但引入额外基础设施；
- K8s 原生（Service/DNS 加 kube-proxy）：全量在 K8s 内时，平台已提供发现与负载均衡——我优先用平台能力，Nacos 只服务跨集群与混合部署场景；
- 服务网格：发现与 LB 下沉 sidecar，应用零感知。
可用性设计（关键认知）：注册中心自身按 AP 设计，加客户端缓存兜底——中心短暂不可用时，消费者用缓存列表照常调用，宁可偶发调用到已下线实例（重试熔断兜底），也不要注册中心故障导致整体瘫痪。这个「降级可用」的权衡是注册中心的架构精髓。
💻 全栈开发专家
本质问题：调用方不知道目标服务实例此刻在哪、谁活着。
静态配置（写死 IP 列表）在云原生时代破产：K8s 里 Pod 是"牛不是宠物"——发布替换 IP、扩缩容 IP 变、故障实例要摘除，静态列表意味着每次变更人工同步，必然出错（半夜扩容忘加 IP，流量打到不存在的实例上 502）。
注册发现给三件事：
- 注册：实例启动上报 IP:port + 元数据（版本、权重、标签）到注册中心
- 发现：调用方按服务名拉实例列表（本地缓存 + 定时刷新/推送），配合负载均衡完成"服务名 → 可用实例"的运行时寻址
- 健康摘除：Nacos 临时实例 5s 心跳、15s 未达标记不健康、30s 剔除；优雅停机先反注册再杀进程
这是微服务弹性伸缩的地基。工程现状：K8s 体系里部分能力下沉给基础设施——Service/DNS 就是注册发现，Spring Cloud Kubernetes 直接用它；但跨集群、多语言、要权重/灰度路由时，Nacos 这类应用层注册中心仍是主流。
排查"服务找不到"三板斧：Nacos 控制台看实例是否注册、调用方本地缓存是否刷新（NacosDiscoveryClient 日志）、心跳端口网络策略是否放行。