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

Google Cloud Well-Architected Framework 中的这一要素提供了有关优化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 Well-Architected Framework 的性能优化核心中的这一原则提供了一些建议来帮助您整合弹性，即根据工作负载要求的变化动态调整资源。

弹性可以让系统的不同组件独立扩缩。这种有针对性的扩缩可以精确地将资源分配到需要的地方，而不会过度预配或预配不足，因此有助于提高性能和成本效益。

原则概览

系统的性能要求会直接影响系统纵向扩缩或横向扩缩的时间和方式。您需要评估系统的容量并确定系统预期在基准时处理的负载。然后，您需要确定希望系统如何响应负载的增加和减少。

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

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

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

建议

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

针对峰值负载期规划

您需要为已知事件（例如客户需求增加的预期时段）规划有效的扩缩路径。

考虑在已知的高流量时段到来之前扩大系统规模。例如，如果您是一家零售组织，您预计需求在季节性销售期间会增加。我们建议您在执行销售之前手动扩缩系统，以确保系统可以立即处理增加的负载或立即调整现有限制。否则，系统可能需要几分钟时间来添加资源以响应实时更改。您应用的容量提升速度可能不够快，导致一些用户遇到延迟。

对于未知或意外事件，例如需求或流量的突然激增，您可以使用自动扩缩功能来触发基于指标的弹性扩缩。这些指标可能包括 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 Well-Architected Framework 的性能优化核心中的这一原则提供了一些建议，可帮助您推广模块化设计。模块化组件和清晰的界面可实现灵活的扩缩、独立更新和未来的组件分离。

原则概览

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

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

有针对性的扩缩可以通过以下方式帮助优化资源利用率并降低费用：

  • 只为每个组件预配必要的资源，并为需求较低的组件分配较少的资源。
  • 在高流量期间添加更多资源，以维持用户体验。
  • 在不影响性能的情况下移除利用率过低的资源。

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

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

建议

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

设计时采用松散耦合

设计松散耦合的架构。依赖项最少的独立组件可帮助您构建可扩缩的弹性应用。在规划服务的边界时，您必须考虑可用性和可扩缩性要求。例如，如果某个组件的要求与其他组件不同，您可以将该组件设计为独立的服务。为不太重要的子进程或服务实施优雅故障计划，这些子进程或服务不会影响主要服务的响应时间。

在设计时考虑并发和并行性

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

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

请尽可能确保每个组件仅使用必要的资源（例如内存、存储空间和处理能力）来执行特定操作。资源过度分配可能会产生不必要的费用，而资源分配不足会降低性能。

使用明确定义的接口

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

使用无状态模型

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

选择互补技术

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

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

持续监控和提升性能

Google Cloud Well-Architected Framework 的性能优化要素中的这一原则提供了一些建议，可帮助您持续监控和提升性能。

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

原则概览

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

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

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

建议

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

设定明确的效果目标和指标

定义与您的业务目标相一致的清晰性能目标。这需要深入了解应用的架构以及每个应用组件的性能要求。

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

这种主动式方法可帮助您识别和解决潜在瓶颈、优化资源分配，并最终为您的用户提供无缝且高性能的体验。

监控效果

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

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

鼓励持续改进

打造一种持续改进的文化，对应用和用户体验都有益。

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

为了防止被动的性能管理，并鼓励积极主动地管理性能，应鼓励员工、客户和利益相关方持续提供反馈。您可以考虑通过跟踪有关性能的 KPI 并以联赛表的形式频繁向团队展示这些指标，使流程实现游戏化。

为了了解应用在一段时间内的表现和用户满意度，我们建议您对用户反馈进行定量和定性衡量。HEART 框架可帮助您捕获以下五类用户反馈：

  • 幸福
  • 互动
  • 采用
  • 留存率
  • 任务成功

通过使用这种框架，您可以通过以数据为依据的反馈、以用户为中心的指标、富有实用价值的分析洞见以及对目标的清晰了解来激励工程师。