问题描述
使用 NServiceBus + RabbitMQ 对比纯 RabbitMQ 有什么优势?我猜它提供了额外的基础设施.但还有什么?
What are advantages of using NServiceBus + RabbitMQ against pure RabbitMQ?I guess it provides additional infrastracture. But what else?
推荐答案
你绝对可以只使用纯 RabbitMQ.你只需要记住几件事.
You can definitely just use pure RabbitMQ. You just have to keep a couple things in mind.
警告:这个答案将非常半开玩笑.
首先您应该阅读企业集成模式封面覆盖并确保你理解它.它有 736 页，有点枯燥，但非常有用的信息.成为 RabbitMQ 所有特性的专家也不会有什么坏处.
First you should read Enterprise Integration Patterns cover to cover and make sure you understand it well. It is 736 pages, and a bit dry, but extremely useful information. It also wouldn't hurt to become an expert in all the peculiarities of RabbitMQ.
然后您只需要决定如何定义消息，如何定义消息处理程序，如何发送消息 和 发布活动.在你走得太远之前，你需要一个好的日志基础设施.您需要为 消息序列化器和基础设施/docs.particular.net/nservicebus/messaging/routing" rel="noreferrer">消息路由.您需要在每条业务消息的内容中包含一堆与基础设施相关的元数据.您需要构建一个性能良好并有效使用代理连接的消息出队策略，同时牢记并发需求.
Then you just have to decide how you'll define messages, how to define message handlers, how to send messages and publish events. Before you get too far you'll want a good logging infrastructure. You'll need to create a message serializer and infrastructure for message routing. You'll need to include a bunch of infrastructure-related metadata with the content of each business message. You'll want to build a message dequeuing strategy that performs well and uses broker connections efficiently, keeping concurrency needs in mind.
接下来您需要弄清楚如何在处理逻辑失败时自动重试消息，但不要太多次.您必须有处理有害消息的策略，因此您需要将它们移到一边，这样您的处理逻辑就不会被阻塞，从而阻止处理有效消息.您需要一种方法来显示那些失败的消息并找出原因，以便您可以修复问题.您需要某种警报选项，以便您知道何时会发生这种情况.如果该有害消息显示还向您显示该消息来自何处以及异常是什么，那么您就不需要去挖掘日志文件了，那就太好了.之后，您需要能够将有害消息重新路由回队列以重试.如果部署不当，您可能会收到很多失败的消息，因此如果您不必一次重试一条消息，那就太好了.
Next you'll need to figure out how to retry messages automatically when the handling logic fails, but not too many times. You have to have a strategy for dealing with poison messages, so you'll need to move them aside so your handling logic doesn't get jammed preventing valid messages from being processed. You'll need a way to show those messages that have failed and figure out why, so you can fix the problem. You'll want some sort of alerting options so you know when that happens. It would be nice if that poison message display also showed you where that message came from and what the exception was so you don't need to go digging through log files. After that you'll need to be able to reroute the poison messages back into the queue to try again. In the event of a bad deployment you might have a lot of failed messages, so it would be really nice if you didn't have to retry the messages one at a time.
由于您使用的是 RabbitMQ，消息代理上没有事务，因此幽灵消息和重复实体是非常现实的问题.您需要在编写所有消息处理逻辑时考虑到幂等性，否则您的 RabbitMQ 消息和数据库实体将开始变得不一致.或者，您可以设计基础架构来模拟分布式事务，方法是将传出消息操作存储在您的业务数据库中，然后分别执行消息分发操作.这会导致重复消息(按设计)，因此您需要在消息传入时对其进行重复数据删除，这意味着您需要一个明确定义的 在您的系统中保持一致的消息 ID 的策略.请小心，因为处理事务和并发的任何事情都可能非常棘手.
Since you're using RabbitMQ, there are no transactions on the message broker, so ghost messages and duplicate entities are very real problems. You'll need to code all message handling logic with idempotency in mind or your RabbitMQ messages and database entities will begin to get inconsistent. Alternatively you could design infrastructure to mimic distributed transactions by storing outgoing messaging operations in your business database and then executing the message dispatch operations separately. That results in duplicate messages (by design) so you'll need to deduplicate messages as they come in, which means you need well a well-defined strategy for consistent message IDs across your system. Be careful, as anything dealing with transactions and concurrency can be extremely tricky.
您可能想要做一些工作流类型的事情，其中传入消息开始一个本质上是一个消息驱动状态机的过程.然后，您可以执行诸如在收到 2 条必需消息后触发操作之类的操作.您需要为该数据设计一个存储系统.您可能还需要一种方法来延迟消息，因此您可以执行诸如 买家的悔恨模式.RabbitMQ 无法对消息进行任意延迟，因此您必须上来用一种方法来实现它.
You'll probably want to do some workflow type stuff, where an incoming message starts a process that's essentially a message-driven state machine. Then you can do things like trigger an action once 2 required messages have been received. You'll need to design a storage system for that data. You'll probably also need a way to have delayed messages, so you can do things like the buyer's remorse pattern. RabbitMQ has no way to have an arbitrary delay on a message, so you'll have to come up with a way to implement that.
您可能需要一些指标和性能计数器 以了解它的性能.您需要某种方式来对您的消息处理逻辑进行测试，因此如果您需要更换一些依赖项以使其工作您可能想要集成一个依赖项注入框架.
You'll probably want some metrics and performance counters on this system to know how it's performing. You'll want some way to be able to have tests on your message handling logic, so if you need to swap out some dependencies to make that work you might want to integrate a dependency injection framework.
由于这些系统本质上是去中心化的，因此很难准确描绘您的系统是什么样子.如果您将每条消息的副本发送到中央位置，您可以编写一些代码 将所有消息对话拼接在一起，然后您可以使用该数据构建消息流图、序列图等.这种基于实时数据的实时文档对于向经理解释事情或找出流程未按预期工作的原因至关重要.
Because these systems are decentralized by nature it can get pretty difficult to accurately picture what your system looks like. If you send a copy of every message to a central location, you can write some code to stitch together all the message conversations, and then you can use that data to build message flow diagrams, sequence diagrams, etc. This kind of living documentation based on live data can be critical for explaining things to managers or figuring out why a process isn't working as expected.
说到文档，请确保您写了很多 用于您的消息队列包装器，否则其他开发人员将很难帮助您维护它.如果你团队中的其他人正在写它，当他们得到一份不同的工作并离开公司时，你会完全被搞砸.您还需要在您构建的 RabbitMQ 包装器上进行大量单元测试.像这样的基础设施代码应该是坚如磐石的.您不希望丢失消息导致销售损失或类似情况.
Speaking of documentation, make sure you write a whole lot of it for your message queue wrapper, otherwise it will be pretty difficult for other developers to help you maintain it. Of if someone else on your team is writing it, you'll be totally screwed when they get a different job and leave the company. You're also going to want a ton of unit tests on the RabbitMQ wrapper you've built. Infrastructure code like this should be rock-solid. You don't want losing a message to result in lost sales or anything like that.
所以如果你记住这几点，你就可以完全使用没有 NServiceBus 的纯 RabbitMQ.
So if you keep those few things in mind, you can totally use pure RabbitMQ without NServiceBus.
希望当你完成后，你的老板不会决定你需要从 RabbitMQ 切换 到 Azure Service Bus 或 亚马逊 SQS.
Hopefully, when you're done, your boss won't decide that you need to switch from RabbitMQ to Azure Service Bus or Amazon SQS.
这篇关于使用 NServiceBus + RabbitMQ 对比纯 RabbitMQ 有什么优势?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！