RESTFUL Web 服务 v 使用 Scatter Gatherer 时的消息队列

Question

假设我有这样的分散收集设置：

1) Web app
2) RabbitMQ
3) Scatter gather API 1
4) Scatter gather API 2
5) Scatter gather API x

假设每个分散集合（以及将来添加的任何新集合）都需要向 Web 应用程序提供图像/更新图像，以便当 Web 应用程序在屏幕上显示结果时，它也会显示图像。最好的方法是什么？

1) 从每个 API 到 Web 应用程序的 RESTFUL 调用在必要时添加/更新图像 2) 使用消息队列发送图片

我认为选项二是最好的，因为我使用的是微服务架构。但是，这意味着图像可以在发出请求后由 Web 应用程序处理（如果使用竞争消费者）。因此网页中可能缺少图片？

选项 1 的问题是分散收集器 API 与 Web 应用程序紧密耦合。

解决这个问题的适当方法是什么？

Answer 1

简短的回答：没有正确的方法可以做到这一点。

长答案：因为没有正确的方法来做到这一点，所以我给你的任何答案都有可能是一种意见。而不是这样做，我将帮助澄清您提出的每个选项的后果。

首先要注意：除非在 HTTP 请求时已经有可用的图像，否则您的 HTTP 响应将无法包含图像。这意味着您的前端需要在 HTTP 请求/响应周期结束后进行更新。有两种方法可以做到这一点：通过 AJAX 请求轮询，或通过套接字推送。

轮询的优势在于它可能更容易集成到现有的网络应用程序中。通过套接字将图像推送到客户端的好处是客户端不需要向您的服务器发送轮询请求。

要注意的第二件事：如您所建议的，可以通过 HTTP 端点或通过消息队列报告来自分散/收集工作人员的图像。

HTTP 端点的优势在于它可能更易于设置。消息队列的优点是工作人员不必等待 HTTP 响应（如果您将大图像文件写入磁盘可能需要一段时间），然后再继续下一个作业。

还有一点需要注意：如果您选择使用 HTTP 端点来创建/更新图像，可能会有多个分散/收集工作人员同时尝试执行此操作.您需要处理此问题以防止多个工作人员尝试同时写入同一个文件。您可以通过在一个进程正在写入文件时使用互斥锁来锁定文件来处理这个问题。如果您选择使用消息队列，您将有几个选项来处理这个问题：您可以使用互斥体，或者您可以使用保证执行顺序的 FIFO 队列，或者您可以限制排成一队，防止并发。

我确实有使用类似系统的经验。我和我的团队选择使用消息队列。考虑到我们的限制，它对我们很有效。但是，最终，您需要根据您的限制来决定哪个更适合您。

编辑

我们在通过 HTTP 选择消息队列时考虑的约束包括：

• 不想将专用端点添加到面向公众的 Web 应用程序
• 不想让工作人员等待 HTTP 请求/响应
• 不想让异步的同步

可能还有其他原因。这些是我记得的。