如果您使用 Pub/Sub 指标作为自动扩缩流水线的信号，请参考以下建议。
使用多个信号来自动扩缩流水线
请勿仅使用 Pub/Sub 指标来自动扩缩流水线。这可能会导致自动扩缩决策出现单点故障。请改用信号组合来触发自动扩缩。其他信号的一个示例是客户端的 CPU 利用率。此信号可以指示客户端任务是否正在处理工作，以及扩容是否可以使客户端任务处理更多工作。 以下是一些可用于流水线的其他 Cloud 产品的信号示例：
Compute Engine 支持根据 CPU 利用率和 Monitoring 指标等信号进行自动扩缩。 Compute Engine 还支持多个指标和多个信号，以提高可靠性。
如需详细了解如何使用 Monitoring 指标进行伸缩，请参阅 根据 Monitoring 指标进行伸缩。 如需详细了解如何使用 CPU 利用率进行伸缩，请参阅根据 CPU 利用率进行伸缩。
Google Kubernetes Engine Pod 横向自动扩缩 (HPA) 支持根据资源使用情况（例如 CPU 和内存用量）、自定义 Kubernetes 指标和外部指标（例如 Pub/Sub 的 Monitoring 指标）进行自动扩缩。它还支持多个信号。
如需了解详情，请参阅 Pod 横向自动扩缩。
使用指标的区域版本，而不是全局版本
Pub/Sub 提供通常用于自动扩缩的每个指标的两个版本。请确保使用带有 by_region 后缀的版本：
如果您希望自动扩缩能够应对单区域中断，请勿使用这些指标的全局版本。这些指标的全局版本需要计算已知有消息的所有区域的积压消息，这意味着单个区域的不可用会导致数据缺口。相比之下，指标的 by_region 版本会按区域计算和报告积压消息。如果无法计算单个区域的积压消息，该指标仍会报告其他区域的值。
避免使用订阅者端吞吐量指标来自动扩缩订阅者
避免使用订阅者端吞吐量指标（例如 subscription/ack_message_count）来自动扩缩订阅者客户端。请考虑改用直接反映待处理消息积压情况的指标，例如前面提到的 subscription/num_unacked_messages 或 subscription/oldest_unacked_message_age。
使用订阅者端吞吐量指标进行自动扩缩时遇到的问题
使用这些指标可能会导致问题，因为它们表示 Pub/Sub 与订阅者之间的流量。根据此类指标进行伸缩可能会创建一个自引用循环，其中传送或确认的消息减少会导致客户端缩减。例如，如果流量暂时下降或某个订阅者出现问题，则可能会发生这种情况。
如果客户端缩减到零或接近零，则所有正在进行的订阅流量都可能会停止，并且订阅者可能无法处理消息，即使有新消息到达也是如此。这可能会导致严重的提取延迟，并导致订阅者客户端处于无法恢复的状态。
在出现指标缺口时进行处理
请勿假设缺少指标意味着没有要处理的消息。例如，如果为了应对缺少指标的情况，您将处理任务缩容为零，则积压消息中已有的消息或在此期间发布的消息可能不会被使用。这会增加端到端延迟时间。 为了最大限度地缩短延迟时间，请将最小任务数设置为大于零的值，以便您始终准备好处理发布的消息，即使最新的 Pub/Sub 指标表明队列为空也是如此。
Compute Engine 自动扩缩器和 Google Kubernetes Engine HPA 旨在在指标不可用时保持当前的副本数。如果没有任何指标可用，这可以提供安全保障。
您还可以实现 Pub/Sub 流控制机制 ，以帮助防止任务因缺少指标而被意外 缩减时不堪重负。