在 Amazon EC2 托管应用程序中使用 NServiceBus

Question

我们正在启动一个新项目，该项目有一些非常基本的消息传递和队列要求，但未来可能会有一些额外的要求，例如 sagas 来处理可能乱序到达的消息，并且需要重新排序。

我们最近刚刚发布了一个完全托管在 Amazon EC2 上的项目，其中还包含一个简单的消息传递系统。我们有一个非常简单的小 pub/sub 机制，通过它我们接收消息，然后根据消息的类型确定要使用哪个处理程序。在我们的新项目中，我们也有类似的机制，并且可能有一些更复杂的要求，但即使我们可以取消使用自己的代码来解析消息处理程序，这也很酷。

我们非常热衷于使用 NServiceBus，因为 pub/sub 模型非常好，但到目前为止，我们一直使用 Amazon SQS 作为队列提供程序。我们的每台 EC2 机器都有一个工作人员，它正在侦听同一个 SQS 队列并从中提取消息来处理它们。显然，在 NServiceBus 中不支持将 SQS 作为传输层（我知道这是因为 NServiceBus 是围绕可靠且低延迟的队列构建的）。

我知道 NServiceBus 有一个分发服务器，我可以想象将它托管在它自己的 EC2 实例上，但问题是那里存在巨大的单点故障，所以如果出现故障，我们基本上就完蛋了.据我所知，人们设置 windows 故障转移集群来处理内部网络的这个问题，但我不知道这是否适用于 EC2。

This 是我能找到的仅有的一篇博文之一，有人实际上曾尝试在基于云的环境中使用 NServiceBus，但他似乎并不推荐它。我只是想知道这里是否有其他人尝试过，如果有，他们有什么建议可以提供吗？仅仅因为我们托管在云上，我们就无法使用如此出色的框架，这似乎是一种耻辱。

看起来有一些 progress 正在使用 Azure 队列，这是我们可能会考虑的，但现在我们希望将基础架构保留在 Amazon 上，因为我们有很多构建自动化，我们可以重新-使用基于此的。

Answer 1

根据在 Amazon EC2 中排队的经验，我们发现 SQS 在高性能消息传递方面非常缓慢。

我们目前没有使用 NServiceBus 作为队列接口，只是想提一下，我们在 EC2 中的 Ubuntu 实例上成功地使用了 RabbitMQ 作为我们的队列提供程序。

根据this post Udi Dahan suggests，人们已经用 NServiceBus 将 MSMQ 换成了 RabbitMQ，因此在 EC2 上使用 RabbitMQ 可能是一项值得调查的事情。

great guide on RabbitMQ's website 描述了一种通过启动兼容的 Ubuntu 映像在 Amazon EC2 上安装 RabbitMQ 的简单方法。

我强烈建议您也安装 RabbitMQ Management Plugin，它可以在队列中为您提供一个简单的 Web 管理界面。