远程服务调用

1 RPC协议分析比较

1.1 RMI

1.1.1 概述

SUN官方，基于TCP协议

允许多个服务绑定一个端口

cachestub为true时，性能提升30%

1.1.2 优点

高效稳定，特别是大数据量的情况下

1.1.3 演化

RMI stub-编译期（JDK5.0前）

动态代理RMI-运行期(JDK5.0后)

1.1.4 缺点

仅限于JAVA

1.1.5 通讯过程

·          客户端发起请求，请求转交至RMI客户端的stub类;

·          stub类将请求的接口、方法、参数等信息进行序列化;

·          基于socket将序列化后的流传输至服务器端;

·          服务器端接收到流后转发至相应的skelton类;

·          skelton类将请求的信息反序列化后调用实际的处理类;

·          处理类处理完毕后将结果返回给skelton类;

·          Skelton类将结果序列化，通过socket将流传送给客户端的stub;

·          stub在接收到流后反序列化，将反序列化后的Java Object返回给调用者。

·          

1.1.6 抓包

服务注册与调用默认为两个端口，服务请求包较大

连接：

 

报文交互：

 

请求报文内容：

 

1.2 自定义报文

1.2.1 目的

希望（或者说渴望）大家（不同业务，不同语言）用统一的协议提供服务，为未来彼此间无缝调用提供一种可能性，重要性堪比秦始皇统一货币。

1.2.2 机制

跨语言（任何编程语言都可以应用和理解）

简单，高效（要求快于RMI、hessian）

数据长度应该尽可能的小

基于TCP/IP，长链接

1.2.3 协议参考

参考报文头：

报文长  4  消息总长度，包含报文头及报文体 

命令或响应类型  4  

消息流水号  4 

1.3 Hessian

1.3.1 基于二进制Http协议

1.3.2 开源，多语言支持

1.3.3 抓包

需要发送Http报文头，请求包数据量小

交互：

 

请求报文：

 

 

 

1.5.1 性能不是一般地差

1.5.2 HTTP、高安全、XML语义

1.6 Phprpc（免费)

1.6.1 高效序列化、低效RPC

1.6.2 简单

1.6.3Hprose（收费) 试用版本高效,不稳定；正式版有待检验

1.7 综合比较图

协议/比较项	RMI	自定义	Hessian		Phprpc	WebService
底层协议	TCP/IP	TCP/IP	HTTP(二进制)		Http	HTTP
稳定性	高	较高	较高			高
性能(每秒循环处理数)	高(980)	理论上最高	高(1010)		较低(313)	低(100以内)
跨语言/开放性	仅限于JAVA、不需二次开发	跨语言、需要开发。协议相对封闭	跨语言、不需二次开发		跨语言、不需二次开发	跨语言、不需二次开发
综合	单台5600 QPS(1.2k) 无法跨语言是硬伤	解决跨语言及性能的理想解决方案； 尚未开发	中庸之道，大数据量时性能下降较快		性能一般，弃用	性能过差，弃用
最终选择	Y	Y	Y		N	N

 

1.8 Java序列化

1.8.1 说明

·          序列化后的内容大小对远程调用影响非常大

·          向pojo增加一个方法不会导致序列化后的值变大

·          增加属性会导致对象序列化变大(String/Date:增10；int:增8；List:增27)，但增长并不固定；空的对象序列化后是42,freedian对象是800多

·          一个对象的大小或属性的多少直接影响序列化后的值大小

·          transient关键词，不序列化的东西

1.8.2 过程

◆将对象实例相关的类元数据输出。

◆递归地输出类的超类描述直到不再有超类。

◆类元数据完了以后，开始从最顶层的超类开始输出对象实例的实际数据值。

◆从上至下递归输出实例的数据

 

1.8.3 例子

public class Parent {

    int parentVersion = 10;

}

class contain implements Serializable{  

        int containVersion = 11;  

}

public class SerialTest extends Parent implements Serializable {  

    int version = 66;  

    contain con = new contain();  

    public int getVersion() {  

           return version;  

    }

}

 

 

·          协议、版本、新对象标识

·          对象类描述

