分布式系统架构2：服务发现

分布式系统架构2：服务发现

服务发现指的是分布式系统中，服务实例动态注册自己的信息到注册中心，其他服务能发现这些实例的位置，实现服务间通信。

为什么需要服务发现？

对于分布式应用来说，服务发现不是可选项，而是必须的。主要目的是让服务实例能相互识别和通信，确保系统在动态扩容、缩容和故障恢复时仍能正常运行。

由注册中心和消费者组成

• 注册中心Service Registry：服务实例将自己的元数据（IP、端口、健康状态等）注册到注册中心。维护一个服务注册表，记录所有可用服务的信息
• 消费者Cumer：从注册中心获取目标服务的位置信息（服务实例列表），通过负载均衡选择一个实例进行通信。

.1客户端发现模式

概念：客户端负责确定可用服务的网络位置和请求负责均衡。

过程：客户端查询注册中心获取实例列表，接着客户端用负载均衡算法选择一个可用服务实例发出请求。如图：

etflix OSS 提供了一个很好的客户端发现模式示例。etflix Eureka 是一个服务注册中心，它提供了一组用于管理服务实例注册和查询可用实例的 REST API。etflix Ribbon 是一个 IPC 客户端，可与 Eureka 一起使用，用于在可用服务实例之间使请求负载均衡。

优点：轻量级

缺点：需要客户端实现服务发现逻辑，代码复杂了。

.2服务端发现模式

过程：客户端通过负载均衡器（如：ginx或API Gateway）向服务发出请求，负载均衡器查询注册中心获取实例信息，然后将请求转发给合适的服务实例

案例：AWS Elastic Load Balancer（ELB）是一个服务端发现路由示例

优点：客户端不再关心服务发现的细节，只需要将请求发给负载均衡器

缺点：需要部署负载均衡器，保障高可用

注册中心的作用是一个包含了服务实例网络位置的数据库。本身需要具备高可用性，通常通过分布式一致性协议（如Raft、Paxos）来保证数据的一致性和可靠性。

比如：etflix Eureka，它提供了一个用于注册和查询服务实例的 REST API。

服务实例使用 POST 请求注册其网络位置。每隔 0 秒使用 PUT 请求刷新其注册信息。通过使用 HTTP DELETE 请求或实例注册超时来移除注册信息。

客户端可以使用 HTTP GET 请求来检索已注册的服务实例。

其他的注册中心：etcd，Cul，Zookeeper这些，我在后面的文章中学习后再写出来

5.1 主动注册Self-Registration

过程：服务实例启动后，主动将自己的信息注册到服务注册中心。并通过发送心跳请求来防止注册信息过期。

适用场景：微服务架构中，服务实例与注册中心直接交互

示例：

• Eureka：
  • Spring Cloud中，服务通过 @EnableEurekaClient 注解实现主动注册。
  • 服务启动时向Eureka Server注册自身的元数据信息（IP、端口、健康状态等）。

优点：实现简单，由服务自己掌握注册逻辑；

缺点：服务代码耦合了注册中心逻辑，增加服务端复杂度，且注册中心故障可能影响服务启动。

5.2被动注册（Third-Party Registration）

又叫第三方注册，原理：服务实例本身不负责注册操作，而是通过外部代理或监控组件检测到服务的状态，当检测到新的可用服务实例时，然后将其注册到服务注册中心。

示例：

Kubernetes：

• 使用kubelet定期监测Pod的状态，并将Pod的网络信息注册到Kubernetes的Service中。

优点：服务实例与注册逻辑解耦，服务代码无侵入。适用于现有服务

缺点：依赖第三方组件，注册的实时性较低于主动注册

6. 总结服务发现的核心流程

• 服务注册：服务启动时向注册中心注册自身的元数据。
• 心跳检测：服务持续发送健康状态给注册中心，确保可用性。
• 服务发现：消费者从注册中心获取服务实例信息。
• 服务调用：消费者选择合适的实例进行调用（客户端负载均衡或服务端负载均衡）。
• 服务注销：服务关闭时从注册中心注销自己的信息。

面试过程中可能还会文档服务发现框架的区别，以及选型依据，可以提前准备一些框架的内容，这里简单列一下：