Google Pub / Sub可以用于聊天消息吗?

时间:2018-12-09 05:20:12

标签: google-cloud-platform google-cloud-pubsub

我正在开发一个可以在用户之间聊天的应用程序。为此使用Pub / Sub是否有意义?我在文档中找不到可能的用例。有什么很好的理由说明它不合适吗?

3 个答案:

答案 0 :(得分:3)

Google Cloud Pub / Sub不太适合与聊天产品中的最终用户设备进行通信。 Cloud Pub / Sub专为种子设计:相对少量的需要高吞吐量的长寿命流。在聊天应用程序中,您需要细流:大量的临时流,它们的吞吐量很低。

Cloud Pub / Sub quotas仅允许10,000个主题项目,每个主题或每个项目10,000个订阅。设置新的流媒体管道时,通常会在开始时创建一次主题及其订阅,然后从该点开始发布和订阅。因此,通常与Dataflow和/或BigQuery结合使用,Cloud Pub / Sub更适合服务器到服务器的通信或大规模流事件摄取。

Cloud Pub / Sub的权限模型也不是聊天应用程序的理想选择。允许写入或读取主题或订阅的权限要求对用户进行身份验证。使用项目中的权限对每个用户进行身份验证实际上是不可行的,因此您可以选择为所有用户使用通用凭据,这可能是不安全的。

这并不是说Cloud Pub / Sub不能成为聊天服务的一部分,只是不能用于向特定用户传递消息。实际上,对于发送到环聊聊天机器人的消息,Cloud Pub / Sub可以为used as the transport mechanism。不过,在这种情况下,对用户的响应将直接转到环聊聊天API,而不是通过发布/订阅返回。因此,如果您正在实施聊天服务,则可能使您的用户将消息发送到您设计的前端服务器,然后将这些消息发布到Cloud Pub / Sub。您构建的另一台服务器可以是这些消息的订阅者,然后将适当的消息传递给适当的单个用户。在这种情况下,Cloud Pub / Sub用于接收来自前端服务器的所有消息(激流),而将消息传递给单个用户则属于某种其他机制(tri俩)。 Google Cloud中为此单个设备交付而设计的产品是Firebase Cloud Messaging

答案 1 :(得分:1)

  

可以将Google Pub / Sub用于聊天消息吗?

是的。我不会使用发布/订阅进行人对人chat消息传递。 Pub / Sub设计用于使系统解耦以支持分布式系统。

为什么不使用发布/订阅:

  • 权限。您将需要创建服务帐户凭据并将此Json文件分发给每个订阅者。这是不安全的。
  • 每个聊天人员都需要订阅发布/订阅主题,然后poll订阅。这意味着每个聊天人员一个订阅。这既不是一个好的设计,也不是inexpensive

chat有更好的解决方案。

答案 2 :(得分:0)

提供聊天的Sub / Sub?否。正如上面正确提到的那样,Pub / sub有2个主要用例,用于数据提取和系统解耦。

如果仍然有兴趣制作聊天应用,我建议您搜索一些有关Web套接字的信息。