我们正在启动一个新项目，它具有一些非常基本的消息传递和排队要求，但是将来可能会有一些额外的要求，例如sagas来处理可能无序到达的消息，并且需要重新排序。
我们刚刚发布了一个完全托管在Amazon EC2上的项目，该项目中还包含一个简单的消息传递系统。我们有一个非常简单的小型pub / sub机制，我们收到一条消息，然后根据其类型确定用于消息的处理程序。在我们的新项目中，我们也有类似的机制，可能会有一些稍微复杂的要求，但即使我们可以取消拥有自己的代码来解决消息处理程序，这也很酷。
我们真的很想使用NServiceBus，因为pub / sub模型非常好，但到目前为止我们一直使用Amazon SQS作为队列提供程序。我们的每台EC2机器都有一个工作人员正在侦听相同的SQS队列并从中拉出消息来处理它们。显然，在NServiceBus中，不支持SQS作为传输层（我知道这是因为NServiceBus是围绕可靠且低延迟的队列构建的）。
我知道NServiceBus有一个分销商，我可以想象在自己的EC2实例上托管它，但问题是那里有一个巨大的单点故障，所以如果这个问题发生了变化我们基本上就搞砸了。根据我的收集，人们设置Windows故障转移群集来处理内部网络的这个问题，但我不知道这是否适用于EC2。
This是我在实际上尝试在基于云的环境中使用NServiceBus的人可以找到的唯一博客文章之一，他似乎并不推荐它。我只是想知道这里有没有其他人尝试过，如果有的话，他们会提供什么建议吗？似乎很遗憾，我们无法仅仅因为我们托管在云上而使用这样一个伟大的框架。
看起来有一些progress是由Azure Queues制作的，这是我们可能会看到的，但是现在我们希望将基础设施保留在亚马逊，因为我们有很多构建自动化，我们可以重复使用那是基于那个。
答案 0 :(得分：5)
根据Amazon EC2排队的经验，我们发现SQS对于高性能消息传递非常缓慢。
我们目前没有使用NServiceBus作为排队接口，但我想我已经提到我们在EC2中的Ubuntu实例上成功使用RabbitMQ作为我们的队列提供程序。
根据this post Udi Dahan suggests，人们已经用NServiceBus换掉了用于RabbitMQ的MSMQ，因此在EC2上使用RabbitMQ可能是值得的调查。
有一个great guide on RabbitMQ's website描述了通过启动兼容的Ubuntu映像在Amazon EC2上安装RabbitMQ的简单方法。
我强烈建议安装RabbitMQ Management Plugin，它会在队列中为您提供简单的Web管理界面。