基于异步 Web 服务的消息队列答案

【问题标题】：Message Queues over asynchronous web services基于异步 Web 服务的消息队列
【发布时间】：2019-11-04 05:52:35
【问题描述】：

我使用过 Web 服务（带有异步回调的 WCF）。现在我正在学习消息队列。当我们更喜欢消息队列而不是 Web 服务时

例如：如果我实现了一个异步 Web 服务（带有异步回调的 WCF 或异步 REST 服务），我可以请求一些东西，同时我可以继续其他操作。那么什么时候我们可以更喜欢 Message Queue 而不是异步 Web 服务呢？

【问题讨论】：

它们非常不同。 Web 服务主要在内存中工作，因此如果有 1000 个请求要由服务器处理并且服务器崩溃，则所有 1000 个请求都会丢失。使用消息队列，如果服务器崩溃然后恢复正常，消息仍将在队列中。还有许多其他差异，但这是我能想到的。请注意，WCF 将 MSMQ 作为其绑定之一。
好的。我明白。是的，WCF 中有一个名为 netMSMQBinding 的绑定，但我只使用了 basicHTTPbinding。因为像服务器崩溃这样的原因，我们只会更喜欢MQ？能否请您提供一些我们可以使用 MQ 的其他场景。
在进行内部系统通信时，您可以使用消息队列来提供持久的松散耦合组件，如果您提供或使用外部 API，您可以使用 Web API (REST/SOAP) 并使用消息队列来管理加工。 Meybe这可以帮助吗？ docs.particular.net/nservicebus/architecture/principles

【解决方案1】：

在异步 Web 服务或 REST 通信模式上使用消息队列的原因有很多：

将发送者与消费者解耦：发送数据的服务不会直接调用消费者获取数据，这会将服务彼此分离。这样可以更轻松地在未来发展架构。
重放失败的传输：由于发送服务必须直接调用消费服务，因此数据传输失败可能难以处理。即使个别服务出现故障，消息队列也会保留消息，这允许服务在服务备份后开始读取队列中的消息。
异步协议：虽然您可能能够进行异步 HTTP 调用，但消息队列在 protocol level 处是异步的，这使得它们在包含大型正在交换大量的小消息。

在决定在 RESTful 通信模式和消息队列之间使用时，还要注意一些 common misunderstandings。

【讨论】：