Backstage服务目录容量巡检插件开发 - 第1节

1.1 Backstage 与平台工程概述

平台工程（Platform Engineering）是近年来 DevOps 领域最重要的演进方向之一。其核心目标是通过构建一套自服务的内部开发者平台（IDP），将基础设施的复杂性抽象化，让开发者能够专注于业务代码的交付。Backstage 正是这一理念下的标杆级开源项目，由 Spotify 创建并捐赠给 CNCF。

平台工程的核心价值在于“黄金路径”（Golden Path）的构建。Backstage 通过以下能力支撑这一路径：

• 统一目录： 将所有软件组件（服务、库、网站、数据管道）注册为实体，形成可搜索、可关联的目录。
• 插件生态： 提供超过 180 个开源插件，覆盖 CI/CD、测试、安全扫描、成本分析等场景。
• 模板引擎： 通过 Software Templates 实现标准化项目脚手架，一键创建符合组织规范的新服务。
• 技术文档： 基于 MkDocs 的 TechDocs 模块，让文档与代码同源、同版本。

下表对比了传统开发模式与基于 Backstage 的平台工程模式的关键差异：

1.2 服务目录平台概念

服务目录（Service Catalog）是 Backstage 的“数据心脏”。它将组织内所有软件组件抽象为统一的实体（Entity），并通过 YAML 描述文件（catalog-info.yaml）进行注册与同步。每个实体都包含元数据、关系、规格和状态四个核心部分。

Backstage 服务目录的核心实体类型包括：

• Component： 最核心的实体，代表一个软件组件（微服务、前端应用、库等）。
• API： 组件对外暴露的接口，支持 OpenAPI、GraphQL、gRPC 等协议。
• Resource： 组件依赖的底层资源（数据库、消息队列、存储桶）。
• System： 多个组件和 API 组成的业务系统边界。
• Domain： 多个系统组成的业务域，对应组织架构中的大部门或产品线。
• Group / User： 组织架构中的团队与人员，用于权限和归属管理。

一个典型的 catalog-info.yaml 示例如下：

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: order-service
  description: 订单核心服务，处理下单与支付回调
  annotations:
    backstage.io/kubernetes-namespace: production
    grafana/dashboard-selector: "order-service"
spec:
  type: service
  lifecycle: production
  owner: group:order-team
  system: order-system
  dependsOn:
    - resource:default/order-db
    - component:default/payment-gateway
  providesApis:
    - api:default/order-api

1.3 容量水位巡检自动化的价值与目标

在微服务架构中，容量管理（Capacity Management）是保障系统稳定性的关键环节。传统巡检方式依赖运维人员手动登录各监控平台查看 CPU、内存、磁盘、连接数等指标，存在以下痛点：

• 信息孤岛： 每个服务的监控散落在 Grafana、Prometheus、CloudWatch 等不同系统中。
• 缺乏上下文： 看到某个 Pod CPU 飙高，但无法快速关联到所属服务、团队、依赖链。
• 被动响应： 往往是告警触发后才开始排查，缺乏趋势预判能力。
• 人工成本高： 大型组织每周需投入数小时进行巡检报告整理。

本课程所构建的自动化巡检方案，其核心目标如下：