Java服务发现机制解析与SPI原理详解

Java服务发现分两类：SPI用于JVM内接口实现加载，依赖META-INF/services配置；微服务发现如Eureka用于跨网络实例寻址，依赖注册中心动态管理。

Java里的服务发现机制，核心分两类：一类是本地类路径级的服务发现（即SPI），用于框架扩展与接口实现解耦；另一类是分布式系统级的服务发现（如Eureka、Consul），用于微服务间动态定位实例。两者目标相似——“找到可用的实现”，但作用域、触发时机和实现方式完全不同。

Java SPI：运行时从classpath自动加载接口实现

SPI不依赖网络或中心化注册中心，它靠约定目录结构和配置文件完成服务发现。

• 在项目 classpath 下的 META-INF/services/ 目录中，创建一个以接口全限定名为名的文本文件（如 com.example.Log）
• 该文件内逐行写入一个或多个实现类的全限定名（如 com.example.Logback、com.example.Log4j）
• 使用 ServiceLoader.load(YourInterface.class) 加载，JVM 自动扫描所有 jar 包中的对应配置文件，反射实例化所有声明的实现类
• 支持多实现共存，可遍历调用，也可按需选择（例如根据配置开关决定启用哪个日志实现）

微服务注册发现：运行时从中心化注册中心获取服务地址

这是面向分布式部署的服务发现，解决的是“服务A怎么知道服务B现在在哪台机器、哪个端口上运行”的问题。

• 服务启动时，主动向注册中心（如 Eureka Server）发送 HTTP 注册请求，上报自身 IP、端口、服务名、健康状态等元数据
• 注册中心持久化并维护服务实例列表，并通过心跳（默认每30秒）检测存活；超时未续约会将实例标记为下线
• 服务消费者启动后，定期拉取（或监听推送）目标服务的最新可用实例列表
• 调用时，客户端从列表中按策略（轮询、权重、区域亲和等）选择一个实例，发起真实请求

SPI 和微服务发现的关键区别

别把两者混为一谈——它们解决的问题层级不同：

• SPI 是编译/启动期的类加载机制，发生在单个 JVM 内部，不涉及网络通信，典型用于 JDBC 驱动加载、Logger 实现切换、Dubbo 协议扩展等
• 微服务发现是运行期的网络寻址机制，跨进程、跨机器，依赖注册中心协调，典型用于 Spring Cloud 中 service-a 调用 service-b 的场景
• SPI 的“服务”是 Java 接口，发现结果是 Class 对象；微服务的“服务”是远程 HTTP/gRPC 端点，发现结果是 IP:PORT 地址
• SPI 配置写死在 jar 包里；微服务注册信息是动态生成、可实时变更的

什么时候该用哪一种？

看你的扩展粒度和部署形态：

• 想让日志框架可插拔、序列化方式可替换、SQL 方言支持多数据库？→ 用 SPI
• 有几十个微服务模块，部署在 K8s 或虚拟机集群，需要自动感知彼此上下线？→ 用 Eureka / Nacos / Consul
• 框架本身（如 Dubbo、Spring Boot Starter）内部常同时用两种：用 SPI 加载协议/序列化扩展点，用注册中心做服务实例寻址