本指南介绍了如何使用 App Hub 和 App Design Center 在以应用为中心的 Google Cloud 中设计、定义和管理 App Hub 应用的最佳实践。 遵循这些实践对于创建可操作、可管理且高效的应用至关重要，这些应用应与您的业务目标保持一致。
应用管理的核心原则
遵循以下核心原则有助于您以应用为中心的方式管理 Google Cloud 基础架构，从而最大限度地提高价值：
明确界定边界：以符合运营、监控、治理和问题排查逻辑的方式设置应用管理边界。此外，在此边界内用作应用组件的资源最好具有共同的运营生命周期或业务价值，以简化管理并降低风险。
出于运营目的，请务必了解应用管理边界与可观测性范围之间的区别。
- 应用管理边界定义了包含 Google Cloud 资源的项目集合，您可以使用这些资源来设计、创建和管理应用，如关键概念中所述。
- 借助 Google Cloud Observability 中的可观测性范围，您可以同时查看多个项目的遥测数据。
您的日志、指标和轨迹范围应包含应用管理边界内的数据。如需详细了解可观测性范围，请参阅配置可观测性范围。
反映业务能力：围绕业务功能或端到端工作流程（而不仅仅是技术层）来定义应用。应用应代表您业务的独特价值流。
明确所有权和元数据：为每个应用分配明确的属性，以便团队在 App Hub 中有效地查找、了解和管理这些应用。这些属性支持发现和治理。 可发现性是指相关团队（例如开发者和运维人员）可以找到应用。治理明确定义了每个应用的所有者和责任人。
在 App Hub 中，您可以定义以下关键属性：
- 环境：应用生命周期中的阶段，例如生产环境、预演、测试或开发。此属性可帮助团队根据组件的部署阶段过滤和管理组件。
- 重要性：应用及其组件的业务重要性，例如它们是否属于任务关键型。此属性可用于确定监控和突发事件响应的优先级。
- 所有者：负责应用的各个团队的联系信息，有助于明确责任、简化沟通并理清职责。
应用设计中心支持这些属性，还包含应用组件的位置和配置详细信息。持续应用这些属性和详细信息对于发现、治理和报告至关重要。
设计以适应发展：App Design Center 可让您为应用创建可重复使用的模板，从而帮助您设计出能够适应发展变化的应用。如果您更新了底层模板，则可以通过重新部署应用来应用这些更改，从而帮助您满足需求、引入新功能或进行架构更改，以适应未来的增长和不断变化的基础设施需求。
迭代和优化应用模型：定期查看并调整应用定义，以反映组织结构、业务优先级和技术架构的变化。Cloud Hub 提供集中式视图，可显示从 Application Design Center 模板部署的应用的可用更新，帮助您查看和调整应用定义，以反映这些不断变化的需求。
数据模型建议
通过了解如何在 App Hub 的框架内将实际系统建模为应用、服务和工作负载，您可以有效地在 Google Cloud环境中使用应用管理功能。
在定义应用时，请务必应用应用管理的核心原则，例如使用属性来明确所有权和元数据。
为了在设计应用组件时考虑到此框架，请参考以下推荐的使用场景示例。
示例：基于微服务的应用
电子商务系统（例如在线商店的 OpenTelemetry 演示中所述的系统）是基于微服务的应用的示例。我们建议将此类系统建模为单个应用。这种方法可提供从产品发现到结账的整个业务功能的统一视图。例如，请考虑以下针对在 Google Cloud中运行的现有资源的模型：
应用：在 App Hub 中创建或定义一个名为
my-ecommerce-site的应用。此应用将整个网店表示为一个可管理的单元。向应用注册以下资源，以创建组件的逻辑分组，这些组件共同提供在线商店的业务功能：- 将微服务作为工作负载：将构成电子商务系统的各个微服务（例如广告、购物车和结账）注册为应用中的工作负载。这些是包含二进制代码的计算资源，可执行业务逻辑的离散部分，以 Google Kubernetes Engine (GKE) 部署的形式运行。
- 将网络端点作为服务：将这些微服务的网络端点（例如其负载平衡器）注册为应用的服务。这些会向客户端公开网店功能。
避免将每个微服务注册为单独的应用。这种方法会使业务背景支离破碎，难以全面了解网店的健康状况和效果。
通过将所有微服务分组到单个应用中，您可以获得以下好处：
- 全面的可视性：您可以在一个统一视图中监控整个电子商务用户历程的健康状况和效果，从广告功能到结账功能。
- 清晰的业务背景：应用将基础架构与其所服务的业务功能（即网上商店）相匹配。这种方法有助于更轻松地了解应用的健康状况和费用。
- 简化问题排查：出现问题时，您可以查看应用中不同微服务之间的依赖关系，从而加快根本原因分析。
示例：三层式 Web 应用
三层式 Web 应用是一种架构模式，可将应用分为前端层、后端层和数据库层。此使用情形演示了如何将完整的业务功能建模为单个应用，而不是将每个层级视为隔离的组件。
以下模型将技术层映射到三层 Web 应用：
应用：创建一个应用（例如
my-web-app），作为构成 Web 应用的所有组件的逻辑容器。服务：将向其他层或用户公开功能的网络接口注册为服务，例如：
- 接收用户流量的前端负载均衡器。
- 用于管理前端和后端之间流量的内部负载均衡器。
- Cloud SQL 或 Spanner 数据库实例，用于向后端逻辑层公开数据服务。
工作负载：将运行应用代码的计算资源注册为工作负载，例如：
- 提供前端用户界面的托管式实例组 (MIG) 或 Google Kubernetes Engine 部署。
- 运行后端业务逻辑的 MIG 或 Google Kubernetes Engine 部署。
通过将所有三个层级分组到一个应用中，您可以获享以下好处：
- 统一的可观测性：您可以在应用监控中的单个信息中心内监控整个应用的健康状况和性能，而无需将来自三个不同应用的数据拼凑在一起。
- 明确所有权：您可以为
my-web-app应用分配业务、开发者和运营者所有者，从而明确整个业务职能的责任。 - 简化治理：您可以在
my-web-app级应用政策和访问权限控制，从而在所有层级实现一致的治理。
应用设计和治理策略
采用以下策略，确保您的 App Hub 和 Application Design Center 设置可伸缩、可管控，并与您的运营实践保持一致。
选择全球应用和区域应用
您为应用选择的位置（全球级或区域级）是一项基本决策，会影响数据处理、延迟时间和合规性：
- 优先考虑区域性应用：尽可能将应用定义为区域性应用。这种做法具有诸多优势，例如缩短延迟时间、节省潜在费用，以及符合数据驻留要求。如果所有应用组件都位于单个 Google Cloud 区域内，建议使用区域级应用，这样可与特定于区域的 Google Cloud 功能和故障网域实现固有的兼容性。如需有关构建高可用性系统的指导，请参阅通过资源冗余构建高可用性系统。
- 有策略地使用全球应用：仅当系统组件必须分布在多个区域或涉及全球 Google Cloud 资源（例如全球外部应用负载平衡器）时，才选择全球应用。
- 分解多区域系统：如果您在多个区域中拥有资源，但这些资源并未形成一个有凝聚力的全球功能，请考虑为每个相应区域中的组件定义单独的区域应用。这种做法可最大限度地提高每个部署的区域化优势。
如需详细比较 App Hub 中不同的部署地理位置，请参阅全球应用和区域应用。
将环境分离为不同的应用
为了支持在安全性、权限和运营风险方面的隔离，请将不同的部署环境（例如开发、预演和生产环境）表示为不同的应用。例如，您可以将应用结构化为 my-app-dev、my-app-staging 和 my-app-prod。
将环境分离为不同的应用，可为访问权限控制、政策执行和监控提供精确的限制。此外，在应用组件中始终如一地使用属性、配置详细信息和位置信息有助于提高可发现性并加强治理。这些属性可提供丰富的元数据，用于过滤、报告和应用政策。例如，Environment 属性可为不同的部署环境政策提供精细的详细信息和资源专属控制。如需详细了解此属性和其他属性，请参阅属性和特性。
使应用管理边界与团队结构保持一致
在应用管理边界内，表示您的组织结构，特别是负责应用开发和运营的团队。
这种做法简化了所有权和沟通，因为应用模型反映了企业用于定义如何划分、分组和协调任务以实现其功能的框架。
遵循应用生命周期
将 App Hub 与 Application Design Center 集成，打造顺畅的应用生命周期体验：
- 您有预先存在的资源要注册到应用中：使用 App Hub 将现有 Google Cloud 资源注册为应用中的服务或工作负载。这种实践可让您快速获得对当前基础设施的统一可见性和运营控制权。（可选）您稍后可以在 App Design Center 中基于正在运行的应用创建模板，以便为未来的部署标准化架构。
- 您没有要注册到应用中的预先存在的资源：使用应用设计中心，通过受监管的可重用模板设计和部署新应用。从应用设计中心模板部署应用时，组件会自动在 App Hub 中注册，以便应用模型准确反映预期设计。应用设计中心还可以帮助您根据模板修订版本管理一致的应用更新。如果您更新模板，可以重新部署应用以传播更改，从而支持一致性和治理。
资源层次结构注意事项
Google Cloud中的资源层次结构是实现应用管理的实用基础。您可以通过配置管理项目来定义应用管理边界，从而在该层次结构之上引入应用管理层。如需大致了解不同产品如何协同工作，共同构成以应用为中心的 Google Cloud 解决方案，请参阅以应用为中心的 Google Cloud。
周全地规划用于应用管理的 Google Cloud 资源层次结构对于建立逻辑分组至关重要。您选择单个项目、文件夹或一组项目来定义应用管理边界，这从根本上决定了治理、政策执行和资源发现。此外，以应用为中心的 Google Cloud 产品支持因您定义的应用管理边界而异。
如需根据资源层次结构和业务需求确定最佳应用管理边界，并了解产品对不同资源结构模式的支持，请参阅选择应用设置模型。
持续优化
应用设计并非一成不变，通常会随着时间的推移而不断发展。定期检查和优化应用，确保它们始终与您的业务职能、团队结构和不断变化的架构保持一致。
我们建议您使用 Cloud Hub 和 Gemini Cloud Assist 提供的分析洞见来确定优化机会，并相应地调整应用。使用 App Design Center 通过模板对架构变更进行建模和部署，并管理应用的生命周期。