如果您使用 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 流控制机制，以防任务因缺少指标而意外缩减规模，导致任务过载。