Google Cloud 良好架构框架中的这一支柱提供了优化Google Cloud中工作负载性能的建议。
本文档适用于规划、设计、部署和管理 Google Cloud中的工作负载的架构师、开发者和管理员。
此支柱中的建议可帮助贵组织高效运营、提高客户满意度、增加收入并降低费用。例如，当应用的后端处理时间缩短时，用户会体验更快的响应速度，从而可以提高用户留存率并增加收入。
性能优化流程可能需要在性能和费用之间进行权衡取舍。不过，优化性能有时可以帮助您降低费用。例如，自动扩缩可确保系统资源不会过载，从而帮助您在负载增加时提供可预测的性能。自动扩缩还会移除未使用的资源，从而帮助您在低负载期间降低费用。
性能优化是一个连续的过程，而不是一次性的活动。下图显示了性能优化过程中的各个阶段：
性能优化过程是一个持续的周期，包括以下阶段：
- 定义要求：在设计和开发应用之前，请为应用堆栈的每个层定义精细的性能要求。如需规划资源分配，请考虑关键的工作负载特征和性能预期。
- 设计和部署：使用有助于满足性能要求的弹性和可扩缩设计模式。
- 监控和分析：使用日志、跟踪、指标和提醒持续监控性能。
优化：随着应用的不断演变，考虑可能的重新设计。调整云资源的大小，并使用新功能来满足不断变化的性能要求。
如上图所示，继续监控、重新评估要求和调整云资源的周期。
如需了解针对 AI 和机器学习工作负载的特定性能优化原则和建议，请参阅良好架构框架中的 AI 和机器学习视角：性能优化。
核心原则
良好架构框架的“性能优化”支柱中的建议对应于以下核心原则：
贡献者
作者：
- Daniel Lees | 云安全架构师
- Gary Harmson | 客户工程师
- Luis Urena | 开发者关系工程师
- Zach Seils | 网络专家
其他贡献者：
- Filipe Gracio，博士 | 客户工程师
- Jose Andrade | 企业基础架构客户工程师
- Kumar Dhanagopal | 跨产品解决方案开发者
- Marwan Al Shawi | 合作伙伴客户工程师
- Nicolas Pintaux | 客户工程师，应用现代化改造专家
- Ryan Cox | 首席架构师
- Radhika Kanakam | Cloud GTM 高级项目经理
- Wade Holmes | 全球解决方案总监
规划资源分配
Google Cloud 良好架构框架的性能优化支柱中提供了这一原则，其中包含一些建议，可帮助您为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 利用率达到阈值时创建更多实例。这些新创建的实例有助于吸收负载，这有助于确保在达到您为 MIG 配置的实例数上限之前，平均 CPU 利用率保持在最佳水平。当需求减少时，自动扩缩政策会移除不再需要的实例。
规划 BigQuery 中的资源槽预留，或使用托管式自动扩缩器调整 Spanner 中自动扩缩配置的限制。
使用预测性扩缩
如果您的系统组件包含 Compute Engine，您必须评估预测性自动扩缩功能是否适用于您的工作负载。预测性自动扩缩功能会根据指标（例如 CPU 利用率）的历史趋势预测未来的负载。预测会每几分钟重新计算，这样可以使自动扩缩器快速调整其预测，以适应负载的最新变化。如果不使用预测性自动扩缩功能，则自动扩缩器只能根据观察到的实时负载变化来被动地扩缩实例组。预测性自动扩缩功能可同时处理实时数据和历史数据，以响应当前负载和预测负载。
实现无服务器架构
考虑使用本身具有弹性的无服务器服务（例如以下服务）实现无服务器架构：
与其他需要微调规则的服务（例如 Compute Engine）中的自动扩缩不同，无服务器自动扩缩是即时的，并且可以缩小到零资源。
使用 Kubernetes Autopilot 模式
对于需要对 Kubernetes 进行更严格控制的复杂应用，不妨考虑使用 Google Kubernetes Engine (GKE) 中的 Autopilot 模式。Autopilot 模式默认提供自动化和可伸缩性。GKE 会根据流量自动扩缩节点和资源。GKE 负责管理节点、为您的应用创建新节点以及配置自动升级和自动修复。
提倡模块化设计
Google Cloud 良好架构框架的性能优化支柱中提供了这一原则，其中提供了一些建议，可帮助您推广模块化设计。模块化组件和清晰的接口可以实现灵活扩缩、独立更新和未来的组件分离。
原则概览
了解应用组件与系统组件之间的依赖关系，以设计可伸缩的系统。
无论最初部署的是单体架构还是微服务架构，模块化设计都能实现灵活性和弹性。通过将系统分解为具有明确接口的定义明确的独立模块，您可以扩展各个组件以满足特定需求。
有针对性地进行扩缩可通过以下方式优化资源利用率并降低费用：
- 仅为每个组件预配必要的资源，并向需求较低的组件分配较少的资源。
- 在高流量时段添加更多资源，以保持用户体验。
- 移除利用率低的资源，而不影响性能。
模块化还可以提高可维护性。较小的自包含单元更易于理解、调试和更新，这有助于缩短开发周期并降低风险。
虽然模块化具有显著优势，但您必须评估潜在的性能权衡。模块之间的通信增加可能会导致延迟和开销。力求在模块化与性能之间取得平衡。高度模块化的设计可能并不适用于所有情况。如果性能至关重要，则可能需要采用更紧密耦合的方法。系统设计是一个迭代过程，您需要在此过程中不断审核和优化模块化设计。
建议
如需提倡模块化设计，请考虑以下部分中的建议。
设计松散耦合
设计松散耦合的架构。具有最少依赖项的独立组件有助于您构建可扩缩且弹性佳的应用。在规划服务边界时，您必须考虑可用性和可扩缩性要求。例如，如果某个组件的要求与其他组件不同，您可以将该组件设计为独立服务。针对不太重要的子进程或不会影响主要服务响应时间的服务，实现顺畅故障处理方案。
并发和并行设计
设计应用以支持同时执行多项任务，例如在用户与您的系统互动时处理多个用户请求或运行后台作业。将大型任务拆分为多个较小的块，以便多个服务实例同时处理。借助任务并发功能，您可以使用自动扩缩等功能来增加以下产品中的资源分配：
平衡模块化以实现灵活的资源分配
尽可能确保每个组件仅针对特定操作使用必要的资源（例如内存、存储空间和处理能力）。资源过度分配可能会导致不必要的费用，而资源分配不足可能会影响性能。
使用定义完善的接口
确保模块化组件通过清晰、标准化的接口（例如 API 和消息队列）有效通信，以减少转换层或外来流量带来的开销。
使用无状态模型
无状态模型有助于确保您可以独立于之前的请求处理每个请求或与服务的交互。此模型有助于实现可扩缩性和可恢复性，因为您可以增加、缩减或重启服务，而不会丢失正在处理的请求或进程所需的数据。
选择互补技术
选择与模块化设计相辅相成的技术。评估编程语言、框架和数据库是否支持模块化。
如需了解详情，请参阅以下资源：
持续监控和改进性能
Google Cloud 良好架构框架的性能优化支柱中提供了这一原则，其中包含一些建议，可帮助您持续监控和提升性能。
部署应用后，您可以使用日志、跟踪、指标和提醒来持续监控其性能。随着应用的发展和演变，您可以根据这些数据点的趋势重新评估您的性能要求。您最终可能需要重新设计应用的某些部分，以维护或提高其性能。
原则概览
持续改进性能的过程需要强大的监控工具和策略。Cloud 可观测性工具可帮助您收集延迟时间、吞吐量、错误率和资源利用率等关键绩效指标 (KPI)。云环境提供了多种方法，可对应用、网络和最终用户体验进行精细的性能评估。
提高性能是一项持续的努力，需要多方位的方法。以下关键机制和流程可帮助您提升性能：
- 为提供明确的方向并帮助跟踪进度，请制定与您的业务目标相符的效果目标。设定 SMART 目标：具体、可衡量、可实现、相关且有时间限制。
- 为了衡量效果并找出有待改进之处，请收集 KPI 指标。
- 如需持续监控系统是否存在问题，请在监控工具中使用可视化工作流。使用架构流程映射技术来发现冗余和低效问题。
- 为了打造持续改进的文化，请提供有助于员工成长的培训和计划。
- 为了鼓励积极主动地持续改进，请激励员工和客户持续提供有关应用性能的反馈。
建议
如需提倡模块化设计，请考虑以下部分中的建议。
定义明确的效果目标和指标
确定与业务目标相符的明确性能目标。这需要您深入了解应用的架构以及每个应用组件的性能要求。
优先优化直接影响核心业务功能和用户体验的关键组件。为确保这些组件能够继续高效运行并满足您的业务需求，请设置具体的可衡量效果目标。这些目标可能包括响应时间、错误率和资源利用率阈值。
这种主动方法有助于您发现和解决潜在瓶颈问题、优化资源分配，并最终为用户提供流畅且高性能的体验。
监控效果
持续监控云系统是否存在性能问题，并针对任何潜在问题设置提醒。监控和提醒功能可帮助您在问题影响到用户之前发现并解决问题。应用性能分析有助于发现瓶颈并优化资源使用。
您可以使用有助于有效排查问题和优化网络的工具。使用 Google Cloud Observability 找出 CPU 消耗、内存消耗或网络消耗较高的方面。这些功能可帮助开发者提高效率、降低成本并提升用户体验。Network Intelligence Center 会以可视化方式显示网络基础架构的拓扑，并可帮助您确定高延迟路径。
激励持续改进
营造一种持续改进的文化，让应用和用户体验都能受益。
为员工提供培训和发展机会，帮助他们提升在各项云服务中的效果提升方面的技能和知识。建立实践社区 (CoP)，并提供导师和教练计划，以支持员工成长。
为防止被动绩效管理，并鼓励积极主动的绩效管理，请鼓励员工、客户和利益相关方持续提供反馈。您可以考虑将该流程游戏化，方法是跟踪效果 KPI，并以排行榜的形式定期向团队呈现这些指标。
为了了解您的应用在用户中的表现和用户满意度随时间的变化情况，我们建议您从定量和定性两个方面衡量用户反馈。HEART 框架可帮助您收集五类用户反馈：
- 幸福
- 互动度
- 采用
- 留存率
- 任务成功
通过使用此类框架，您可以通过数据驱动的反馈、以用户为中心的指标、富有实用价值的分析洞见以及对目标的清晰理解，激励工程师。