信息化进程越来越快，企业的要求也越来越高。而且随着应用的增多，大量的重复性劳动开始显现，面向服务架构呼之欲出。应客户要求，同时也未雨绸缪，了解一下市面上的MQ和RPC框架，有了一个大概的初步印象。

1. ZeroMQ

ZeroMQ是一个简单好用的传输层，像框架一样的一个socket library，他使得Socket编程更加简单、简洁和性能更高。是一个消息处理队列库，可在多个线程、内核和主机盒之间弹性伸缩。

正向上文所说的，它是一个library，在可靠性(持久性、投递确认、发布者证实和高可用性)方面需要自定义大量的代码来实现。想要自力更生、点对点的可以一用。如果想要快速开发部署的，我觉的就可以放弃了。而且使用之后造成的星状布局着实让人头疼。

2. RabbitMQ

RabbitMQ是一个由erlang开发的AMQP（Advanced Message Queue ）的开源实现。因为使用erlang开发，使其的处理速度和应对高并发上面的表现十分良好。高并发的场景应付起来应该是得心应手，相对于ActiveMQ和ZeroMQ来说，它的效率确实要高一些。不过，如果是个Java控，或者说企业的主要应用都是Java平台下的，又或者希望了解其代码的，还是需要综合考虑一下。

3. Kafka

Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。Kafka设计的初衷就是处理日志的，针对性很强。

4. Zeroc ice

ZeroC ICE 是指ZeroC公司的ICE（Internet Communications Engine）中间件平台。对于客户端和服务端程序的开发提供了很大的便利。是RPC通讯领域里最稳定、强大、高性能、跨平台、多语言支持的老牌开源中间件，特别适合于当前互联网领域中一个平台存在多种开发语言编程，以及网站和app应用并存的复杂大型项目。

但是国内目前的应用情况并不理想，相应的讨论和资料就很少，上手相对来说难度就比较大。

5. Thrift

Apache Thrift 是 Facebook 实现的一种高效的、支持多种编程语言的远程服务调用的框架。Thrift的文档并不太完善，而且Facebook留下了很多问题没有修复。现在Facebook又开源了一个fbthrift，导致Thrift的位置很尴尬。

6. Dubbo

阿里巴巴的开源解决方案，在国内应用使用的范围较广，但是阿里现在已经放弃了该项目，很尴尬啊。

7. Hessian

Hessian是一个轻量级的remoting onhttp工具，使用简单的方法提供了RMI的功能。 相比WebService，Hessian更简单、快捷。采用的是二进制RPC协议，因为采用的是二进制协议，所以它很适合于发送二进制数据。

Hessian目前不太活跃，还是算了吧。

8. Spring Cloud

Spring Cloud 为开发者提供了在分布式系统（如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性 Token、全局锁、决策竞选、分布式会话和集群状态）操作的开发工具。使用 Spring Cloud 开发者可以快速实现上述这些模式。

Spring Cloud最重要的一点是它可以和Spring Boot一起工作，Spring Boot可以帮助开发者更容易地创建基于Spring的应用程序和服务。

Spring Cloud更加像一套解决方案，天生就是为微服务架构服务的。但是其诞生时间相对来说较晚，目前还处于发展和充实的过程中，不可避免的有一些不稳定。另外它最好与Spring Boot开发框架和Docker容器相结合来使用。它要求的学习曲线过长，相对于单一的MQ或者RPC框架来说显得更重，所以并不建议在短期内使用。当然，在积累了一定的实践经验，并且这套方案相对来说更加成熟的时候，应该不失为一个较好的方案。

9. Hasor-RSF

一个高可用、高性能、轻量级的分布式服务框架。支持容灾、负载均衡、集群。一个典型的应用场景是，将同一个服务部署在多个Server上提供 request、response 消息通知。
使用RSF可以点对点调用，也可以分布式调用。部署方式上：可以搭配注册中心，也可以独立使用。

从其描述上可以看出这还是一款不错的框架，并且一直在稳定更新，对于国内的各种框架也都有支持，但是关键的问题在于没有使用案例，所以难免让人信心不足。

但是查阅其示例可以发现，它与Spring相结合也是非侵入方式的，这是优点，会让业务代码很干净，可以作为备选的方案。

10. ActiveMQ

ActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现。

在国内，ActiveMQ和RabbitMQ也算是应用比较广泛的框架，有着良好的用户基础，虽然在性能和高并发方面，ActiveMQ稍逊于RabbitMQ，但是由于其使用Java开发，所以对于很多公司来说ActiveMQ具备天然的优势。

ActiveMQ可以实现RPC，并且与Spring相结合时，不会侵入业务代码，也可以作为备选的方案。但是使用其开发示例发现，高版本的ActiveMQ存在一些问题，有可能会与Spring框架冲突，虽然问题可以解决，但是毕竟有一些担忧。另外，由于ActiveMQ是JMS的坚定支持者，所以在实现RPC时，需要通过Spring内的JMS包来实现。

11. Zbus

一款轻量级的MQ和RPC服务框架。支持消息队列, 发布订阅, RPC, 代理（TCP/HTTP/DMZ）；亿级消息堆积能力、支持HA高可用超轻量级；单个Jar包无依赖 ~250K；丰富的API--JAVA/C/C++/C#/Python/Node.JS多语言接入。目前zbus总线在国信证券、前海股权交易中心 以及 OSChina 等企业众多项目中实际应用，主要担当基础消息队列、SOA服务治理角色。Zbus与Spring相结合时，也不会侵入业务代码，而且它不依赖于其它包实现RPC。

12. 总结

从初步印象来看，我更加倾向于ActiveMQ和zbus，毕竟都是用Java语言开发的，而且两个框架对于业务代码的侵入程度很低，同时与Spring结合的也较好。ActiveMQ就不用说了，使用的案例很多，zbus也获得了很多人的支持。

说个题外话，如果国产的开源软件都像Nutz一样有完善的社区该多好。