4. Backstage 插件资源需求分析：CPU、内存、存储的典型需求与基线评估

在实施冷启动削峰之前，必须精确掌握每个插件的资源消耗特征。Backstage 插件并非“轻量无状态”的单一模型——不同插件在 CPU 计算密度、内存驻留模式、存储访问频次上存在显著差异。本章将建立一套可量化的资源基线评估方法，为后续的配额设置与镜像预热提供数据依据。

4.1 三类典型插件的资源消耗模型

根据 Backstage 社区与生产环境统计，插件可按资源消耗特征分为三类。下表列出了每类插件的典型代表与资源画像：

4.2 资源基线评估的四个维度

评估插件资源基线不能仅依赖文档标称值，必须通过实际压测获得。推荐采用以下四维评估法：

1. 稳态基线（Steady-State Baseline）：插件在无用户请求、仅维持心跳与后台同步时的资源占用。
2. 峰值基线（Peak Baseline）：插件在承受最大并发请求（通常为 50–100 QPS）时的资源上限。
3. 冷启动基线（Cold-Start Baseline）：插件从容器启动到首次就绪期间的最大资源瞬时值。
4. 存储增长基线（Storage Growth Baseline）：插件运行 24 小时后本地缓存/日志的增量速率。

4.3 评估工具与命令示例

以下是在 Kubernetes 环境中获取插件资源基线的标准命令组合：

# 1. 查看插件 Pod 的实时资源使用（每 2 秒采样）
kubectl top pod -n backstage -l app=backstage-plugin-catalog \
  --containers --interval=2s

# 2. 获取冷启动阶段的资源峰值（需在 Pod 启动后立即执行）
kubectl logs -n backstage deployment/backstage-plugin-catalog \
  --tail=50 | grep "resource_usage"

# 3. 使用 Prometheus 查询历史内存趋势（适用于已部署的环境）
# 查询语句示例（PromQL）：
# max_over_time(container_memory_working_set_bytes{
#   namespace="backstage",
#   container="plugin-catalog"
# }[5m]) / (1024*1024)

4.4 资源基线评估流程（SVG 图）

下图展示了从采集到基线输出的完整评估流程，建议在每个插件上线前执行一次：

4.5 典型插件资源基线参考表

以下数据基于 Backstage 1.20+ 版本在 4 核 8 GiB 节点上的实测结果，可作为初始配额设置的参考起点：

4.6 存储需求专项分析

存储是插件冷启动削峰中最容易被忽视的维度。Backstage 插件的存储消耗主要来自以下三个方面：

• 本地缓存（Local Cache）：Catalog 插件的实体缓存、TechDocs 的文档渲染缓存，通常占用 500 MiB–5 GiB。
• 日志与审计（Logs & Audit）：插件运行日志、API 调用审计，按天增长约 100–500 MiB。
• 临时工作目录（Temp Workspace）：插件在构建、渲染、代码分析时产生的中间文件，生命周期短但瞬时占用大。

评估存储基线时，建议使用以下命令监控临时卷的使用率：

# 查看插件挂载的 emptyDir 卷使用情况（需进入容器）
kubectl exec -n backstage deploy/plugin-catalog -- df -h /cache

# 通过 Prometheus 监控 PVC 增长趋势
# container_fs_usage_bytes{namespace="backstage", pod=~"plugin-.*"}

4.7 基线评估的常见误区与避坑