平台工程实践：Backstage、Crossplane与内部开发者门户

让开发者无需等待运维即可发布产品的平台

平台工程是构建内部开发者平台的实践——包括工具、工作流和自助服务能力，使应用开发者能够专注于功能而非基础设施。它已成为软件工程中增长最快的学科之一，这一趋势源于一个简单的观察：超过一定规模的团队都会重新发明相同的内部工具，而这种重新发明的成本很高。本指南涵盖了平台工程实际涉及的内容、用于构建它的具体工具，以及关于何时值得投资的诚实指导。

平台工程解决的问题

没有平台团队，应用开发者通常会将20-30%的时间花在与产品核心无关的任务上：

• 为新服务配置CI/CD流水线
• 设置Kubernetes部署、服务和入口
• 管理密钥（轮换凭证、更新环境变量）
• 申请并等待新的数据库、队列或存储桶
• 为新服务配置监控和告警
• 处理生产环境访问的合规要求

平台团队构建自助服务系统以减少这种开销。产出不仅仅是工具——它减少了认知负荷和等待时间，从而减缓了产品工程的进度。

内部开发者门户：Backstage

Spotify的Backstage已成为内部开发者门户的标准基础。它提供服务目录、用于引导新服务的软件模板，以及一个插件系统，用于将所有内部工具集成到一个界面中。

# 安装Backstage
npx @backstage/create-app@latest
cd my-platform
yarn dev

# 或使用官方Docker镜像
docker run -p 7007:7007 spotify/backstage

服务目录是核心：一个可以查看每个服务、其所有者、文档、部署状态和依赖关系的单一位置。

# catalog-info.yaml — 检入到每个服务的仓库中
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: order-service
  title: Order Service
  description: 处理订单创建、管理和履行
  annotations:
    github.com/project-slug: myorg/order-service
    backstage.io/techdocs-ref: dir:.
    pagerduty.com/service-id: P1234
    datadog/service-name: order-service
  tags:
    - java
    - kafka
    - payments
spec:
  type: service
  owner: team-commerce
  lifecycle: production
  dependsOn:
    - component:payment-service
    - component:inventory-service
    - resource:orders-postgres
  providesApis:
    - order-api

软件模板让开发者无需阅读文档即可搭建新服务：

# template.yaml — 新微服务的软件模板
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: java-microservice
  title: Java Spring Boot 微服务
  description: 创建一个新的 Java 微服务，预配置了 CI/CD、监控和部署功能
spec:
  parameters:
    - title: 服务详情
      properties:
        name:
          title: 服务名称
          type: string
          pattern: '^[a-z][a-z0-9-]*$'
        owner:
          title: 所有者团队
          type: string
          ui:field: OwnerPicker
        description:
          title: 描述
          type: string

  steps:
    - id: fetch-template
      name: 获取模板
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          owner: ${{ parameters.owner }}

    - id: create-github-repo
      name: 创建 GitHub 仓库
      action: publish:github
      input:
        repoUrl: github.com?repo=${{ parameters.name }}&owner=myorg
        defaultBranch: main

    - id: register-in-catalog
      name: 在目录中注册
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps['create-github-repo'].output.repoContentsUrl }}
        catalogInfoPath: /catalog-info.yaml

    - id: create-datadog-monitor
      name: 创建监控
      action: http:backstage:request
      input:
        method: POST
        path: /api/proxy/datadog/monitor
        body:
          name: "错误率 - ${{ parameters.name }}"
          type: metric alert
          query: "avg(last_5m):sum:trace.servlet.request.errors{service:${{ parameters.name }}} / sum:trace.servlet.request.hits{service:${{ parameters.name }}} > 0.05"

开发者运行此模板，填写表单，即可获得一个生产就绪的仓库，包含 CI/CD、Kubernetes 清单、监控和目录注册功能 — 全部在 5 分钟内完成，无需等待任何运维团队的参与。

基础设施即自助服务：Crossplane

