利用弹性

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

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

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

原则概览

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

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

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

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

建议

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

针对峰值负载期规划

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

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

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

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

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

使用预测性扩缩

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

实现无服务器架构

考虑实现无服务器架构，其中包含本身具有弹性的无服务器服务，例如：

• Cloud Run
• Cloud Run 函数
• BigQuery
• Spanner
• Eventarc
• 工作流程
• Pub/Sub

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

为 Kubernetes 使用 Autopilot 模式

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