在 Cloud Foundry 上使用 Node.JS 的 RabbitMQ 服务
最近,我们推出了Cloud Foundry 的 RabbitMQ 服务,让您可以在 Cloud Foundry 上轻松地启动消息代理以供您的应用程序使用。网上有关于将其与 Ruby on Rails 和使用 Spring 的 Java 应用程序的教程。在这里,我们将探讨如何将 RabbitMQ 服务与 Node.JS 应用程序结合使用。
最近,我们推出了Cloud Foundry 的 RabbitMQ 服务,让您可以在 Cloud Foundry 上轻松地启动消息代理以供您的应用程序使用。网上有关于将其与 Ruby on Rails 和使用 Spring 的 Java 应用程序的教程。在这里,我们将探讨如何将 RabbitMQ 服务与 Node.JS 应用程序结合使用。
今天,我们在 CloudFoundry.com 上启动了一项 RabbitMQ 服务。这项服务为在 Cloud Foundry 上构建应用程序的开发人员带来了 RabbitMQ 的消息传递功能。您可以在 Cloud Foundry 博客上阅读 主要公告。Cloud Foundry 知识库中还有一个 FAQ,提供更多详细信息。 CloudFoundry.com 是一项免费的 beta 服务。所以请在此注册(如果您还没有注册),然后查看 RabbitMQ 服务,试用示例应用程序,并编写您自己的应用程序。并告诉我们如何做得更好。
我从根本上不同意我们当前 AMQP 客户端库公开的 API。
它们不完美是有原因的:我们从一开始就故意避免在 API 上进行创新。我们的客户端库的目的是公开通用的 AMQP,而不是消息传递的任何一种视图。但是,在我看来,试图将 AMQP 直接映射到客户端库 API 是错误的,会导致过度复杂化和难以使用的抽象。
没有共同点:盲目遵循 AMQP 模型而设计的客户端库将很复杂;易于使用的客户端库必须是有倾向性的。
最近我看到一条推文说“ZeroMQ 让一切都 Erlang 化!”之类的。虽然我意识到并非网上发布的所有内容都是认真的,但似乎最近有一股类似的说法应该被遏制。
在文章“多线程魔法”[^1] 中,Pieter Hintjens 和 Martin Sustrik 有说服力地解释了为什么通过消息传递比通过锁和共享内存更能满足并发的需求。而且,我认为他们的分析是公平的——除了暗示使用 ZeroMQ 会将你选择的编程语言变成家用的 Erlang。
注意:这篇博文讨论的是为 RabbitMQ 2.5.0 发布的一个 federation 插件预览版。如果您使用的是 2.6.0 或更高版本,federation 是主发行版的一部分;您可以像获取任何其他插件一样获取它。
又一天,又一款新插件发布😃今天发布的是 **federation**。如果您想跳过这篇博文直接下载插件,请前往此处。详细说明请参见此处。
Federation 的高级目标是在广域网和管理域中扩展发布/订阅消息。
为此,我们引入了 **federation exchange** 的概念。federation exchange 像一个给定类型的普通 exchange 一样工作(它可以模拟任何已安装的 exchange 类型的路由逻辑),但它也知道如何连接到 **上游** exchange(这些上游 exchange 本身也可能是 federation exchange)。
RabbitMQ 团队很高兴地宣布 RabbitMQ 2.5.0 发布。
我们 RabbitMQ 总部的大多数人都曾在 Erlang 之外的许多函数式语言工作过,例如 Haskell、Scheme、Lisp、OCaml 等。虽然 Erlang 有很多值得称道的地方,比如它的虚拟机/模拟器,但不可避免地会有我们从其他语言中怀念的功能。对我来说,在回到 RabbitMQ 之前,我在 Haskell 工作了几年,结果发现有各种各样的功能“缺失”,比如惰性求值、类型类、额外的中缀运算符、指定函数优先级的能力、更少的括号、部分应用、更一致的标准库和 do-notation。这是一个不错的列表,我需要花点时间才能在 Erlang 中全部实现它们,但这里有两个作为开端。
在我们上一篇博文中,我们讨论了几种主题路由优化方法,并简要描述了其中两个最重要的。在这篇文章中,我们将讨论在实现 DFA 时我们尝试过的一些方法,以及我们对 trie 和 DFA 进行的一些性能基准测试。
RabbitMQ 2.4.0 引入了一项扩展,允许发布者在 CC 和 BCC 消息头中指定多个路由键。BCC 标头在消息传递之前被从消息中移除。直接和主题交换是仅有的使用路由键的标准交换类型,因此此功能的路由逻辑仅适用于这些交换类型。
我决定运行一些我的 AMQP 编码器/解码器(AMQ Protocol gem)与 AMQP gem 中的旧编码器/解码器进行的基准测试,看看它的性能是否更好。到目前为止,我只做了一些最基本的优化,比如将可重用的值存储在常量中,没有什么特别的(目前)。
我做了两组基准测试:使用我分叉的 RBench(支持自定义格式化程序,例如将结果写入 YAML 文件)进行的 CPU 时间基准测试,以及使用 Object.count_objects(Ruby 1.9)进行的内存基准测试。