xin*_*nix 9 esb nservicebus amazon-ec2
所以我已经看到了一年前+/- 前面询问有关在Amazon EC2上支持NServiceBus的一些参考和链接.想知道最近有没有人试图对此做任何事情？
我看过以下文章/帖子,但担心信息和相关链接已过时.
亚马逊EC2上带有NServiceBus的不太积极的体验
正确的想法,对此有何看法？
Azure Love,但没有亚马逊？
我在NServiceBus论坛上看到很多关于"下一版本"的讨论,主要关注对云的支持(当前版本为2.5).我有一个场景,我想在Amazon EC2实例的集群上运行带有MSMQ或RabbitMQ的NServiceBus,但我担心没有更多关于在Amazon上实际使用NServiceBus的人的讨论.
任何人成功做到或有理由避免考虑它？
[编辑] - 是否有人知道使用保留实例是否解决了上述文章中描述的EC2重启的问题？
Jon*_*eus 17
有不同的方法可以在EC2上成功运行NServiceBus.选择哪个选项需要权衡成本,可扩展性和运营开销之间的平衡.
NServiceBus在EC2上使用MSMQ运行良好,但有一些障碍需要注意.主要问题是EC2实例上的计算机名称/ DNS名称在每次重新启动时都会更改.这是一个问题,因为在订阅消息时也会在向端点发送消息时使用计算机名称.克服此开销的一个简单选择是将弹性IP附加到实例并使用其DNS名称.好处是它很容易做到这一点.缺点是默认情况下您只获得5个弹性IP.你可以要求更多,亚马逊通常非常自由地发放额外的弹性IP.您的比例也会受到限制.例如,您将无法简单地插入AWS的弹性扩展功能.您还必须处理备份.我会将队列放在一个单独的EBS卷上并按间隔拍摄快照.
如果您想使用消息传递,我会选择此选项,但您没有真正疯狂的SLA,您不需要快速扩展和缩小计算机,并且您不需要处理高消息量.大多数项目都是这种情况.
您可以为SQS编写自定义传输.将NSB与SQS远程队列一起使用的好处是,您可以获得高可用性队列,您无需在EC2实例上管理它们,也不必担心备份.使用这种方法也可以更轻松地利用弹性缩放.缺点是每次读取成本为$$$,因此以与MSMQ或RabbitMQ相同的速度读取可能在经济上不可行 - 尽管通过支持长轮询和在单个呼叫中下载多个消息的能力可以缓解此问题.另一个缺点是它不支持DTC的分布式事务.如果您使用的是NServiceBus 5或更高版本,则可以按照此处所述在传输中实施发件箱模式,以确保您的邮件仅处理一次.否则,您需要确保您的终端和处理程序具有幂等解决方案.您可以通过调整每个端点的轮询间隔来解决速度与成本问题,甚至可以采用退避策略,如果您在一段时间内没有收到消息,则可以减少轮询间隔.您还必须担心消息的大小,因为SQS具有较小的大小限制(256 K).你在大多数消息中都没有这样做.
如果读/写速度不是问题,我会选择此选项,但您不必担心在操作上支持您的排队基础架构.
我没有亲自在EC2上玩RabbitMQ,但是快速搜索了一些关于如何在EC2实例上启动和运行的文章.有一个成熟的RabbitMQ传输可用,它支持NServiceBus版本5的保证一次性消息处理,如上面的链接所述.这比SQS更便宜,我听说它比MSMQ更容易集群.最后,像MSMQ一样,您必须提出备份策略(可能使用快照).
没有人说你必须选择一个排队系统.您可以将SQS用于需要高可用性的端点,并且不介意支付$$$,然后将MSMQ/RabbitMQ用于系统的其余部分.