.NET ESB 性能
我开始设计我公司的一款电信产品的新版本，为了提供负载平衡和可扩展性，我正在考虑使用某种（.NET 开源）ESB。我希望通过避免使用关系数据库并使用（可能）非事务性队列馈入分布式内存缓存（例如 Velocity 或 memcached）来提高系统的吞吐量。
我从未在实时系统中使用过这样的架构，而且我担心在日常开发的简单性中获得的收益，却会损失吞吐量（对于这个应用程序来说，吞吐量至关重要）。
我只玩过 NServiceBus，所以我不知道它（或其兄弟）是否适合作为实时 no-sql 应用程序的基础。你怎么认为？
我该如何判断这些产品呢？我应该购买商业应用程序，像躲避瘟疫一样避免 ESB，还是使用其他方法？
I'm starting to design a new version of one of my company's telecommunications products, and to provide load balancing and scalability I was considering some kind of (.NET open source) ESB. I'm hoping to boost the throughput of the system by avoiding relational databases and use (perhaps) non-transactional queues feeding into distributed in-memory caches (Velocity or memcached for example).
I've never used an architecture like this for a real-time system, and I'm worried that what I gain in simplicity of day-to-day development, I lose in throughput (which for this app is hyper-critical).
I've only played about with NServiceBus, so I have no idea whether it (or its brethren) is suitable as a foundation for real-time no-sql apps. What do you think?
How should I judge these products? Should I buy a commercial app instead, avoid ESB like the plague, or use some other approach?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Andrew，
当谈到吞吐量时，基于并行消息的架构往往工作得很好。 NServiceBus 特别已扩展到非常高的级别，并且当与非锁定持久存储结合使用时，可以实现巨大的性能。
当你说实时时，显然你不是在谈论硬实时 - 因为你仍然在 Windows 上，甚至不是用 C/C++ 编程。换句话说，听起来主要目标是吞吐量而不是低延迟。我认为您会发现 ESB 非常适合您。
Andrew,
When talking about throughput, parallel message-based architectures tend to work very well. NServiceBus specifically has scaled to very high levels, and when used in conjunction with non-locking persistent stores, can perform tremendously.
When you say real-time, obviously you're not talking about hard real-time here - as you're still on Windows, and even then not programming in C/C++. In other words, it sounds like the main goal is throughput rather than low latency. I think you'll find that ESBs can work out very well for you.