NServiceBus适合周期性任务的负载分配
NServiceBus 或等效的 ESB 是否适合具有大量不同类型后台维护类型任务的应用程序？例如：
- 扫描数据库以查找用户生成的内容中出现的某些单词
- 更新存储相对昂贵的查询结果的数据库表
- 创建/维护内容的外部索引
- 发送计划事件的事件通知电子邮件。
我的想法是采用某种任务调度程序（Windows 内置任务调度程序、Quartz.NET 或我自己的基于数据库的解决方案）定期将不同类型的消息发布到总线上。该时间短则一分钟，长则一天。我想使用总线的原因是，当系统变得更大、更繁忙以及任务变得更加频繁或更加资源密集时，我可以扩展订阅者的数量。只要我始终有至少两个订阅者在运行，它也会提供冗余。
明显的替代方案是编写我自己的 Windows 服务，该服务由调度程序触发并执行工作，但我觉得使规模超越单台计算机并提供容错能力可能比使用 ESB 作为管道更困难。
这听起来是一个合理的方法吗？替代建议？
TIA
Would NServiceBus or an equivalent ESB be appropriate for an application that has a bunch of different kinds of background maintenance-type tasks? For example:
- Scanning databases for the occurence of certain words in user-generated content
- Updating database tables that store the results of relatively expensive queries
- Creating/maintaining external indexes for content
- Sending event notification emails for a scheduled event.
My idea is to employ some kind of task scheduler (either the Windows builtin one, Quartz.NET, or my own database-based solution) to publish different kinds messages onto the bus periodically. The period may be as short as one minute or as long as a days. The reason I want to use the bus is so that I can scale out the number of subscribers as the system becomes larger and busier and the tasks become either more frequent or more resource-intensive. It would also provide redundancy as long as I always have at least two subscribers running.
The obvious alternative to this would be to write my own Windows Service that is triggered by the scheduler and performs the work, but I feel like making that scale beyond a single machine and provide fault tolerance might be more difficult than using the ESB as that plumbing.
Does this sound like a reasonable approach? Alternative suggestions?
TIA
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
作为 NServiceBus 的作者，我很可能有偏见，但是学习新技术和编写自己的技术（可能是更简单的版本）之间需要权衡。与内部编写的解决方案相比，我建议考虑您自己的解决方案的长期维护（和文档）成本。
就您所描述的功能集而言，NServiceBus 确实提供了所有这些功能。
As the author of NServiceBus, I'm quite probably biased, but there is a tradeoff between learning a new technology and writing (possibly a simpler version of) your own. I would recommend considering the longer term maintainance (and documentation) costs of your own solution as compared to one written in house.
In terms of the feature-set you described, NServiceBus does provide facilities for all of that.