ALB流控功能Target Optimizer Agent逆向原理分析

请注意本文部分内容经过AI辅助生成，虽然经过笔者检查但是并不保证内容的正确性，请自行判断准确性，本文对相关后果不承担责任

AWS ALB Target Optimizer 是 2025 年底发布的新功能，允许用户为 ALB Target Group 配置容量感知的负载均衡。其核心依赖一个轻量级的 Target Control Agent，以 Sidecar 形式部署在应用旁边。

本文通过拉取官方镜像 public.ecr.aws/aws-elb/target-optimizer/target-control-agent:latest，对二进制进行逆向分析，并结合官方文档，还原其真实工作原理。

基础信息

项目	实际值
镜像地址	public.ecr.aws/aws-elb/target-optimizer/target-control-agent:latest
版本	0.0.1-beta.1+202512280148Z
基础系统	Amazon Linux 2023 (x86_64)
二进制路径	/opt/alb-target-control-agent/bin/alb-target-control-agent
二进制大小	15 MB
编程语言	Rust（构建工具链 brazil-rustup/toolchains/stable-x86_64-unknown-linux-gnu）
内部 crate 名	amzn-alb-target-control-0.1.1388
异步运行时	tokio 1.48.0
gRPC 框架	tonic 0.12.3
TLS 库	s2n-tls（AWS 自研，非 OpenSSL）
HTTP 框架	hyper + axum
运行时内存占用	~2.5 MB
运行时线程数	5
动态链接库	仅 libc、libm、libgcc_s（极简依赖）

Agent 采用双平面分离架构，数据流量和控制信号走不同的端口和协议：

                    控制平面 (gRPC over TLS)
ALB Proxy Node ◄══════════════════════════════► Agent (controlAddress :3000)│                                            ││         数据平面 (HTTP/HTTP2)               │└────────────────────────────────────────► Agent (dataAddress :80) ──► App (:8080)

端口职责

端口	环境变量	协议	用途
dataAddress	TARGET_CONTROL_DATA_ADDRESS	HTTP/HTTP2	接收 ALB 转发的应用流量
controlAddress	TARGET_CONTROL_CONTROL_ADDRESS	gRPC over TLS	与 ALB 交换管理信号
destinationAddress	TARGET_CONTROL_DESTINATION	HTTP	代理到实际后端应用

命令行参数

Usage: alb-target-control-agent [OPTIONS] --data-address <LISTEN> --control-address <GRPC_LISTEN> <DEST>Arguments:<DEST>                         上游应用地址 (IP:PORT)Options:--data-address <LISTEN>        数据监听地址--control-address <GRPC_LISTEN> 控制通道监听地址--max-concurrency <N>          最大并发数 (默认 1，范围 0-1000)--tls-cert-path <PATH>         TLS 证书路径 (PEM)，默认自动生成自签名证书--tls-key-path <PATH>          TLS 私钥路径 (PEM)--tls-security-policy <POLICY> TLS 安全策略--protocol-version <VERSION>   协议版本 (HTTP1/HTTP2/GRPC)--pid-file <PATH>              PID 文件路径

支持的 TLS 安全策略：

• ELBSecurityPolicy-TLS13-1-0-2021-06
• ELBSecurityPolicy-TLS13-1-0-FIPS-2023-04
• ELBSecurityPolicy-TLS13-1-0-FIPS-PQ-2025-09（后量子密码学）
• ELBSecurityPolicy-2016-08

核心工作原理

Agent 是一个内联反向代理（inline proxy）。所有从 ALB 到应用的流量都必须经过 Agent。Agent 通过直接代理流量来精确计数并发请求数

"The agent serves as an inline proxy between the load balancer and your application."
"The agent tracks the number of requests the target is processing."

gRPC 控制协议

从二进制 strings 提取出的 gRPC service 定义：

service TargetController {rpc WorkProbe(stream WorkStats) returns (stream WorkUpdate);
}

这是一个双向流式 RPC。ALB 作为 gRPC client 连接 Agent（gRPC server），双方在同一个长连接上持续互发消息。

WorkStats — ALB → Agent 方向

message WorkStats {timestamp recorded_at       // 统计时间戳int work_queue_length       // ALB 侧排队等待分配给此 target 的请求数int idle_targets            // 当前空闲的 target 数量（全局视角）int total_requests          // 累计总请求数int accepted_requests       // 累计被接受的请求数int rejected_requests       // 累计被拒绝的请求数int total_work_tokens       // 累计收到的 work token 总数
}

ALB 周期性地把自己观察到的全局状态发送给 Agent

1. 状态同步与对账：Agent 发出 AssignWork 后不知道 ALB 是否收到。ALB 通过 total_work_tokens 回传"我一共收到了多少个令牌"，让双方账本对齐。
2. 全局视角补充：Agent 只知道自己这一个 target 的情况，ALB 通过 idle_targets、work_queue_length 等字段提供集群全局视角。
3. 一致性校验：Agent 要求这些计数器单调递增，如果出现倒退会记录异常日志。

Agent 的校验逻辑：

"Received a Stats update with reduced total_work_tokens, was X and received Y which is invalid"
"Received a Stats update with reduced total_requests, was X"
"Received a Stats update with an out of order timestamp"
"Received a Stats update with the same timestamp as the last update"

WorkUpdate — Agent → ALB 方向

message WorkUpdate {oneof update {AssignWork assign_workCancelWork cancel_work}
}message AssignWork {string work_id        // 工作令牌 IDduration expires_in   // 令牌过期时间
}message CancelWork {string work_id        // 要取消的令牌 ID
}

