通讯协议

RMI ,HESSIAN,BURLAP,HTTPINVOKER,WEBSERVICE

总体性能比较： Socket(BIO/NIO)RMIHTTPInvoker=HessianRESTBurlapEJBWeb Service 如果协议设计的比较好，Socket性能毫无疑问是最高，同时灵活性和复杂度也最高，如果采用高效的网络框架如:Mina、Netty等可以降低开发复杂 度，一般在对性能有非常苛刻的条件下

总体性能比较： 
Socket(BIO/NIO)>RMI>HTTPInvoker>=Hessian>REST>>Burlap>EJB>>Web Service

1. 如果协议设计的比较好，Socket性能毫无疑问是最高，同时灵活性和复杂度也最高，如果采用高效的网络框架如:Mina、Netty等可以降低开发复杂度，一般在对性能有非常苛刻的条件下使用。
2. RMI 的性能相对略低，但是与Socket还在同1个数量级，同时只能在Java系统间通信，如果是基于互联网使用，还存在穿越防火墙的问题。采用Spring 封装的方式使用比原始RMI方式性能略高，主要原因是：Spring采用了代理和缓存机制，节省了对象重新获取的时间。
3. HTTPInvoker是Spring特有的，只能在客户端和服务器端都采用Spring框架下使用，与RMI本质相同，使用java的序列化技术传输对象，两者性能差别较小。
4. Hessian 在数据量较小时性能表现出众，甚至比RMI还高，在数据结构复杂的对象或者大量数据对象时，较RMI要慢20%左右；Hessian的优点是精简高效，同 时可以跨语言使用，目前支持Java,C++, .net, python, ruby等语言。另外Hessian可以充分利用web容器的成熟功能，在处理大量用户访问时很有优势，在资源分配、线程排队、异常处理等方面都可以由 web容器保证，而RMI本身不提供多线程的服务器。
5. REST架构也是一种比较简单、高效的Web服务架构，相对于Hessian性能略低，但还在同一个数量级，同时也是基于HTTP协议，目前也有比较多的成功案例。
6. Burlap 在数据量非常小时性能尚可，同时性能随着数据量的增加急剧降低，通常性能耗时是RMI的3倍左右，主要原因是：Hessian采用二进制传输数据，而 Burlap采用XML格式，而XML描述内容太多，同样的结构，其传输量要大很多，同时，XML的解析是比较耗资源的，尤其大数据量情况下更是如此。
7. EJB基于RMI协议，性能不高，同时只能在Java系统内使用，不能跨语言，目前使用越来越少，目前阿里巴巴内部已经完全放弃EJB。
8. 在 这些远程调用协议中，Web Service的性能是最低的，一般情况下，Web Service的性能相对于Hessian性能要慢10~20倍左右，同时，对于同样的访问请求，Web Service的传输数据量约为Hessian的6倍左右，对网络带宽消耗非常大，同时XML的解码器普遍性能不高，XML<->Java Bean的编码、解码非常耗费资源，对于并发和负载比较高的网站不是一个好的选择。同时，Web Service的使用也不太方便。

总结：Hessian和REST架构个人认为是比较优秀的高性能通信协议，如果对性能要求特别苛刻可以直接采用Socket方式，目前，阿里巴巴内部的远程调用主要采用Hessian和Dubbo(基于Mina框架)，经受了苛刻的高并发、高负载考验。

主要几种协议远程调用消耗大致时间(小数据量)： 
Socket/RMI/Hessian: 0.5ms 
REST:0.7ms 
Web Service(Axis): 约10ms，其中如果采用wsdl2java的方式，效率更低些。 
Socket/RMI/Hessian/REST之间选择还需要在传输数据量，性能要求等各方面考量，合适的场景选择合适的协议。