RabbitMQ, Windows Server 上服务总线的替代品
RabbitMQ, Windows Server 上服务总线的替代品
https://www.robfox.io/2017/04/17/rabbitmq-alternative-service-bus-windows-server/
我想为复活节写点东西。为什么不是关于 RabbitMQ 呢？
数个月前，微软宣布不再支持其 Azure Service Bus Messaging。也被称为 Service Bus for Widnows Server。为什么呢？因为显而易见的是，未来所有人都在迁移到云和混合云。这是现实，大量的公司正在迁移，但是因为他们还需要再本地保持数据，这就需要做一些集成的工作。当前我们需要本地的工具而不能完全依赖于云解决方案。
幸运的是，我最近几个月正在一个项目上，实际处理本地解决方案中建议使用 RabbitMQ。比较微软的本地方案，我确实感到我们采用 RabbitMQ 而不是微软方案的好处。
为什么采用 RabbitMQ?
总结一下为什么我们选择 RabbitMQ，以及为什么未来我们会继续选择它：
- AMQP 协议
- 广泛采用，当前几乎是最为流行的队列方案
- 成熟，当前是它的 10 周年庆典 ( 本文写于 2017 )
- 独立，不需要 SQL Server ( 或者其它商用数据库 )，这是其优势，为什么我还需要付费给 SQL Server 呢？
- 只需 2 台机器即可高可用，而微软的 Service Bus 需要至少 3 台机器
- 跨平台，Windows, Linux 及 Mac
- 支持所有流行的编程平台和语言
- Python
- Java
- C#
- Ruby
- PHP
- JavaScript
- Go
- 内置管理门户可以管理所有方面。对我来说是很大的优势。
- 内置的状态分析，对于交换、队列，还有内存使用和队列级别的磁盘使用。甚至可以看到当前存在哪些监听器和连接
- 友好的文档
至于缺点？当然有，我只考虑到 2 个：
- 没有 BizTalk 的适配器
- 不得不基于 Rabbit 的方式来使用
支持与云
尽管 RabbitMQ 是开源产品。还是存在多种方式获得支持。Pivotal 可能是最好的。
如果需要，还可以在云中使用它。
与 Service Bus Messaging 有何不同？
如果最后归结为习惯术语和协议的实现。 这并没有那么不同。 在 不同的是，Microsoft 方案简单，只有队列和主题，而 RabbitMQ 中的方法有点不同。
RabbitMQ 使用 exchanges 工作。任何发送到 RabbitMQ 的消息都都发送到一个 exchange。exchange 的类型决定了它如何工作。有如下 4 种类型：
- headers
- fanout
- topics
- direct
下面我概述这些类型，以后的文章会详细说明。
Headers
Headers exchange 基于发送到当前队列的消息头。
Fanout
Fanout 简单直接地将接收到的所有消息发送到绑定的队列
Topics
主题的 routing key 通过中间点发送，并且使用正则表达式匹配订阅，消息只会发送到与绑定中的模式匹配的队列
Direct
将消息发送给配置了完全相同的 key 的队列
Linux
在这一切的过程中，RabbitMQ 也让我重新开始使用 Linux - 在我的例子中是 Ubuntu。好吧，尽管 RabbitMQ 可以和 .Net Core 在 Windows Server 机器上运行，但有一些开源的东西可以让它在 Linux 上运行。
我至少有 10 年没有接触过 Linux（在内部，我的网站都在 Linux 上运行）并且不得不重新开始使用它。几个小时后，我再次掌握了窍门。而且，就像我之前说的，你永远不会太老而不能学习。试一试。
这将需要几个小时（以及几天或几周）的混乱，但我很确定从长远来看我们将需要它。越来越多的事情发生在开源领域。甚至 .Net 也是开源的并在 Linux 上运行。有一天将不再有借口为 RabbitMQ 等小型解决方案部署（昂贵的）Windows 机器，而这些知识将派上用场！
下载 MabbitMQ
不，这不是一篇拉票的文章。我是真的喜爱 RabbitMQ。极快的安装，多平台支持，多语言支持，开箱即用的管理界面，以及友好的在线文档。易于上手，我总是建议在本地队列机制中采用它。
下载 RabbitMQ 并尝试它。如果你是 Winodws 使用人员，只需要下载 Windows 版本的安装器并安装即可。如果是 Ubuntu 使用人员，就是用 apt-get 库来安装它，是的，特别简单。
