微服务是大型架构的核心，下面我重点详解微服务发现@mikechen
什么是微服务发现
微服务发现是指在微服务架构中，服务实例能够在运行时动态地找到其他服务实例的过程。
每个服务实例启动时会将自己的网络地址、端口号、健康状态等信息注册到一个集中的服务注册中心。
其他需要调用该服务的服务，则通过查询服务注册中心获取目标服务的最新实例信息，实现动态定位和通信。
为什么需要微服务发现
在微服务架构中，服务通常有多个实例。
且实例数量动态变化（增加或减少），服务位置也会频繁变动。
没有服务发现机制，调用方需要硬编码或者配置服务地址，导致维护困难，且难以实现高可用和负载均衡。
服务发现解耦了服务调用方与被调用方的具体位置，实现了服务的动态管理和调用，提升了系统的灵活性、扩展性和稳定性。
微服务客户端实现
服务发现主要分为两种实现方式：客户端和服务端。
我首先，谈谈客户端实现。
实现方式：服务实例启动向注册表（如Consul、Nacos）注册。
消费者直接查询注册表并在客户端实现负载均衡（轮询、权重、熔断等）。
优点：请求路径短（直接调用目标实例）。
客户端可实现智能路由（本地缓存、重试、熔断）；去中心化，注册中心压力较小。
缺点：客户端实现复杂，需在每个调用方维护发现与负载策略。
客户端与注册中心耦合，更新策略需同步到多端；对跨语言或异构环境支持工作量较大。
典型实现：
-
Netflix Eureka（Spring Cloud Netflix）；
-
Nacos（默认也是客户端发现模式）；
-
Etcd（gRPC 生态）；
服务端发现
实现方式：客户端请求，发送给统一反向代理或负载均衡器。
比如：NGINX、HAProxy、Kubernetes Service + kube-proxy、Envoy，由代理查询注册信息并转发到后端实例。
优点：
-
客户端极简，不需要感知发现逻辑；
-
支持多语言调用；
-
易于集中控制与策略治理（由代理层统一管理）。
缺点：
-
多一跳代理层（性能损耗）；
-
代理层成为系统单点，需要 HA；
-
实现复杂度较高。
每种实现都有适用场景，选择时需结合系统规模、性能要求和复杂度做权衡。
常见服务发现组件对比
| 实现方式 | 组件 | 语言生态 | 一致性模型 | 健康检查 | 典型场景 | 优点 | 缺点 |
|---|---|---|---|---|---|---|---|
| Eureka | 客户端发现 | Java | AP（最终一致性） | 客户端心跳 | Spring Cloud | 简单高效、无中心化依赖 | 已停止维护（Netflix不再更新） |
| Consul | 服务端发现 | 多语言 | CP（强一致性） | 主动探测 | 多语言微服务 | 健康检查强大、支持DNS | 架构略复杂 |
| Nacos | 客户端发现 | Java | AP + CP 可选 | 主动+被动结合 | Spring Cloud Alibaba | 支持动态配置 + 注册 | 对云原生支持较弱 |
| Zookeeper | 客户端发现 | Java | CP | 临时节点 | Dubbo、Hadoop | 稳定可靠 | API 繁琐，性能一般 |
| Etcd | 服务端发现 | Go | CP | 无原生探测 | Kubernetes | 高一致性、云原生 | 不提供直接注册API |
陈睿mikechen
10年+大厂架构经验，资深技术专家，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注作者「mikechen」公众号，获取更多技术干货！
后台回复【架构】，即可获取《阿里架构师进阶专题全部合集》，后台回复【面试】即可获取《史上最全阿里Java面试题总结》