1. 课程导论：Backstage 平台概述、服务目录概念、容量水位巡检的重要性、故障排查的挑战
1.1 Backstage 平台概述
Backstage 是由 Spotify 开源并捐赠给 CNCF 的开发者门户平台，旨在解决微服务架构下日益增长的“基础设施碎片化”与“认知负载”问题。它通过统一的插件化架构，将分散在 Jenkins、GitLab、Prometheus、Kubernetes 等工具中的信息与操作聚合到单一界面，成为开发者与运维人员的“统一指挥中心”。
1.2 服务目录概念
服务目录是 Backstage 的“数据大脑”，它通过 实体模型（Entity Model） 将组织内的所有软件组件（微服务、API、网站、库、资源等）进行标准化建模。每个服务在目录中都是一个实体，包含元数据、技术栈、负责人、依赖关系、API 定义等关键信息。
| 实体类型 | 描述 | 典型 YAML 标识 |
|---|---|---|
| Component | 软件组件（微服务、前端应用、库） | kind: Component |
| API | 服务对外暴露的接口定义 | kind: API |
| Resource | 基础设施资源（数据库、缓存、消息队列） | kind: Resource |
| System | 多个组件组成的业务系统 | kind: System |
| Domain | 业务域，聚合多个系统 | kind: Domain |
服务目录不仅是静态的资产清单，更是动态的运行时视图。通过插件，可以将监控数据、部署状态、日志信息直接关联到对应的服务实体上，实现“从代码到生产”的全链路可观测性。
1.3 容量水位巡检的重要性
容量水位巡检是指对服务所依赖的计算、存储、网络等资源的 使用率与饱和度 进行周期性检查，以提前发现资源瓶颈，避免因资源耗尽导致的服务降级或中断。在微服务与云原生环境下，容量管理面临以下挑战：
- 动态性高： 容器、Pod 的扩缩容使得资源水位频繁波动。
- 维度多： CPU、内存、磁盘、网络 I/O、连接数、队列深度等指标需要综合评估。
- 关联性强： 一个服务的容量问题可能由上游依赖的瓶颈引发。
通过 Backstage 插件实现容量水位巡检，可以将巡检结果直接展示在服务目录中，让每个服务的 Owner 在查看服务详情时，第一时间看到资源健康状态，无需切换多个监控系统。
1.4 故障排查的挑战
在复杂的微服务拓扑中，故障排查往往面临“信息孤岛”与“认知过载”的双重困境。以下是常见的痛点：
| 挑战维度 | 具体表现 | 传统解决方式 |
|---|---|---|
| 数据分散 | 监控、日志、告警、变更记录分布在多个平台 | 手动切换系统，上下文丢失 |
| 依赖关系不透明 | 无法快速定位故障是自身问题还是上游依赖导致 | 人工梳理调用链，效率低 |
| 历史基线缺失 | 无法判断当前水位是异常突增还是正常波动 | 依赖个人经验，缺乏数据支撑 |
| 协作成本高 | 需要拉多个团队建群排查，信息同步慢 | 电话会议、共享屏幕 |
Backstage 通过服务目录的 依赖关系图（Dependency Graph） 和插件集成，可以将上述信息聚合到统一的“故障排查视图”中。例如，当某个服务的 CPU 水位异常时，运维人员可以直接在 Backstage 上查看该服务的依赖拓扑、关联的 Pod 日志、最近的变更记录以及历史水位趋势，大幅缩短平均修复时间（MTTR）。