Dubbo解析

对Dubbo的总体理：服务发布+远程调用+容错机制

Dubbo过程图

一、服务发布

1、服务发布

Dubbo服务注册时序图

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 地址。

由上总结详细过程：

Dubbo服务注册详细过程

二、服务调用

Dubbo服务调用时序图

1、解析XML成为ReferenceConfig

2、选择对应的协议生成Invoker（可以执行远端调用）

3、通过动态代理生成客户端需要的接口

由上总结详细过程：

Dubbo服务调用过程

Invoker介绍：

由于 Invoker 是 Dubbo 领域模型中非常重要的一个概念，很多设计思路都是向它靠拢。这就使得 Invoker 渗透在整个实现代码里，对于刚开始接触 Dubbo 的人，确实容易给搞混了。 下面我们用一个精简的图来说明最重要的两种 Invoker：服务提供 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：一致性哈希

Dubbo容错设计图机制

四、扩展点

spi机制及双亲委派模型

双亲委派模式加载：

（1）优点
避免类库重复加载
安全，将核心类库与用户类库隔离，用户不能通过加载器替换核心类库，如String类。

（2）弊端
委托永远是子加载器去请求父加载器，是单向的，即上层的类加载器无法访问下层的类加载器所加载的类：
下层类对于上层类是不可见的
举个例子，假设「BootStrap」中提供了一个接口，及一个创建其实例的工厂方法，但是该接口的实现类在「System」中，那么就会出现工厂方法无法创建在「System」加载的类的实例的问题。拥有这样问题的组件有很多，比如JDBC、Xml parser等。

spi机制（友善的打破）：

当服务的提供者，提供了服务接口的一种实现之后，在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类。而当外部程序装配这个模块的时候，就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名，并装载实例化，完成模块的注入。

基于这样一个约定就能很好的找到服务接口的实现类，而不需要再代码里制定