如果所有消息都在本地发送，那么使用服务总线是否太过分了？
我有一个邮件阅读服务，可以从收件箱中读取每封电子邮件，对其进行解析并将其插入数据库中。我遇到的问题是，不能保证我会按照收到的顺序解析电子邮件（这是业务要求）。我对此的解决方法是引入某种排队系统。通过这种方式，我可以按照项目进入的顺序对其进行处理。这也将给我带来好处，将我对电子邮件的阅读和解析/插入它们到数据库中解耦。
所以我的问题是，如果我只打算在本地发送消息，那么使用服务总线（例如 NServiceBus）是否太过分了？这意味着读取电子邮件的服务和在数据库中解析/插入电子邮件的服务将驻留在同一台计算机上。
谢谢。
I have a mail reading service that reads every email from an inbox, parses it and inserts it into a database. The issue I'm running into is that there is no guarantee that I will be parsing the emails in order they were received (this is a business requirement). My fix for this would be to introduce some sort of queueing system. This way I would process the items in order they came in. This would also give me the benefit of decoupling my reading of the emails and parsing/inserting them in the database.
So my question is is it overkill to use a service bus (such as NServiceBus) if I only plan on sending messages locally? Meaning that the service that would be reading emails and the service that parses/inserts emails in the database would reside on the same machine.
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
是的，这显然是多余的，特别是因为 NServiceBus 不保证消息按顺序传递。
您可以只使用
Queue，假设您知道如何按顺序取出消息（这似乎是您遇到麻烦的地方，而不是您是否正在使用队列或者其他什么；你必须知道如何以正确的顺序将项目放入队列）。KISS 和 YAGNI 每天都在这里工作。
Yes, this is clearly overkill, especially since NServiceBus doesn't guarantee that messages are delivered in order.
You can just use a
Queue<T>, assuming you know how to get the messages out in order (this appears to be where you are having trouble, not that you are or aren't using a queue or whatever; you have to know how to get the items into the queue in the right order to begin with).KISS and YAGNI apply here, all day, every day.
我只想用 MSMQ 来解决您的持久性问题。一旦它进入，无论机器断电或其他应用程序崩溃，它都保证在那里。
I would just us an MSMQ for your persistence issues. Once it's in, it's guaranteed to be there, regardless of the machine losing power, or some other application crashing.
我不喜欢这个词。我认为：使您的系统尽可能灵活，而不影响应用程序可接受的性能限制（只有您可能知道）。
一般来说：为你能想到的最糟糕的营销决策做好准备。
The would word I dont't like. In my opinion: make your system as much flexible as it possible, without affecting limits of acceptable performance of your application (that only you may know).
In general: be prepared to worst marketing decision you can think of.
这取决于。对于您的应用程序，我同意 Jason 的观点，服务总线不会比本地数据结构更能帮助您按顺序处理消息。而且，正如 Jason 所说，考虑到服务总线中消息的顺序无法得到保证，这很可能会变得更加困难。
但是，使用服务总线在本地发送消息可能非常有用。它使得异步向其他进程发送消息变得非常容易。由于消息的使用者位于不同的进程中，因此您实际上没有任何线程问题。消息可以是持久的，因此您不必担心会丢失某些内容，并且只需添加新订阅者即可轻松为消息添加额外的处理。作为额外的好处，如果系统变得太大而无法在一台机器上舒适地运行，则分配总线将是微不足道的。
对于您的解决方案来说，这是不必要的，甚至可能会导致问题。但在某些情况下，在本地使用服务总线是有意义的。
It depends. For your application, I agree with Jason, a service bus will not help you process messages in order any more than a local data structure will. And, as Jason said, it will most likely be more difficult considering the order of messages in a service bus is not guaranteed.
However, sending messages locally with a service bus can be very useful. It makes it very easy to send messages to other processes asynchronously. Since the consumer of the message is in a different process, you don't really have any threading concerns. Messages can be durable so you don't have to worry about something being missed, and it's very easy to add additional processing for a message after-the-fact by just adding a new subscriber. As an extra bonus, if the system ever becomes too big to run comfortable on one machine, it would be trivial to distribute the bus.
For your solution, it is unnecessary and might even cause issues. But there are cases where it makes sense to use a service bus locally.
ZeroMQ 在这种工作中效果很好，而且给您带来的附带好处是您可以学习如何使用可以与其他语言和其他平台一起使用的工具。
This is the kind of job where ZeroMQ works well, and the side benefit to you is that you learn how to use a tool which can be used with other languages and on other platforms as well.