良好架构框架：性能优化支柱

Last reviewed 2025-02-14 UTC

Google Cloud 架构完善框架中的这一支柱提供了有关如何优化Google Cloud中的工作负载性能的建议。

本文档适用于计划、设计、部署和管理 Google Cloud中的工作负载的架构师、开发者和管理员。

此支柱中的建议可帮助您的组织高效地运营、提高客户满意度、增加收入并降低费用。例如，当应用的后端处理时间缩短时，用户会体验更快的响应速度，从而可以提高用户留存率并增加收入。

性能优化过程可能需要在性能和费用之间进行权衡取舍。不过，优化性能有时可以帮助您降低费用。例如，当负载增加时，自动扩缩可确保系统资源不会过载，从而帮助您提供可预测的性能。自动扩缩还会移除低负载期间未使用的资源，从而帮助您降低费用。

性能优化是一个连续的过程，而不是一次性的活动。下图显示了性能优化过程中的各个阶段：

性能优化过程

性能优化过程是一个持续的循环，包括以下阶段：

  1. 定义要求：在设计和开发应用之前，请为应用堆栈的每个层定义精细的性能要求。为了规划资源分配，请考虑关键工作负载特征和性能预期。
  2. 设计和部署：使用有助于满足性能要求的弹性和可伸缩设计模式。
  3. 监控和分析：使用日志、跟踪、指标和提醒持续监控性能。

  4. 优化：随着应用的发展，考虑进行潜在的重新设计。 合理调整云资源大小并使用新功能来满足不断变化的性能要求。

    如上图所示，继续执行监控、重新评估要求和调整云资源的循环。

如需了解针对 AI 和机器学习工作负载的性能优化原则和建议，请参阅架构完善框架中的 AI 和机器学习视角：性能优化。

核心原则

架构完善框架的性能优化支柱中的建议与以下核心原则相对应：

贡献者

作者：

其他贡献者：

规划资源分配

Google Cloud Well-Architected Framework 的性能优化支柱中的这一原则提供了一些建议，可帮助您为Google Cloud中的工作负载规划资源。它强调了在设计和开发应用以进行云部署或迁移之前，定义精细要求的重要性。

原则概览

为满足业务需求，请务必在设计和开发之前定义应用的性能要求。尽可能准确地定义这些要求，包括针对整个应用的要求和针对应用堆栈每一层的要求。例如，在存储层中，您必须考虑应用所需的吞吐量和每秒 I/O 操作次数 (IOPS)。

从一开始，就应在规划应用设计时考虑到性能和可伸缩性。考虑用户数量、数据量以及随时间推移的潜在增长等因素。

每种工作负载的性能要求各不相同，具体取决于工作负载的类型。每个工作负载都可以包含具有独特性能特征的组件系统和服务。例如，负责定期批量处理大型数据集的系统与交互式虚拟桌面解决方案相比，对性能的要求有所不同。您的优化策略必须满足每个工作负载的特定需求。

选择与每个工作负载的性能目标相符的服务和功能。在优化效果方面，没有一种解决方案能够适用于所有情况。优化每个工作负载后，整个系统可以实现最佳性能和效率。

请考虑以下可能会影响性能要求的工作负载特征：

  • 部署原型：您为应用选择的部署原型会影响您对产品和功能的选择，进而决定您可以从应用中获得的效果。
  • 资源放置：为应用资源选择 Google Cloud 区域时，我们建议您优先考虑最终用户的低延迟，遵守数据本地化法规，并确保所需 Google Cloud 产品和服务的可用性。
  • 网络连接：选择可优化数据访问和内容传送的网络服务。充分利用 Google Cloud的全球网络、高速骨干网、互连位置和缓存服务。
  • 应用托管选项：选择托管平台时，您必须评估每个选项的性能优势和劣势。 例如，考虑裸机、虚拟机、容器和无服务器平台。
  • 存储策略：根据您的性能要求选择最佳存储策略。
  • 资源配置：机器类型、IOPS 和吞吐量可能会对性能产生重大影响。此外，在设计阶段的早期，您必须考虑适当的安全功能及其对资源的影响。规划安全功能时，请准备好接受必要的性能权衡，以免产生任何不可预见的影响。

