因此，我从一年 +/- 前看到了许多参考资料和链接，询问对 Amazon EC2 上的 NServiceBus 的支持。想知道最近是否有人试图对此做任何事情？
我看过以下文章/帖子，但担心信息和相关链接已过时。
在 Amazon EC2 上使用 NServiceBus 的不太积极的体验
正确的想法，对此有何进展？
Azure Love，但没有亚马逊？
我在 NServiceBus 论坛上看到很多关于“下一个版本”的讨论，主要关注对云的支持（当时当前版本是 2.5）。我有一个场景，我想在 Amazon EC2 实例集群上运行带有 MSMQ 或 RabbitMQ 的 NServiceBus，但我担心没有更多关于人们在 Amazon 上实际使用 NServiceBus 的讨论。
有人成功地做到了，或者有理由避免考虑它吗？
[编辑] - 有谁知道使用保留实例是否可以解决上面文章中描述的 EC2 重启问题？
在 EC2 上成功运行 NServiceBus 有多种方法。选择使用哪个选项需要权衡成本、可扩展性和运营开销之间的平衡。
NServiceBus 在带有 MSMQ 的 EC2 上运行良好，但有一些障碍需要注意。主要问题是 EC2 实例上的计算机名称/DNS 名称在每次重启期间都会发生变化。这是一个问题，因为在向端点发送消息以及订阅消息时都会使用计算机名称。克服此开销的一个简单选项是将弹性 IP 附加到实例并使用其 DNS 名称。这样做的好处是很容易做到这一点。缺点是默认情况下您只能获得 5 个弹性 IP。您可以要求更多，而且亚马逊通常会非常慷慨地提供额外的弹性 IP。您的扩展方式也将受到限制。例如，您将无法简单地插入 AWS 的弹性扩展功能。您还必须处理备份。
如果您想使用消息传递，我会选择此选项，但您没有真正疯狂的 SLA，您不需要快速扩展和缩减机器，并且您不需要处理大量消息。大多数项目都是这种情况。
You could write a custom transport for SQS. The benefit of using NSB with SQS remote queues is that you get highly available queues, you don't have to manage them on your EC2 instances & you don't have to worry about backups. It's also easier to leverage elastic scaling with this approach. The downside is that each read costs $$$, so it may not be economically feasible to read at the same speeds as MSMQ or RabbitMQ - although this problem is mitigated by support for long polling and the ability to download many messages in a single call. Another downside is that it doesn't support distributed transactions with DTC. If you're using NServiceBus 5 or later, you could implement the Outbox pattern in your transport as described here, to ensure your messages are still processed only once. Otherwise it's up to you to ensure that your endpoints and handlers have idempotency solutions in place. You can play around with speed vs cost by adjusting the polling intervals of each of your endpoints & perhaps even have a back-off strategy where you decrease your polling intervals if you haven't received messages in a while. You will also have to worry about the size of your messages, as SQS has a small size limitation (256 K). You don't hit this in most messages.
I'd pick this option if read / write speeds aren't an issue, but you don't want to worry about operationally supporting your queuing infrastructure.
I haven't personally played with RabbitMQ on EC2, but a quick search came up with a few articles on how to get it up and running on an EC2 instance. There is a mature RabbitMQ transport available and it supports guaranteed once-only processing of messages as of NServiceBus version 5, as described in the link above. This would be cheaper to operate than SQS & I've heard that it's easier to cluster than MSMQ. Finally, like MSMQ, you would have to come up with a backup strategy (probably using snapshots).
Nobody says that you have to pick one queuing system. You could use SQS for endpoints that need high availability & you don't mind paying the $$$, then use MSMQ / RabbitMQ for the rest of your system.