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

云中的消息演进

随着组织越来越多地在云环境中构建和部署应用程序，支持这种新模型的基础设施也在不断发展。需要一种新型的轻量级、可靠、可扩展和可移植的消息系统，以支持将用户请求路由到适当的资源，无论它们位于何处。RabbitMQ在该领域处于领先地位，并在云消息方面展现了显著创新。

RabbitMQ之所以非常适合云，主要有三个原因

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

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

这对你意味着什么？

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

我们热爱并致力于各种语言和平台（超越 Java）的多样性，开发者正是通过它们使用 Rabbit。消息传递技术的部分价值在于其跨平台的能力。

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

这种 Spring 集成将包含两个要素

• 与 Spring 的 JMS 支持类似的低层集成。这将包括一个 RabbitTemplate，它提供简单的发送和接收操作，并委托给 MessageConverter 以支持 POJO 消息模型。除了模板之外，我们还将通过 MessageListenerContainer 和 MessageListenerAdapter 提供“消息驱动 POJO”的支持，它们与 Spring 的 JMS 支持中的同名组件非常相似。当然，我们还将管理低层资源以及事务。所有这些都将适用于 Java 和 .NET，我们正在设计高级 AMQP 层，以便它将来可以支持多种实现。
• Spring Integration 支持。这将包括通道适配器，用于将 Spring Integration 消息通道连接到发送端的 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 之上。开发者可以使用声明式、配置驱动的方法来解决集成问题，例如转换、路由、拆分和聚合，同时保持与基于 POJO 的业务逻辑的清晰分离，业务逻辑可以轻松地独立测试。Spring Integration 的消息通道抽象提供了进程内和进程间消息传递之间的一致性。它还将应用程序代码与任何特定的传输或协议解耦。这与 Spring 的一般哲学非常吻合，即可移植性不应要求代码更改，技术选择不应导致锁定。通过将 RabbitMQ 添加到传输选项中，开发者将拥有更多选择，并且能够立即在 RabbitMQ 和任何其他受支持的传输之间建立桥梁。

我写这篇博客有点晚了。新闻界、博客圈和 Twitter（它一直是一个热门话题）已经对 SpringSource/Rabbit 议论纷纷。（这提醒我：最近我在 Twitter 上比在我的博客上活跃得多，我鼓励您在springrod关注我。）

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