Crossplane 扩展了 Kubernetes，使其能够使用与应用程序相同的 GitOps 工作流来管理外部云资源。这正是平台团队如何为开发者提供对数据库、队列和存储的自助访问权限，而无需暴露云凭证。

# 开发者通过提交 Kubernetes 资源创建数据库
# 平台团队定义了"数据库"在其环境中的含义
apiVersion: database.platform.mycompany.com/v1alpha1
kind: PostgresDatabase
metadata:
  name: order-service-db
  namespace: team-commerce
spec:
  storageGB: 20
  version: "16"
  tier: standard          # 平台团队定义了'standard'的含义
  backupEnabled: true
  maintenanceWindow: "sun:03:00-sun:04:00"

# 在幕后，Crossplane 将此转换为 AWS RDS 实例
# 平台团队定义了 Composition
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: postgres-database-aws
spec:
  compositeTypeRef:
    apiVersion: database.platform.mycompany.com/v1alpha1
    kind: PostgresDatabase
  resources:
    - name: rds-instance
      base:
        apiVersion: rds.aws.upbound.io/v1beta1
        kind: Instance
        spec:
          forProvider:
            region: us-east-1
            engine: postgres
            instanceClass: db.t3.medium
            allocatedStorage: 20
            backupRetentionPeriod: 7
      patches:
        - type: FromCompositeFieldPath
          fromFieldPath: spec.storageGB
          toFieldPath: spec.forProvider.allocatedStorage

应用程序开发者声明他们的需求。平台团队控制如何配置这些资源。合规性、成本控制和最佳实践都被编码在 Composition 中，而不是记录在无人阅读的 wiki 中。

内部黄金路径：有主见的默认值

平台团队最具影响力的产出往往不是工具，而是一套有主见的默认值——即常见任务的”黄金路径”。黄金路径是做某事的推荐方式，被实现为模板或工具，使正确的选择变得简单易行。

值得构建的黄金路径示例：

• 服务模板：包含预配置的 Dockerfile、Kubernetes 清单、CI 管道和可观测性的 GitHub 仓库模板
• 密钥模板：使用 Vault 或 AWS Secrets Manager 的标准模式——开发者获得文档化的工作示例，而不是从头开始摸索
• 可观测性模板：为新服务预构建的 Grafana 仪表板——错误率、延迟、饱和度——在新服务创建时自动配置
• 运行手册模板：每个服务使用的标准运行手册结构，包含相同的章节和升级路径

衡量平台工程的成功

平台团队就是基础设施团队——他们的客户是内部开发者。正确的指标应反映开发者的生产力和满意度，而不是平台正常运行时间：

• 新服务的首次部署时间：从仓库创建到首次生产部署。纵向跟踪这一指标。
• 开发者体验评分：季度调查，要求开发者对其工作流程中的摩擦程度进行评分（1-10分）
• 自助服务比例：无需人工运维工单即可完成的基础设施请求百分比
• DORA指标：部署频率、变更前置时间、变更失败率、恢复时间——平台团队的工作应当推动这些指标改善

平台工程何时为时过早

平台工程有成本：它需要那些不构建产品功能的工程师。问题是这项投资是否比直接的产品工作创造更多价值。

当以下情况出现时，平台工程为时过早：

• 您的工程团队少于15-20人
• 生产环境中的服务少于5-10个
• 每个团队仍然能够端到端地理解整个技术栈
• 基础设施工作不是可衡量的瓶颈

当以下情况出现时，平台工程变得值得：

• 多个团队在重复基础设施设置工作
• 新团队入职需要数周时间，因为内部工具没有文档记录
• 开发者需要等待运维工单才能获得基本资源配置
• 安全和合规控制被绕过，因为合规路径太慢

原则与任何共享基础设施相同：当没有平台的成本超过构建平台的成本时，投资平台。在小规模情况下，一个组织良好的Wiki和一些shell脚本就是您的平台。随着规模扩大，自助服务工具的投资会产生复合效应——每个能够独立部署的开发者，都是不需要等待他人的开发者。