欢迎来到平台工程的世界！🌟 如果您是Backstage的新手，您会很快发现一切都围绕着“目录”展开。但是，您知道构成这个目录的最小砖块，即基本单元是什么吗？
今天，我们将非常详细地剖析构成Backstage基础的“Entity（实体）”。阅读本文后，您将理解您的复杂基础设施如何转变为一个统一、一致的数据模型！
1. 什么是Entity（实体）？ 🧱
在Backstage中，Entity（实体）是描述软件生态系统中所有独立组件的标准化基本单元。
它不仅仅指包含源代码的“服务”。构成您系统的所有有机存在都可以成为实体。
- 服务（Component）：实际运行的微服务或Web应用
- API：服务提供或消费的接口
- 团队（Group）和开发者（User）：关于谁创建和管理它们的信息
- 基础设施资源（Resource）：数据库、S3存储桶、Kubernetes集群等
2. 实体长什么样？ (YAML结构) 📝
实体通常在名为catalog-info.yaml的文件中定义。这个文件具有与Kubernetes资源定义非常相似的结构，您可能会很熟悉。每个实体主要由三部分组成：
YAML
apiVersion: backstage.io/v1alpha1
kind: Component # 实体的种类
metadata:
name: my-awesome-service # 实体的名称
description: 우리 팀의 메인 API 서비스입니다.
tags: ["java", "spring-boot"]
annotations:
backstage.io/managed-by-location: url:https://github.com/...
spec:
type: service
owner: team-alpha # 所属团队（与其他实体的关系）
lifecycle: production- apiVersion & kind: 定义这个实体是什么（例如，是组件还是组）。
- metadata: 包含用于搜索和识别的信息，如名称、描述和标签。
- spec: 定义特定于该种类（Kind）的详细信息以及与其他实体之间的关系（Relationship）。
3. 实体强大的原因：关系（Relationship） 🕸️
实体之所以能够超越简单的“说明书”而发挥强大作用，是因为实体之间的连接。
例如，当您在Component实体的spec.owner字段中写入特定Group实体的名称时，Backstage会自动将两者连接起来。
- “这个服务由谁管理？” 👉 连接到Group实体
- “这个服务使用什么数据库？” 👉 连接到Resource实体
- “这个团队开发了哪些API？” 👉 可以反向查询
这些关系共同构成了庞大的软件图谱（Software Graph）。
4. 主要实体种类（Kinds）一览 🧐
Backstage默认提供以下核心种类：
| 种类（Kind） | 描述 | 示例 |
|---|---|---|
| Component | 由代码组成的软件片段 | 服务、网站、库 |
| API | 服务之间的接口契约 | REST API, GraphQL, gRPC |
| Resource | 软件运行所需的基础设施 | PostgreSQL, S3, RDS |
| Group | 组织内的团队或部门 | 平台团队、支付部门 |
| User | 单个开发者 | 张三、李四 |
| System | 相关实体的较大抽象组 | 支付系统、用户管理系统 |
—
5. 实体为开发者带来的优势 💡
- 一致性：所有团队都以相同的格式描述其服务。
- 可发现性（Discoverability）：“不知道谁创建的API”将不复存在。通过在目录中搜索实体，可以找到所有信息。
- 自动化的基础：基于实体信息，可以自动关联部署状态检查、安全漏洞扫描结果。🤖
🏁 总结
Backstage目录的基石——Entity（实体），不仅仅是数据片段，它更像是绘制组织复杂软件地图的坐标。实体定义和连接得越好，开发者就能越专注于实际的“开发”，而不是不必要的沟通。
何不立即在您的项目根目录中创建一个catalog-info.yaml文件，并定义您的第一个实体呢？🚀
发表回复