AV Chaos Monkey

分布式混沌工程平台，用于对视频会议系统进行负载测试。模拟超过1500个WebRTC参与者，传输H.264/Opus流，并注入网络混沌尖峰，以验证系统在降级条件下的韧性

架构

媒体处理管道：
- FFmpeg 在启动时将输入视频转换为 H.264 Annex-B 和 Ogg/Opus
- NAL Reader 解析 H.264 流（SPS/PPS/IDR/Slices）
- Opus Reader 从 Ogg 容器中提取 20ms 音频帧
- 帧数据缓存在内存中，所有参与者共享（零拷贝）
- 相比每个参与者独立编码，CPU 降低约 90%
控制平面：
- HTTP 服务（:8080）通过 REST API 管理测试生命周期
- 尖峰调度器分配混沌事件（均匀/随机/前载/后载/遗留）
- 网络降级器应用混沌：丢包（1-25%）、抖动（10-50ms）、码率降低（30-80%）、丢帧（10-60%）
- 加载的混沌配置应用到参与者池
参与者池：
- 基于 participant_id % total_partitions = partition_id 自动跨 Pod 分区
- 每个参与者生成 RTP 流（PT=96 视频，PT=111 音频）
- 参与者 ID 嵌入 RTP 扩展头（ID=1）
- 池大小：1-100（本地），100-500（Docker），500-1500（Kubernetes）
Kubernetes 自动配置：
- Pod 从 Pod 名称自动检测分区 ID：orchestrator-3 → PARTITION_ID=3
- 端口分配：base_port + (partition_id × 10000) + participant_index
- 示例：分区 0 使用 5000-14999，分区 1 使用 15000-24999
- StatefulSet 有 10 个副本，每个处理约 150 个参与者
- 资源：每个 Pod 1-4 CPU，2-4Gi 内存
- 根据宿主机规格自动配置
UDP 中继链（仅 Kubernetes）：
```
Orchestrator Pods (10×) → UDP :5000 → udp-relay Pod (Python)
→ Length-Prefixed TCP :5001 → kubectl port-forward 15001:5001
→ tools/udp-relay (Go) → UDP :5002 → Your Receiver
```
- 原因：kubectl port-forward 仅支持 TCP，不支持 UDP
- 集群内中继：Python 脚本从所有 Pod 聚合 UDP，以带 2 字节长度前缀的 TCP 流形式传输
- 本地中继：Go 工具将 TCP 流转换回 UDP 数据包
- 将 1500 个参与者流聚合为单个连接
WebRTC 基础设施：
- Coturn StatefulSet：3 个初始副本，HPA 根据负载在 1-10 间伸缩（约 500 参与者/副本）
- coturn-lb 服务：在副本间负载均衡 TURN 流量
- webrtc-connector：可选的代理层（Deployment + HPA 2-10 副本），处理 SDP 信令
- Docker 模式：单个 Coturn 容器用于本地测试
- 端口：3478（TURN），49152-65535（中继范围）
- 凭据：webrtc/webrtc123
客户端集成：
- UDP 接收器：通过中继链接收来自所有参与者的聚合 RTP 流
- WebRTC 接收器：通过 TURN 服务器进行 SDP 交换，建立 1:1 WebRTC 连接
- 两者都将流转发给你正在测试的视频通话系统（SFU/MCU/Mesh）
可观测性栈（可选）：
- Prometheus：每 5 秒从所有编排器 Pod 的 /metrics 端点抓取数据
- Grafana：通过预配置仪表盘（admin/admin）可视化指标
- 暴露的指标：参与者数量、发送数据包数、发送字节数、活跃尖峰数、丢包率%、抖动、MOS 评分
- 访问：Prometheus :30090，Grafana :30030（NodePort）
- 编排器 Pod 带有自动发现注解：prometheus.io/scrape: "true"

核心概念

参与者模拟

每个虚拟参与者生成真实的媒体流：

视频：来自实际视频文件的 H.264 NAL 单元，按 RFC 6184 封装
音频：来自 Ogg 容器的 Opus 帧，按 RFC 7587 封装
RTP：符合标准的头部，包含参与者 ID 扩展
时序：帧级精确时序（30fps 视频，20ms 音频数据包）

