我很高兴地宣布，VMware 旗下的 SpringSource 部门已收购 Rabbit Technologies Ltd.，该公司是流行的开源云消息传递技术 RabbitMQ 背后的公司。此次收购将增强我们的中间件产品组合，并加速我们的云计划。

云中的消息传递演进

随着组织越来越多地在云环境中构建和部署应用程序，支持这种新模型的 Infrastructure 正在不断发展。需要一种新型的轻量级、可靠、可伸缩和可移植的消息传递系统，以支持将用户请求路由到适当的资源，无论它们位于何处。RabbitMQ 是该领域的领导者，并在云消息传递方面展示了重要的创新。

RabbitMQ 非常适合云环境，主要有三个原因

• 开放：RabbitMQ 是开源的，拥有开放且活跃的社区，并基于开放标准。开放性将是成功构建云平台的关键因素，因为如果结果只是另一种形式的厂商锁定，那么迁移到云端将失去很多吸引力。
• 灵活的可伸缩性：RabbitMQ 能够以多种不同方式进行伸缩，不仅包括技术性的横向伸缩，还包括跨服务伸缩的联合消息传递，直至跨地域的多样化伸缩。
• 基于协议：RabbitMQ 是一个基于协议而非基于 API 的消息传递系统。这意味着消息客户端不依赖于厂商安装的库，这提高了应用程序的可移植性，并允许客户端从各种不同的平台发送和接收消息。这种方法还使 RabbitMQ 能够支持多种协议，从而提高了它在云等异构环境中的实用性。

事实上，Rabbit 在云场景下的适用性已通过云服务提供商和构建私有云的组织（例如 NASA Nebula）的采用得到了实践验证。

这对您意味着什么？

如果您是 RabbitMQ 社区的成员，这是个好消息，也是对您技术选择的进一步重要肯定。RabbitMQ 将继续保持开源，并以与以前相同的方式分发。社区可以期待对这项杰出技术投入更多资源，这将显著改进开源版本。RabbitMQ 社区还可以期待获得 SpringSource 对其其他开源社区（如 Spring、Grails、Groovy 和基于 Apache 的技术）提供的同样的奉献和支持。

我们热爱并致力于开发者使用 Rabbit 的多样化语言和平台（不仅限于 Java）。消息传递技术的部分价值在于其跨平台能力。

正如您可以预期的那样，我们将为 Spring 社区构建一种特别引人注目的体验。直接使用 Spring 或通过 Grails 使用 Spring 的企业开发者可以期待 RabbitMQ 作为消息传递系统的出色集成。这将为开发者提供更多灵活性和选择来构建他们的应用程序，同时确保他们开发的应用程序可以更轻松地从开发者桌面迁移到虚拟或物理数据中心，再到云端。

这种 Spring 集成将包含两个方面

• 类似于 Spring JMS 支持的低级集成。这将包括一个 RabbitTemplate，它提供简单的发送和接收操作，并委托给 MessageConverter 以支持 POJO 消息传递模型。除了模板之外，我们还通过 MessageListenerContainer 和 MessageListenerAdapter 提供对“消息驱动 POJO”的支持，它们与 Spring JMS 支持中的对应项非常相似。当然，我们将管理低级资源以及事务。所有这些都将适用于 Java 和 .NET，并且我们正在设计高级 AMQP 层，以便将来可以支持多种实现。
• Spring Integration 支持。这将包括通道适配器（Channel Adapters），用于将 Spring Integration 消息通道（Message Channels）连接到发送端的 AMQP 交换机（Exchanges）和接收端的 AMQP 队列（Queues）。虽然这些适配器建立在上述低级支持的基础上，但它们进一步抽象了编程模型，以便最终用户可以在纯 POJO 服务层之上依赖 Spring Integration 配置。

后者尤为重要。Spring Integration 是最令人兴奋的 Spring 项目之一，它提供了 Spring POJO 编程模型自然地扩展，以处理企业集成模式。我们看到社区和客户对 Spring Integration 的兴趣日益高涨，并正在大幅增加对其开发的投资。正如 Spring 依赖注入提供了一种抽象，避免了使用 JNDI 等低级 API 的需求，简化了应用程序代码并将其与部署问题解耦一样，我相信许多（如果不是大多数）异步模式最好在更概念化的层面表达，就像 Spring Integration 那样，而不是直接使用消息传递 API 和协议。

Spring Integration 允许开发者利用同步和异步消息传递，而无需实现监听器接口或编写依赖于模板的代码。它支持 企业集成模式 (Hohpe/Woolf)，直接构建在 Spring Framework 之上。开发者可以使用声明式、配置驱动的方法来处理集成问题，例如转换 (Transformation)、路由 (Routing)、拆分 (Splitting) 和聚合 (Aggregation)，同时与易于独立测试的基于 POJO 的业务逻辑保持清晰的分离。Spring Integration 的 Message Channel 抽象提供了进程内和进程间消息传递之间的一致性。它还将应用程序代码与任何特定的传输或协议解耦。这与 Spring 的总体理念非常吻合，即可移植性不应需要修改代码，技术选择不应导致锁定。通过将 RabbitMQ 添加到传输选项中，开发者将拥有更多选择，并能够立即在 RabbitMQ 和任何其他支持的传输之间建立桥梁。

这篇博客我有点晚了。媒体、博客圈和推特（RabbitMQ 是热门话题）已经对 SpringSource/Rabbit 议论纷纷。（这让我想起：我最近在推特上比在博客上活跃得多，我鼓励大家在 springrod 关注我。）

然而，请允许我率先欢迎 RabbitMQ 社区加入 SpringSource 大家庭，并鼓励 SpringSource 社区了解如何开始使用 RabbitMQ。