服务发现与负载均衡

从一个问题出发

在单体时代,所有逻辑在一个进程内,调用另一个模块就是函数调用.拆成微服务后:

• 订单服务要调用用户服务--用户服务跑在哪台机器,哪个端口?
• 用户服务有 3 个副本--调哪一个?
• 其中一个副本刚发布新版本正在重启--怎么避免把请求发过去?

这就是服务发现和负载均衡要解决的核心问题.

服务发现的两层模型

在 Kubernetes 04 篇中我们讨论过--服务发现有两个层次:

K8s 原生服务发现

ClusterIP Service 回顾

K8s 04 篇的核心知识--这里只做关联总结:

1. 创建 Service 得到一个虚拟 IP(ClusterIP)
2. CoreDNS 将 order-service.default.svc.cluster.local 解析为该 ClusterIP
3. kube-proxy 在每个节点维护 iptables/IPVS 规则,将 ClusterIP 流量转发到后端 Pod
4. 当 Pod 挂了 / 未就绪时,自动从 Endpoints 移除

对于大多数 HTTP/REST 服务,这就够了--ClusterIP 做 L4 负载均衡,每个连接随机分配到一个 Pod.

gRPC 长连接的负载均衡问题

K8s 04 篇和 02 篇都提到过--gRPC 使用 HTTP/2 长连接,ClusterIP 的 L4 负载均衡失效:

问题:
  gRPC Client ──[TCP 连接]──→ ClusterIP ──→ Pod A
                                             Pod B(空闲)
                                             Pod C(空闲)

  kube-proxy 只在 TCP 连接建立时选择一次后端
  后续所有 RPC 复用同一连接 → 全打到 Pod A

解决方案:
  1. Headless Service + 客户端 LB(gRPC 内置 round_robin)
  2. L7 代理(Envoy / Istio)按请求级别负载均衡

Headless Service + 客户端负载均衡

# Headless Service(ClusterIP: None)
apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  clusterIP: None  # 不分配虚拟 IP
  selector:
    app: user-service
  ports:
    - port: 50051

Headless Service 的 DNS 查询直接返回所有 Pod IP(A 记录),而非 ClusterIP.客户端可以自己决定连接哪个 Pod.

// gRPC 客户端使用 dns 解析 + round_robin 策略
conn, _ := grpc.Dial(
    "dns:///user-service.default.svc.cluster.local:50051",
    grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy":"round_robin"}`),
    grpc.WithInsecure(),
)
// 客户端会与所有 Pod 建立连接,每次 RPC 轮询选择

应用层注册中心:Consul

当 K8s Service 不够用时(跨集群,非 K8s 环境,细粒度健康检查),需要应用层注册中心.Consul 是最流行的选择之一.

注册/发现模型

sequenceDiagram
  participant SVC as 用户服务实例
  participant CONSUL as Consul Server
  participant CLIENT as 订单服务

  SVC->>CONSUL: 注册(IP:Port + 健康检查配置)
  loop 每 10s
    CONSUL->>SVC: 健康检查(HTTP/gRPC/TCP)
    SVC-->>CONSUL: 200 OK
  end
  CLIENT->>CONSUL: 查询"user-service"的健康实例
  CONSUL-->>CLIENT: [{IP:10.0.1.5, Port:8080}, {IP:10.0.1.6, Port:8080}]
  CLIENT->>SVC: 直接调用(客户端负载均衡)

Consul vs K8s Service

Nacos:注册中心 + 配置中心一体

国内团队常用 Nacos(阿里开源),同时提供服务发现和配置管理:

负载均衡策略

服务端 vs 客户端负载均衡

常见策略

gRPC Name Resolver 与 Balancer

gRPC 的服务发现和负载均衡是插件化架构:

┌────────────────────────────────────────────┐
│ gRPC Client                                │
├────────────────────────────────────────────┤
│  • Name Resolver
(dns/consul/etcd) │
│  • SubChannel Pool                          │
└────────────────────────────────────────────┘

关系: SC ──→ P1, SC ──→ P2, SC ──→ P3

Name Resolver 负责"发现地址列表",Balancer 负责"选择哪个地址".两者解耦,可以自由组合:

// 自定义 Consul resolver(伪代码)
resolver.Register(&consulResolver{})

conn, _ := grpc.Dial(
    "consul:///user-service", // 使用 consul scheme
    grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy":"p2c"}`),
)

健康检查

负载均衡的前提是知道哪些实例是健康的.健康检查有两种模式:

生产环境最佳实践:两者结合.

• 主动探测做粗粒度剔除(实例彻底挂了 → 从列表移除)
• 被动观察做细粒度降权(实例偶尔超时 → 降低权重/临时隔离)

与 Service Mesh 的关系(预告)

本篇讨论的服务发现和负载均衡,在 Service Mesh 架构中会被 Sidecar(Envoy)接管:

• 无 Mesh:应用内嵌 resolver + balancer(如 gRPC 内置,go-zero)
• 有 Mesh:Envoy sidecar 统一处理发现和 LB,应用只需连接 localhost

第 08 篇会详细讲解 Service Mesh 如何将这些能力从应用代码中完全剥离.