代码之家  ›  专栏  ›  技术社区  ›  Denis Liger

一个API两个通道

  •  0
  • Denis Liger  · 技术社区  · 6 年前

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

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

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

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

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

    1. 你认为这种设计方法怎么样?
    2. 你认为它有什么潜在的问题吗?
    3. 您知道任何公共解决方案吗 这种做法?
    1 回复  |  直到 6 年前
        1
  •  3
  •   Guanxi Master Mind    6 年前

    由于您的服务速度很慢,因此将其视为批处理作业可能是有道理的。

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