一个 API 的两个通道

Question

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

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

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

可以通过提供隐藏所有这些内部复杂性的 JS 客户端库来隐藏此架构。

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

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

Answer 1

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

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