说我有一个像这样的分散收集设置：
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应用紧密结合。
解决这个问题的合适方法是什么？
答案 0 :(得分：1)
简短的答案：没有正确的方法。
冗长的答案：由于没有正确的方法来执行此操作，因此我给您的任何答案都可能会引起您的意见。与其说那样做，不如说是要澄清您提出的每个选项的后果。
首先要注意的：除非在HTTP请求时已经有可用的图像，否则您的HTTP响应将无法包含图像。这意味着您的前端将需要在HTTP请求/响应周期结束后进行更新。有两种方法可以执行此操作：通过AJAX请求进行轮询，或通过套接字推送。
轮询的优点在于，它可能更容易集成到现有的Web应用程序中。通过套接字将映像推送到客户端的好处是，客户端无需通过轮询请求向服务器发送垃圾邮件。
要注意的第二件事：根据您的建议，可以通过HTTP端点或消息队列从分散/聚集工作人员报告映像。
HTTP端点的优点是它可能更易于设置。消息队列的优点在于，工作人员在继续下一个作业之前不必等待HTTP响应（如果将大型图像文件写入磁盘，则可能需要一段时间）。
要注意的另一件事：：如果您选择使用HTTP端点来创建/更新图像，则可能有多个散布/聚集工作人员试图同时执行此操作。您需要处理此问题，以防止多个工作程序尝试同时写入同一文件。您可以通过一个互斥锁在一个进程写入文件时将其锁定来处理此问题。如果选择使用消息队列，则有几种处理方法：可以使用互斥锁，或者可以使用FIFO队列来保证执行顺序，或者可以限制消息队列上的工作程序数量。排成一列，以防止并发。
我确实有使用类似系统的经验。我和我的团队选择使用消息队列。考虑到我们的限制，它对我们来说运作良好。但是，最终，您需要确定在给定约束的情况下哪种方法更适合您。
编辑
我们在通过HTTP选择消息队列时考虑的约束包括：
可能还有其他原因。我记得这些就是我的头顶。