将自动扩缩器工具部署到 Cloud Run functions

自动扩缩器工具具有灵活性，可以适应运维和应用团队之间的现有职责分离。配置 Spanner 实例的自动扩缩功能的职责可以由单个运维团队集中管理，也可以分发给更接近这些 Spanner 实例所处理的应用的团队。

本文档是系列文章中的一篇，该系列文章还包括：

本系列文章适用于想要降低运维开销和优化 Spanner 部署成本的 IT、运维和站点可靠性工程 (SRE) 团队。

本页面介绍了根据您的要求将自动扩缩器部署到 Cloud Run functions 的三种方式：

每个项目的部署拓扑。自动扩缩器基础架构与需要自动扩缩的 Spanner 部署在同一项目中。对于希望管理自己的自动扩缩器配置和基础架构的独立团队，我们建议使用此拓扑。此外，按项目部署拓扑也是测试自动扩缩器功能的良好起点。
集中式部署拓扑。自动扩缩器工具部署在单个项目中，并管理不同项目中的一个或多个 Spanner 实例。对于管理一个或多个 Spanner 实例的配置和基础架构的团队，我们建议使用此拓扑结构，同时保持自动扩缩程序的组件和配置位于中心位置。在集中式拓扑中，除了自动扩缩程序，您还设置了第二个项目，本教程中称为“应用项目”。应用项目包含应用资源，包括 Spanner。
分布式部署拓扑。大多数自动扩缩器基础架构部署在一个项目中，但某些基础架构组件会与进行自动扩缩的 Spanner 实例部署在不同的项目中。如果组织拥有多个团队，并且拥有 Spanner 实例的团队希望仅管理其实例的自动扩缩器配置参数，但其余的自动扩缩器基础架构由中心团队管理，我们建议使用此拓扑。

无服务器方便部署和管理

在此模型中，自动扩缩器工具仅使用无服务器和低管理 Google Cloud 工具（例如 Cloud Run functions、Pub/Sub、Cloud Scheduler 和 Firestore）构建。这种方法可最大限度地减少运行自动扩缩器工具的成本和运维开销。

通过使用内置 Google Cloud 工具，自动扩缩器工具可充分利用 Identity and Access Management (IAM) 来进行身份验证和授权。

配置

自动扩缩器工具通过在 Cloud Scheduler 中定义的配置管理 Spanner 实例。如果您需要以相同的间隔轮询多个 Spanner 实例，我们建议您在相同的 Cloud Scheduler 作业中配置它们。每个实例的配置都以 JSON 对象的形式表示。以下是一个配置示例，在其中使用一个 Cloud Scheduler 作业管理两个 Spanner 实例：

[
  {
    "projectId": "my-spanner-project",
    "instanceId": "my-spanner",
    "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
    "units": "NODES",
    "minSize": 1,
    "maxSize": 3
  },
  {
    "projectId": "different-project",
    "instanceId": "another-spanner",
    "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
    "units": "PROCESSING_UNITS",
    "minSize": 500,
    "maxSize": 3000,
    "scalingMethod": "DIRECT"
  }
]

Spanner 实例可以在不同的 Cloud Scheduler 作业中有多个配置。例如，一个实例可以有一个包含用于正常操作的线性方法的自动扩缩器配置，但还有另一个包含用于计划批量工作负载的直接方法的自动扩缩器配置。

Cloud Scheduler 作业运行时，它将向 Polling Pub/Sub 主题发送 Pub/Sub 消息。此消息的载荷是在同一作业中配置的所有实例的配置对象的 JSON 数组。如需查看配置选项的完整列表，请参阅轮询器 README 文件。

每个项目的拓扑

在每个项目的拓扑部署中，每个需要 Spanner 实例进行自动缩放的项目也具有自己的自动扩缩器组件独立部署。对于希望管理自己的自动扩缩器配置和基础架构的独立团队，我们建议使用此拓扑。这也是测试自动扩缩器工具功能的良好起点。

下图展示了每个项目部署的高度概括的概念视图。

概念性的每个项目部署。

上图中描述的按项目部署具有以下特征：

两个应用（应用 1 和应用 2）分别使用各自的 Spanner 实例。
Spanner 实例 (A) 位于相应的应用 1 和应用 2 项目中。
独立的自动扩缩器 (B) 将部署到每个项目中，以控制项目中的实例自动扩缩。

每个项目部署具有以下优点和缺点。

优点：

最简单的设计：按项目拓扑是三种拓扑中最简单的设计，因为所有自动扩缩器组件均与进行自动扩缩的 Spanner 实例一起部署。
配置：由拥有 Spanner 实例的团队控制调度器参数，与集中式或分布式拓扑相比，这使该团队能够更灵活地按需求调整自动扩缩器。
明确承担基础架构责任：每个项目的拓扑设计可以为自动扩缩器基础架构建立明确的责任与安全性，因为 Spanner 实例的团队所有者也是自动扩缩器基础架构的所有者。

缺点：

