几种分布式调用技术的比较 -- 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的传输协议，性能较高，适合高并发的场景