本指南介绍了在 App Hub 中设计和定义应用的最佳实践。有效的应用设计是充分利用以应用为中心的 Google Cloud 的关键，可提供增强的可见性、治理和运营效率。
应用设计的核心原则
遵循以下核心原则有助于您创建稳健、可维护且符合业务目标的应用，从而最大限度地提高您从应用中心获得的价值：
反映业务能力：围绕业务功能或端到端工作流（而不仅仅是技术层或单个微服务）定义 App Hub 应用。应用应代表业务的独特价值流。
确定明确的所有权：为每个应用分配明确的属性和特性，以支持可发现性和治理。 特别是，添加应用所有者有助于提高责任感并简化沟通流程。
考虑应用边界：定义对运营、监控和治理有意义的边界。应用中的资源应尽可能共享一个共同的运营生命周期和影响域，以简化管理并降低运营风险。
出于运营目的考虑应用的边界时，请务必了解 Google Cloud 可观测性如何构建数据收集和显示。虽然 App Hub 侧重于应用边界，但 Google Cloud Observability 使用范围来定义哪些遥测数据可在项目中查看和分析。这些可观测性范围的配置与宿主项目或管理项目之间存在特定关系，决定了您如何汇总和查看来自不同项目的遥测数据。如需详细了解如何配置这些范围以实现统一视图，请参阅配置可观测性范围。
适应发展：设计应用时要考虑到架构未来的变化和增长。
迭代式优化：定期查看并调整应用，以反映组织结构、团队和业务优先级的变化。
如何定义应用
了解 App Hub 中的应用构成对于在Google Cloud中有效集成应用管理功能至关重要。应用用于对共同提供特定业务功能的服务和工作负载进行分组。如需详细了解 App Hub 中应用、服务和工作负载的核心概念，请参阅概念和数据模型。
为帮助您确定 App Hub 应用的合适边界，请考虑以下关键问题：
- 此资源集合可为用户或商家带来哪些价值？
- 这些组件是否具有共同的运营生命周期？
- 这些资源是否具有明确的统一所有权？
- 这种分组方式是否有助于进行有效的监控和问题排查？
示例：OpenTelemetry 演示版架构
OpenTelemetry 演示版架构表示一个包含 Ad、Cart 和 Checkout 等微服务的电子商务系统。为了在 App Hub 中更好地定义此应用，请考虑以下建议：
将整个电子商务系统建模为一个 App Hub 应用，例如
my-ecommerce-site：- 各个微服务的计算实例（例如 Google Kubernetes Engine (GKE) 部署）会映射到 App Hub 工作负载。
- 网络端点（例如经过负载均衡的 gRPC/HTTP 接口）会映射到 App Hub 服务。
避免将每个微服务（例如 Ad、Cart 和 Checkout）注册为单独的 App Hub 应用。这种方法会使业务情境变得支离破碎。
如需详细了解 App Hub 支持作为服务和工作负载的基础设施资源，请参阅 App Hub 支持的资源。
设计策略
采用以下设计策略，确保您的 App Hub 设置可伸缩、可管理，并符合您的运营实践。
选择全球应用和区域应用
在设计 App Hub 应用时，一个基本决策是确定应用是全球性还是区域性的。此选择会影响可包含的资源、数据处理、延迟时间、费用和合规性：
- 全球应用最适合本身就分布在多个 Google Cloud 区域或依赖全球资源（例如全球应用负载平衡器）的服务和工作负载。
- 如果所有应用组件都位于单个 Google Cloud 区域中，建议使用单区域应用。如果您的架构允许，这种做法通常是最佳方法。
以下最佳实践列表可帮助您在全局应用和区域应用之间做出选择：
- 优先考虑区域级应用：尽可能将应用设计为区域级，以充分利用以下优势：缩短延迟时间、可能节省区域间网络流量费用、符合数据存放区域要求，以及与特定区域的Google Cloud 功能和故障网域实现固有兼容。
- 有策略地使用全球应用：仅当系统组件必须分布在多个区域或涉及全球 Google Cloud 服务时，才选择全球应用。
- 分解多区域系统：如果您在多个区域中拥有资源，但这些资源并未形成一个统一的全球功能，请考虑为每个相应区域中的资源定义单独的区域应用。这种做法可最大限度地提高每个部署的区域化优势。
如需详细比较并深入了解此选择的影响，请参阅全球应用和区域应用。
将环境定义为单独的应用
您可以将不同的部署环境表示为不同的 App Hub 应用。这种方法可针对安全性、权限和运营风险提供强大的隔离，防止环境之间发生意外影响。
例如，您可以将应用结构化为 my-app-dev、my-app-staging 和 my-app-prod，分别对应开发、预演和生产环境。
虽然您可以在单个应用中使用 Environment 属性来标记资源，但将环境划分为不同的应用可以为访问权限控制、政策执行和监控提供精确的边界。您仍必须在这些特定于环境的应用中的资源上始终如一地使用 Environment 属性，以提供精细的详细信息并进一步指定角色。如需详细了解此属性和其他属性，请参阅使用属性进行治理。
与团队结构保持一致
考虑将应用边界与负责应用开发和运营的团队保持一致。由于 App Hub 中的应用模型反映了贵组织的结构，因此这种做法可以简化所有权和沟通。
使用属性进行治理
始终将属性应用于所有应用资源，以提高可发现性并强制执行治理。这些属性可提供丰富的元数据，用于过滤、报告和应用政策：
- 严重程度：有助于确定监控和突发事件响应资源的优先级。
- 环境：支持过滤和特定于环境的政策。
- 所有者：提供可见性和责任。
为使用这些属性标记资源建立组织标准。 如需了解详情，请参阅支持可发现性和治理。
确定应用管理用例
将 App Hub 与 Application Design Center 集成，打造从设计到运营的顺畅应用生命周期体验：
- 您有要注册为应用的现有资源：将设置模型中的现有 Google Cloud 资源注册到 App Hub 中的应用，以获得统一的可见性和运营控制。
- 您没有可注册为应用的现有资源：请使用应用设计中心设计和部署新应用。应用设计中心会自动在 App Hub 中注册已部署的资源，以便您的模型准确反映预期设计。应用设计中心还可以帮助您管理应用更新。当应用模板发生更改时，您可以更新基于该模板的所有实例，从而确保应用更新保持一致。
资源层次结构
标准Google Cloud 资源层次结构由组织、文件夹和项目资源组成。App Hub 通过已启用应用的文件夹和宿主项目的概念（具体取决于您的设置模型），在该层次结构之上引入了一个应用管理层。
了解所选设置模型如何适应现有的 Google Cloud资源层次结构有助于实现有效的治理、政策执行和资源发现。在选择设置模型来管理应用时，请查看建议的结构并规划资源层次结构。
持续优化
应用设计并非一成不变，通常会随着时间的推移而不断发展。定期检查并完善您的应用，确保它们始终符合您的业务需求、团队结构和不断变化的架构。
我们建议您使用 Cloud Hub 和 Gemini Cloud Assist 提供的分析洞见来确定优化机会，并相应地调整应用。此外，您还可以使用 App Design Center 来管理应用的生命周期。Cloud Hub 中的部署页面会显示基于 App Design Center 模板创建且有可用更新的应用，从而简化更新流程。