阅读源码的作用
提取设计思路，增强设计能力
理解运行机制，便于快速解决问题以及功能扩展
Dubbo框架设计分层
配置层（Config）：该层是将业务方的service信息，配置文件的信息收集起来，主要是以ServiceConfig和ReferenceConfig为中心，ServiceConfig是服务提供方的配置，当Spring启动的时候会相应的启动provider服务发布和注册的过程，主要是加入一个ServiceBean继承ServiceConfig在Spring注册。同理ReferenceConfig是consumer方的配置，当消费方启动时，会启动consumer的发现服务订阅服务的过程，当然也是使用一个ReferenceBean继承ReferenceConfig注册在spring上。
服务代理层（Proxy）：对服务接口进行透明代理，生成服务的客户端和服务器端，使服务的远程调用就像在本地调用一样。默认使用JavassistProxyFactory，返回一个Invoker，Invoker则是个可执行核心实体，Invoker的invoke方法通过反射执行service方法。
服务注册层（Registry）：封装服务地址的注册和发现，以服务URL为中心，基于zk。
集群层（Cluster）:提供多个节点并桥接注册中心，主要负责loadBanlance、容错。
监控层（Monitor）：RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory、Monitor和MonitorService。
远程调用层（Protocol）：封装RPC调用，provider通过export方法进行暴露服务/consumer通过refer方法调用服务。而Protocol依赖的是Invoker。通过上面说的Proxy获得的Invoker，包装成Exporter。
信息交换层（Exchange）：该层封装了请求响应模型，将同步转为异步，信息交换层依赖Exporter，最终将通过网络传输层接收调用请求RequestFuture和ResponseFuture。
网络传输层（Transport）：抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel、Transporter、Client、Server和Codec。
数据序列化层：将数据序列化反序列化。
Dubbo源码的结构分层
dubbo-common 公共逻辑模块，包括Util类和通用模型。
dubbo-remoting 远程通讯模块，相当于Dubbo协议的实现，如果RPC用RMI协议则不需要使用此包。
dubbo-rpc 远程调用模块，抽象各种协议，以及动态代理，只包含一对一的调用，不关心集群的管理。
dubbo-cluster 集群模块，将多个服务提供方伪装为一个提供方，包括：负载均衡, 容错，路由等，集群的地址列表可以是静态配置的，也可以是由注册中心下发。
dubbo-registry 注册中心模块，基于注册中心下发地址的集群方式，以及对各种注册中心的抽象。
dubbo-monitor 监控模块，统计服务调用次数，调用时间的，调用链跟踪的服务。
dubbo-config 配置模块，是Dubbo对外的API，用户通过Config使用Dubbo，隐藏Dubbo所有细节。
dubbo-container 容器模块，是一个Standlone的容器，以简单的Main加载Spring启动，因为服务通常不需要Tomcat/JBoss等Web容器的特性，没必要用Web容器去加载服务。
整体上按照分层结构进行分包，与分层的不同点在于
container为服务容器，用于部署运行服务，没有在层中画出。
protocol层和proxy层都放在rpc模块中，这两层是rpc的核心，在不需要集群时(只有一个提供者)，可以只使用这两层完成rpc调用。
transport层和exchange层都放在remoting模块中，为rpc调用的通讯基础。
serialize层放在common模块中，以便更大程度复用。
下面是更详细的Project关系图，依赖关系线有点乱。整个模块是从上到下传递依赖的。
Dubbo中采用的设计模式
1、工厂模式
ServiceConfig中有个字段，代码是这样的：
查看文本打印
private static final Protocol protocol=ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
Dubbo里有很多这种代码。这也是一种工厂模式，只是实现类的获取采用了jdkspi的机制。这么实现的优点是可扩展性强，想要扩展实现，只需要在classpath下增加个文件就可以了，代码零侵入。另外，像上面的Adaptive实现，可以做到调用时动态决定调用哪个实现，但是由于这种实现采用了动态代理，会造成代码调试比较麻烦，需要分析出实际调用的实现类。
2、装饰器模式
Dubbo在启动和调用阶段都大量使用了装饰器模式。以Provider提供的调用链为例，具体的调用链代码是在ProtocolFilterWrapper的buildInvokerChain完成的，具体是将注解中含有group=provider的Filter实现，按照order排序，最后的调用顺序是
查看文本打印
EchoFilter-》ClassLoaderFilter-》GenericFilter-》ContextFilter-》ExceptionFilter-》
TimeoutFilter-》MonitorFilter-》TraceFilter。
更确切地说，这里是装饰器和责任链模式的混合使用。例如，EchoFilter的作用是判断是否是回声测试请求，是的话直接返回内容，这是一种责任链的体现。而像ClassLoaderFilter则只是在主功能上添加了功能，更改当前线程的ClassLoader，这是典型的装饰器模式。
3、观察者模式
Dubbo的provider启动时，需要与注册中心交互，先注册自己的服务，再订阅自己的服务，订阅时，采用了观察者模式，开启一个listener。注册中心会每5秒定时检查是否有服务更新，如果有更新，向该服务的提供者发送一个notify消息，provider接受到notify消息后，即运行NotifyListener的notify方法，执行监听器方法。
4、动态代理模式
Dubbo扩展jdkspi的类ExtensionLoader的Adaptive实现是典型的动态代理实现。Dubbo需要灵活地控制实现类，即在调用阶段动态地根据参数决定调用哪个实现类，所以采用先生成代理类的方法，能够做到灵活的调用。生成代理类的代码是ExtensionLoader的createAdaptiveExtensionClassCode方法。代理类的主要逻辑是，获取URL参数中指定参数的值作为获取实现类的key。
