NServiceBus会是我们的应用程序的正确选择吗？

Question

我目前正在开发一个遗留的应用程序，它可以在机器之间进行大量的同步通信。通信主要是通过Http post完成的，我想知道使用NServiceBus使通信异步是否会对我们有好处。

通过CQRS，我已经知道了NServiceBus，但还没有详细了解它。

与编写该应用程序的同事交谈时，他们认为如果无法进行呼叫，则整个事务都会失败，我们应该坚持这种模式。大多数通信涉及多个用户在服务器上配置硬件，也许在这种情况下，我们不需要某种排队/异步框架。

那么，我将从异步中获得什么好处，NServiceBus是正确的框架吗？如果在我们的情况下，我如何让他们相信asnyc消息传递体系结构是可行的？或者我引入了一个不必要的框架？

Answer 1

好吧，那句古老的格言“如果它没坏”..在这里发挥作用。

严肃地说，如果没有理由“修复”某些东西(例如，可用性/数据丢失问题)，那么就很难建立一个理由来改变它。

稍微回答一下您的问题，根据我的经验，NServiceBus的主要好处之一是拥有成本较低。它很容易上手、学习和部署，并且一旦投入生产，管理开销就很小。

更新

RE:关于向用户显示呼叫结果的评论：

这取决于你想怎么玩。

在这种情况下，在CQRS模式中向用户显示成功消息是很常见的，因为在用户检查调用结果时，结果不太可能是他们期望的结果。

但是，如果呼叫做了一些可能导致延迟的严重处理，或者如果呼叫有“自然”的高失败机会，那么您可以选择向用户显示一条“谢谢您的请求”消息，然后通过一些离线方式(例如带有响应链接的电子邮件)提醒他们呼叫结果。

当您进入异步状态时，您必须开始以不同的方式考虑服务级别协议-例如，指定99%的请求将在1秒内得到处理，然后您可以围绕该要求规划设计和基础架构。