A-A+

MQ和RPC初印象

2017年03月29日 技术 暂无评论 阅读 1,978 次

信息化进程越来越快,企业的要求也越来越高。而且随着应用的增多,大量的重复性劳动开始显现,面向服务架构呼之欲出。应客户要求,同时也未雨绸缪,了解一下市面上的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一样有完善的社区该多好。

给我留言

Copyright © 字痕随行 保留所有权利.   Theme  Ality 京ICP备14039894号

用户登录

分享到: