我正在研究构建一个简单的解决方案，其中生产者服务将事件推送到消息队列，然后让流服务通过gRPC流API提供这些服务。
Cloud Pub / Sub似乎非常适合这项工作，但扩展流服务意味着该服务的每个副本都需要创建自己的订阅并在缩小之前将其删除，这看起来不必要地复杂，而不是平台的用途。
另一方面，Kafka似乎对这样的事情很有效，但我想避免必须管理底层平台本身，而是利用云基础设施。
我还应该提一下，拥有流API的原因是允许流向前端（可能无法访问底层基础架构）
有没有更好的方法可以使用GCP平台做这样的事情而无需部署和管理我自己的基础架构？
如果您基本上想要短暂订阅，那么在创建订阅时，您可以在Subscription对象上设置一些内容：
expiration_policy设置为较小的持续时间。当订户未在该时间段内接收消息时，将删除订阅。需要权衡的是，如果您的订户由于持续时间超过此期限的暂时性问题而关闭，则订阅将被删除。默认情况下，到期时间为31天。您可以将此设置为低至1天。对于拉取订户，订户只需要在启动到期时停止向Cloud Pub / Sub发出请求给定时器。对于推送订阅，计时器根据没有消息成功传递到端点的时间启动。因此，如果没有发布消息或者端点正在为所有推送消息返回错误，则计时器有效。message_retention_duration的价值。这是在订户未接收消息并对其进行处理的情况下保留消息的时间段。默认情况下，这是7天。您可以将其设置为低至10分钟。权衡的是，如果您的订户断开或落后处理消息的时间超过此持续时间，则将删除早于此的消息，并且订户将不会看到它们。干净关闭的订阅者可能只是自己调用DeleteSubscription，以便订阅立即消失，但对于那些意外关闭的订阅者，设置这两个属性将最大限度地缩短订阅继续存在的时间和消息数量（即永远不会交付）将保留。
请记住，Cloud Pub/Sub quotas每个主题和每个项目限制一到10,000个订阅。因此，如果创建了大量订阅并且活动或未清除（手动或在expiration_policy的ttl通过后自动清除），则可能无法创建新订阅。