前言

在腾讯云国际版的网络产品矩阵中，CLB（Cloud Load Balancer，云负载均衡）是连接用户与后端服务的核心枢纽。无论你是通过 CDN 边缘节点回源、WAF 安全过滤后的流量转发，还是 VPC 内微服务之间的东西向通信，CLB 都扮演着流量调度总控的角色。

然而，大多数用户对 CLB 的使用停留在"创建监听器 → 绑定后端服务器 → 开启健康检查"的基础层面。本文将深入 CLB 的高级特性，从七层路由规则编写、会话保持策略选型、跨可用区容灾设计，到基于腾讯云 CLI 和 API 的自动化运维脚本，带你把 CLB 真正用透。

一、四层与七层CLB的技术本质

1.1 协议栈层面的根本差异

理解 CLB 的转发能力，首先要区分四层（L4）和七层（L7）在 OSI 模型中处理的数据层级：

关键认知：七层 CLB 因为能解析 HTTP 协议，可以实现四层无法做到的高级路由——例如将 /api/ 转发到应用服务器集群，将 /static/ 转发到静态资源服务器，将 admin.example.com 转发到独立的管理后台。这种基于内容的路由能力是实现微服务架构和灰度发布的基础。

1.2 四层与七层混合架构设计

在生产实践中，最常见的模式是四层和七层 CLB 组合使用：

用户请求
   │
   ▼
┌──────────────┐
│  公网 CLB     │  ← 七层 HTTPS，SSL 卸载 + 域名路由
│  (L7 HTTPS)  │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│  内网 CLB     │  ← 四层 TCP，高性能后端转发
│  (L4 TCP)    │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│  CVM 集群     │
└──────────────┘

为什么这么设计？

• 公网入口用七层 CLB：需要 SSL 证书管理、基于域名的多站点路由、请求头注入（X-Forwarded-For）等能力
• 内网间通信用四层 CLB：不需要重复解析 HTTP，减少延迟，提升吞吐量
• 后端 CVM 只需处理原始业务逻辑，不关心 SSL 和路由

二、七层高级路由规则实战

2.1 基于域名的多站点路由

当一台 CLB 需要服务多个域名时，利用七层转发规则实现「一个 IP 承载多站点」：

