服务注册发现与负载均衡

服务注册发现与负载均衡

在微服务架构中，服务实例动态扩缩容，客户端无法硬编码地址。注册中心与负载均衡解决了"如何找到服务"和"如何分配流量"的核心问题。

1. 服务注册发现模式

客户端发现

┌─────────┐    ┌───────────────┐    ┌────────────┐
│ Service │ ←→ │ Registry      │    │            │
│   A     │    │ (Eureka,Consul)│   │  Service B │
└─────────┘    └───────────────┘    └────────────┘
       ↓ 查询并缓存实例列表            ↑
       └─────────────────────────────→
                    
       Service A 自行决定访问哪个 B 实例

代表：Eureka、Consul Client、Nacos Client

服务端发现

┌─────────┐    ┌───────────────┐    ┌────────────┐
│ Service │ →  │ Load Balancer │ →  │  Service B │
│   A     │    │ (Consul,Nginx)│    │  Instance  │
└─────────┘    └───────────────┘    └────────────┘

       A 只访问 LB 地址，由 LB 选择后端实例

代表：AWS ALB、Kubernetes Service、Nginx + Consul Template

1.5 服务注册发现的核心挑战

在单体应用时代，服务地址是静态配置在文件中的。微服务化后，实例数量、IP、端口都在动态变化，注册发现系统必须解决以下核心挑战：

1. 服务如何注册？

• 自注册（Self-registration）：服务启动时主动向注册中心注册，停止时注销。
• 第三方注册（Third-party registration）：由外部代理（如 K8s Pod、Consul Agent）代为注册。

2. 服务如何发现？

• 客户端发现：客户端直接向注册中心查询服务列表，自行选择实例。
• 服务端发现：客户端只访问负载均衡器/网关，由其从注册中心获取实例并分发请求。

3. 如何处理故障？

• 心跳机制：实例定期发送心跳证明存活，超时未收到则标记为不健康。
• 健康检查：注册中心主动探测实例健康状态（HTTP/TCP/自定义脚本）。
• 快速失败重试：客户端调用失败时自动切换其他实例，避免级联故障。

4. 网络分区怎么办？

• CP 优先（Consul/ZooKeeper）：网络分区时拒绝写入，保证一致性但牺牲可用性。
• AP 优先（Eureka/Nacos）：网络分区时保留旧数据，优先保证可用性但可能读到过期信息。

2. 注册中心对比

Eureka 自我保护

网络分区时，Eureka 进入保护模式：不注销心跳过期的实例，优先保证可用性（AP）。

eureka:
  server:
    enable-self-preservation: true
    renewal-percent-threshold: 0.85

Consul 服务网格

# 服务定义 + Sidecar 代理
service {
  name = "order-service"
  port = 8080
  connect {
    sidecar_service {}
  }
}

Nacos 注册+配置一体化

spring:
  cloud:
    nacos:
      discovery:
        server-addr: nacos:8848
        namespace: prod
      config:
        server-addr: nacos:8848
        file-extension: yaml

2.5 服务端发现与 API 网关集成

服务端发现模式将服务发现的复杂性从客户端转移到基础设施层。客户端只需知道 API 网关的地址，由网关负责从注册中心获取实例、负载均衡、重试、熔断等。

Spring Cloud Gateway + Consul 集成示例：

@Configuration
public class GatewayConfig {
    
    @Bean
    public RouteLocator customRouteLocator(RouteLocatorBuilder builder, 
                                           ConsulDiscoveryClient discoveryClient) {
        return builder.routes()
            .route("order-service", r -> r
                .path("/api/orders/**")
                .filters(f -> f
                    .stripPrefix(2)
                    .circuitBreaker(config -> config
                        .setName("orderService")
                        .setFallbackUri("forward:/fallback/order"))
                    .retry(retryConfig -> retryConfig.setRetries(3)))
                .uri("lb://order-service"))  // lb:// 表示从 Consul 获取实例
            .build();
    }
}

服务端发现的优势：

实践建议：内部微服务调用使用客户端发现（性能更优，减少一跳网络延迟）；对外暴露 API 使用服务端发现（统一管理安全策略和流量控制）。

