C# 使用District Gatherer时的RESTFUL web service v消息队列

假设我有这样一个分散-聚集设置：

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） 使用消息队列发送图像

我相信选项二是最好的，因为我使用的是微服务架构。然而，这意味着在提出请求后（如果使用竞争性消费者），网络应用程序可以处理图像。因此网页上的图像可能会丢失

选项1的问题是分散采集API与web应用程序紧密耦合

---

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

简单的回答是：没有正确的方法

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

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

轮询的优点是，它可能更容易集成到现有的web应用程序中。通过套接字将映像推送到客户机的优点是，客户机不需要向服务器发送轮询请求

需要注意的第二件事：可以通过HTTP端点或消息队列（如您所建议）从分散/聚集工作进程报告映像

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

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

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

编辑

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

• 不希望将私有终结点添加到面向公共的web应用
• 不希望阻止工作进程等待HTTP请求/响应
• 不想使同步成为异步

---

可能还有其他原因。这些都是我记忆最深的问题。

我可以问一下你的限制是什么（见最后一段）。更新了限制的答案。谢谢。在我标出答案之前；使用分散-聚集模式时是否使用轮询或事件？您是否为每个消费者使用控制台应用程序或web API？从技术上讲，我们不做分散/聚集。但是，我们的架构是相似的。我们一次发送数百个单独的工作，让我们的工人同时处理这些工作。每个工人都使用web API来完成他们的工作。然后他们排队报到。谢谢。他们使用事件还是轮询？