服务发现机制的核心是动态获取服务实例地址，服务端负责注册与心跳上报，客户端负责拉取、缓存、负载均衡和故障剔除；nacos、eureka、consul、zookeeper 各具特性，框架通过 resttemplate、feign 或 dubbo 封装实现透明调用。
Java 微服务中，服务发现机制的核心是让服务消费者（客户端）能动态获取服务提供者（服务端）的实例地址，避免硬编码 IP 和端口。它通常由注册中心统一协调，客户端和服务端各自承担不同职责：服务端负责注册与心跳上报，客户端负责拉取、缓存、负载均衡和故障剔除。
服务端：向注册中心注册自身并维持健康状态
服务端启动时需将自身元数据（如服务名、IP、端口、健康检查路径、标签等）注册到注册中心，并周期性发送心跳以表明存活。常见实现方式：
- 使用 Spring Cloud Alibaba Nacos：添加
nacos-discovery依赖，在application.yml中配置spring.cloud.nacos.discovery.server-addr，启动类加@EnableDiscoveryClient即可自动注册 - 使用 Spring Cloud Netflix Eureka（已停更但仍有项目在用）：引入
spring-cloud-starter-netflix-eureka-client，配置eureka.client.service-url.defaultZone，同样通过注解自动完成注册与心跳 - 自定义注册逻辑（如直连 Consul）：通过 Consul SDK 调用
/v1/agent/service/register接口注册，配合 TTL 健康检查维持服务有效性
客户端：从注册中心获取服务列表并发起调用
客户端不直接调用固定地址，而是通过服务名查到可用实例列表，再结合负载均衡策略选择目标节点。关键环节包括：
- 初始化时主动拉取全量服务实例，并监听变更（如 Nacos 的
subscribe或 Eureka 的增量更新） - 本地缓存服务列表，降低注册中心压力；支持缓存刷新策略（定时轮询或事件驱动）
- 集成负载均衡器（如 Spring Cloud LoadBalancer 或 Ribbon）：根据策略（轮询、权重、响应时间）从实例列表选一个发起 HTTP 或 RPC 调用
- 调用失败时触发重试或熔断，并将异常实例临时踢出本地缓存（如标记为“疑似下线”，避免短时间反复调用故障节点）
注册中心选型与关键能力对比
不同注册中心对客户端/服务端行为支持程度不同，选型需关注以下能力：
- Nacos：支持 AP+CP 模式切换，内置健康检查（TCP/HTTP/MySQL），控制台友好，Java 生态集成度高
- Eureka：纯 AP 架构，自我保护模式防止网络分区误删实例，但不支持主动健康检查，已停止维护
- Consul：基于 Raft 实现 CP，支持多数据中心和服务网格集成，需额外部署 agent，配置略复杂
- ZooKeeper：强一致性，适合对一致性要求极高的场景，但运维成本高，临时节点 + Watch 机制需客户端自行处理较多细节
客户端透明调用的关键：声明式服务调用封装
实际开发中，开发者不手动查服务、选实例、拼 URL。框架通过抽象屏蔽底层逻辑：
- 使用
@LoadBalanced RestTemplate：Spring Cloud 自动为其添加拦截器，在发起请求前解析服务名、查询实例、替换为真实 URL - 使用 OpenFeign：接口上加
@FeignClient("user-service")，编译期生成代理，运行时完成服务发现 + 负载均衡 + 熔断（集成 Sentinel 或 Resilience4j） - RPC 场景（如 Dubbo）：通过
registry://协议连接注册中心，Consumer 启动时订阅 provider 列表，Provider 变更通过 ZooKeeper/Redis/Nacos 的事件通知实时同步
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
