因此，我从一年前开始就已经看到了许多引用和链接，询问对NServiceBus on Amazon EC2的支持。想知道最近是否有人尝试对此做任何事情？
我看过以下文章/帖子，但担心信息和相关链接已过时。
A Less Than Positive Experience w/NServiceBus on Amazon EC2
The right idea, any movement on this?
Azure Love, but no Amazon?
我在NServiceBus论坛上看到很多关于“下一个版本”的讨论，这些讨论着重于对云的支持(当前版本为2.5)。我有一种情况，我想在Amazon EC2实例的群集上运行带有MSMQ或RabbitMQ的NServiceBus，但令我感到关注的是，围绕在Amazon上实际使用NServiceBus的人们没有更多的讨论。
任何人成功完成此操作还是有理由避免考虑？
[编辑]-是否有人知道使用保留实例是否可以解决上述文章中所述的EC2重新启动问题？
最佳答案
有多种方法可以在EC2上成功运行NServiceBus。选择哪个选项需要权衡成本，可伸缩性和运营开销之间的平衡。
MSMQ
NServiceBus在带有MSMQ的EC2上运行良好，但是有一些障碍需要注意。主要问题是EC2实例上的计算机名称/DNS名称在每次重新启动期间都会更改。这是一个问题，因为在将消息发送到终结点以及订阅消息时也会使用计算机名。克服此开销的一个简单选择是将弹性IP附加到实例并使用其DNS名称。好处是这样做很容易。不利的一面是，默认情况下仅给您5个Elastic IP。您可以要求更多，亚马逊通常会派发额外的弹性IP，相当自由。您的扩展方式也将受到限制。例如，您将无法简单地插入AWS的弹性伸缩功能。您还必须处理备份。我会将队列放在单独的EBS卷上，并按一定间隔拍摄快照。
如果您想使用消息传递，则选择此选项，但是您并没有真正疯狂的SLA，您不需要快速按比例缩放计算机，也不需要处理大量消息。大多数项目就是这种情况。
亚马逊SQS
您可以为SQS编写自定义传输。将NSB与SQS远程队列一起使用的好处是，您可以获得高可用性的队列，无需在EC2实例上进行管理，也不必担心备份。通过这种方法利用弹性缩放也更容易。缺点是每次读取都需要花费$$$，因此以与MSMQ或RabbitMQ相同的速度进行读取可能在经济上不可行-尽管通过支持长轮询和一次调用即可下载许多消息的能力可以缓解此问题。 。另一个缺点是，它不支持使用DTC进行分布式事务。如果您使用的是NServiceBus 5或更高版本，则可以按照here所述在传输中实现发件箱模式，以确保您的消息仅被处理一次。否则，您需要确保您的端点和处理程序具有适当的幂等性解决方案。您可以通过调整每个端点的轮询间隔来解决速度与成本之间的关系，甚至可以采用退避策略，如果一段时间没有收到邮件，可以减少轮询间隔。您还必须担心消息的大小，因为SQS的大小限制很小(256 K)。您不会在大多数邮件中都点击此按钮。
如果读/写速度不是问题，我会选择此选项，但是您不必担心在操作上支持您的排队基础结构。
兔子MQ
我还没有亲自在EC2上玩RabbitMQ，但是快速搜索了一些文章，介绍了如何在EC2实例上启动和运行它。有一个成熟的RabbitMQ传输可用，它支持从NServiceBus版本5开始保证的消息仅一次处理，如上面的链接中所述。这将比SQS便宜，而且我听说它比MSMQ更容易集群。最后，像MSMQ一样，您必须提出一种备份策略(可能使用快照)。
混合的
没有人说您必须选择一种排队系统。您可以将SQS用于需要高可用性的端点，并且您不介意支付$$$$的费用，然后将MSMQ/RabbitMQ用于系统的其余部分。
关于amazon-ec2 - 在Amazon EC2上运行NServiceBus，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10593739/