在开发云基础架构时，您可能会跨多个项目整理资源。这种方法可能会导致资源难以管理和整理。App Hub 提供了一种以应用为中心的方式来对这些资源进行分组，有助于您将基础架构与业务功能保持一致。
App Hub 可作为 Google Cloud上应用的基础数据模型和中央注册表。它创建了一个可信来源，用于明确资源所有权、依赖关系和业务背景信息。这反过来又可以为其他 Google Cloud 服务提供所需的以应用为中心的上下文。如需详细了解这种以应用为中心的模型及其资源组织方式，请参阅以应用为中心的 Google Cloud。
本文档从概念上简要介绍了 App Hub，以便您在设置或管理 App Hub 之前了解其功能和优势。
为何要使用 App Hub？
App Hub 将重点从单个基础架构组件转移到它们所组成的应用，有助于您大规模简化治理和运营。
App Hub 可帮助您实现以下目标：
整理应用并为其编目：将一个或多个项目中分散的资源分组到逻辑应用中。然后，您可以按所有者、业务关键性和环境等属性对这些应用进行分类，以提高可发现性和问责性。如需了解详情，请参阅支持可发现性和治理。
为团队创建统一视图：通过在 App Hub 中定义应用，您可以为其他 Google Cloud服务提供必要的背景信息。例如，您启用以下功能：
- Cloud Hub 中的集中式运维和分析洞见视图，可在应用上下文中显示提醒、突发事件和性能数据。
- Gemini Cloud Assist 提供的 AI 赋能的辅助功能，该功能使用 App Hub 的数据模型来帮助您设计、运营和排查应用问题。
- 借助 Google Cloud Observability 进行应用监控，通过显示应用及其资源的遥测数据，帮助您排查错误并提升性能。
明确资源所有权和依赖关系：了解应用的组成方式以及其组件之间的依赖关系。此功能可帮助开发者和运维人员直观呈现应用架构、确定所有者并解决问题。
如需详细了解 App Hub 如何融入更广泛的应用生命周期，请参阅以应用为中心的 Google Cloud。
概念和数据模型
App Hub 基于以下关键概念的数据模型构建：应用、服务和工作负载。虽然这些术语很常见，但 App Hub 以特定方式使用它们。下表将 App Hub 定义与常见的行业用法进行了比较：
| 概念 | App Hub 定义 | 常见行业使用情况 |
|---|---|---|
| 应用 | 服务和工作负载的逻辑分组，共同提供业务功能。 | 可以指单个可部署单元、代码库或广泛的系统。 |
| 服务 | 向客户端公开功能的网络或 API 接口，例如负载均衡器。 | 通常指微服务，一种具有专属业务逻辑和数据的可部署组件。 |
| 工作负载 | 执行不同业务功能单元的二进制部署，例如 GKE 部署或 Compute Engine 实例组。 | 一个更通用的术语，指消耗计算资源的任何进程或组件。 |
如需详细了解这些核心概念，请参阅主要概念。
您可以根据地理分布要求定义 App Hub 应用。您可以指定以下位置：
- 全球应用可以对来自多个Google Cloud 区域的服务和工作负载进行分组。
- 区域级应用包含的资源全部位于单个区域内。
此选择会影响您可以注册哪些资源，对于数据留存位置要求而言非常重要。如需详细比较以帮助您选择合适的位置，请参阅全球应用和区域应用。
服务和工作负载的注册状态
Google Cloud 资源的组织结构会影响 App Hub 与服务和工作负载的互动方式，并允许您将它们分组到应用中。您可以向应用注册的服务和工作负载具有以下注册状态之一：
- 已发现：您可以将这些服务和工作负载注册到应用，因为它们属于设置模型的资源层次结构，并且未注册到任何其他应用。已发现的服务和工作负载还包括您从应用中删除或取消注册但可以再次注册的服务或工作负载。
- 已注册：已向应用注册并由 App Hub 管理的服务和工作负载。您只能注册已发现的服务和工作负载，并且每项服务和工作负载只能属于一个应用。注册服务或工作负载后，注册状态会从 discovered 更新为 registered。
已分离：已作为组件注册到应用的服务或工作负载，但 App Hub 无法管理或监控这些服务或工作负载，因为底层资源不再属于设置模型的资源层次结构。注册到应用的服务和工作负载的注册状态可能会因以下原因而更改为已分离：
- 底层资源会被删除。例如，如果您删除由某项服务表示的转发规则，该服务的注册状态会更改为 detached。
- 对于宿主项目：如果您在设置模型中使用宿主项目，并且从宿主项目中移除了具有注册服务或工作负载的基础资源的服务项目。
- 对于管理项目：如果您将管理项目用于设置模型，并且从已启用应用的文件夹中移除了后代项目，而该后代项目具有已注册服务或工作负载的基础资源，则会发生此问题。
分离的服务和工作负载会一直保留在应用中，直到您将其取消注册。
如果您将项目移出设置模型的应用管理边界，则其分离的服务和工作负载可能会被其他边界中的应用发现。您可以再次注册可发现的服务和工作负载，但必须遵守应用管理边界确立的资源层次结构。
如需查看服务和工作负载的注册状态，请参阅查看服务和工作负载的详细信息。
支持可发现性和治理
为了丰富数据模型，App Hub 可让您公开属性和特性，以支持应用的可发现性、可追责性和资源治理。将这些值定义为应用元数据有助于您大规模过滤、管理资源并为资源应用政策。
以下是属性和特性的一些定义和特征：
属性是不可变的字段，用于描述已注册的服务或工作负载的底层基础架构，例如其项目 ID、位置或可用区。这些内容会自动发现，无法在 App Hub 中修改。
属性是可变的用户定义元数据，您可以将其应用于应用、服务和工作负载，以便组织和管理它们。主要属性包括：
所有者：开发者、运营商和业务团队的联系信息。支持的所有者类型包括：
developer_owners：拥有开发和编码的开发团队。operator_owners：确保运行时和运营完整性的运营商团队。business_owners：确保满足质量要求和用户期望的企业团队。
严重程度：资源对您业务的重要性。支持的值包括：
- 任务关键型
- 高
- 中
- 低
环境：资源的生命周期阶段。支持的值包括：
- 生产
- 预演
- 测试
- 开发
App Hub 资源模型
为了启用以应用为中心的功能，App Hub 使用基于以下 Google Cloud 文件夹和项目的模型：
建议： 已启用应用的文件夹：已针对应用管理配置的标准 Google Cloud 文件夹。此文件夹充当应用的管理边界。当文件夹启用应用后，系统会在其中 Google Cloud 自动创建管理项目。此 Google 创建的项目可作为所有应用模型和元数据的中央存储库。这是使用以应用为中心的 Google Cloud 产品的推荐途径，也是访问全套应用管理功能的必要条件。
宿主项目：一种 Google Cloud 项目，您可以使用它在 App Hub 中将服务和工作负载分组为应用，但它不支持访问应用管理功能的完整产品。
如需详细了解以应用为中心的资源模型，请参阅资源组织概念。 如需有关入门的详细说明，请参阅选择设置模型。
后续步骤
- 如需查看可在 App Hub 中注册哪些 Google Cloud 资源，请参阅支持的资源。
- 如需开始设置 App Hub，请参阅通过启用应用的文件夹设置 App Hub。
- 如需了解使用 App Hub 所需的权限，请参阅角色和权限。