说我有这样的散点收集设置：
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应用程序的重新调用，在必要时添加/更新图像2）使用消息队列发送图像
我相信选项二是最好的，因为我使用的是微服务体系结构。但是，这意味着在提出请求后可以通过Web应用程序处理图像（如果使用竞争性的消费者）。因此，网页可能会缺少图像？
选项1的问题是散点收集器API与Web应用程序紧密结合。
接近此问题的合适方法是什么？
简短答案：没有正确的方法来执行此操作。
长答案：，因为没有正确的方法可以做到这一点，所以我给您任何答案的危险都将是一种意见。我将帮助您澄清您提出的每个选项的后果。
首先要注意的是：，除非在HTTP请求时已经有一个图像，否则您的HTTP响应将无法包含图像。这意味着在HTTP请求/响应周期结束后，需要更新您的前端。有两种方法：通过AJAX请求进行轮询，或通过插座推动。
投票的优点是将集成到现有的Web应用程序中可能更容易。通过插座将图像推向客户端的优点是，客户不需要通过轮询请求向您的服务器垃圾邮件。
要注意的第二件事：从散点/收集工人报告的图像可以通过HTTP端点或通过消息队列进行。
HTTP端点的优点是，它可能更简单地设置。消息队列的优点是，工人不必等待HTTP响应（如果您将大图像文件写入磁盘，可能需要一段时间）才能继续进行下一个工作。
还有一件事要注意：如果选择使用HTTP端点来创建/更新图像，那么多个散点/收集工人可能会同时尝试执行此操作。您需要处理此操作，以防止多个工人同时尝试写入同一文件。您可以在一个过程写入其中时使用Mutex锁定文件来处理此问题。如果选择使用消息队列，您将有几个选择来处理此操作：您可以使用互斥品，或者可以使用保证执行顺序的FIFO队列，或者您可以限制该工人的数量排队到一个，以防止并发。
我确实有类似系统的经验。我和我的团队选择使用消息队列。考虑到我们的限制，它对我们效果很好。但是，最终，鉴于您的限制，您需要决定哪种对您的效果更好。
编辑
我们在选择http的消息队列时考虑的约束包括：
- 不想将私人端点添加到公共面向的Web应用程序
- 不想举起工人等待HTTP请求/响应
- 不想使同步的同步
可能还有其他原因。那些是我记得我头顶的那些。