两个频道合一 API

Question

我们有 SaaS。它由单页应用程序（客户端）、网关、数据服务1、数据服务2和通知服务组成。 客户端与网关（使用 REST）对话，服务将请求路由到适当的数据服务（1 或 2）或进行自己的计算。 来自客户端的一个请求可以在网关服务上拆分为多个。结果是来自子服务的响应的聚合。 Notification Service - 是一种将其他用户使用 MQ 和 WebSocket 连接所做的更改的信息推送到客户端的服务。任何服务都可以发布通知。

我们与工程师讨论了如何优化流程。 目前，网关花费大量时间等待数据服务响应的问题。 其中一项提议是让网关服务在消息推送到数据服务后立即响应 200 Ok，并让客户端等待操作进度抛出通知通道（WebSocket 连接）。

这意味着客户端始终发送 HTTP 操作请求，并从不同的端点确认操作是由 WebSocket 执行的。

可以通过提供 JS 客户端库来隐藏此模式，这将隐藏所有这些内部复杂性。

我认为这种方法有问题。我从未见过这样的设计。但我没有反对它的有价值的论据，除了复杂性和两点故障（而不是一个）。

1. 您如何看待这种设计方法？
2. 您认为它有任何潜在问题吗？
3. 你知道 public 解决方案吗 这样的做法？

Answer 1

由于您的服务速度很慢，因此将其更像是批处理作业可能更有意义。

1. 客户端向网关发送作业请求。
2. 网关 returns 从客户端接受后立即的作业 ID。
3. 客户端定期轮询网关以获取该作业 ID 的结果。