3. 负载均衡算法

一致性哈希

Hash Ring (0 ~ 2^32-1)

     Node A ●----------------● Node B
           /                  \
   Key 1 ●                    ● Key 2
   Key 3 ●         ● Node C
                  Key 4
                   
  Key 顺时针找最近的 Node，新增/删除只影响相邻区域

Ribbon 负载均衡规则

// Spring Cloud OpenFeign + Ribbon
@FeignClient(name = "order-service", configuration = FeignConfig.class)
public interface OrderClient { ... }

// IRule 实现
new RoundRobinRule();      // 轮询
new WeightedResponseTimeRule(); // 按响应时间加权
new RandomRule();          // 随机

4. Kubernetes 服务发现

Service + Endpoint

apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  selector:
    app: order
  ports:
    - port: 80
      targetPort: 8080

# 集群内 DNS 解析
order-service.default.svc.cluster.local → Pod IPs

Headless Service

spec:
  clusterIP: None  # 直接返回 Pod IP 列表，用于 StatefulSet

高级流量管理（Istio）

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: order-route
spec:
  http:
    - route:
        - destination:
            host: order-service
            subset: v1
          weight: 90
        - destination:
            host: order-service
            subset: v2
          weight: 10

4.5 服务网格中的发现：Istio + Envoy xDS

服务网格（Service Mesh）将服务发现、负载均衡、安全通信、可观测性从应用代码中剥离到 Sidecar 代理（Envoy）中，通过控制面（Istiod）统一管理。

Istio 发现机制：

pilot-discovery (Istiod)
      │
      │ xDS API (ADS/CDS/EDS/LDS/RDS/SDS)
      │
      ▼
Envoy Sidecar ──► 其他服务
      │
      mTLS + 自动负载均衡

Istio 服务发现的优势：

1. 智能路由：无需修改应用即可实现金丝雀发布、A/B 测试、故障注入
2. mTLS 自动加密：Sidecar 之间自动协商证书，应用无感知
3. 多集群发现：通过 Istio 多集群网格，跨 K8s 集群的服务自动发现
4. 细化观察：Envoy 原生输出 RED 指标（Rate/Errors/Duration）

# Istio DestinationRule：配置负载均衡和连接池
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: order-service
spec:
  host: order-service
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST  # 最少请求负载均衡
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s  # 故障实例摘除 30 秒

选型建议：小规模（< 50 服务）用 K8s Service + Ingress 足够；中等规模（50-200 服务）用 Consul Connect 或 Linkerd（轻量）；大规模（> 200 服务）或需要多集群治理能力时选择 Istio。

5. CAP 权衡：CP vs AP 选型

分布式系统的 CAP 定理指出：一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）三者不可兼得。注册中心的选型本质上是 CP 与 AP 的权衡。

CP 注册中心（ZooKeeper/Consul with Raft/etcd）：

网络分区时：
┌─────────────┐     ×     ┌─────────────┐
│  Leader     │◄───────►│  Follower   │
│  (可写)     │   分区   │  (拒绝写入)  │
└─────────────┘         └─────────────┘

优势：强一致性，不会读到过期节点
劣势：分区时部分节点不可用

AP 注册中心（Eureka/Nacos 默认模式）：

网络分区时：
┌─────────────┐     ×     ┌─────────────┐
│  Node A     │◄───────►│  Node B     │
│  (接受注册)  │   分区   │  (接受注册)  │
└─────────────┘         └─────────────┘

优势：分区时所有节点仍可读写
劣势：可能读到已下线的实例（需客户端重试）

选型决策树：

需要强一致性保证（如金融交易服务发现）？
  ├─ 是 → CP（Consul Raft / etcd / ZooKeeper）
  └─ 否 → 需要多语言 SDK 支持？
           ├─ 是 → Nacos（Java/Go/Python/Node.js）
           └─ 否 → Spring Cloud 生态？
                    ├─ 是 → Eureka（简单）/ Consul（功能全）
                    └─ 否 → Kubernetes 原生 DNS

6. 高可用设计

总结

选择注册中心时考虑：技术栈匹配、一致性需求、生态集成、运维复杂度。