Google Pub-Sub双向通信架构

Question

我正在尝试了解如何使用以下架构google 发布-订阅进行双向通信

编辑：我的意思是订阅者而不是消费者

我正在尝试支持以下工作流程：

1. UI 向 api 服务发送请求以处理异步进程
2. API 服务向主题发布请求以开始流程启动
3. 消费者获取消息并处理异步流程服务。
4. 异步流程服务完成后，它会发布到流程完成主题。
5. 这里是我希望 UI 获取流程完成消息的地方，我正在尝试找出最佳方法。

所以两个问题：

1. 当想要与客户端进行双向通信时，多主题是首选方法吗？或者有没有办法通过多个订阅的单个主题来做到这一点？
2. Process-Complete 的消费者应该如何获得对 UI 的响应？ UI 应该是订阅的消费者吗？或者我应该将它发送回 api 服务并发布一个 websocket 消息？这两种方法似乎都各有优缺点。

Answer 1

在这种情况下，将首选多个主题，一个用于发送到异步处理器的消息，另一个用于返回的响应。否则，您的异步处理器将不必要地接收响应消息并必须立即确认它们，这是不必要的额外消息传递。

关于将响应返回给 UI，UI 不应是订阅的消费者。为此，您需要 UI 的每个 运行 实例都有自己的订阅，否则它们会在它们之间负载平衡消息，您无法保证特定的客户端发送请求实际上会收到响应。如果您有多个 API 服务器需要根据通过它们传输的请求接收特定响应，情况也是如此。 Cloud Pub/Sub 并不是真正为以这种方式短暂的主题和订阅而设计的；最好只创建一次，然后所有数据都通过它们传输。

此外，让 UI 充当订阅者意味着您必须拥有 UI 中的凭据才能订阅，这可能是一个安全问题。

您也可以考虑不使用主题进行异步响应。相反，您可以将期望响应的客户端或 API 服务器的地址或套接字编码为消息的一部分。然后，异步处理器可以接收消息，处理它，向消息中指定的地址发送响应，然后确认它收到的消息。这将确保响应被路由到他们需要去的地方，并最大限度地减少订阅者只是确认他们不需要处理的消息的传递，例如，用于不同 API 服务器的消息。