家里装了三台智能音箱，手机App却总连错设备；公司新上线一个后台系统，开发小哥改了五次配置才让前端调通接口——这些事儿，背后都藏着一个词：服务发现。
服务发现不是玄学，是“找人”的自动化
想象一下：你搬进新小区，想约邻居一起修WiFi，但不知道谁家网速快、谁家路由器支持Mesh。如果挨家挨户敲门问，效率低还尴尬；要是物业提前建了个微信群，大家一进群就自动看到彼此昵称和设备类型，事情就简单多了。服务发现干的就是这个活——它让程序自动知道“谁在线、在哪、能干啥”。
常见方案，其实就三类路子
1. DNS方式：最省心，像查电话簿
比如用 order-service.prod.local 这种域名代替IP+端口。Kubernetes里默认就走这条路，部署完服务，DNS自动更新记录。适合中小团队，不用额外装组件，但刷新延迟可能几秒到几十秒，不适合秒级扩缩容的场景。
2. 客户端集成：自己动手，丰衣足食
Spring Cloud Eureka、Nacos客户端SDK就是典型。你的Java服务启动时，主动向注册中心“报到”；调用方拉取列表后缓存本地，直接发请求。好处是响应快、控制细，缺点是每个服务都要加依赖、写配置，Python/Go项目接入得单独折腾。
3. 代理模式：中间人帮忙转发
Consul + Envoy 或者 Kubernetes 的 Service Mesh（如Istio）属于这类。所有流量先过代理，它根据实时健康检查结果决定转发到哪台实例。运维统一管，业务代码零侵入，但多一层网络跳转，排查问题要盯日志链路。
选哪个？先摸清自家“底牌”
刚起步的小网站，用云厂商自带的SLB+DNS就够了，比如阿里云的PrivateZone配上内网SLB，点点鼠标就通；做微服务改造的中型团队，Nacos中文文档全、控制台友好，还能当配置中心用，上手门槛比Eureka低；要是已经上了K8s，别折腾注册中心了，Service + Headless Service + CoreDNS 原生组合，稳定又轻量。
有次帮朋友迁老系统，他非要用ZooKeeper，结果运维不会调参，集群脑裂三次，最后换成Nacos，两天搞定。技术没有高低，只有合不合适。
spring:
cloud:
nacos:
discovery:
server-addr: 192.168.1.100:8848
namespace: dev-env记住一点：服务发现不是越复杂越好，能让开发少改一行代码、运维少盯一个告警，就是好选择。