我们有一个SaaS。它由单页应用程序(客户端)、网关、数据服务1、数据服务2和通知服务组成。
客户端与网关对话(使用REST)和服务将请求路由到适当的数据服务(1或2)或进行自己的计算。
来自客户端的一个请求可以在多个at网关服务上拆分。结果是来自子服务的响应的聚合。
通知服务-是一种将有关其他用户使用MQ和WebSocket连接所做更改的信息推送到客户端的服务。通知可以由任何服务发布。
我们与enginers讨论了如何优化流程。
目前,网关只需等待数据服务的响应就需要花费大量时间。
其中一个建议是让网关服务在消息推送到数据服务时立即响应200 Ok,并让客户端等待操作进度抛出通知通道(WebSocket连接)。
这意味着客户端总是发送HTTP操作请求,并确认操作是由WebSocket从不同的端点执行的。
这个模式可以通过提供JS客户端库来隐藏,JS客户端库将隐藏所有这些内部复杂性。
我认为这种方法有问题。我从未见过这样的设计。但除了复杂性和两个失败点(而不是一个),我没有什么有价值的论据反对它。
-
你认为这种设计方法怎么样?
-
你认为它有什么潜在的问题吗?
-
您知道任何公共解决方案吗
这种做法?