整体维护更多：每个团队都负责自动扩缩器配置和基础架构，因此难以确保公司中的所有自动扩缩器工具都遵循相同的更新准则。
更复杂的审核：由于每个团队都具有更高级别的控制，因此集中式审核可能会更复杂。

如需了解如何使用按项目拓扑设置自动扩缩器，请参阅按项目部署分步指南。

集中式拓扑

与按项目拓扑一样，在集中式拓扑部署中，自动扩缩器工具的所有组件都位于同一项目中。但是，Spanner 实例位于不同的项目中。此部署适用于通过中央位置处的单个自动扩缩器工具部署来管理多个 Spanner 实例的配置和基础架构的团队。

下图显示集中式项目部署的高度概括的概念视图：

概念性的集中式项目部署。

上图中显示的集中式部署具有以下特征：

两个应用（应用 1 和应用 2）分别使用各自的 Spanner 实例。
Spanner 实例 (A) 位于相应的应用 1 和应用 2 项目中。
自动扩缩器 (B) 部署在单独的项目中，以控制应用 1 和应用 2 项目中的 Spanner 实例的自动扩缩。

集中式部署具有以下优势和缺点。

优点：

集中式配置和基础架构：单个团队控制调度器参数和自动扩缩器基础架构。在受严格监管的行业中，这种方法非常有用。
整体维护更少：与按项目部署相比，维护和设置通常需要更少的维护工作。
集中式政策和审核：跨团队的最佳做法可能更易于指定和强制执行。审核可能更容易执行。

缺点：

集中式配置：对自动扩缩器参数的任何更改都需要通过集中式团队完成，即使请求更改的团队拥有 Spanner 实例也是如此。
可能面临额外风险：集中式团队本身可能会成为单点故障，即使自动扩缩器基础架构在设计时考虑了高可用性。

如需了解如何使用集中式拓扑设置自动扩缩器，请参阅集中式部署分步指南。

分布式拓扑

在分布式拓扑部署中，Cloud Scheduler 和需要自动扩缩的 Spanner 实例位于同一项目中。自动扩缩器工具的其余组件位于一个集中管理的项目中。此部署是混合部署。拥有 Spanner 实例的团队仅管理其实例的自动扩缩器配置参数，而中心团队负责管理其余的自动扩缩器基础架构。

下图显示分布式项目部署的高度概括的概念视图。

概念性的分布式项目部署。

上图中描述的混合部署具有以下特征：

两个应用（应用 1 和应用 2）使用各自的 Spanner 实例。
Spanner 实例 (A) 位于应用 1 和应用 2 项目中。
独立的 Cloud Scheduler 组件 (C) 将部署到每个项目中：应用 1 和应用 2。
将其余的自动扩缩器组件 (B) 部署到单独的项目中。
自动扩缩器工具使用每个项目中独立 Cloud Scheduler 组件发送的配置，自动扩缩应用 1 和 2 项目中的 Spanner 实例。

转发器函数

Cloud Scheduler 只能向同一项目中的主题发布消息，因此对于分布式拓扑，需要一个名为转发器函数的中间组件。

转发器函数将消息从 Cloud Scheduler 中发布到 Pub/Sub，检查其 JSON 语法，然后将其转发到“轮询器 Pub/Sub”主题。该主题可以属于 Cloud Scheduler 的一个单独项目。

下图显示了用于转发机制的组件：

转发机制。

如上图所示，Spanner 实例位于名为应用 1 和应用 2 的项目中：

Cloud Scheduler 与 Spanner 实例属于同一项目。
(2a) Cloud Scheduler 会将其消息发布到应用 1 和应用 2 项目中的转发器主题。

(2b) 转发器函数从转发器主题中读取消息。

(2c) 转发器函数将消息转发到自动扩缩器项目中的轮询主题。
轮询器函数从轮询主题中读取消息，然后继续执行该过程，如轮询器部分中所述。

分布式部署具有以下优势和缺点。

优点：

应用团队控制配置和时间表：Cloud Scheduler 与进行自动扩缩的 Cloud Spanner 实例一起部署，从而让应用团队可更好地控制配置和调度。
运维团队控制基础架构：自动扩缩器工具的核心组件集中部署，从而让运维团队可控制自动扩缩器基础架构。
集中式维护：扩缩器基础架构是集中式的，降低了开销。

缺点：

配置更复杂：应用团队需要提供服务账号才能向轮询主题进行写入。
可能会面临额外风险：共享基础架构可能会成为单点故障，即使基础架构在设计时考虑了高可用性。

如需了解如何使用分布式拓扑设置自动扩缩器，请参阅分布式部署分步指南。

后续步骤

了解如何将自动扩缩器工具部署到 GKE。
详细了解 Spanner 建议的阈值。
详细了解 Spanner CPU 利用率指标和延迟时间指标。
了解 Spanner 架构设计的最佳实践，以避免热点并将数据加载到 Spanner。
探索有关 Google Cloud 的参考架构、图表和最佳做法。查看我们的 Cloud 架构中心。

将自动扩缩器工具部署到 Cloud Run functions 使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。