1.概念
服务发现指的是分布式系统中，服务实例动态注册自己的信息到注册中心，其他服务能发现这些实例的位置，实现服务间通信。
为什么需要服务发现？
对于分布式应用来说，服务发现不是可选项，而是必须的。主要目的是让服务实例能相互识别和通信，确保系统在动态扩容、缩容和故障恢复时仍能正常运行。
2.组成
由注册中心和消费者组成
-
注册中心Service Registry：服务实例将自己的元数据（IP、端口、健康状态等）注册到注册中心。维护一个服务注册表，记录所有可用服务的信息
-
消费者Consumer：从注册中心获取目标服务的位置信息（服务实例列表），通过负载均衡选择一个实例进行通信。
3.两种发现模式
3.1客户端发现模式
概念：客户端负责确定可用服务的网络位置和请求负责均衡。
过程：客户端查询注册中心获取实例列表，接着客户端用负载均衡算法选择一个可用服务实例发出请求。如图：
Netflix OSS 提供了一个很好的客户端发现模式示例。Netflix Eureka 是一个服务注册中心，它提供了一组用于管理服务实例注册和查询可用实例的 REST API。Netflix Ribbon 是一个 IPC 客户端，可与 Eureka 一起使用，用于在可用服务实例之间使请求负载均衡。
优点：轻量级
缺点：需要客户端实现服务发现逻辑，代码复杂了。
3.2服务端发现模式
过程：客户端通过负载均衡器（如：Nginx或API Gateway）向服务发出请求，负载均衡器查询注册中心获取实例信息，然后将请求转发给合适的服务实例
案例：AWS Elastic Load Balancer（ELB）是一个服务端发现路由示例
优点：客户端不再关心服务发现的细节，只需要将请求发给负载均衡器
缺点：需要部署负载均衡器，保障高可用
4.注册中心
注册中心的作用是一个包含了服务实例网络位置的数据库。本身需要具备高可用性，通常通过分布式一致性协议（如Raft、Paxos）来保证数据的一致性和可靠性。
比如：Netflix Eureka，它提供了一个用于注册和查询服务实例的 REST API。
服务实例使用 POST 请求注册其网络位置。每隔 30 秒使用 PUT 请求刷新其注册信息。通过使用 HTTP DELETE 请求或实例注册超时来移除注册信息。
客户端可以使用 HTTP GET 请求来检索已注册的服务实例。
其他的注册中心：etcd，Consul，Zookeeper这些，我在后面的文章中学习后再写出来
5.服务注册的方式
5.1 主动注册Self-Registration
过程：服务实例启动后，主动将自己的信息注册到服务注册中心。并通过发送心跳请求来防止注册信息过期。
适用场景：微服务架构中，服务实例与注册中心直接交互
示例：
- Eureka ：Spring Cloud中，服务通过
@EnableEurekaClient注解实现主动注册。服务启动时向Eureka Server注册自身的元数据信息（IP、端口、健康状态等）。
优点：实现简单，由服务自己掌握注册逻辑；
缺点：服务代码耦合了注册中心逻辑，增加服务端复杂度，且注册中心故障可能影响服务启动。
5.2被动注册（Third-Party Registration）
又叫第三方注册，原理：服务实例本身不负责注册操作，而是通过外部代理或监控组件检测到服务的状态，当检测到新的可用服务实例时，然后将其注册到服务注册中心。
示例：
Kubernetes：
- 使用
kubelet定期监测Pod的状态，并将Pod的网络信息注册到Kubernetes的Service中。
优点：服务实例与注册逻辑解耦，服务代码无侵入。适用于现有服务
缺点：依赖第三方组件，注册的实时性较低于主动注册
6. 总结服务发现的核心流程
-
服务注册：服务启动时向注册中心注册自身的元数据。
-
心跳检测：服务持续发送健康状态给注册中心，确保可用性。
-
服务发现：消费者从注册中心获取服务实例信息。
-
服务调用：消费者选择合适的实例进行调用（客户端负载均衡或服务端负载均衡）。
-
服务注销：服务关闭时从注册中心注销自己的信息。
7.框架对比
面试过程中可能还会文档服务发现框架的区别，以及选型依据，可以提前准备一些框架的内容，这里简单列一下：
文章转载自： 卷福同学