如需将基础设施资源有效整理到应用中心应用中，您必须为应用管理选择设置模型。App Hub 提供以下模型：
- 已启用应用的文件夹（预览版）：建议用于新的应用分组实现。它会配置一个标准的 Google Cloud 文件夹以进行应用管理，从而解锁以应用为中心的 Google Cloud 中的所有可用功能。
- 宿主项目：面向现有 App Hub 用户的受支持模型，用于配置标准 Google Cloud 项目以对资源进行分组。
下表比较了可用的应用管理设置模型，以便您大致了解它们之间的主要区别，并帮助您选择最符合自己需求的选项：
| 功能 | 已启用应用的文件夹 | 宿主项目 |
|---|---|---|
| 建议 | 建议新用户使用 | 面向现有用户的支持模型 |
| 主要边界 | 已启用应用的文件夹及其所有子文件夹 | 宿主项目和任何手动附加的服务项目 |
| 资源发现 | 文件夹及其后代中的自动权限 | 需要手动关联服务项目 |
| 管理项目 | 由 Google 自动创建 | 不适用 |
| 主要功能 | 对以应用为中心的 Google Cloud 功能拥有完整访问权限，包括 Cloud Hub 和 Google Cloud Observability 产品中的增强型监控功能、App Design Center 中的应用设计和部署功能，以及使用 Gemini Cloud Assist 进行应用优化 | 基本应用分组，对在 App Hub 或 Cloud Logging、Cloud Monitoring 和 Cloud Trace 中查看可观测性数据的支持有限 |
| IAM 策略 | 在文件夹、管理项目或单个应用级层进行精细的权限控制 | 项目级权限控制 |
| 启用 API | 在管理项目中自动执行 | 宿主项目中的人工操作 |
| 可伸缩性 | 专为组织规模而设计 | 受项目资源限制 |
| 设置复杂性 | 提前规划文件夹结构 | 通过手动关联进行直接初始设置 |
| 设置说明 | 设置启用应用的文件夹的 App Hub | 使用宿主项目设置 App Hub |
本页将引导您选择最适合应用管理需求的模型，并详细介绍这些模型之间的优势、注意事项和功能差异。
已启用应用的文件夹
推荐已启用应用的文件夹是您为应用管理配置的标准 Google Cloud 文件夹。此模型可作为应用的管理边界，是以应用为中心的 Google Cloud 上应用管理体验的基础。
为文件夹启用应用管理功能后，系统会在其中 Google Cloud 自动创建管理项目。此管理项目会存储您的所有应用模型、元数据和配置，以用于 App Hub 和应用设计中心等服务。它还负责自动启用所需的 API。
优势：
- 分层资源发现：将已启用应用的文件夹中所有项目或嵌套文件夹内的任何受支持的服务和工作负载分组为单个应用。
- 完整的功能访问权限：解锁全方位的应用管理功能，包括用于设计和部署应用的 App Design Center，以及 Gemini Cloud Assist 提供的 AI 赋能的辅助功能。
- 集中式元数据：在已启用应用的文件夹中创建的管理项目可为应用定义和属性提供单一可信来源。
- 可扩缩的治理：使用文件夹将应用管理与组织结构保持一致。
注意事项：
- 文件夹结构：仔细规划 Google Cloud 资源层次结构。已启用应用的文件夹中的应用可以包含该文件夹或其后代中的任何项目的资源。您可以考虑按业务部门、环境或团队整理文件夹，以满足您的需求。
- IAM 策略：您通常可以按照标准的 IAM 继承规则，在启用应用的文件夹本身或管理项目上授予权限。这种做法可实现精细的访问权限控制。
- 结算：我们建议您了解结算的关联方式，尤其是对于在应用中自动启用或使用的 API 和服务。
- 启用 API：以应用为中心的 Google Cloud 的关键 API 会在管理项目中自动启用。
如需查看设置说明，请参阅通过启用应用的文件夹设置 App Hub。
宿主项目
宿主项目是一个标准 Google Cloud 项目，您可以使用它将服务和工作负载分组到 App Hub 应用中。宿主项目是现有 App Hub 用户支持的设置模型。不过，它们不支持以应用为中心的 Google Cloud 的全方位应用管理功能，并且需要手动配置才能纳入资源。
限制：
- 手动关联资源：您必须手动将包含要分组为应用资源的每个服务项目附加到宿主项目。未关联项目中的资源对 App Hub 不可见。
- 功能集有限：宿主项目不支持已启用应用的文件夹提供的功能，例如应用设计中心集成和通过管理项目自动启用 API。
- 项目资源边界：应用管理仅限于宿主项目和手动附加的服务项目，可能无法反映您的组织结构。
我们建议现有宿主项目的用户规划迁移事宜。如需了解设置说明，请参阅使用宿主项目设置 App Hub。
规划资源层次结构的结构
App Hub 应用的组织基础是已启用应用的文件夹或宿主项目，具体取决于您选择的设置模型。应用中心的数据模型基于标准的 Google Cloud 资源层次结构构建，并沿用相同的层次结构规则和继承政策。
您可以将预期应用边界映射到设置模型的基础应用启用文件夹或宿主项目，从而有效地将 Google Cloud 资源层次结构的优势与 App Hub 的应用功能相结合。您可以将 App Hub 的数据模型视为标准 Google Cloud 资源层次结构上的叠加层：
- 文件夹和项目是边界：Resource Manager 中的文件夹和项目会以与已启用应用的文件夹或宿主项目定义应用管理边界相同的方式对资源进行分组，以实现政策继承和组织。
- 角色和权限是继承的：App Hub 的 IAM 角色和权限是根据标准的 IAM 继承规则在管理项目、已启用应用的文件夹本身或宿主项目上授予的。
- 元数据集中化：管理项目或宿主项目可集中管理应用元数据，从而为资源管理添加应用感知层。
如需详细了解资源组织，请参阅资源组织概念和为应用管理配置文件夹。
资源层次结构注意事项
选择已启用应用的文件夹还是宿主项目，从根本上决定了您如何为 App Hub 整理资源。作为最佳实践，请务必周全地规划 Google Cloud 资源层次结构。
在选择用于管理应用的设置模型时，建议您考虑以下资源层次结构：
已启用应用的文件夹：
- 服务和工作负载必须位于已启用应用的文件夹或其后代项目内，才能在相应文件夹的管理边界内的 App Hub 应用中注册。
- 服务和工作负载的自动发现功能在已启用应用的特定文件夹及其后代项目的边界内运行。
仔细规划文件夹结构：
- 使用单个已启用应用的文件夹来管理其中多个项目中的应用。
- 创建支持应用的嵌套文件夹，以便将应用管理权限委托给不同的团队或业务部门，从而更精细地控制应用。
宿主项目：
- 所有资源都必须位于您手动附加到宿主项目的服务项目中，这样您才能在 App Hub 应用中注册这些资源。
如需了解常见的组织方法，请参阅资源结构模式。
如在文件夹中管理应用中所述，在父文件夹（例如 F1）中启用应用管理功能后，该文件夹中的应用便可包含直接位于其中的项目（例如 P10 和 P11）中的资源，也可包含嵌套文件夹（例如 F2 中的 P20 和 P21）中的资源。
如果您仅在嵌套文件夹 F2 中启用应用管理，则该文件夹中的应用只能使用其中项目的资源，例如 P20 和 P21。父文件夹 F1 中的资源（例如 P10 和 P11）无法供 F2 中的应用使用。如需包含父文件夹中某个项目的资源，您必须将该项目移至 F2。
资源结构模式
以下是建议的文件夹和项目结构模式：
- 单个已启用应用的文件夹：在小型组织或初始采用阶段开始配置，将应用管理整合到单个管理边界内。
- 每个环境对应一个启用应用功能的文件夹：在开发环境之间强制实施严格的隔离，从而实现不同的政策并降低风险。
- 每个业务部门或团队一个启用应用的文件夹：使管理与组织结构和团队职责保持一致，从而提高自主性。您可以通过构建多个单独的启用应用文件夹来实现此实践。
- 支持应用的文件夹的嵌套结构：以分层控制为目标进行组织，例如按业务部门、团队或环境进行组织。您可以为各个业务部门创建顶级文件夹，并在每个部门内创建嵌套的开发、预演和生产环境文件夹。此模式利用了资源层次结构注意事项中概述的已启用应用的文件夹结构。
- 每个应用或应用组对应一个宿主项目：整理标准项目中的现有资源，适合习惯于基于项目分离关注点的组织，或以这种方式管理现有应用的组织。