与纯 RabbitMQ 相比，使用 NServiceBus + RabbitMQ 有什么优势? [英] What are advantages of using NServiceBus + RabbitMQ against pure RabbitMQ?

问题描述

使用 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.

警告:这个答案会有点 非常半开玩笑.

Warning: This answer will be a bit extremely tongue-in-cheek.

首先您应该阅读企业集成模式封面覆盖并确保您很好地理解它.它有 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.

然后您只需决定如何定义消息，如何定义消息处理程序，如何发送消息 和 发布事件.在您走得太远之前，您需要一个良好的日志基础设施.您需要为 消息序列化程序 和 消息路由.您需要在每条业务消息的内容中包含一堆与基础架构相关的元数据.您需要构建一个性能良好并有效使用代理连接的消息出队策略，同时牢记并发需求.

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.

您可能需要一些 metrics 和 性能计数器 在这个系统上了解它的性能.您需要某种方式来对您的消息处理逻辑进行测试，所以如果您需要换掉一些依赖项以使其工作您可能想要集成依赖项注入框架.

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 服务总线 或 Amazon 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.

这篇关于与纯 RabbitMQ 相比，使用 NServiceBus + RabbitMQ 有什么优势?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！