Agent 根据自己的并发余量，主动向 ALB 发放或回收令牌：

• AssignWork："我有空位了，给你一个 work_id，你可以在 expires_in 时间内用它发一个请求过来"
• CancelWork："这个 work_id 作废了，别用了"（应用压力变大、令牌超时未使用等）

完整请求流程

1.  ALB 连接 Agent 的 controlAddress，建立 gRPC 双向流
2.  ALB 开始发送 WorkStats 流（周期性状态同步）
3.  Agent 检查：max_concurrency=5，当前并发=2，还有 3 个空位
4.  Agent 发送 AssignWork{work_id="abc", expires_in=30s}
5.  Agent 发送 AssignWork{work_id="def", expires_in=30s}
6.  Agent 发送 AssignWork{work_id="ghi", expires_in=30s}
7.  ALB 收到 3 个 work_id，放入可用令牌池
8.  用户请求到达 ALB，ALB 取出 work_id="abc"
9.  ALB 通过 dataAddress 发送 HTTP 请求，header 带上：x-amzn-target-control-work-id: abc
10. Agent 收到请求，用 work_id 创建 WorkPermit 对象，并发计数 +1
11. Agent 将请求代理转发给后端应用 127.0.0.1:8080
12. 应用处理完毕，响应返回
13. WorkPermit 对象被 Drop（Rust RAII 机制），并发计数 -1
14. Agent 通过 gRPC 流发送 WorkUpdate 通知 ALB 令牌已释放
15. Agent 又有空位，继续发送新的 AssignWork

这是一个具名令牌桶机制：

• Agent 是令牌的发放者
• ALB 是令牌的消费者
• 每个令牌有唯一 ID（work_id）和过期时间（expires_in）
• 令牌不是简单的数字计数，而是可追踪、可取消、可过期的具名对象

WorkPermit 的 RAII 生命周期

从 Rust 符号表提取的关键类型：

amzn_alb_target_control::agent::work_permit::WorkPermitimpl Drop for WorkPermit  // 请求完成时自动释放

WorkPermit 实现了 Rust 的 Drop trait，这意味着：

• 请求进来 → 创建 WorkPermit → 并发 +1
• 请求结束（无论成功、失败、超时）→ WorkPermit 自动 Drop → 并发 -1 → 通知 ALB

这种 RAII 模式保证了并发计数的绝对准确性，不会出现泄漏。

Proxy Manager — 多 ALB 节点管理

从符号表提取的关键类型：

amzn_alb_target_control::agent::main::ProxyManager
amzn_alb_target_control::agent::main::Proxy

Agent 内部有 ProxyManager 管理多个 Proxy（即多个 ALB 节点）。每个 ALB 节点独立建立 gRPC 连接，Agent 跟踪每个 proxy 的并发状态。相关日志字符串：

"No proxies currently registered, exiting maxcon check"
"assigned to proxy X, concurrency is Y/Z (N active work_ids)"
"cancelling work_id X for proxy Y because it was being hoarded"
"Goodbye Proxy from X!"

注意 "hoarding" 检测 — Agent 会防止某个 ALB 节点囤积 work_id 不使用。

优雅关闭

Agent 支持优雅关闭，从日志字符串可以看到：

"Ctrl-C received, starting shutdown"
"Gracefully shutdown - all connections completed!"
"Waited 10 seconds for graceful shutdown, aborting..."

流程：

1. 收到 SIGTERM/SIGINT
2. 停止接受新连接
3. 等待存量请求处理完毕
4. 10 秒超时后强制退出

TLS 安全

• 控制通道默认启用 TLS（Agent 自动生成自签名证书）
• 使用 AWS 自研的 s2n-tls 库（非 OpenSSL）
• 支持 TLS 1.3、FIPS 合规、后量子密码学（PQ）安全策略
• 数据通道支持 HTTP/1.1 和 HTTP/2

Kubernetes 部署

部署方式

官方支持两种部署方式：

方式一：手动 Sidecar

initContainers:- name: alb-target-control-agentimage: public.ecr.aws/aws-elb/target-optimizer/target-control-agent:latestrestartPolicy: Alwaysenv:- name: TARGET_CONTROL_DATA_ADDRESSvalue: "0.0.0.0:80"- name: TARGET_CONTROL_CONTROL_ADDRESSvalue: "0.0.0.0:3000"- name: TARGET_CONTROL_DESTINATIONvalue: "127.0.0.1:8080"- name: TARGET_CONTROL_MAX_CONCURRENCYvalue: "100"ports:- containerPort: 80- containerPort: 3000

方式二：自动注入

通过 AWS Load Balancer Controller 的 Mutating Webhook 自动注入，类似 Istio sidecar 注入机制。需要：

1. 安装 ALBTargetControlConfig CRD
2. 配置 Mutating Webhook
3. 给 Namespace 或 Pod 打标签启用注入

Ingress 配置

annotations:alb.ingress.kubernetes.io/target-type: ip  # 必须使用 ip 模式alb.ingress.kubernetes.io/target-control-port.${serviceName}.${servicePort}: "3000"

Service 的 targetPort 指向 Agent 的 dataAddress（如 80），而非应用端口。

参考资料

1. AWS Load Balancer Controller - Target Control Agent 官方文档
2. ALBTargetControlConfig Spec
3. Ingress Annotations - target-control-port
4. ALB Target Optimizer 发布公告
5. ECR Gallery - target-control-agent