·          属性version描述（类型、长度、名称）

·          属性con描述

·          父类（Parent ）及父类属性描述

·          各个属性的值(parentVersion、version)

·          contain类的描述、属性描述及值

 

 

3 代理机制

 

3.1 JAVA代理机制

3.1.1 reflect.Proxy

示例

import java.lang.reflect.InvocationHandler;

import java.lang.reflect.Method;

import java.lang.reflect.Proxy;

 

/**

* reflect.Proxy代理Demo

*

*/

public class GenericProxyFactory {

 

    /**

     * 拦截处理类，负责保存对象并拦截处理

     */

    private static class JavaBeanProxy<T> implements InvocationHandler {

 

        /*

         * 代理的对象，在构造函数中植入

         */

        final T underlying;

 

        public JavaBeanProxy(T underlying) {

            this.underlying = underlying;

        }

评论

5 楼 andot 2010-06-09  

Hprose 1.1试用版已经开放申请了，这个试用版是跟正式版相同的，楼主有兴趣可以测试一下。

4 楼 bingobird 2010-01-27  

呵呵，andot跑来揪错了，关心自己的孩子，好现象。
文中确实有些不严谨的地方，在此表示抱歉。

这个比较是公司内部选型时我们的结论，所以不要太在意，大家用时也自己去做下比较。所有的第三方比较只能是参考，结论要自己得出。

Hprose测试肯定是做了，当时包也是向Hprose小组要的，可能基于一个试用版本，选型时不可能买个软件来试试。当时测试小组的结论是不稳定，至于正式版本如何，没用过不好说。

3 楼 andot 2010-01-22  

还有一点忘记说了，PHPRPC 是免费的，而且是永远免费的。而楼主却说它是收费的，真不知道楼主的钱是被谁给骗走的！

当然，Hprose 是商业版产品，当然是收费的，而且从来也没有免费过，也永远不会免费。因为它与 PHPRPC 是有本质区别的，它的性能和易用性与它的价格是相符的，甚至可以说它的性能和易用性远远超过了它的定价，是超值的。

2 楼 andot 2010-01-22  

楼主对Phprpc/Hprose的描述没有一项是正确的。

首先，PHPRPC 和 Hprose 是两个东西，不应该放在一起来说，因为它们在性能和易用性上有本质区别。

第二，PHPRPC/Hprose 的底层协议不是 TCP/IP，目前的实现是 Http。虽然 Hprose 在今年下半年才会推出 TCP 版本，但现在仍然不存在这个版本。而 PHPRPC 不会推出 TCP 版本。

第三，PHPRPC/Hprose 的稳定性不是低，而是高，不知道楼主是否在实际环境中使用过，PHPRPC到目前为止已经有5年历史了，有许多基于 PHPRPC 的应用 24x7 也已经运行了2－3年了，从没有出现过所谓的不稳定的问题。Hprose 是 PHPRPC 的商业版，更是超级稳定，楼主恐怕连使用都未使用过，就在这里妄加断言，实在是很不负责。

第四，PHPRPC/Hprose 的性能是不同的，你说的较低(313)是PHPRPC的性能，而 Hprose 的性能是 PHPRPC 的性能的十倍，是 Hessian 性能的三倍，这都是在实际中经过测试的，Hprose 每秒循环处理数是 3000 多，而且测试的机器只不过是一台普通的神舟笔记本。

第五，PHPRPC/Hprose 的跨语言/开放性是最好的，支持的语言多达数十种，并且还在不断增加，并且还有详细的开放的协议和实现的描述文档。楼主恐怕只是单纯的下载了一个 PHPRPC for Java 小用了一下，并且估计也没看文档，就在这里说只支持 Java，只能说明楼主是个非常粗心的人。

第六，综合就不用说了，前面对 PHPRPC/Hprose 的所有描述都是错误的，所以综合自然得出的结论也是错误的。

真心希望楼主在评价一个东西的时候先真正搞明白然后再做评价，不然不但会误人子弟，而且会贻笑大方。

1 楼 bingobird 2010-01-05  

晕，一粘贴格式就乱了。。。