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