建议

为确保资源分配达到最佳状态，请考虑以下各部分中的建议。

配置和管理配额

确保您的应用仅使用必要的资源，例如内存、存储空间和处理能力。过度分配会导致不必要的支出，而分配不足可能会导致性能下降。

为了适应弹性伸缩并确保有足够的资源可用，请定期监控配额容量。此外，您还可以跟踪配额用量，以发现潜在的伸缩限制或过度分配问题，然后就资源分配做出明智的决策。

普及知识并提高认知度

向用户告知性能要求，并提供有关有效性能管理技巧的教育资源。

为了评估进展情况并确定需要改进的方面，请定期记录目标效果和实际效果。对应用进行负载测试，以找出潜在的断点并了解如何扩缩应用。

监控性能指标

使用 Cloud Monitoring 来分析性能指标的趋势、分析实验的影响、定义关键指标的提醒，以及执行回顾性分析。

Active Assist 是一组工具，可提供数据分析和建议，帮助您优化资源利用率。这些建议可帮助您调整资源分配并提升效果。

利用弹性

Google Cloud 架构完善框架的性能优化支柱中的这一原则提供了相关建议，可帮助您纳入弹性，即根据工作负载要求的变化动态调整资源的能力。

弹性允许系统的不同组件独立扩缩。这种有针对性的伸缩有助于提高性能和成本效益，因为它可以根据实际需求精确分配资源，而不会过度或不足地配置资源。

原则概览

系统的性能要求直接影响系统何时以及如何进行纵向扩缩或横向扩缩。您需要评估系统的容量，并确定系统在基准状态下预计要处理的负载。然后，您需要确定希望系统如何响应负载的增加和减少。

当负载增加时，系统必须横向扩容、纵向扩容或同时进行这两种扩容。对于横向伸缩，请添加副本节点，以确保系统具有足够的总体容量来满足增加的需求。对于纵向伸缩，请将应用的现有组件替换为包含更多容量、内存和存储空间的组件。

当负载减少时，系统必须缩减（横向、纵向或同时横向和纵向）。

定义系统扩缩的情况。计划在已知的高流量时段手动扩缩系统。使用自动扩缩等工具，这些工具可以根据负载的增减情况做出响应。

建议

如需利用弹性，请考虑以下各部分中的建议。

规划高峰负荷时段

您需要为已知事件规划高效的伸缩路径，例如客户需求预计会增加的时期。

考虑在已知的高流量时期之前伸缩系统。例如，如果您是零售组织，则预计在季节性促销期间需求会增加。我们建议您在这些促销活动开始之前手动扩容或横向扩缩系统，以确保系统能够立即处理增加的负载或立即调整现有限制。否则，系统可能需要几分钟时间才能添加资源来响应实时变化。应用的容量可能无法快速增加，导致部分用户遇到延迟。

对于未知或意外事件（例如需求或流量突然激增），您可以使用自动伸缩功能来触发基于指标的弹性伸缩。这些指标可以包括 CPU 利用率、负载均衡器处理能力、延迟时间，甚至包括您在 Cloud Monitoring 中定义的自定义指标。

例如，假设某个应用在 Compute Engine 代管式实例组 (MIG) 上运行。此应用要求每个实例在平均 CPU 利用率达到 75% 之前以最佳状态运行。在此示例中，您可以定义一个自动扩缩政策，该政策会在 CPU 利用率达到阈值时创建更多实例。这些新创建的实例有助于吸收负载，从而确保平均 CPU 利用率保持在最佳水平，直到达到您为 MIG 配置的实例数上限。当需求减少时，自动扩缩政策会移除不再需要的实例。

