Dubbo解析
对Dubbo的总体理：服务发布+远程调用+容错机制
一、服务发布
1、服务发布
1、解析XML成为SericeConfig
2、通过动态代理创建Invoker（此时的Invoker可以接受对应的参数执行相应的服务）
动态代理方式：默认使用javassist动态代理、也可以选择使用Jdk进行动态代理
3、选择对应的协议生成Exporter
默认的选择Dubbo协议、还可以选择rmi、http等等（hessian、webservice、thrift、memcached、redis、reset）。。
Duubo协议的简单介绍：NIO异步传输、Hessian序列化
BIO：同步阻塞式IO，服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理，如果这个连接不做任何事情会造成不必要的线程开销，当然可以通过线程池机制改善。
NIO：同步非阻塞式IO，服务器实现模式为一个请求一个线程，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有I/O请求时才启动一个线程进行处理。 （Netty的使用）
原生序列化（实现serializable接口）：保留对象的元数据（类、成员变量、继承信息）及对象数据。性能一般
Hessian序列化：自描述序列化类型、语言无关且比原生高效
Json序列化：抛弃类型信息，反序列化时需要提供类型
4、打开Socket服务器
5、注册到注册中心
zookeeper、redis等等。。
介绍zk:可以使用curator进行操作，dubbo节点注册发布最终为Url格式：dubbo://service-host/com.XXX.XXXService?version=1.0.0。
服务提供者启动时: 向 /dubbo/com.XXX.XXXService/providers 目录下写入自己的 URL 地址
服务消费者启动时: 订阅 /dubbo/com.XXX.XXXService/providers 目录下的提供者 URL 地址。并向 /dubbo/com.XXX.XXXService/consumers 目录下写入自己的 URL 地址
监控中心启动时: 订阅 /dubbo/com.foo.BarService 目录下的所有提供者和消费者 URL 地址。
由上总结详细过程：
二、服务调用
1、解析XML成为ReferenceConfig
2、选择对应的协议生成Invoker（可以执行远端调用）
3、通过动态代理生成客户端需要的接口
由上总结详细过程：
Invoker介绍：
由于 Invoker 是 Dubbo 领域模型中非常重要的一个概念，很多设计思路都是向它靠拢。这就使得 Invoker 渗透在整个实现代码里，对于刚开始接触 Dubbo 的人，确实容易给搞混了。 下面我们用一个精简的图来说明最重要的两种 Invoker：服务提供 Invoker 和服务消费 Invoker：
三、容错机制
首先介绍Directory：Directory 代表多个 Invoker，可以把它看成 List<Invoker> ,但与 List 不同的是，它的值可能是动态变化的，比如注册中心推送变更（RegistryDirectory维护一个key为method，value为Invoker的map）
Router ：禁用某些服务
cluster ：容错机制failover 重试，可以通过retries配置失败次数
failfast快速失败，只发起一次调用，失败立即报错
failsafe 失败安全，出现异常时直接忽略
failback，出现异常时定时重发，通常用于消息通知
forking，并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源
Broadcast，广播所有调用者，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。
LoadBlance
RandomLoadBalance:按权重设置随机概率
RoundRobin LoadBalance：轮循 存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
LeastActiveLoadBalance(最少活跃数)：使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。每个服务有一个活跃计数器,那么我们假如有A,B两个提供者.计数均为0.当A提供者开始处理请求,该计数+1,此时A还没处理完,当处理完后则计数-1.而B请求接收到请求处理得很快.B处理完后A还没处理完,所以此时A,B的计数为1,0.那么当有新的请求来的时候,就会选择B提供者(B的活跃计数比A小).这就是文档说的,使慢的提供者收到更少请求
ConsistentHashLoadBalance：一致性哈希
四、扩展点
spi机制及双亲委派模型
双亲委派模式加载：
（1）优点
避免类库重复加载
安全，将核心类库与用户类库隔离，用户不能通过加载器替换核心类库，如String类。
（2）弊端
委托永远是子加载器去请求父加载器，是单向的，即上层的类加载器无法访问下层的类加载器所加载的类：
下层类对于上层类是不可见的
举个例子，假设「BootStrap」中提供了一个接口，及一个创建其实例的工厂方法，但是该接口的实现类在「System」中，那么就会出现工厂方法无法创建在「System」加载的类的实例的问题。拥有这样问题的组件有很多，比如JDBC、Xml parser等。
spi机制（友善的打破）：
当服务的提供者，提供了服务接口的一种实现之后，在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类。而当外部程序装配这个?？榈氖焙?，就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名，并装载实例化，完成模块的注入。
基于这样一个约定就能很好的找到服务接口的实现类，而不需要再代码里制定
Spi对Dubbo扩展：调用链扩展等等
五、推荐
1、首推http://dubbo.apache.org/zh-cn/docs/user/quick-start.html duubo 中文文档，实现的流程图及各种配置扩展点
2、https://github.com/apache/incubator-dubbo dubbo源码，配合http://08643.cn/u/f7daa458b874 肥朝简书食用
