3. 平台门户概述：Backstage、Port、Humanitec 等门户的功能、开发者自助服务与基础设施编排

平台门户是平台工程落地的核心交互界面，它将底层基础设施的复杂性抽象为开发者可理解的自助服务目录。本章聚焦三类主流门户——Backstage（开源）、Port（SaaS 优先）和 Humanitec（编排引擎型），分析它们在功能定位、自助服务模型与基础设施编排上的差异。

3.1 平台门户的核心能力模型

无论采用哪种门户，其核心价值都围绕三个维度展开：

3.2 主流门户对比

3.2.1 Backstage — 开源可扩展的开发者门户

Backstage 由 Spotify 开源，CNCF 孵化项目。其核心是插件架构，平台团队通过编写或配置插件来扩展功能。

• 服务目录： 基于 catalog-info.yaml 文件注册实体（服务、API、资源、域），支持多后端存储（PostgreSQL、SQLite）。
• 自助服务： 通过 Scaffolder 插件实现"软件模板"，开发者选择模板（如"创建 Node.js 微服务"），填写参数，触发后端模板引擎生成代码仓库 + CI/CD 配置。
• 编排方式： 模板内部可调用 Terraform、Pulumi、Helm 或自定义 Action。编排结果通常提交到 Git 仓库，由 GitOps 工具同步。
• 适用场景： 需要高度定制、已有 Kubernetes 和 GitOps 基础、愿意投入开发资源的团队。

# catalog-info.yaml 示例
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  annotations:
    backstage.io/kubernetes-id: payment-service
    github.com/project-slug: org/payment-service
spec:
  type: service
  lifecycle: production
  owner: team-payment
  system: payment-system

3.2.2 Port — SaaS 优先、低代码的门户

Port 强调"开发者自助服务即代码"，通过 YAML 配置定义蓝图（Blueprint）和自助动作，无需编写后端插件。

• 服务目录： 基于"蓝图"模型定义实体类型（微服务、环境、集群、数据库），支持从 Kubernetes、PagerDuty、Datadog 等自动同步数据。
• 自助服务： 使用 port-action 定义动作，动作可触发 GitHub Actions、Jenkins、Argo Workflows 或自定义 Webhook。
• 编排方式： 动作执行器在外部运行，Port 负责传递参数和展示结果。编排结果通过 GitOps 仓库或直接 API 写入基础设施。
• 适用场景： 希望快速上线、团队规模较小、不想维护门户基础设施的团队。

3.2.3 Humanitec — 以编排引擎为核心的门户

Humanitec 定位为"内部开发者平台（IDP）的编排引擎"，其门户层与编排层深度绑定。

• 服务目录： 以"应用"和"环境"为核心，自动解析依赖关系（如服务 A 依赖 PostgreSQL 和 Redis）。
• 自助服务： 开发者通过"Score"文件（一种与平台无关的工作负载规范）声明资源需求，Humanitec 自动解析并生成 Helm Chart 或 Terraform 配置。
• 编排方式： 内置资源匹配引擎，将声明式需求（"需要 PostgreSQL 12，高可用"）映射到具体资源实例（"使用 RDS 实例 xxx"）。编排结果直接驱动 GitOps 仓库更新。
• 适用场景： 需要精细化资源编排、多环境管理、希望降低 IaC 编写复杂度的团队。

3.3 开发者自助服务流程对比

以下 SVG 展示了三种门户在"开发者请求新环境"这一典型自助服务动作中的流程差异：

3.4 基础设施编排架构

平台门户的基础设施编排层通常采用"声明式需求 → 资源解析 → 清单生成 → GitOps 同步"的管道模式。以下 SVG 展示了通用编排架构：

3.5 选择建议