混沌注入

五种尖峰类型模拟现实网络条件：

丢包：在应用层丢弃 RTP 数据包（1-100%）
网络抖动：增加延迟变化（基础延迟 + 高斯抖动）
码率降低：限制视频编码码率（减少 30-80%）
丢帧：跳过视频帧（丢弃率 10-60%）
带宽限制：限制总吞吐量

分布策略

尖峰按可配置策略分布在测试持续时间内：

均匀：带抖动的均匀间隔（可预测的负载）
随机：不可预测的时机（真实的混沌）
前载：早期密集尖峰（恢复测试）
后载：基线后引入混沌（对比测试）
遗留：固定间隔计时器（运行时注入）

分区

Kubernetes 部署使用参与者分区进行水平扩展：

每个 Pod 处理 participant_id % total_partitions == partition_id
端口分配：base_port + (partition_id * 10000) + participant_index
在 1-10 个 Pod 间自动负载分配
可扩展到 1500+ 参与者（每个 Pod 150 个）

运行系统

1. 本地开发（原生 Go）

最佳用途：开发、调试、小规模测试（1-100 参与者）

# 启动编排器
go run cmd/main.go

# 另一个终端：启动 UDP 接收器
go run examples/go/udp_receiver.go 5002

# 编辑 config/config.json 设置 num_participants: 10
# 运行混沌测试
go run tools/chaos-test/main.go -config config/config.json

执行过程：

单个编排器进程监听 :8080
参与者向 127.0.0.1:5002 发送 UDP
通过 HTTP API 注入混沌尖峰
每 2 秒显示实时指标

配置（config/config.json）：

{
  "base_url": "http://localhost:8080",
  "media_path": "public/rick-roll.mp4",
  "num_participants": 10,
  "duration_seconds": 300,
  "spikes": {
    "count": 20,
    "interval_seconds": 5,
    "types": { "rtp_packet_loss": {...}, "network_jitter": {...} }
  },
  "spike_distribution": {
    "strategy": "random",
    "min_spacing_seconds": 5,
    "jitter_percent": 15
  }
}

2. Docker Compose（容器化）

最佳用途：隔离测试、CI/CD、中规模测试（100-500 参与者）

前提条件：

Docker Desktop 分配 8-16GB 内存
已安装 docker-compose

# 构建并启动编排器容器
./scripts/start_everything.sh build

# 另一个终端：启动 UDP 接收器
go run examples/go/udp_receiver.go 5002

# 编辑 config/config.json 设置 num_participants: 100
# 运行混沌测试（目标为容器）
go run tools/chaos-test/main.go -config config/config.json

资源限制（编辑 docker-compose.yaml）：

services:
  orchestrator:
    deploy:
      resources:
        limits:
          cpus: "14.0"
          memory: 6G  # 增加以容纳更多参与者

扩缩指南：

Docker 内存	最大参与者数	CPU 核心数
8 GB	~100	4
16 GB	~250	8
24 GB	~400	12
32 GB	~500	14

3. 使用 Nix 的 Kubernetes（生产规模）

最佳用途：大规模测试（500-1500 参与者）、水平扩展、生产验证

前提条件：

启用 flakes 的 Nix
Docker Desktop 或 kind 集群
配置好的 kubectl

第一步：进入 Nix 环境

# Nix 提供：Go、Docker、kubectl、kind、ffmpeg
nix develop

# 或使用 direnv 自动激活
echo "use flake" > .envrc
direnv allow

第二步：部署到 Kubernetes

# 自动部署并优化设置（检测系统资源）
./scripts/start_everything.sh run -config config/config.json

# 或指定自定义媒体文件
./scripts/start_everything.sh run --media=path/to/video.mp4 -config config/config.json

执行过程：

使用 Nix 提供的 Go 工具链构建 Docker 镜像
创建/使用 kind 集群
部署包含 10 个编排器 Pod 的 StatefulSet
部署 UDP 中继 Pod
设置 UDP 中继的 kubectl port-forward
启动本地 TCP→UDP 中继
跨所有 Pod 运行混沌测试

第三步：接收聚合的 UDP 流

