服务发现：微服务通信的基础设施

Souloss

公告

欢迎来到我的博客！这是一条示例公告

Learn More

标签

Souloss

公告

欢迎来到我的博客！这是一条示例公告

Learn More

标签

Souloss

公告

欢迎来到我的博客！这是一条示例公告

Learn More

标签

1416 字

4 分钟

服务发现：微服务通信的基础设施

2025-03-09

分布式系统深入

微服务

/

分布式

/

底层原理

某电商系统从单体架构拆分为 50 个微服务，每个服务部署 3-10 个实例，实例 IP 随容器调度频繁变化。订单服务需要调用库存服务的接口，但库存服务的 IP 每天可能变化数次——硬编码 IP 显然不可行。服务发现机制让服务消费者动态感知服务提供者的地址变化，是微服务通信的基础设施。

一、为什么需要服务发现#

1.1 单体架构 vs 微服务架构#

在单体架构中，模块间通过函数调用通信，地址在编译期确定。微服务架构中，服务实例动态变化：

容器调度导致 IP 频繁变化
弹性伸缩导致实例数量动态增减
故障恢复导致实例替换

1.2 服务发现的核心需求#

需求	描述
注册	服务实例启动时将自己的地址告知注册中心
发现	消费者从注册中心获取提供者的地址列表
健康检查	注册中心定期检查实例是否存活
通知	实例状态变化时通知消费者

二、服务发现模式#

2.1 客户端发现（Client-Side Discovery）#

消费者直接查询注册中心，自行选择实例：

优点：

客户端可自定义负载均衡策略
无需中间代理，延迟更低

缺点：

客户端与注册中心耦合
每种语言需实现服务发现客户端

典型实现：Netflix Eureka + Ribbon、Nacos。

2.2 服务端发现（Server-Side Discovery）#

消费者通过负载均衡器间接访问服务实例：

graph LR A[服务消费者] -->|请求| B[负载均衡器] B -->|查询| C[注册中心] B -->|转发| D[服务实例1] B -->|转发| E[服务实例2]

优点：

客户端无需感知服务发现逻辑
与语言无关

缺点：

负载均衡器是额外组件
增加一跳延迟

典型实现：Kubernetes Service + kube-proxy、AWS ALB。

2.3 两种模式对比#

维度	客户端发现	服务端发现
负载均衡	客户端实现	负载均衡器实现
客户端复杂度	高	低
语言依赖	有	无
额外组件	无	负载均衡器
延迟	低	多一跳

三、注册中心实现#

3.1 核心数据模型#

注册中心存储的是服务实例的元数据：

1
服务名: inventory-service
2
实例列表:
3
  - 10.0.1.10:8080  weight=100  status=UP
4
  - 10.0.1.11:8080  weight=100  status=UP
5
  - 10.0.1.12:8080  weight=50   status=UP
6
元数据:
7
  - region: cn-east
8
  - zone: zone-a
9
  - version: v2.1.0

3.2 注册与发现流程#

sequenceDiagram participant P as 服务提供者 participant R as 注册中心 participant C as 服务消费者 P->>R: 注册实例（IP、端口、元数据） P->>R: 发送心跳 C->>R: 订阅服务变更 R-->>C: 推送实例列表 C->>P: 发起调用

3.3 健康检查#

模式	原理	优缺点
客户端心跳	实例定期发送心跳	简单，但无法检测假死
服务端探活	注册中心主动探测	准确，但增加注册中心负担
应用层探活	检查应用特定接口	最准确，但需定义探活接口

四、主流注册中心对比#

维度	Eureka	Consul	Nacos	ZooKeeper
一致性	AP	CP（默认）	AP/CP 可选	CP
健康检查	客户端心跳	TCP/HTTP/gRPC	TCP/HTTP/MySQL	会话保持
配置管理	无	有	有	有
多数据中心	有	有	有	无
访问协议	HTTP	HTTP/DNS	HTTP/gRPC	TCP
Spring Cloud	原生支持	原生支持	原生支持	原生支持

4.1 Eureka#

Netflix 开源的 AP 注册中心，优先保证可用性：

1
// Eureka 客户端配置
2
eureka:
3
  client:
4
    serviceUrl:
5
      defaultZone: http://eureka1:8761/eureka/,http://eureka2:8761/eureka/
6
    registryFetchIntervalSeconds: 30
7
  instance:
8
    leaseRenewalIntervalInSeconds: 10
9
    leaseExpirationDurationInSeconds: 90

特点：

自我保护模式：心跳比例低于阈值时不再剔除实例
Peer-to-Peer 复制：节点间异步复制，最终一致
适合 AWS 等云环境

4.2 Nacos#

阿里开源的注册中心，支持 AP/CP 切换：

1
// Nacos 客户端配置
2
spring:
3
  cloud:
4
    nacos:
5
      discovery:
6
        server-addr: nacos1:8848,nacos2:8848
7
        namespace: production
8
        group: DEFAULT_GROUP
9
        cluster-name: SH

特点：

临时实例走 AP 模式（Distro 协议），永久实例走 CP 模式（Raft 协议）
支持配置管理和服务发现一体化
支持权重路由和就近路由

4.3 Consul#

HashiCorp 开源的 CP 注册中心：

1
# Consul 服务定义
2
service {
3
  name = "inventory-service"
4
  port = 8080
5
  tags = ["v2.1.0"]
6
  check {
7
    http     = "http://localhost:8080/health"
8
    interval = "10s"
9
    timeout  = "1s"
10
  }
11
}

特点：

支持 DNS 接口，方便非微服务应用接入
内置多数据中心支持
提供 KV 存储、服务网格等功能

五、负载均衡策略#

服务发现获取实例列表后，需要选择一个实例发起调用：

策略	原理	适用场景
Round Robin（轮询）	依次选择	实例性能相近
Random（随机）	随机选择	实例性能相近
Weighted Round Robin（加权轮询）	按权重分配	实例性能不均
Least Connections（最少连接）	选择连接数最少的	长连接场景
Consistent Hash（一致性哈希）	相同请求路由到同一实例	有状态服务
Zone Aware（区域感知）	优先同区域实例	多区域部署

六、服务发现与 Kubernetes#

Kubernetes 内置了服务发现机制：

6.1 Service 资源#

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: inventory-service
5
spec:
6
  selector:
7
    app: inventory
8
  ports:
9
    - port: 80
10
      targetPort: 8080
11
  type: ClusterIP

6.2 DNS 发现#

Kubernetes 集群内通过 CoreDNS 提供服务发现：

1
inventory-service.default.svc.cluster.local

6.3 Endpoint 维护#

kube-proxy 监控 Endpoint 变化，更新 iptables/IPVS 规则：

1
Service: inventory-service → 10.0.1.10:8080, 10.0.1.11:8080, 10.0.1.12:8080

七、实践建议#

注册中心高可用：至少部署 3 个节点，跨可用区分布
合理配置心跳：心跳间隔和超时时间需要根据网络环境调整
优雅上下线：服务下线前先从注册中心注销，避免请求打到已停止的实例
本地缓存：消费者缓存实例列表，注册中心不可用时仍可调用
元数据丰富：利用元数据实现灰度发布、就近路由等高级功能

1
// 优雅下线示例
2
@PreDestroy
3
public void gracefulShutdown() {
4
    // 1. 从注册中心注销
5
    registry.deregister(instance);
6
    // 2. 等待在途请求完成
7
    Thread.sleep(5000);
8
    // 3. 关闭服务
9
    server.stop();
10
}