4. 流量采集挑战：并发请求的弹性伸缩、请求来源的不可预测性、API Gateway与函数之间的流量映射
在无服务器架构中，流量（Traffic）是衡量系统负载与用户体验的核心信号。然而，与传统的固定容量架构不同，无服务器环境的流量采集面临着三大独特挑战：并发请求的弹性伸缩、请求来源的不可预测性以及API Gateway与函数之间的流量映射。本节将深入剖析这些挑战，并提供可落地的采集策略。
4.1 并发请求的弹性伸缩：从“容量规划”到“并发配额”
传统架构中，流量采集通常基于固定实例数（如 N 台服务器）的 CPU/内存使用率。而在无服务器架构中，函数实例会从 0 弹性扩展到数千个并发实例。此时，请求速率（RPS） 和 并发执行数（Concurrent Executions） 成为衡量流量的关键指标。
- 请求速率（RPS）： 每秒到达 API Gateway 或触发函数的请求总数。反映入口流量压力。
- 并发执行数： 在任意给定时刻，正在被函数实例处理的请求数量。反映系统当前的并行处理深度。
- 并发配额： 云平台为每个 AWS 账户或区域设定的最大并发执行数上限（如 AWS Lambda 默认 1000）。
采集并发请求的挑战在于：弹性伸缩的滞后性与冷启动会导致流量瞬间尖刺被截断。例如，当 RPS 从 100 瞬间飙升至 10000 时，函数实例的创建速度可能跟不上请求到达速度，导致部分请求被限流（Throttling）。
(ConcurrentExecutions / ReservedConcurrency) * 100，以提前预警配额耗尽风险。
4.2 请求来源的不可预测性：从“固定客户端”到“万物互联”
无服务器架构的流量来源极其分散：Web 浏览器、移动 App、IoT 设备、定时触发器（CloudWatch Events）、消息队列（SQS）、事件总线（EventBridge）等。这种不可预测性给流量采集带来了两个难题：
- 来源标识困难： 不同来源的请求可能经过同一个 API Gateway 端点，但请求头、IP 段、User-Agent 差异巨大，难以统一归类。
- 流量模式碎片化： 用户行为驱动的流量（如电商秒杀）与后台事件驱动的流量（如 S3 文件上传处理）的峰值时段、并发特征完全不同。
| 请求来源类型 | 典型特征 | 采集难点 | 推荐采集维度 |
|---|---|---|---|
| Web / 移动端 | 高 RPS，突发性强 | 需要区分用户会话 | , User-Agent, 地理区域 |
| IoT 设备 | 低 RPS，长连接，周期性 | 设备 ID 可能重复或缺失 | 设备 ID (X-Device-Id), 协议类型 |
| 事件驱动 (S3/SQS) | 异步，批量到达 | 无直接 HTTP 上下文 | 事件源 ARN, 消息组 ID |
| 定时触发器 | 固定周期，可预测 | 容易与其他流量混淆 | 触发器名称, Cron 表达式 |
X-Source-Type 或 X-Request-Id 等自定义标识。
4.3 API Gateway 与函数之间的流量映射：从“黑盒”到“可观测”
在无服务器架构中，API Gateway 是流量的第一入口，而函数是流量的最终处理单元。两者之间存在一个关键的映射断层：API Gateway 记录的指标（如 Count、4XXError、5XXError）与函数记录的指标（如 Invocations、Errors、Duration）在时间戳、请求 ID 和错误分类上往往不完全对齐。
这种断层会导致以下问题：
- 错误归因困难： API Gateway 返回 502，但函数日志显示正常执行，实际是 Gateway 超时设置过短。
- 流量丢失： API Gateway 统计到 1000 个请求，但函数只收到 950 个 Invocations，中间的 50 个请求可能在 Gateway 层被 WAF 拦截或限流。
- 延迟拆分不准确： 无法区分“网络传输延迟”与“函数执行延迟”。
1. 在 API Gateway 阶段启用 详细 CloudWatch 日志，记录每个请求的
requestId 和 integrationLatency。2. 在函数代码中，通过
context.awsRequestId 获取 AWS 内部请求 ID，并将其作为结构化日志的字段输出。3. 使用 分布式追踪（如 AWS X-Ray 或 OpenTelemetry）将 API Gateway 的 Trace ID 透传到函数，实现请求级别的映射。
4.4 流量采集的黄金指标清单
综合以上挑战，我们整理出一份针对无服务器架构流量采集的黄金指标清单。这些指标应作为可观测性平台的必选采集项：
| 指标名称 | 来源 | 采集粒度 | 告警阈值建议 |
|---|---|---|---|
| RequestCount | API Gateway | 1 分钟 | 基于基线 + 200% 突发 |
| ConcurrentExecutions | Lambda | 1 分钟 | 账户配额的 80% |
| Throttles | Lambda | 1 分钟 | > 0 持续 5 分钟 |
| IntegrationLatency | API Gateway | p50/p95/p99 | p99 > 函数超时时间 * 0.8 |
| 4XXError / 5XXError | API Gateway | 1 分钟 | 错误率 > 1% |
| Invocations | Lambda | 1 分钟 | 与 RequestCount 偏差 > 5% |
# 获取 API Gateway 请求计数
aws cloudwatch get-metric-statistics \
--namespace AWS/ApiGateway \
--metric-name Count \
--dimensions Name=ApiName,Value=my-api \
--start-time $(date -u -d '5 minutes ago' +%Y-%m-%dT%H:%M:%SZ) \
--end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
--period 60 \
--statistics Sum
# 获取 Lambda 并发执行数
aws cloudwatch get-metric-statistics \
--namespace AWS/Lambda \
--metric-name ConcurrentExecutions \
--dimensions Name=FunctionName,Value=my-function \
--start-time $(date -u -d '5 minutes ago' +%Y-%m-%dT%H:%M:%SZ) \
--end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
--period 60 \
--statistics Average通过以上指标的组合分析，SRE 团队可以快速定位流量异常：例如，当 RequestCount 正常但 ConcurrentExecutions 飙升时，说明函数处理变慢（可能是代码性能问题或外部依赖延迟）；当 Throttles 出现时，应立即检查并发配额并考虑启用预置并发（Provisioned Concurrency）。