选项 A：UDP 接收器（推荐用于 Kubernetes）

# 接收来自所有 1500 个参与者的聚合流
go run ./examples/go/udp_receiver.go 5002

选项 B：WebRTC 接收器（多个参与者）

# 通过 WebRTC 连接最多 150 个参与者
go run ./examples/go/webrtc_receiver.go http://localhost:8080 <test_id> 150

架构流程：

1500 个参与者分布在 10 个 Pod 上
  → 每个 Pod：150 个参与者
  → 按 participant_id % 10 分区
  → 全部向 udp-relay:5000 发送 UDP
  → UDP 中继聚合 → TCP :5001
  → kubectl port-forward 15001:5001
  → 本地中继转换 TCP → UDP :5002
  → 你的接收器获取全部 1500 个流

注意：start_everything.sh 脚本会自动设置：

kubectl port-forward（udp-relay 15001:5001）
本地 TCP→UDP 中继（tools/udp-relay）
你只需运行接收器

手动 Kubernetes 设置

# 构建并加载镜像
docker build -t chaos-monkey-orchestrator:latest .
kind load docker-image chaos-monkey-orchestrator:latest

# 部署
kubectl apply -f k8s/orchestrator/orchestrator.yaml
kubectl apply -f k8s/udp-relay/udp-relay.yaml

# 等待 Pod 就绪
kubectl wait --for=condition=ready pod -l app=orchestrator --timeout=300s

# 端口转发 UDP 中继
kubectl port-forward udp-relay 15001:5001 &

# 启动本地 TCP→UDP 中继
go run tools/udp-relay/main.go &

# 另一个终端：启动接收器
go run ./examples/go/udp_receiver.go 5002

# 另一个终端：运行混沌测试
go run tools/chaos-test/main.go -config config/config.json

清理

# 删除 Kubernetes 资源
./scripts/cleanup.sh

# 或删除整个集群
kind delete cluster --name av-chaos-monkey

使用 Nix 的跨平台构建

# 为 Linux x86_64 构建（最常见）
nix build .#packages.x86_64-linux.av-chaos-monkey

# 为 ARM64 构建（Raspberry Pi、AWS Graviton）
nix build .#packages.aarch64-linux.av-chaos-monkey

# 为 macOS Intel 构建
nix build .#packages.x86_64-darwin.av-chaos-monkey

# 为 macOS Apple Silicon 构建
nix build .#packages.aarch64-darwin.av-chaos-monkey

# 二进制文件位置
./result/bin/main

API 参考

测试生命周期

# 创建测试
POST /api/v1/test/create
{
  "test_id": "optional_id",
  "num_participants": 100,
  "video": {...},
  "audio": {...},
  "duration_seconds": 600,
  "spikes": [...],
  "spike_distribution": {
    "strategy": "even",
    "min_spacing_seconds": 5,
    "jitter_percent": 15
  }
}

# 启动测试
POST /api/v1/test/{test_id}/start

# 获取指标
GET /api/v1/test/{test_id}/metrics

# 停止测试
POST /api/v1/test/{test_id}/stop

WebRTC 信令

# 获取 SDP 提议
GET /api/v1/test/{test_id}/sdp/{participant_id}

# 设置 SDP 应答
POST /api/v1/test/{test_id}/sdp/{participant_id}
{"sdp_answer": "v=0..."}

混沌注入

# 注入尖峰
POST /api/v1/test/{test_id}/spike
{
  "spike_id": "unique_id",
  "type": "rtp_packet_loss",
  "duration_seconds": 30,
  "participant_ids": [1001, 1002],
  "params": {"loss_percentage": "15"}
}

AV-Chaos-Monkey

最受欢迎

AV Chaos Monkey

架构

核心概念

参与者模拟

混沌注入

分布策略

分区

运行系统

1. 本地开发（原生 Go）

2. Docker Compose（容器化）

3. 使用 Nix 的 Kubernetes（生产规模）

第一步：进入 Nix 环境

第二步：部署到 Kubernetes

第三步：接收聚合的 UDP 流

手动 Kubernetes 设置

清理

使用 Nix 的跨平台构建

API 参考

测试生命周期

WebRTC 信令

混沌注入

配置