使用托管的自动扩缩器，在 BigQuery 中规划资源槽预留，或调整 Spanner 中自动扩缩配置的限制。

使用预测性伸缩

如果您的系统组件包含 Compute Engine，则必须评估预测性自动扩缩是否适合您的工作负载。预测性自动扩缩功能会根据指标（例如 CPU 利用率）的历史趋势预测未来的负载。预测会每几分钟重新计算一次，因此自动扩缩器可以快速调整其预测，以适应负载的最新变化。如果不使用预测性自动扩缩功能，则自动扩缩器只能根据观察到的实时负载变化来被动地扩缩实例组。预测性自动扩缩功能会同时处理实时数据和历史数据，以应对当前负载和预测负载。

实现无服务器架构

考虑使用本身就具有弹性的无服务器服务来实现无服务器架构，例如：

与其他需要微调规则的服务（例如 Compute Engine）中的自动扩缩不同，无服务器自动扩缩是即时的，并且可以缩小到零资源。

使用 Kubernetes 的 Autopilot 模式

对于需要更好地控制 Kubernetes 的复杂应用，请考虑使用 Google Kubernetes Engine (GKE) 中的 Autopilot 模式。Autopilot 模式默认提供自动化和可伸缩性。 GKE 会根据流量自动扩缩节点和资源。GKE 会管理节点、为您的应用创建新节点，并配置自动升级和自动修复。

推广模块化设计

Google Cloud 架构完善框架的性能优化支柱中的这一原则提供了一些建议，可帮助您推广模块化设计。模块化组件和清晰的接口可实现灵活的伸缩、独立更新和未来的组件分离。

原则概览

了解应用组件与系统组件之间的依赖关系，以便设计可伸缩的系统。

无论最初部署的是单体架构还是微服务架构，模块化设计都能实现灵活性和弹性。通过将系统分解为具有清晰接口的独立模块，您可以扩展各个组件以满足特定需求。

有针对性的伸缩有助于通过以下方式优化资源利用率并降低成本：

  • 仅为每个组件预配必要的资源，并为需求较低的组件分配较少的资源。
  • 在高流量时段添加更多资源，以保持良好的用户体验。
  • 移除利用率低的资源，同时不影响性能。

模块化还可提高可维护性。更小、更独立的单元更易于理解、调试和更新，从而缩短开发周期并降低风险。

虽然模块化具有显著优势，但您必须评估潜在的性能权衡。模块之间通信的增加可能会导致延迟和开销。力求在模块化和性能之间取得平衡。高度模块化的设计可能并不适合所有情况。如果性能至关重要，则可能需要采用更紧密耦合的方法。 系统设计是一个迭代过程，您可以在其中不断检查和优化模块化设计。

建议

如需推广模块化设计，请考虑以下各部分中的建议。

针对松散耦合进行设计

设计松散耦合的架构。 具有最少依赖项的独立组件可帮助您构建可伸缩的弹性应用。 在规划服务边界时，您必须考虑可用性和可伸缩性要求。例如，如果某个组件的要求与其他组件不同，您可以将该组件设计为独立服务。针对不太重要的子进程或不影响主要服务响应时间的服务，实施从容失败方案。

针对并发和并行性进行设计

设计应用时，应使其能够同时支持多项任务，例如在用户与系统互动时处理多项用户请求或运行后台作业。将大型任务分解为多个较小的块，以便多个服务实例可以同时处理这些块。借助任务并发，您可以使用自动扩缩等功能来增加以下产品中的资源分配：

平衡模块化，实现灵活的资源分配

尽可能确保每个组件仅使用特定操作所需的资源（如内存、存储空间和处理能力）。资源过度分配会导致不必要的费用，而资源分配不足则会影响性能。

使用定义完善的接口

确保模块化组件通过清晰、标准化的接口（例如 API 和消息队列）有效通信，以减少因转换层或无关流量而产生的开销。

使用无状态模型

