RPC框架Dubbo深入分析，java软件开发工程师面试题目

Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现

可以和原生Hessian服务互操作

提供者用Dubbo的Hessian协议暴露服务，消费者直接用标准Hessian接口调用

或者提供方用标准Hessian暴露服务，消费方用Dubbo的Hessian协议调用

基于Hessian的远程调用协议

总结

连接个数：多连接

连接方式：短连接

传输协议：HTTP

传输方式：同步传输

序列化：Hessian二进制序列化

适用范围：传入传出参数数据包较大，提供者比消费者个数多，提供者压力较大，可传文件

适用场景：页面传输，文件传输，或与原生hessian服务互操作

约束

参数及返回值需实现Serializable接口

参数及返回值不能自定义实现List, Map, Number, Date, Calendar等接口，只能用JDK自带的实现，因为hessian会做特殊处理，自定义实现类中的属性值都会丢失

exchange（ 信息交换层）

封装请求响应模式，同步转异步

以Request, Response为中心，扩展接口为Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer

transport（ 网络传输层）

抽象mina和netty为统一接口

以Message为中心，扩展接口为Channel, Transporter, Client, Server, Codec

选择

Netty

性能较好（推荐使用）

一次请求派发两种事件，需屏蔽无用事件

Mina

老牌NIO框架，稳定

待发送消息队列派发不及时，大压力下，会出现FullGC

Grizzly

Sun的NIO框架，应用于GlassFish服务器中

线程池不可扩展，Filter不能拦截下一Filter

serialize（ 数据序列化层）

可复用的一些工具

扩展接口为Serialization, ObjectInput, ObjectOutput, ThreadPool

选择

Hessian

性能较好，多语言支持（推荐使用）

Hessian的各版本兼容性不好，可能和应用使用的Hessian冲突，Dubbo内嵌了hessian3.2.1的源码

Dubbo

通过不传送POJO的类元信息，在大量POJO传输时，性能较好

当参数对象增加字段时，需外部文件声明

Json

纯文本，可跨语言解析，缺省采用FastJson解析

性能较差

Java

Java原生支持

性能较差

关系说明

在RPC中，Protocol是核心层，也就是只要有Protocol + Invoker + Exporter就可以完成非透明的RPC调用，然后在Invoker的主过程上Filter拦截点。

图中的Consumer和Provider是抽象概念，只是想让看图者更直观的了解哪些类分属于客户端与服务器端，不用Client和Server的原因是Dubbo在很多场景下都使用Provider, Consumer, Registry, Monitor划分逻辑拓普节点，保持统一概念。

而Cluster是外围概念，所以Cluster的目的是将多个Invoker伪装成一个Invoker，这样其它人只要关注Protocol层Invoker即可，加上Cluster或者去掉Cluster对其它层都不会造成影响，因为只有一个提供者时，是不需要Cluster的。

Proxy层封装了所有接口的透明化代理，而在其它层都以Invoker为中心，只有到了暴露给用户使用时，才用Proxy将Invoker转成接口，或将接口实现转成Invoker，也就是去掉Proxy层RPC是可以Run的，只是不那么透明，不那么看起来像调本地服务一样调远程服务。

而Remoting实现是Dubbo协议的实现，如果你选择RMI协议，整个Remoting都不会用上，Remoting内部再划为Transport传输层和Exchange信息交换层，Transport层只负责单向消息传输，是对Mi