微服务服务发现机制详解

服务发现机制使微服务能自动识别并通信，解决动态寻址问题。服务启动后向注册中心（如Nacos）注册自身信息，通过心跳维持存活状态；调用方查询注册中心获取可用实例列表，并结合负载均衡策略选择实例发起调用。分为客户端发现与服务端发现两种模式，前者由客户端直接获取地址并决策，后者由网关或负载均衡器代为查询转发。例如订单服务调用用户服务时，从注册中心获取其IP和端口，完成调用，若用户服务宕机则被自动剔除。该机制支撑了系统的弹性与可扩展性。

微服务架构中，服务发现机制的核心作用是让服务之间能够自动识别和通信，而不需要硬编码地址。随着服务实例频繁地创建、销毁或迁移，手动维护地址列表不可行，服务发现解决了这一动态寻址问题。

服务注册与注册中心

每个微服务启动后，会主动向一个集中化的注册中心（如Eureka、Consul、ZooKeeper或Nacos）注册自己的网络信息，包括IP地址、端口、服务名称和健康状态。这个过程称为服务注册。注册中心持续维护一份所有可用服务实例的清单。

服务实例通常通过心跳机制定期向注册中心发送存活信号。如果注册中心在一定时间内未收到心跳，就会将该实例从服务列表中移除，确保调用方不会路由到已下线的服务。

服务查询与负载均衡

当一个服务需要调用另一个服务时，它会向注册中心发起服务查询，获取目标服务的可用实例列表。客户端可以根据策略（如轮询、随机或权重）选择一个实例进行调用。

这个过程常与客户端负载均衡结合使用。例如，Netflix Ribbon 可以在本地缓存服务列表，并完成负载决策，减少每次调用都查询注册中心的压力。

两种模式：客户端发现 vs 服务端发现

• 客户端发现：调用方直接从注册中心获取目标服务地址，并自行选择实例。优点是灵活高效，缺点是逻辑耦合到客户端。
• 服务端发现：请求先到达负载均衡器或网关（如API Gateway），由它查询注册中心并转发请求。客户端无感知，但引入了中间节点，可能成为瓶颈。

实际工作流程示例

假设订单服务要调用用户服务：

• 用户服务启动，向Nacos注册自己（IP: 192.168.1.10, 端口: 8080）。
• 订单服务从Nacos获取“用户服务”的实例列表。
• 订单服务选择其中一个实例，发起HTTP调用。
• 用户服务实例宕机，未发送心跳，Nacos将其剔除，后续请求不再路由过去。

基本上就这些。服务发现让微服务系统具备弹性与可扩展性，是实现动态部署和自动化运维的关键环节。