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