几种分布式调用技术的比较 -- RPC VS REST

我之前在传统IT公司干活,后来来了互联网,感受到了很多不同,其中有一点就是两者使用到的技术有一些差别。比如说分布式调用技术。

我在的这家公司内部的服务架构是基于Thrift的,服务基于Thrift进行发布,以至于很多人没有听过、使用过Web Service。

话说传统IT传了很多年的SOA就是基于Web Service,已经有了一整套完整的理论和产品进行支持,互联网竟然很多没涉及过。后来想了想,也是,传统IT更多做的是各种资源的整合,偏重各种异构,遗留系统整合的复杂度,对效率要求不高。互联网则是对效率要求到了极致,内部系统使用Web Service性能跟不上。而且现在对外发布的服务有了更优的REST,使用Web Service的场景也没那么多。


我用一个比较大的词“分布式调用“来表示一台机器对另外一台机器的访问。分布式这个东东说白了就是随着技术和业务的发展,一台单独机器的计算,存储能力不能够满足日益增长的IT业务需求,所以需要把计算,存储能力扩大到多台机器上


分布式调用的底层基础就是网络编程,一台机器向另外一台机器发送消息,另外一台机器收到消息后,根据某种协议来做一些事情

1. 比如进行一个方法的调用

2. 比如对某个资源进行操作


分布式调用大体上就分为两类,RPC式的,REST式的,两者的区别主要是就是:

1. RPC是面向动作的(方法调用)

2. REST是面向资源的(URL表示资源,HTTP动词表示动作)


从变现形式来看,RPC的编程模型较重量级,REST的编程模型更轻量级


分布式调用技术的主要关注点有四个,前面两点比较常见,最后两点是我新加的:

1. 采用什么传输协议,TCP, HTTP,还是其他

2. 采用什么序列化协议(也叫CodeC,编解码,Marshalling),比如基于文本的XML(自定义XML,或者SOAP),基于二进制流(Java序列化,或者自定义序列化协议,比如Thrift, Protobuf, JBoss Marshalling)

3. 采用什么IO形式,阻塞IO,非阻塞同步IO(select / poll / epoll),非阻塞异步IO

4. 采用什么方式运行,运行在HTTP服务器上,还是以单独进程运行


根据第一点来看,RPC阵营如下

1. Web Service采用HTTP协议做传输层协议,采用SOAP做应用层协议

2. XML-RPC,采用HTTP协议做传输层协议,使用自定义XML做应用层协议

3. JMI, Thrift, Protobuf等都使用TCP做传输协议,使用自定义应用层协议


REST直接使用HTTP做应用层协议,使用URL表示资源,使用HTTP动词表示动作


根据第二点来看,RPC阵营如下

1. Web Service和XML-RPC采用基于文本的XML进行序列化

2. RMI基于Java序列化协议

3. Thrfit, Protobuf等采用了基于二进制流的序列化协议,比如就是采用消息头消息体的方式传输,通过消息头来定义长度,从而保证能够正确读写数据


根据第三点来看,随着NIO的广泛应用,越来越多的服务器端支持非阻塞IO,客户端可以采用同步IO,也可以采用非阻塞IO。

关于阻塞,非阻塞,同步,异步的概念,看这篇http://blog.csdn.net/iter_zc/article/details/39291647


关于第四点,Web Service和REST都运行在HTTP服务器上,Thrift这样的都是以单独进程运行


另外多说几句Web Service,Web Service采用HTTP层做传输协议,采用文本格式的SOAP做应用层协议,相比于基于二进制流的RPC协议,

好处是:基于HTTP传输,采用文本方式,可以穿越防火墙,适合组织内向组织外提供服务

坏处是:基于文本的序列化效率低下,传输层基于HTTP,相比于TCP,多了一层协议,性能也有影响,不适合对性能要求高的场景


REST近年来有取代Web Service的趋势,主要是Web Service的优点它都有,而且更轻量级,采用JSON来序列化数据性能也还可以,编程模型更加简单,适合组织内向组织外发布服务。

组织内部对性能要求高的场景可以使用Thrift这种的RPC技术,基于二进制流的序列化协议,基于NIO的传输协议,性能较高,适合高并发的场景











展开阅读全文

没有更多推荐了,返回首页