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

Question

我们正在启动一个新项目,它具有一些非常基本的消息传递和排队要求,但是在将来可能会有一些额外的要求,例如sagas可以处理可能无序到达并需要重新排序的消息.

我们刚刚发布了一个完全托管在Amazon EC2上的项目,该项目中还有一个简单的消息传递系统.我们有一个非常简单的小型pub/sub机制,我们收到一条消息,然后根据其类型确定用于消息的处理程序.在我们的新项目中,我们也有类似的机制,并且可能有一些稍微复杂的要求,但即使我们可以取消使用我们自己的代码来解决消息处理程序,这也很酷.

我们真的很想使用NServiceBus,因为pub/sub模型非常好,但到目前为止我们一直在使用Amazon SQS作为队列提供者.我们的每台EC2机器都有一个工作人员正在侦听相同的SQS队列并从中拉出消息来处理它们.显然,在NServiceBus中,不支持SQS作为传输层(我知道这是因为NServiceBus是围绕可靠且低延迟的队列构建的).

我知道NServiceBus有一个分销商,我可以想象在它自己的EC2实例上托管它,但问题是那里有一个巨大的单点故障,所以如果这个故障发生,我们基本上就搞砸了.根据我的收集,人们设置Windows故障转移群集来处理内部网络的这个问题,但我不知道这是否适用于EC2.

这是我在实际上尝试在基于云的环境中使用NServiceBus的人可以找到的唯一博客文章之一,他似乎并不推荐它.我只是想知道这里有没有其他人尝试过,如果有的话,他们会提供什么建议吗？似乎很遗憾,我们无法仅仅因为我们托管在云上而使用这样一个伟大的框架.

看起来Azure Queues正在取得一些进展,这是我们可能会看到的,但是现在我们希望将基础设施保留在亚马逊,因为我们有很多可以重复使用的构建自动化,这是基于.

Answer 1

根据Amazon EC2排队的经验,我们发现SQS对于高性能消息传递非常缓慢.

我们目前没有使用NServiceBus作为排队接口,但我想我已经提到我们在EC2中的Ubuntu实例上成功使用RabbitMQ作为我们的队列提供者.

根据这篇文章,Udi Dahan建议人们已经用NServiceBus换掉了用于RabbitMQ的MSMQ,因此在EC2上使用RabbitMQ可能是值得的调查.

RabbitMQ的网站上有一个很好的指南,描述了通过启动兼容的Ubuntu映像在Amazon EC2上安装RabbitMQ的简单方法.

我强烈建议安装RabbitMQ 管理插件,它会在队列中为您提供简单的Web管理界面.