3. 压测沙盘整体架构
压测沙盘的整体架构遵循“数据流驱动”的设计原则，从压测请求生成到最终可视化呈现，共分为四个核心层级。每一层承担明确的职责，并通过标准接口进行数据交换，确保系统具备高可观测性与故障隔离能力。
3.1 四层架构总览
下表概括了各层的核心组件、数据流向与关键指标，是理解整个沙盘的基础。
| 层级 | 核心组件 | 数据流向 | 关键观测指标 |
|---|---|---|---|
| 压测工具层 | benchmark / ghz / k6 | 生成请求 → 发送至 etcd 集群 | QPS、P99 延迟、错误率、并发数 |
| 数据采集层 | etcd 内置 metrics / OpenTelemetry Collector / cAdvisor | 拉取/推送指标 → 暂存于时序缓冲 | 采集延迟、丢点率、指标基数 |
| 存储层 | VictoriaMetrics / Thanos / Prometheus | 写入时序库 → 压缩/降采样 → 持久化 | 写入吞吐、磁盘 IO、数据保留周期 |
| 可视化层 | Grafana / 自定义 Dashboard | 查询存储层 → 渲染面板 → 告警触发 | 面板加载时间、查询并发、告警延迟 |
3.2 压测工具层
压测工具层是整个沙盘的流量发生器。根据测试目标的不同，选择不同的工具：
- benchmark（etcd 官方）：专为 etcd 设计的压测工具，支持 key-value 读写、事务、watch 等操作，输出延迟分布与吞吐量。
- ghz：gRPC 协议压测工具，适合模拟微服务间对 etcd 的 gRPC 调用，支持元数据注入与负载配置。
- k6：脚本化压测工具，可编写复杂业务场景（如模拟 leader 选举后的流量冲击）。
实践建议： 在压测沙盘中，建议同时运行 benchmark 与 ghz，分别覆盖 HTTP API 与 gRPC 接口，以暴露不同协议下的性能差异。
3.3 数据采集层
数据采集层负责从 etcd 集群及压测工具中收集指标，并做初步处理：
- etcd 内置 metrics：通过
/metrics端点暴露 Prometheus 格式指标，包括 Raft 状态、磁盘 fsync 延迟、请求速率等。 - OpenTelemetry Collector：作为统一采集网关，接收 metrics/traces，进行标签处理、采样、重试，再转发到后端存储。
- cAdvisor：采集容器级资源指标（CPU、内存、网络），用于关联 etcd 进程资源消耗与压测负载。
风险提示： 采集层容易成为瓶颈。当 etcd 集群 QPS 超过 10 万时，
/metrics 端点自身可能产生毫秒级延迟，需提前配置采集间隔（建议 ≥15s）并启用指标缓存。
3.4 存储层
存储层负责时序数据的持久化与查询加速。在压测沙盘中，推荐使用 VictoriaMetrics 作为主存储，其优势包括：
- 高写入吞吐：单实例可处理百万级指标/秒，适合压测场景的高频数据注入。
- 降采样与保留策略：自动对历史数据做降采样，降低存储成本，同时保留原始精度数据 7 天。
- PromQL 兼容：可直接对接 Grafana，无需修改查询语句。
| 存储方案 | 写入吞吐 | 压缩比 | 适用场景 |
|---|---|---|---|
| VictoriaMetrics | ~1M samples/s | 10:1 ~ 20:1 | 高并发压测、长期存储 |
| Thanos | ~500K samples/s | 5:1 ~ 10:1 | 多集群联邦、全局查询 |
| Prometheus | ~200K samples/s | 3:1 ~ 5:1 | 小规模压测、单机验证 |
3.5 可视化层
可视化层是 SRE 观测压测状态的窗口。Grafana 面板需覆盖以下核心视图：
- 实时 QPS 与延迟面板：展示当前压测请求速率、P99/P50 延迟，用于快速判断 etcd 是否达到性能拐点。
- Raft 状态面板：监控 leader 切换次数、提案提交延迟、日志同步速率，识别集群稳定性风险。
- 资源消耗面板：关联 etcd 进程的 CPU、内存、磁盘 IO，定位资源瓶颈。
- 告警事件面板：展示触发告警的时间线，辅助复盘压测过程中的异常行为。
面板复核要点： 在压测沙盘中，每次压测结束后需复核面板数据的完整性——检查是否存在断点、指标缺失或标签错乱。这是风险控制的第一道防线。
3.6 架构总结
压测沙盘的四层架构形成了完整的可观测性闭环：
- 压测工具层 生成可控负载；
- 数据采集层 确保指标无遗漏；
- 存储层 提供高性能写入与查询；
- 可视化层 将数据转化为可操作的洞察。