移动测试/质量效能平台 + 性能监控平台 · 合并部署方案

移动测试 / 质量效能平台 + 性能监控平台 · 合并部署方案

把"实验室质量效能"与"线上性能监控"并入同一度量中枢，一份部署、一套看板、一组门禁。

Python FastAPI 后端 复用 Airtest/Appium/雷电/Allure docker-compose 一键起

一、合并后的总体架构

两条能力线（质量效能 + 性能监控）在接入层分流入门、在度量中枢收口归一。性能数据有"双源"：实验室性能（受控、可复现、用于回归门禁）与线上 APM（真实用户、用于告警与趋势），二者共用同一 TSDB 与同一质量门禁引擎。

接入层 Web 控制台 CLI / CI 插件 线上 APM 接入网关 能力层 设备农场 雷电模拟器+ 真机 ADB Hub 执行引擎 Airtest/Poco Appium/UA2/monkey 性能探针 实验室采集器+ 应用内 APM SDK 用例中心 功能+性能 基线/门禁 度量中枢 采集器(归一化) 计算引擎 存储(TSDB+PG+OSS) 展现+告警 门禁类型： 质量门禁(通过率/崩溃/ANR) ｜ 性能基线漂移(FPS/启动/内存阈值) ｜ DORA 四指标 数据源：实验室(可复现回归) ∪ 线上(真实用户趋势) → 同一 TSDB、同一看板 基础设施 消息队列 NATS 调度 Worker (Celery) 容器编排 docker/K8s

二、性能"双源"模型（合并的关键）

维度	实验室性能（Lab Perf）	线上 APM（Online Perf）
数据来源	设备农场跑性能用例（复用《雷霆分队》5 分钟随机冒烟范式：ADB 读 dumpsys/gfxinfo/batterystats + perfetto trace）	应用内 APM SDK（Matrix / Booster 风格：crash、ANR、冷启动、FPS、内存、流量）
环境	受控、固定机型/版本，可复现	真实用户、碎片化机型/系统
用途	性能回归门禁（PR/发版卡点）	线上告警、版本趋势、Top 劣化机型
采集频率	每次构建/定时任务	持续上报（采样/聚合）
落库	统一写入 VictoriaMetrics（TSDB），同一 label 体系（app / version / device / scenario）

合并收益：同一套 Grafana 看板同时看"实验室基线"和"线上真实值"；性能门禁既能在 CI 卡住劣化，也能在发版后持续盯梢。

三、部署拓扑（两种形态）

方案 A：单机 docker-compose（MVP / 演示 / 小团队）

一台机器（建议 Windows + WSL2 Docker Desktop 或 Linux）跑 docker-compose.yml 控制面；设备节点（雷电模拟器）以独立 Agent 跑在同一 Windows 主机或局域网内，注册到设备农场。

• 控制面：postgres / redis / nats / victoriametrics / minio / backend / worker / grafana
• 设备节点：Windows 主机跑雷电模拟器 + device-agent（ADB 暴露给 worker）
• 线上 APM：SDK 走公网/内网打到 backend 的接入网关
• 一键起：docker compose up -d

方案 B：分布式 / K8s（生产）

控制面与数据面分离，设备农场独立成节点池，横向扩展。

• 控制面 Pod：backend / worker / grafana（K8s Deployment）
• 数据面：托管的 PG + VictoriaMetrics + MinIO（或自建 StatefulSet）
• 设备农场：独立 Windows 节点池（雷电）+ Linux 节点（AVD/真机），NAT 穿透/专线回连
• 边缘：线上 APM 走公网网关 + WAF/限流，与 Lab 控制面隔离网络

⚠️ 雷电模拟器（LDPlayer）为 Windows 专属，设备节点须是 Windows；控制面容器可跑在 WSL2 或 Linux。不要把 emulator 塞进 Linux 容器。

四、组件 → 容器映射

能力	容器 / 服务	作用	端口
元数据	postgres	任务 / 用例 / 设备 / 门禁定义	5432
缓存 / broker	redis	调度 broker、会话缓存	6379
事件流	nats	测试事件 + APM 上报流式	4222
时序库	victoriametrics	性能/质量指标（双源归一）	8428
对象存储	minio	每步截图 / perfetto trace / 报告	9000/9001
后端中枢	backend	控制台 API + APM 网关 + 采集+计算	8000
执行调度	worker	消费任务、下发到设备 Agent	—
看板	grafana	质量门禁 + 性能基线 + 趋势	3000
设备节点（外部）	device-agent（Windows）	雷电模拟器 / 真机 ADB，受 worker 调度	自定

五、资源规格建议

规模	CPU	内存	存储	设备节点
MVP（单机）	4 核	8 GB	100 GB SSD	1×Windows(雷电×2实例)
小团队	8 核	16 GB	500 GB	2×Windows(雷电×4) + 2 真机
生产	弹性	弹性	TSDB 独立盘 1TB+	Windows 节点池 + 真机矩阵

六、分阶段落地路线（按依赖顺序）

阶段 1 · 复用即战力
把现有 Airtest 5 分钟随机冒烟 + Allure 报告 + 每步截图，包装成"平台可调度的任务"，先打通 Lab 质量闭环。

阶段 2 · 纳管设备
容器化纳管雷电模拟器（device-agent 注册设备农场），加设备列表页原型，支持任务派发到指定设备。

阶段 3 · 接入性能探针
Lab 端用 dumpsys/gfxinfo/perfetto 采 FPS/内存/启动；写入 VictoriaMetrics，配 Grafana 性能看板。

阶段 4 · 线上 APM
应用内 SDK 上报 crash/ANR/启动/FPS 到接入网关，与 Lab 共用 TSDB，补齐真实用户视角。

阶段 5 · 统一门禁
质量门禁 + 性能基线漂移合并为一套 CI 卡点；发版后持续盯梢，告警接入 IM。

零积分承诺：后端 Python、容器均开源；性能探针用系统自带 dumpsys + 轻量自研 SDK，不引入任何付费 APM SaaS。

七、红线与风险

⚠️ 度量红线（沿用之前框架约定）：

• 指标不与个人绩效挂钩，只用于改进流程；
• 采集 100% 自动化，禁止人工填表；
• 性能门禁阈值需评审基线，避免"假绿"（阈值过松）；
• 线上 APM 涉及用户数据，须脱敏、不采 PII、遵守隐私政策。

主要风险：雷电模拟器仅 Windows，跨节点调度需处理 Windows/Linux 混合环境；线上 APM 上报量需限流与采样，防止 TSDB 暴涨；性能基线要随机型迭代重标定。

移动测试/质量效能平台 + 性能监控平台 合并部署方案 · 单文件交付 · 配套 docker-compose.yml 可直接起控制面