1. 课程导论：Backstage 是什么、插件生态概览、容量规划与故障域的基本概念
1.1 Backstage 平台定位与核心价值
Backstage 是 Spotify 开源并捐赠给 CNCF 的内部开发者门户（IDP）平台，旨在解决微服务架构下日益增长的“开发者体验碎片化”与“基础设施复杂度”之间的矛盾。它通过统一的软件目录、插件化架构和可定制的工程模板，将分散在 Jenkins、GitHub、Kubernetes、Datadog、PagerDuty 等工具中的运维数据与开发流程整合到单一控制面。
| 维度 | 传统模式痛点 | Backstage 解决方式 |
|---|---|---|
| 服务发现 | Wiki 文档过期、Confluence 散乱 | 软件目录（Software Catalog）自动同步实体元数据 |
| 工具链整合 | 多平台跳转、上下文切换频繁 | 统一插件面板，单点查看 CI/CD、监控、告警 |
| 标准化治理 | 各团队自建脚手架，质量参差 | 软件模板（Software Templates）强制最佳实践 |
| 权限与合规 | RBAC 分散、审计困难 | 统一身份与访问策略，集中审计日志 |
关键认知：Backstage 不是又一个 CI/CD 工具或监控面板，而是“开发者体验的操作系统”——它本身不产生数据，而是通过插件将已有系统的数据与操作能力编排到一处。
1.2 插件生态概览
Backstage 的扩展性完全依赖插件体系。每个插件是一个独立的功能模块，可以读取软件目录中的实体信息，并在前端 UI 中渲染专属卡片或页面。插件之间通过“实体上下文”和“API 注册表”进行松耦合通信。
- 核心插件（Core Plugins）：软件目录、软件模板、技术文档（TechDocs）、搜索、权限管理。
- 基础设施插件：Kubernetes 插件、AWS/GCP/Azure 资源视图、Terraform 状态展示。
- 可观测性插件：Datadog、Grafana、Prometheus、Sentry、Jaeger 集成。
- CI/CD 插件：GitHub Actions、GitLab CI、Jenkins、CircleCI、ArgoCD。
- 协作与告警：PagerDuty、Opsgenie、Slack、Jira。
插件隔离的起点：每个插件在运行时拥有独立的“插件 ID”和“权限作用域”，但默认情况下它们共享同一个后端进程与数据库连接池。当某个插件出现内存泄漏或慢查询时，可能影响整个 Backstage 实例的稳定性——这正是本课程要解决的容量规划与故障域问题。
1.3 容量规划的基本概念
在 Backstage 场景下，容量规划不是简单的“算 QPS 和内存”，而是围绕插件级资源消耗展开的精细化工程。每个插件可能因为数据源规模、查询复杂度、缓存策略不同，产生差异极大的资源需求。
| 容量维度 | 典型指标 | Backstage 插件影响示例 |
|---|---|---|
| CPU | 请求处理速率、模板渲染 | TechDocs 插件在 Markdown 转 HTML 时突发 CPU 峰值 |
| 内存 | 堆使用率、缓存命中率 | Kubernetes 插件缓存大量集群资源对象，易导致 OOM |
| 数据库连接 | 连接池水位、慢查询 | 软件目录插件频繁查询实体关系，连接池耗尽影响全局 |
| 网络带宽 | 出站请求量、API 限频 | Datadog 插件拉取指标时可能触发外部 API 限流 |
常见误区：很多团队只对 Backstage 整体做“垂直扩容”（增加单实例内存），忽略了“水平隔离”的价值。当某个插件出现内存泄漏时，垂直扩容只能延缓崩溃，无法阻止故障扩散到其他插件。
1.4 故障域的基本概念
故障域（Failure Domain）是指系统中一个组件失效后，不会导致其他组件失效的隔离边界。在 Backstage 插件架构中，故障域的设计直接决定了爆炸半径——即一个插件出问题时，会影响多少用户和功能。
- 进程级故障域：每个插件运行在独立进程中，一个进程崩溃不影响其他进程。代价是资源开销大，进程间通信复杂。
- 容器级故障域：每个插件部署为独立容器（Pod），利用 Kubernetes 资源配额（ResourceQuota）和限制范围（LimitRange）做硬隔离。这是当前最推荐的隔离粒度。
- 集群级故障域：将不同重要级别的插件部署到不同 Kubernetes 集群，甚至不同区域（Region）。适用于跨团队、跨合规域的极端隔离场景。
1.5 容量规划与故障域的关联
容量规划与故障域不是两个独立课题，而是同一枚硬币的两面。故障域决定了“隔离到什么粒度”，容量规划决定了“每个隔离单元需要多少资源”。两者结合才能回答以下关键问题：
- 每个插件 Pod 应该分配多少 CPU 和内存？——基于历史监控数据与压力测试。
- 哪些插件应该共享同一个 Pod？——根据依赖关系与故障容忍度。
- 当某个插件流量突增时，如何保证不挤占其他插件的资源？——通过 Kubernetes ResourceQuota 与 LimitRange 实现硬隔离。
- 跨集群部署时，如何保证插件数据的一致性？——通过 Backstage 的“实体提供者”模式与事件总线。