协议
远程调用层的协议，封将RPC调用，以Invocation和Result为中心，扩展接口为Protocol、Invoker和Exporter。Protocol是服务域，它是Invoker暴露和引用的主功能入口，它负责Invoker的生命周期管理。Invoker是实体域，它是Dubbo的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。
协议名 | 功能 | 备注 | Dubbo协议 采用NIO复用单一长连接，并使用线程池并发处理请求，减少握手和加大并发效率，性能较好（推荐使用） 在大文件传输时，单一连接会成为瓶颈。假设网络为千兆网卡(1024Mbit=128MByte)，根据测试经验数据每条连接最多只能压满7MByte(不同的环境可能不一样，供参考)，理论上1个服务提供者需要20个服务消费者才能压满网卡。如果每次请求的数据包大小为500KByte，假设网络为千兆网卡(1024Mbit=128MByte)，每条连接最大7MByte(不同的环境可能不一样，供参考)，单个服务提供者的TPS(每秒处理事务数)最大为：128MByte / 500KByte = 262。单个消费者调用单个服务提供者的TPS(每秒处理事务数)最大为：7MByte / 500KByte = 14 Rmi协议 可与原生RMI互操作，基于TCP协议 偶尔会连接失败，需重建Stub Hessian协议 可与原生Hessian互操作，基于HTTP协议 需hessian.jar支持，http短连接的开销大传输
网络传输层，抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel、Transporter、Client、Server和Codec。
协议名 | 功能 | 备注 | Netty Transporter JBoss的NIO框架，性能较好（推荐使用） 一次请求派发两种事件，需屏蔽无用事件 Mina Transporter 老牌NIO框架，稳定 待发送消息队列派发不及时，大压力下，会出现FullGC序列化
数据序列化层，可复用的一些工具，扩展接口为Serialization、 ObjectInput、ObjectOutput和ThreadPool
协议名 | 功能 | 备注 | Hessian Serialization 性能较好，多语言支持（推荐使用） Hessian的各版本兼容性不好，可能和应用使用的Hessian冲突，Dubbo内嵌了hessian3.2.1的源码 Dubbo Serialization 通过不传送POJO的类元信息，在大量POJO传输时，性能较好 当参数对象增加字段时，需外部文件声明 Json Serialization 纯文本，可跨语言解析，缺省采用FastJson解析 较差 Java Serialization Java原生支持 性能较差注册中心
协议名 | 功能 | 备注 | Zookeeper注册中心 支持基于网络的集群方式，有广泛周边开源产品，建议使用dubbo-2.3.3以上版本（推荐使用） 依赖于Zookeeper的稳定性 Redis注册中心 支持基于客户端双写的集群方式，性能高 要求服务器时间同步，用于检查心跳过期脏数据 Multicast注册中心 去中心化，不需要安装注册中心 依赖于网络拓普和路由，跨机房有风险 Simple注册中心 Dogfooding，注册中心本身也是一个标准的RPC服务 没有集群支持，可能单点故障代理
服务代理层，服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory
协议名 | 功能 | 备注 | Javassist ProxyFactory 通过字节码生成代替反射，性能比较好（推荐使用） 依赖于javassist.jar包，占用JVM的Perm内存，Perm可能要设大一些：java -XX:PermSize=128m Jdk ProxyFactory JDK原生支持 性能较差负载均衡
协议名 | 功能 | 备注 | Random LoadBalance 随机，按权重设置随机概率（推荐使用） 在一个截面上碰撞的概率高，重试时，可能出现瞬间压力不均 RoundRobin LoadBalance 轮循，按公约后的权重设置轮循比率 存在慢的机器累积请求问题，极端情况可能产生雪崩 LeastActive LoadBalance 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差，使慢的机器收到更少请求 不支持权重，在容量规划时，不能通过权重把压力导向一台机器压测容量 ConsistentHash LoadBalance 一致性Hash，相同参数的请求总是发到同一提供者，当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动 压力分摊不均集群容错模式
协议名 | 功能 | 备注 | Failover Cluster 失败自动切换，当出现失败，重试其它服务器，通常用于读操作（推荐使用） 重试会带来更长延迟 Failfast Cluster 快速失败，只发起一次调用，失败立即报错,通常用于非幂等性的写操作 如果有机器正在重启，可能会出现调用失败 Failsafe Cluster 失败安全，出现异常时，直接忽略，通常用于写入审计日志等操作 调用信息丢失 Failback Cluster 失败自动恢复，后台记录失败请求，定时重发，通常用于消息通知操作 不可靠，重启丢失 Forking Cluster 并行调用多个服务器，只要一个成功即返回，通常用于实时性要求较高的读操作 需要浪费更多服务资源 Broadcast Cluster 广播调用所有提供者，逐个调用，任意一台报错则报错，通常用于更新提供方本地状态 速度慢，任意一台报错则报错路由规则
协议名 | 功能 | 备注 | 条件路由规则 基于条件表达式的路由规则，功能简单易用 有些复杂多分支条件情况，规则很难描述 脚本路由规则 基于脚本引擎的路由规则，功能强大 没有运行沙箱，脚本能力过于强大，可能成为后门服务容器
协议名 | 功能 | 备注 | Spring Container 自动加载META-INF/spring目录下的所有Spring配置 Jetty Container 启动一个内嵌Jetty，用于汇报状态 大量访问页面时，会影响服务器的线程和内存 Log4j Container 自动配置log4j的配置，在多进程启动时，自动给日志文件按进程分目录 用户不能控制log4j的配置，不灵活