# CLB 转发规则配置（腾讯云控制台 / API）
监听器: HTTPS 443
  - 转发规则 1:
      域名: api.example.com
      URL路径: /
      后端服务器组: api-server-group (端口 8080)
      
  - 转发规则 2:
      域名: admin.example.com
      URL路径: /
      后端服务器组: admin-server-group (端口 3000)
      
  - 转发规则 3:
      域名: www.example.com
      URL路径: /static/*
      后端服务器组: static-server-group (端口 80)
      
  - 转发规则 4:  # 默认兜底规则
      域名: www.example.com
      URL路径: /
      后端服务器组: web-server-group (端口 8080)

规则匹配优先级：腾讯云 CLB 按「最长路径匹配」原则执行——添加规则时的顺序不影响实际匹配优先级，系统自动选择路径最精确匹配的规则。例如 /api/v2/users 会优先匹配 /api/v2/ 规则而非 /api/。这一设计与 Nginx 的 location 指令逻辑一致。

2.2 基于请求头的灰度发布路由

利用七层 CLB 对 HTTP Header 的感知能力，可以实现基于用户标签的灰度路由：

# 灰度规则思路（通过 CLB 自定义转发条件实现）
# 条件：请求头 X-Canary-Version: v2
# 动作：转发到灰度后端服务器组

# 实践中的配置策略：
# 1. 创建两套后端服务器组
#    - web-server-group-stable（稳定版，权重 90）
#    - web-server-group-canary（灰度版，权重 10）

# 2. 在 CLB 控制台添加转发条件
#    匹配条件: HTTP Header "X-Canary" 值为 "true"
#    目标组: web-server-group-canary

# 3. 灰度用户通过客户端/网关注入 Header

灰度发布完整流程：

1. 部署新版本到 canary 服务器组，初始权重 5%
2. 监控 canary 组的错误率和响应时间 15 分钟
3. 若指标正常，逐步提升权重至 25% → 50% → 100%
4. 全量切换后，旧版本服务器组保留 24 小时用于快速回滚

2.3 自定义错误页面与重定向

七层 CLB 支持在转发层面配置自定义响应，无需后端服务器参与：

三、会话保持策略深度对比

3.1 三种会话保持方案的技术剖析

3.2 Cookie 植入模式的实战配置

# CLB 会话保持配置（七层监听器）
会话保持:
  开启: true
  保持方式: Cookie植入
  Cookie名称: TENCENTCLB_SESSIONID  # 默认，可自定义
  超时时间: 900秒                      # 15分钟
  后端权重: 按权重分配初始请求
  
# Cookie 植入流程:
# 1. 客户端首次请求 → CLB 按权重选择后端 RS1
# 2. RS1 返回响应 → CLB 注入 Set-Cookie: TENCENTCLB_SESSIONID=xxxx; Path=/
# 3. 客户端再次请求 → 携带 Cookie，CLB 识别后继续转发到 RS1
# 4. 超时 900 秒 → Cookie 失效，重新分配后端

关键注意事项：

• Cookie 名称冲突：如果后端应用也使用同名 Cookie，CLB 植入的 Cookie 会覆盖后端 Cookie。务必确认 Cookie 名称互不冲突，推荐使用自定义 Cookie 名称如 MYAPP_CLB_STICKY
• 超时时间权衡：太短（< 300 秒）导致频繁重新分配，太长（> 3600 秒）导致某台后端故障时用户长时间得不到恢复。900 秒是经过大量实践验证的平衡点
• 跨域问题：如果前端和后端不同源，确保 Cookie 的 Domain 和 Path 设置正确

四、健康检查的高级策略

4.1 健康检查配置指南

# 生产环境推荐配置
健康检查:
  # 基础配置
  检查协议: HTTP
  检查端口: 8080               # 与业务端口一致
  检查路径: /health            # 专用健康检查端点
  检查域名: api.example.com    # 七层指定域名，确保路由正确
  
  # 阈值配置
  检查间隔: 5秒                # 过短增加后端负载，过长影响故障发现
  超时时间: 2秒                # 后端必须在2秒内响应
  健康阈值: 2次                # 连续2次成功才标记为健康（防止抖动）
  不健康阈值: 3次              # 连续3次失败才剔除（容忍瞬时波动）
  
  # HTTP状态码判定
  正常状态码: http_2xx, http_3xx  # 200-399 均视为健康

4.2 健康检查端点实现示例

后端应用应提供独立的健康检查端点，不能把业务首页作为健康检查目标：

# Python (Flask) 健康检查端点
from flask import Flask, jsonify
import psycopg2
import redis

app = Flask(__name__)

@app.route('/health')
def health_check():
    """CLB 健康检查端点——轻量、快速、无副作用"""
    checks = {"status": "healthy", "checks": {}}
    
    # 1. 数据库连接检查
    try:
        conn = psycopg2.connect(
            host="10.0.4.10", port=5432,
            dbname="mydb", user="app", password="***",
            connect_timeout=2
        )
        conn.close()
        checks["checks"]["database"] = "ok"
    except Exception:
        checks["status"] = "unhealthy"
        checks["checks"]["database"] = "failed"
    
    # 2. Redis 连接检查
    try:
        r = redis.Redis(host="10.0.4.20", port=6379, socket_connect_timeout=2)
        r.ping()
        checks["checks"]["redis"] = "ok"
    except Exception:
        checks["status"] = "degraded"
        checks["checks"]["redis"] = "failed"
    
    # 根据状态返回不同的 HTTP 状态码
    if checks["status"] == "healthy":
        return jsonify(checks), 200
    elif checks["status"] == "degraded":
        return jsonify(checks), 200  # 降级仍返回200，由监控告警
    else:
        return jsonify(checks), 503  # 不健康返回503

// Go (net/http) 健康检查端点——更轻量
package main

import (
    "context"
    "encoding/json"
    "net/http"
    "time"
)

func healthHandler(w http.ResponseWriter, r *http.Request) {
    ctx, cancel := context.WithTimeout(r.Context(), 2*time.Second)
    defer cancel()
    
    result := map[string]string{"status": "ok"}
    
    // 快速检查关键依赖
    if err := db.PingContext(ctx); err != nil {
        result["status"] = "unhealthy"
        result["database"] = err.Error()
        w.WriteHeader(http.StatusServiceUnavailable)
    }
    
    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(result)
}

func main() {
    http.HandleFunc("/health", healthHandler)
    http.ListenAndServe(":8080", nil)
}

健康检查设计原则：

• 端点必须轻量，响应时间 < 500ms
• 不触发写操作、不发送外部请求、不产生费用
• 检查关键依赖（数据库、缓存、消息队列），但不要因为非核心依赖失败而标记整个实例不健康
• 返回标准 JSON 格式，方便监控系统解析

五、跨可用区容灾架构

5.1 多可用区部署策略

腾讯云 CLB 支持跨可用区容灾，在单个可用区故障时自动切换流量：

                        ┌──────────────────────┐
                        │   公网 CLB（跨AZ）     │
                        │   地域：新加坡         │
                        └──┬───────┬───────┬───┘
                           │       │       │
              ┌────────────┼───────┼───────┼────────────┐
              │            │       │       │            │
              ▼            ▼       ▼       ▼            ▼
        ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
        │ 一区 CVM  │ │ 一区 CVM  │ │ 二区 CVM  │ │ 三区 CVM  │
        │ (主/权100)│ │ (主/权100)│ │ (主/权100)│ │ (备/权50) │
        └──────────┘ └──────────┘ └──────────┘ └──────────┘

5.2 加权轮询与动态权重调整

# 使用腾讯云 CLI 调整后端服务器权重（自动化容灾脚本）
# 安装 tccli: pip install tccli

# 场景：检测到可用区一区故障，降低一区 CVM 权重
tccli clb ModifyTargetWeight \
  --region ap-singapore \
  --load-balancer-id lb-xxxxxxxx \
  --listener-id lbl-xxxxxxxx \
  --targets.0.instance-id ins-az1-node1 \
  --targets.0.port 8080 \
  --weight 10  # 从 100 降到 10

# 同时提升其他可用区权重
tccli clb ModifyTargetWeight \
  --region ap-singapore \
  --load-balancer-id lb-xxxxxxxx \
  --listener-id lbl-xxxxxxxx \
  --targets.0.instance-id ins-az2-node1 \
  --targets.0.port 8080 \
  --weight 100

5.3 完整的自动故障切换脚本

#!/bin/bash
# CLB 自动故障切换脚本
# 用途：检测后端健康状态，自动调整 CLB 权重

CLB_ID="lb-xxxxxxxx"
LISTENER_ID="lbl-xxxxxxxx"
REGION="ap-singapore"
ALERT_WEBHOOK="https://hooks.slack.com/xxx"

# 定义后端实例列表
declare -A BACKENDS=(
  ["ins-az1-node1"]="8080:100:sg-zone1"
  ["ins-az1-node2"]="8080:100:sg-zone1"
  ["ins-az2-node1"]="8080:100:sg-zone2"
  ["ins-az3-node1"]="8080:50:sg-zone3"
)

check_health() {
  local instance_id=$1
  local port=$2
  
  # 通过腾讯云 API 检查实例健康状态
  status=$(tccli clb DescribeTargetHealth \
    --region "$REGION" \
    --load-balancer-ids "[\"$CLB_ID\"]" \
    | jq -r ".LoadBalancers[0].Listeners[0].Targets[] | 
             select(.InstanceId==\"$instance_id\") | .HealthStatus")
  
  echo "$status"
}

# 主逻辑
for instance in "${!BACKENDS[@]}"; do
  IFS=':' read -r port weight zone <<< "${BACKENDS[$instance]}"
  
  health=$(check_health "$instance" "$port")
  
  if [[ "$health" != "true" && "$weight" != "0" ]]; then
    echo "[ALERT] $instance in $zone is unhealthy, setting weight to 0"
    
    tccli clb ModifyTargetWeight \
      --region "$REGION" \
      --load-balancer-id "$CLB_ID" \
      --listener-id "$LISTENER_ID" \
      --targets.0.instance-id "$instance" \
      --targets.0.port "$port" \
      --weight 0
    
    # 发送告警
    curl -X POST "$ALERT_WEBHOOK" \
      -H "Content-Type: application/json" \
      -d "{\"text\": \"CLB后端 $instance ($zone) 健康检查失败，权重已设为0\"}"
  elif [[ "$health" == "true" && "$weight" == "0" ]]; then
    echo "[RECOVERY] $instance in $zone is healthy again, restoring weight"
    
    # 恢复时使用原有权重
    original_weight=$(echo "${BACKENDS[$instance]}" | cut -d':' -f2)
    tccli clb ModifyTargetWeight \
      --region "$REGION" \
      --load-balancer-id "$CLB_ID" \
      --listener-id "$LISTENER_ID" \
      --targets.0.instance-id "$instance" \
      --targets.0.port "$port" \
      --weight "$original_weight"
  fi
done

六、CLB与WAF、CDN的联动架构

6.1 推荐的流量链路

用户 → DNSPod智能解析 → CDN/ECDN边缘 → WAF安全过滤 → CLB负载均衡 → 后端CVM

各组件在链路中的职责：

6.2 获取真实客户端IP

当流量经过 CDN → WAF → CLB 多层代理后，后端 CVM 默认只能看到 CLB 的内网 IP。需要通过 HTTP 头部传递真实客户端 IP：

# 后端 Nginx 配置，提取真实客户端 IP
http {
    # 信任 CDN 和 CLB 的回源 IP 段
    set_real_ip_from 10.0.0.0/8;      # VPC 内网
    set_real_ip_from 172.16.0.0/12;
    
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;
    
    server {
        listen 8080;
        
        # 日志中记录真实 IP
        log_format main '$remote_addr - $remote_user [$time_local] '
                        '"$request" $status $body_bytes_sent '
                        '"$http_referer" "$http_user_agent"';
        access_log /var/log/nginx/access.log main;
    }
}

# Python Flask 获取真实 IP
from flask import Flask, request

app = Flask(__name__)

@app.before_request
def get_real_ip():
    """从代理链中提取真实客户端IP"""
    # CDN 和 CLB 都会追加 X-Forwarded-For
    forwarded = request.headers.get('X-Forwarded-For', '')
    if forwarded:
        # X-Forwarded-For 格式: client, proxy1, proxy2
        # 取第一个（最原始客户端IP）
        request.real_ip = forwarded.split(',')[0].strip()
    else:
        request.real_ip = request.remote_addr

@app.route('/api/info')
def info():
    return {"your_ip": request.real_ip}

七、CLB 自动化运维实战

7.1 基于腾讯云 CLI 的批量管理

# === CLB 常用运维命令合集 ===

# 1. 查看所有 CLB 实例及状态
tccli clb DescribeLoadBalancers \
  --region ap-singapore \
  --output json | jq '.LoadBalancerSet[] | {id: .LoadBalancerId, name: .LoadBalancerName, status: .Status, vip: .LoadBalancerVips[0]}'

# 2. 查看指定监听器的后端健康状态
tccli clb DescribeTargetHealth \
  --region ap-singapore \
  --load-balancer-ids '["lb-xxxxxxxx"]' \
  | jq '.LoadBalancers[0].Listeners[0].Targets[] | {instance: .InstanceId, port: .Port, health: .HealthStatus}'

# 3. 批量添加后端服务器
for instance in ins-node1 ins-node2 ins-node3; do
  tccli clb RegisterTargets \
    --region ap-singapore \
    --load-balancer-id lb-xxxxxxxx \
    --listener-id lbl-xxxxxxxx \
    --targets.0.instance-id "$instance" \
    --targets.0.port 8080 \
    --targets.0.weight 100
done

# 4. 批量修改权重（灰度发布）
tccli clb BatchModifyTargetWeight \
  --region ap-singapore \
  --modify-list "[{\"ListenerId\":\"lbl-xxx\",\"Targets\":[{\"InstanceId\":\"ins-node1\",\"Port\":8080,\"Weight\":50}]}]"

# 5. 绑定 SSL 证书到七层监听器
tccli clb ModifyListener \
  --region ap-singapore \
  --load-balancer-id lb-xxxxxxxx \
  --listener-id lbl-xxxxxxxx \
  --certificate.ssl-mode UNIDIRECTIONAL \
  --certificate.cert-id xxxxxxxx

7.2 监控告警配置

# 使用腾讯云监控 CLI 创建 CLB 告警策略
tccli monitor CreateAlarmPolicy \
  --region ap-singapore \
  --policy-name "CLB-4xx错误率告警" \
  --monitor-type MT_QCE \
  --namespace qce/clb \
  --conditions '[{
    "MetricName": "HttpCode_4XX",
    "Period": 60,
    "Operator": "gt",
    "Value": "100",
    "ContinuePeriod": 3,
    "NoticeFrequency": 300
  }]' \
  --notice-ids '["notice-xxxxxxxx"]'

# 关键监控指标建议
# 1. HttpCode_4XX / HttpCode_5XX — 客户端/服务端错误
# 2. ConNum — 并发连接数（判断是否需要扩容）
# 3. InPkg / OutPkg — 出入包量（DDoS 预警）
# 4. UnhealthyRsCount — 不健康后端数（及时告警）

1. 验证 CLB VIP 可达性（从同 VPC 内执行）

curl -v -H "Host: www.example.com" http://CLB-VIP/health

2. 检查 CLB HTTPS 证书信息

openssl s_client -connect CLB-VIP:443 -servername www.example.com 2>/dev/null \ | openssl x509 -noout -dates -subject -issuer

3. 模拟 CDN 回源请求（带 X-Forwarded-For）

curl -H "X-Forwarded-For: 1.2.3.4" \ -H "Host: www.example.com" \ http://CLB-VIP/api/test

4. 压力测试（使用 wrk）

wrk -t4 -c100 -d60s --latency \ -H "Host: www.example.com" \ https://CLB-VIP/api/endpoint

5. 查看 CLB 访问日志（需先在控制台开启日志投递到 COS）

日志字段包含: request_time, upstream_response_time, ssl_handshake_time

## 总结

CLB 负载均衡器远不止是"把请求分到多台服务器"这么简单。从技术本质上看，七层 CLB 是一个功能完整、性能卓越的反向代理——它理解 HTTP 协议，可以做域名路由、Header 改写、灰度发布、会话保持。四层 CLB 则是极低延迟的高性能转发器。二者组合使用，配合 CDN、WAF、VPC 等周边产品，构成了腾讯云国际版网络架构的真正骨架。

本文从技术原理、实战配置、自动化运维到故障排查，系统性地梳理了 CLB 在生产环境中的关键实践。建议读者按照"七层路由规则 → 会话保持调优 → 自动故障切换脚本"的顺序逐步深入，先在小范围验证再推广到全量。云上的每一层抽象都是为了让你用更少的代码和运维成本实现更可靠的架构，而 CLB 正是这个理念的典型代表。

---

> 本文由 [4.chengzicloud.cloud](https://4.chengzicloud.cloud) 提供，点击访问首页了解更多