一个API的两个渠道

Question

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

通过引擎，我们讨论了如何优化流程。 目前，Gateway花费大量时间等待来自Data Services的响应的问题。 其中一个建议是，一旦消息被推送到数据服务，让网关服务响应200 Ok，让客户端等待操作进程抛出通知通道（WebSocket连接）。

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

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

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

1. 您对此设计方法有何看法？
2. 你看到它有任何潜在的问题吗？
3. 你知道任何公共解决方案吗？ 这样的方法？

Answer 1

由于您的服务很慢，因此将其视为批处理作业更有意义。

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