微服务架构中，服务发现机制的核心作用是让服务之间能够自动识别和通信，而不需要硬编码地址。随着服务实例频繁地创建、销毁或迁移，手动维护地址列表不可行，服务发现解决了这一动态寻址问题。
服务注册与注册中心
每个微服务启动后，会主动向一个集中化的注册中心（如Eureka、Consul、ZooKeeper或Nacos）注册自己的网络信息，包括IP地址、端口、服务名称和健康状态。这个过程称为服务注册。注册中心持续维护一份所有可用服务实例的清单。
服务实例通常通过心跳机制定期向注册中心发送存活信号。如果注册中心在一定时间内未收到心跳，就会将该实例从服务列表中移除，确保调用方不会路由到已下线的服务。
服务查询与负载均衡
当一个服务需要调用另一个服务时，它会向注册中心发起服务查询，获取目标服务的可用实例列表。客户端可以根据策略（如轮询、随机或权重）选择一个实例进行调用。
这个过程常与客户端负载均衡结合使用。例如，Netflix Ribbon 可以在本地缓存服务列表，并完成负载决策，减少每次调用都查询注册中心的压力。
两种模式：客户端发现 vs 服务端发现
常见的服务发现实现分为两类： 客户端发现：调用方直接从注册中心获取目标服务地址，并自行选择实例。优点是灵活高效，缺点是逻辑耦合到客户端。 服务端发现：请求先到达负载均衡器或网关（如API Gateway），由它查询注册中心并转发请求。客户端无感知，但引入了中间节点，可能成为瓶颈。实际工作流程示例
假设订单服务要调用用户服务：
用户服务启动，向Nacos注册自己（IP: 192.168.1.10, 端口: 8080）。 订单服务从Nacos获取“用户服务”的实例列表。 订单服务选择其中一个实例，发起HTTP调用。 用户服务实例宕机，未发送心跳，Nacos将其剔除，后续请求不再路由过去。基本上就这些。服务发现让微服务系统具备弹性与可扩展性，是实现动态部署和自动化运维的关键环节。
