通过异步通信从微服务获取用户启动操作的响应

Posted 2023-02-16

【中文标题】通过异步通信从微服务获取用户启动操作的响应

【英文标题】：Getting response for user-initiated action from microservices with asynchronous communication

【发布时间】：2018-04-27 22:09:25

【问题描述】：

我不知道如何用语言来表达，所以这里有一个（相当常见的）例子。

假设用户正在使用我们的博客服务并点击“保存”按钮发布他的精彩博客文章。 现在一个常见的用户故事是，他将被通知他的操作结果 - 一个类似“成功发布！”的通知。或“发生错误。请重试。”。

在同步世界中，这并不难 - 您向服务器发送请求，等待响应，然后根据响应显示通知。

但是让我们假设我们的服务器是面向微服务的架构，利用异步通信；例如，我们使用消息队列。 API 网关微服务从前端接收请求，将其消息发布到队列中。然后一个“消费者”微服务将消费消息的结果发送到前端。 在这种情况下，什么是回馈用户操作结果的好方法？ 例如，如果我们设置一个 websocket 会话来获取此类响应，则启动用户操作的代码和为用户操作提供反馈的代码最终将完全分开，尽管它发生在同一个用户工作流程中。这是一个明智的想法吗？还是我在这里遗漏了一些基本概念？

【参考方案1】：

您描述的过程是一个很好的过程，并带来了一些您可能尚未意识到的“隐藏”好处。我认为这里的重点是与用户交流什么。

我认为在这种情况下，您应该立即回复说，博客文章已发送发布。您不是说它已发布，而是它的发布过程已成功启动。通过这个你对用户说：你的好博客文章是安全的（消息技术将保证这一点），我们正在努力将其公开。放松并等待它在一两秒或一分钟内发布。 这种方法的隐藏好处是，您可以在发布帖子之前应用额外的处理，例如由版主检查？

其他一切都和你描述的一样。这实际上只是您与用户交流的方式。清楚地传达您的系统在此处所做的工作是关键。

【讨论】：

谢谢，有道理！我很好奇你描述的“隐藏的好处”。在您的示例中，它（由版主检查）是否需要放入数据库或显示给版主的东西？如果是这种情况，我不确定它如何比同步过程更好（例如，接受请求，将“状态”列为“待处理”或其他内容的数据库中保存，并在主持人仪表板中显示所有待处理的请求)。

所以，我们这里讲的是两个进程。第一个是发布消息（用户触发），第二个是在发布之前检查帖子（从第一个过程触发）。两者都是独立的，这就是为什么您可以立即完成第一个 - 用户不需要（想要）等待前端响应，直到管理员验证帖子。但也许在某些情况下，这种检查甚至是不必要的，例如如果它不包含任何“警告”字样？也许在这种情况下可以以正确的方式发布？

但是如果我需要从微服务获得一些响应？