一、导论
dubbo作为阿里开发优秀的rpc服务框架，现已广泛用于各大rpc项目之间的远程通信，虽然阿里现在已经没有维护dubbo的开发，但是其结构设计也是值得学习。
二、结构简介
这部分只是简单介绍dubbo的结构图解，可能会有些复杂，但确实是dubbo设计的精髓所在。
1、各层介绍
config，配置层，对外配置接口，以ServiceConfig, ReferenceConfig为中心，可以直接new配置类，也可以通过spring解析配置生成配置类,dubbo的相关配置都是该对象在维护。
proxy，服务代理层，服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory。
registry，注册中心层，封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory, Registry, RegistryService。
cluster，路由层，封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster, Directory, Router, LoadBalance。
monitor，监控层，RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory, Monitor, MonitorService。
protocol，远程调用层，封将RPC调用，以Invocation, Result为中心，扩展接口为Protocol, Invoker, Exporter。
exchange，信息交换层，封装请求响应模式，同步转异步，以Request, Response为中心，扩展接口为Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer。
transport，网络传输层，抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel, Transporter, Client, Server, Codec。
serialize，数据序列化层，可复用的一些工具，扩展接口为Serialization, ObjectInput, ObjectOutput, ThreadPool。
2、层次关系
在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层只负责单向消息传输，是对Mina,Netty,Grizzly的抽象，它也可以扩展UDP传输，而Exchange层是在传输层之上封装了Request-Response语义。
Registry和Monitor实际上不算一层，而是一个独立的节点，只是为了全局概览，用层的方式画在一起。
3、模块简介
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容器去加载服务。
4、依赖关系
提供方和消费方都是通过注册中心来交互，提供方依赖注册中心来暴露需提供的接口，服务方通过注册中心来调用接口。提供方和注册方与注册中心之间是无状态联系的，也就是说它俩不论说挂掉了不会影响另一方的使用。这也是大部分生产/消费框架设计最科学的地方，双方进行无状态交互，互不干涉互不影响，软件设计的观察者模式也与此类似。
5、调用链
6、服务提供方提供服务的时序图
7、服务消费方消费服务时序图
三、实现细节
1、服务的解析
基于dubbo.jar内的META-INF/spring.handlers配置，Spring在遇到dubbo名称空间时，会回调DubboNamespaceHandler。所有dubbo的标签，都统一用DubboBeanDefinitionParser进行解析，基于一对一属性映射，将XML标签解析为Bean对象。在ServiceConfig.export()或ReferenceConfig.get()初始化时，将Bean对象转换URL格式，所有Bean属性转成URL的参数。然后将URL传给Protocol扩展点，基于扩展点的Adaptive机制，根据URL的协议头，进行不同协议的服务暴露或引用。
2、提供者暴露服务
(1) 只暴露服务端口：
在没有注册中心，直接暴露提供者的情况下，即：
<dubbo:service regisrty="N/A" /> or <dubbo:registry address="N/A" />
ServiceConfig解析出的URL的格式为：基于扩展点的Adaptive机制，通过URL的"dubbo://"协议头识别，直接调用DubboProtocol的export()方法，打开服务端口。
dubbo://service-host/com.foo.FooService?version=1.0.0
(2) 向注册中心暴露服务：
在有注册中心，需要注册提供者地址的情况下，即：
<dubbo:registry address="zookeeper://10.20.153.10:2181" />
ServiceConfig解析出的URL的格式为：
registry://registry-host/com.alibaba.dubbo.registry.RegistryService?export=URL.encode("dubbo://service-host/com.foo.FooService?version=1.0.0")
基于扩展点的Adaptive机制，通过URL的"registry://"协议头识别，就会调用RegistryProtocol的export()方法，将export参数中的提供者URL，先注册到注册中心，再重新传给Protocol扩展点进行暴露：基于扩展点的Adaptive机制，通过提供者URL的"dubbo://"协议头识别，就会调用DubboProtocol的export()方法，打开服务端口。
dubbo://service-host/com.foo.FooService?version=1.0.0
3、消费方消费服务
(1) 直连引用服务：
在没有注册中心，直连提供者的情况下，即：
<dubbo:reference url="dubbo://service-host/com.foo.FooService?version=1.0.0" />
ReferenceConfig解析出的URL的格式为：基于扩展点的Adaptive机制，通过URL的"dubbo://"协议头识别，直接调用DubboProtocol的refer()方法，返回提供者引用。
dubbo://service-host/com.foo.FooService?version=1.0.0
(2) 从注册中心发现引用服务：
在有注册中心，通过注册中心发现提供者地址的情况下，即：
<dubbo:registry address="zookeeper://10.20.153.10:2181" />
ReferenceConfig解析出的URL的格式为：
registry://registry-host/com.alibaba.dubbo.registry.RegistryService?refer=URL.encode("consumer://consumer-host/com.foo.FooService?version=1.0.0")
基于扩展点的Adaptive机制，通过URL的"registry://"协议头识别，就会调用RegistryProtocol的refer()方法，基于refer参数中的条件，查询提供者URL，如：基于扩展点的Adaptive机制，通过提供者URL的"dubbo://"协议头识别，就会调用DubboProtocol的refer()方法，得到提供者引用。
dubbo://service-host/com.foo.FooService?version=1.0.0
然后RegistryProtocol将多个提供者引用，通过Cluster扩展点，伪装成单个提供者引用返回。
4、服务者暴露服务过程图解
可以看到ServiceConfig类拿到对外提供服务的实际类ref,然后通过代理工厂类ProxyFactory类的getInvoker方法使用ref生成一个抽象代理对象AbstractProxyInvoker实例，到这一步就完成具体服务到Invoker的转化。接下来就是Invoker转换到Exporter的过程。
4、消费者消费服务过程图解
可以看到引用配置对象ReferenceConfig的init方法调用Protocol的refer方法生成Invoker实例(如上图中的红色部分)，这是服务消费的关键。接下来把Invoker转换为客户端需要的接口。
本文转自lzwxx 51CTO博客，原文链接:http://blog.51cto.com/13064681/1944360
