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

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

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

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

但让我们想象一下，我们的服务器是在面向微服务的体系结构中，利用异步通信；例如，我们使用消息队列。API网关微服务从前端接收请求，将其消息发布到队列中。然后消费者微服务将消费消息的结果发送到前端。 在这种情况下，返回用户操作结果的好方法是什么？

---

如果我们设置一个websocket会话来获取这样的响应，那么启动用户操作的代码和为用户操作提供反馈的代码最终将完全分离，尽管它发生在同一个用户工作流中。这是一个明智的想法吗？或者我在这里遗漏了一些基本的想法？

您描述的过程是一个很好的过程，并且带来了一些您可能尚未意识到的“隐藏”好处。我认为这里的要点是如何与用户沟通

我认为在这种情况下，你应该立即回复说，博客帖子被发送发布。你不会说，它已经发布了，但发布过程已经成功启动。你这样对用户说：你漂亮的博客文章是安全的，信息技术将确保这一点，我们正在注意将其公开。放松，等待它在一两秒钟或一分钟内发布。 这种方法的潜在好处是，您可以在公开帖子之前进行额外的处理，例如由版主检查

---

其他一切都和你描述的一样。这实际上只是你与用户沟通的方式。关键在于清楚地传达您的系统正在执行的操作。

谢谢，这很有意义！我很好奇你所描述的隐藏的好处。在您的示例中，是否需要将由版主进行的检查放入数据库或向版主显示的内容中？如果是这种情况，我不确定它如何比同步进程更好，例如，以请求为例，将“status”列持久化为“pending”或其他列，并在版主仪表板中显示所有挂起的请求。因此，我们这里讨论的是两个进程。第一个是发布用户触发的消息，第二个是在发布第一个进程触发的消息之前检查该消息。两者都是独立的，这就是为什么您可以立即完成第一个任务-用户不需要等待前端响应，直到管理员验证帖子。但在某些情况下，该检查甚至可能是不必要的，例如，如果它不包含任何警告词？也许在这种情况下，它可以以正确的方式发布？但如果我需要微服务的响应？