1.21 亿条并发 gRPC 长连接背后：CloudFront 扩容不能忽略 DNS 路由

预计阅读时间：9 分钟

在体育赛事直播开始后的几秒内，1.21 亿台移动设备同时建立持久 gRPC 连接，这和普通 Web 流量不是同一种扩容问题。服务器数量、CloudFront 容量和网络带宽固然重要，但真正决定连接能否均匀落到后端的，可能是 DNS 记录背后的路由策略。策略选错后，所有客户端可能集中连接同一个源站入口，让已经准备好的其他容量闲置。

长连接改变了负载均衡的时间尺度

gRPC 遥测通常基于 HTTP/2 长连接。客户端完成 DNS 查询、TLS 握手并建立流后，会持续在同一条连接上传事件。与短 HTTP 请求不同，后端很难依靠下一次请求迅速重新分配负载。

这带来三个直接后果：

连接建立阶段决定长期分布。 开播瞬间形成的倾斜，可能持续到客户端重连。
DNS TTL 不是实时调度器。 解析器和移动网络可能缓存结果，已经建立的连接也不会因为 DNS 更新而自动迁移。
请求吞吐量不足以描述压力。 还要观察活跃连接数、每个入口的新建连接速率、HTTP/2 流数量、文件描述符和连接存续时间。

因此，“源站总容量足够”并不等于“入口可以承受突发”。如果 DNS 把大部分设备指向一个入口，整体扩容仍会失败。

DNS 策略为什么会放大热点

假设系统准备了三个独立入口，每个入口后面都有足够的计算资源。若权威 DNS 始终返回一个固定目标，或者路由策略在某个维度上产生偏斜，那么客户端看到的实际上仍是单入口系统。

加权、延迟、地理位置和故障转移策略解决的是不同问题：

策略	适合解决的问题	在长连接场景中的风险
加权路由	按预设比例分配新连接	DNS 缓存和递归解析器聚合会让实际比例偏离权重
延迟路由	将用户导向测得延迟较低的区域	某个区域可能因“最快”而吸收远超预期的连接
地理路由	按用户位置进行确定性分区	热门地区的流量可能远大于其他地区
故障转移	主入口异常时切换备用入口	备用入口必须能承受重连风暴，而不只是日常流量

关键问题不是哪一种策略永远正确，而是它是否与容量模型一致。延迟最优不代表容量最充足；固定地理分区也不代表赛事观众会均匀分布。

CloudFront 可以承担面向设备的边缘连接，但源站域名、入口分片和 DNS 决策仍需作为一个整体设计。尤其要确认每层究竟按请求、连接、解析器还是地理区域进行分配。

可以这样实践：创建可调权重的源站记录

下面是一个可改造的 Route 53 示例。它假设你已经有三个可独立承载流量的入口域名，并希望通过同一个源站域名分配新连接。请将托管区 ID、域名和三个目标地址替换为实际值。

export HOSTED_ZONE_ID="Z0123456789EXAMPLE"
export ORIGIN_NAME="telemetry-origin.example.com"

cat > /tmp/weighted-origins.json <<'JSON'
{
  "Comment": "Distribute new telemetry connections across three origin entry points",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "telemetry-origin.example.com",
        "Type": "CNAME",
        "SetIdentifier": "origin-a",
        "Weight": 40,
        "TTL": 30,
        "ResourceRecords": [{"Value": "origin-a.example.net"}]
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "telemetry-origin.example.com",
        "Type": "CNAME",
        "SetIdentifier": "origin-b",
        "Weight": 30,
        "TTL": 30,
        "ResourceRecords": [{"Value": "origin-b.example.net"}]
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "telemetry-origin.example.com",
        "Type": "CNAME",
        "SetIdentifier": "origin-c",
        "Weight": 30,
        "TTL": 30,
        "ResourceRecords": [{"Value": "origin-c.example.net"}]
      }
    }
  ]
}
JSON

aws route53 change-resource-record-sets \
  --hosted-zone-id "$HOSTED_ZONE_ID" \
  --change-batch file:///tmp/weighted-origins.json

这只是一个实践模型，不代表来源案例使用了相同权重。生产环境还需要结合健康检查、入口容量和故障域调整配置。权重也不能直接理解为设备连接占比，因为运营商递归 DNS、缓存和客户端重用都会影响结果。

变更后可以从多个网络或探针节点重复查询，观察答案分布：

for i in $(seq 1 20); do
  dig +short telemetry-origin.example.com
  sleep 1
done

如果要测试 gRPC 入口，且服务启用了反射，可以用 grpcurl 验证 TLS、HTTP/2 和服务可达性：

grpcurl -vv telemetry.example.com:443 list

大规模压测不能只从一个 VPC 或一台机器发起。单一压测源会受本地端口、NAT、带宽和递归 DNS 缓存限制，也无法复现真实移动网络中的解析分布。

上线前要盯住连接，而不只是请求

建议为每个入口分别建立以下指标：

每秒新建连接数和 TLS 握手失败率；
当前活跃 gRPC/HTTP/2 连接数；
连接建立延迟及其高分位数；
每个源站入口的连接占比，而不只是总请求占比；
GOAWAY、RST_STREAM、超时和客户端重连次数；
CPU、内存、文件描述符、NAT 端口及网卡吞吐量；
DNS 查询答案在不同地区、运营商和递归解析器上的分布。

还要提前设计过载行为。客户端应采用带抖动的指数退避，避免入口恢复时同步重连；服务端应设置连接和流并发上限；备用入口则要按照故障时的迁移流量验证容量。

采用这类架构时的判断清单

面对赛事直播这样的瞬时连接洪峰，可以按以下顺序检查：

明确 DNS 策略分配的是解析结果，而不是已经建立的连接。
按入口和故障域计算连接容量，不只计算全局总容量。
用赛事观众的真实地域和运营商分布校验路由策略。
在开播前预热入口，并进行分布式连接建立测试。
准备逐步调整权重的操作手册，避免一次性迁移全部长连接。
验证客户端退避、服务端限流和备用入口容量能够共同处理重连风暴。

1.21 亿并发连接说明云边缘网络可以支撑极端规模，但容量只有在流量能够正确抵达各个入口时才有价值。对于持久 gRPC 遥测，DNS 不是外围配置，而是连接扩容路径中的核心控制面。