2010-08-19 34 views
0

我开始设计我公司的一个电信产品的新版本,并提供负载平衡和可伸缩性我正在考虑某种(.NET开源)ESB。我希望通过避免关系数据库和使用(可能)非馈送到分布式内存缓存(例如Velocity或memcached)的非事务性队列来提高系统的吞吐量。.NET ESB性能

我从来没有在实时系统中使用过这样的体系结构,我担心我在日常开发的简单性中获得了什么,我在吞吐量方面失败了(对于此应用程序而言,它是超-危急)。

我只玩过NServiceBus,所以我不知道它(或它的兄弟)是否适合作为实时无sql应用程序的基础。你怎么看?

我应该如何判断这些产品?我应该购买一个商业应用程序,避免像瘟疫一样的ESB,或使用其他方法?

回答

2

Andrew,

当谈到吞吐量时,基于并行消息的体系结构往往工作得很好。 NServiceBus专门扩展到非常高的水平,并且与非锁定持久性存储一起使用时,可以发挥巨大作用。当你说实时时,显然你并没有在这里讨论硬实时 - 因为你仍然在Windows上,甚至不用C/C++编程。换句话说,听起来主要目标是吞吐量而不是低延迟。我想你会发现ESB可以为你解决问题。

+0

嗨Udi,真的,从系统的各个层面都要求100%可预测的时间不是实时的,但进入的消息必须从拨号器硬件传送到用户机器的固定数量毫秒,否则它们毫无价值(实时性较弱的定义)。从这个意义上讲,我们既需要尽可能减少单个消息延迟,又要允许系统处理许多同时发送的消息。我们还需要将许多其他非实时系统挂起该消息流。 – 2010-08-19 23:36:20

+0

还有Rhino.Esb - 我不知道这次展会是否与NServiceBus相比? – iwayneo 2010-09-24 09:07:32

+0

Rhino.Esb的设计很大程度上取决于NServiceBus的设计 - 所以我会假设性能和吞吐量应该具有可比性。 – 2010-10-06 21:26:04