无状态模型有助于确保您可以独立于之前的请求处理每个请求或与服务的交互。此模型有助于实现可伸缩性和可恢复性，因为您可以增加、缩减或重启服务，而不会丢失正在处理的请求或进程所需的数据。

选择互补技术

选择与模块化设计相辅相成的技术。评估编程语言、框架和数据库的模块化支持。

如需了解详情，请参阅以下资源：

持续监控和改进性能

Google Cloud 架构完善框架的性能优化支柱中的这一原则提供了一些建议，可帮助您持续监控和提升性能。

部署应用后，您可以使用日志、跟踪、指标和提醒来持续监控其性能。随着应用的发展和发展，您可以根据这些数据点的趋势重新评估性能要求。您可能最终需要重新设计应用的某些部分才能维护或提高其性能。

原则概览

持续改进性能的过程需要强大的监控工具和策略。借助云可观测性工具，您可以收集延迟时间、吞吐量、错误率和资源利用率等关键绩效指标 (KPI)。云环境提供了多种方法，可对应用、网络和最终用户体验进行精细的性能评估。

提高性能是一项持续的工作，需要采取多方面的方法。以下关键机制和流程可帮助您提升效果：

  • 为了提供明确的方向并帮助跟踪进度，请确定与您的业务目标相符的效果目标。设定 SMART 目标：具体、可衡量、可实现、相关且有时限。
  • 为了衡量效果并确定需要改进的方面，请收集 KPI 指标。
  • 如需持续监控系统是否存在问题，请使用监控工具中的可视化工作流。使用架构流程映射技术来识别冗余和低效之处。
  • 为了打造持续改进的文化，请提供有助于员工成长的培训和计划。
  • 为了鼓励主动持续改进，您可以激励员工和客户持续提供有关应用性能的反馈。

建议

如需推广模块化设计，请考虑以下各部分中的建议。

定义明确的绩效目标和指标

确定与业务目标相符的明确效果目标。这需要深入了解应用的架构以及每个应用组件的性能要求。

优先优化直接影响核心业务功能和用户体验的最关键组件。为确保这些组件继续高效运行并满足您的业务需求，请设置具体且可衡量的效果目标。这些目标可以包括响应时间、错误率和资源利用率阈值。

这种主动式方法有助于您发现并解决潜在的瓶颈问题，优化资源分配，最终为用户提供顺畅且高性能的体验。

监控效果

持续监控云系统是否存在性能问题，并针对任何潜在问题设置提醒。借助监控和提醒，您可以及时发现并解决问题，以免影响到用户。应用分析有助于识别瓶颈，并有助于优化资源使用。

您可以使用有助于有效排查问题和优化网络的工具。使用 Google Cloud Observability 找出 CPU 消耗、内存消耗或网络消耗较高的区域。这些功能可帮助开发者提高效率、降低成本并提升用户体验。Network Intelligence Center 可直观呈现网络基础设施的拓扑，并帮助您识别高延迟路径。

激励持续改进

营造持续改进的文化，让应用和用户体验都能从中受益。

为员工提供培训和发展机会，以提升他们在各种云服务中的性能优化技巧方面的技能和知识。 建立实践社区 (CoP)，并提供指导和辅导计划来支持员工成长。

为防止被动的绩效管理，并鼓励主动的绩效管理，请鼓励员工、客户和利益相关者持续提供反馈。您可以考虑将此流程游戏化，方法是跟踪绩效方面的 KPI，并以排行榜的形式定期向团队展示这些指标。

为了解您的表现和用户满意度随时间的变化情况，我们建议您从定量和定性两个方面衡量用户反馈。HEART 框架可帮助您收集五个类别的用户反馈：

  • 幸福感
  • 互动
  • 采用
  • 保留
  • 任务成功

通过使用此类框架，您可以利用数据驱动的反馈、以用户为中心的指标、可据以采取行动的数据洞见以及对目标的清晰了解来激励工程师。