Dubbo源码解析（二）
一、SPI机制原理
一、Java SPI 机制
SPI 全称Service Provider Interface，是Java 提供的一套用来被第三方实现或者扩展的API，它可以用来启用框架扩展和替换组件。
可以看到，SPI 的本质，其实是帮助程序，为某个特定的接口寻找它的实现类。而且哪些实现类的会加载，是个动态过程（不是提前预定好的）。有点类似IOC 的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。所以SPI 的核心思想就是解耦。
比较常见的例子：
1、数据库驱动加载接口实现类的加载、JDBC 加载不同类型数据库的驱动
2、日志门面接口实现类加载、SLF4J 加载不同提供商的日志实现类
3、Spring 中大量使用了SPI,比如：对servlet3.0 规范对ServletContainerInitializer 的实现、自动类型转换Type Conversion SPI(Converter SPI、Formatter SPI)等
一、使用介绍
要使用Java SPI，需要遵循如下约定：
1、当服务提供者提供了接口的一种具体实现后，在jar 包的META-INF/services 目录下创建一个以“接口全限定名”为命名的文件，内容为实现类的全限定名；
2、接口实现类所在的jar包放在主程序的classpath 中；
3、主程序通过java.util.ServiceLoder 动态装载实现模块，它通过扫描META-INF/services 目录下的配置文件找到实现类的全限定名，把类加载到JVM；
4、SPI 的实现类必须携带一个不带参数的构造方法；
先定义一个接口
再定义一系列它的实现
第二个实现
测试，程序运行时可以发现只加载了配置文件指定的实现类
二、核心功能类
需要指出的是，java 之所以能够顺利根据配置加载这个实现类，完全依赖于jdk 内的一个核心类：
ServiceLoader
二、Dubbo SPI 机制
在上一节中，可以看到，java spi 机制非常简单，就是读取指定的配置文件，将所有的类都加载到程序中。而这种机制，存在很多缺陷，比如：
1. 所有实现类无论是否使用，直接被加载，可能存在浪费
2. 不能够灵活控制什么时候什么时机，匹配什么实现，功能太弱。Dubbo 基于自己的需要，增强了这套SPI 机制，下面介绍Dubbo 中的SPI用法。
一、标签@SPI 用法
与Java SPI 实现类配置不同，Dubbo SPI 是通过键值对的方式进行配置，这样我们就可以按需加载指定的实现类。另外，需要在接口上标注@SPI 注解。表明此接口是SPI 的扩展点：
dubbo 的配置文件夹路径：
配置文件内容：
测试功能，指定加载某个实现
测试结果
二、标签@Activate 用法
Dubbo 的Spi 机制虽然对原生SPI 有了增强，但功能还远远不够。在工作中，某种时候存在这样的情形，需要同时启用某个接口的多个实现类，如Filter 过滤器。我们希望某种条件下启用这一批实现，而另一种情况下启用那一批实现，比如：希望的RPC 调用的消费端和服务端，分别启用不同的两批Filter，怎么处理呢？这时我们的条件激活注解@Activate，就派上了用场。
Activate 注解表示一个扩展是否被激活(使用),可以放在类定义和方法上，dubbo 用它在spi 扩展类定义上，表示这个扩展实现激活条件和时机。它有两个设置过滤条件的字段，group，value 都是字符数组。用来指定这个扩展类在什么条件下激活。
下面以com.alibaba.dubbo.rpc.filter 接口的几个扩展来说明。
@Activate(group = {Constants.PROVIDER, Constants.CONSUMER})
public class testActivate1 implements Filter {}
//表示如果过滤器使用方（通过group 指定）属于Constants.PROVIDER（服务提供方）或者Constants.CONSUMER（服务消费方）就激活使用这个过滤器。
//再看这个扩展
@Activate(group = Constants.PROVIDER, value = Constants.TOKEN_KEY)
public class testActivate2 implements Filter {}
//表示如果过滤器使用方（通过group 指定）属于Constants.PROVIDER（服务提供方）并且URL 中有参数Constants.TOKEN_KEY（token）时就激活使用这个过滤器
三、标签@Adaptive 用法
我们在前面演示了dubbo SPI 的使用，但是有一个问题，扩展点对应的实现类不能在程序运行时动态指定，就是extensionLoader.getExtension 方法写死了扩展点对应的实现类，不能在程序运行期间根据运行时参数进行动态改变。
而我们希望在程序使用时，对实现类进行懒加载，并且能根据运行时情况来决定，应该启用哪个扩展类。为了解决这个问题，dubbo 引入了Adaptive注解，也就是dubbo 的自适应机制。
我们的InfoService 的passInfo 方法参数内，有一个URL 的参数。URL 中附带了信息info.service=a，希望调用a 实现。a 实现的配置如下：
这初看起来非常矛盾，都已经在调用InfoService 对象了，怎么还有机会来选择调用哪个InfoService 对象呢？其实重点就在于，现在的InfoService 的调用对象adaptiveExtension ，在
当前，还只是个代理类，因此我们还有在代理内选择哪个目标实现的机会。
我们运行代码，会发现还真就是调用的A 实现类
使用重点，URL 的格式：
info.service=a 的参数名格式，是接口类InfoService 的驼峰大小写拆分
四、Dubbo SPI 的依赖注入
Dubbo SPI 的核心实现类为ExtensionLoader，此类的使用几乎遍及Dubbo 的整个源码体系。是大家以传统方式读源码的严重障碍。
ExtensionLoader 有三个重要的入口方法，分别与@SPI、@Activate、@Adaptive 注解对应。
getExtension 方法，对应加载所有的实现
getActivateExtension 方法，对应解析加载@Activate 注解对应的实现
getAdaptiveExtension 方法，对应解析加载@Adaptive 注解对应的实现
其中，@Adaptive 注解作的自适应功能，还涉及到了代理对象（而Dubbo 的代理机制，有两
种选择，jdk 动态代理和javassist 动态编译类）。我们将后后续篇章对此进行说明。
Dubbo 的SPI 机制，除上以上三种注解的用法外，还有一个重要的功能依赖注入。
对于spring 这个强大的IOC 工具，依赖注入大家一定都很了解！在Dubbo 自动生成SPI 的
扩展实例的时候也会发生依赖注入的场景，举一个具体的例子。
而其实现类中，引入了另一个扩展点接口对象infoService
此时，假如我们的OrderService 在加载时会发生什么呢？
可以看到，dubbo 自动生成了实例，并注入了依赖之中。
这是什么机理呢，看这个扩展接口：
这是dubbo 的一个扩展点工厂接口，只有一个方法，根据class 和name 查找实现。这个接口，是一个扩展点，接下来看看此接口的实现类
AdaptiveExtensionFactory 在内部持有了所有的factory 实现工厂，即后两个实现类。一个为SPI 工厂（依赖类是扩展接口时发挥作用，由于OrderServiceImpl中的infoService为扩展接口，所以会根据url适配infoService的实现类），一个为Spring 工厂（依赖的是springbean 时发挥作用）。于是，当我们需要为某个生成的对象注入依赖时，直接调用此对象即可。至此，整套DubboSPI 的IOC 功能圆满了。
二、Dubbo高级特性
一、启动时检查
Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止Spring 初始化完成，以便上线时能及早发现问题，默认check="true"。可以通过check="false"关闭检查，比如测试时，有些服务不关心，或者出现了循环依赖，必须有一方先启动。
1、关闭某个服务的启动时检查（没有提供者时报错）：
<dubbo:reference id="xxxService" check="false" interface="com.xxx.XxxService"/>
2、关闭所有服务的启动时检查（没有提供者时报错）：
<dubbo:consumer check="false" />
3、关闭注册中心启动时检查（注册订阅失败时报错）：
<dubbo:registry check="false" />
二、Dubbo超时重连
一、超时
Dubbo 消费端在发出请求后，需要有一个临界时间界限来判断服务端是否正常。这样消费端达到超时时间，那么Dubbo 会进行重试机制，不合理的重试在一些特殊的业务场景下可能会引发很多问题，需要合理设置接口超时时间。
Dubbo 超时和重试配置示例： <!-- 服务调用超时设置为5 秒,超时不重试-->
<dubbo:reference id="xxxService" interface="com.xxx.XxxService" retries="0" timeout="5000"/>
二、重连
Dubbo 在调用服务不成功时，默认会重试2 次。
Dubbo 的路由机制，会把超时的请求路由到其他机器上，而不是本机尝试，所以Dubbo 的重试机
制也能一定程度的保证服务的质量
三、集群容错
当消费端某次调用失败是一些环境偶然因素造成的（如网络抖动），dubbo还给予了容错补救机会。补救方式存在以下几种：
<dubbo:consumer cluster="failover” retries="2" forks="2" />
1、Failover ：当出现失败，重试其它服务器。retries=“2” 来设置重试次数(不含第一次)。幂等性操作使用，如读操作。
2、Failfast ：快速失败，只发起一次调用，失败立即报错非幂等性操作，如写操作。
3、Failsafe ：出现异常时，直接忽略无关紧要的旁支操作，如打日志。
4、Failback ：后台记录失败请求，定时重发。
5、Forking ：并行调用多个服务器，只要一个成功即返回，forks=“2” 来设置最大并行数。
四、负载均衡配置
在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为random 随机调用。可以自行扩展负载均衡策略。
<dubbo:consumer loadbalance="random"/>
1、Random ：按权重随机，根据weight 值（服务方设置）来随机
2、RoundRobin ：轮询
3、LeastActive ：最少活跃数（正在处理的数），慢的机器收到的请求少
五、结果缓存
dubbo 对方法调用的结果，还有缓存功能。在服务消费方和提供方都可以配置使用缓存。以消费方为例，可以配置全局缓存策略，这样所有服务引用都启动缓存
<dubbo:consumer cache="lru"/>
还可以仅对某个服务引用配置缓存策略
<dubbo:reference id="xxxService" interface="com.xxx.XxxService" cache="lru" >
还支持对单个方法启用缓存策略
<dubbo:reference id="xxxService" interface="com.xxx.XxxService">
<dubbo:method name="sayHello" cache="lru"> </dubbo:method></dubbo:reference>
服务方配置方法与消费端完全一样。
六、服务分组
比如，想在同一个注册中心中，分隔测试和开发环境（省一套注册服务）
<dubbo:consumer group ="dev"/>
<dubbo:provider group ="dev"/>
只要group 按开发组和测试组对应，同一个注册中心里的两套服务就互不干扰
七、多版本
服务端提供接口的实现升级时，可由dubbo 的版本号操作进行过渡。如果上线上测试新版本接口有
缺陷，为了不影响业务，要迅速切回原版本接口，最大程度减少损失。
服务方：
<!--版本1 接口-->
<dubbo:service interface="com.xxx.XxxServices" ref="xxxService1" version="1.0"/>
<!--版本2 接口-->
<dubbo:service interface="com.xxx.XxxServices" ref="xxxService2" version="2.0"/>
消费方：
<dubbo:reference id="xxxService1.0" interface="com.xxx.XxxServices" version="2.0"/>
八、只订阅/只注册
一、只订阅
场景：我们在本地开发的时候，不能把自己机器的未开发好的服务注册到开发环境，但是又需要使
用注册中心的其他服务，服务提供者配置禁止注册register="false"
<dubbo:registry protocol="zookeeper" register="false"/>
二、只注册
比如开发环境为了省机器，没有部署某个服务，如短信/邮件功能。但整个系统又必须要调用它。此时我们可以借用一下测试环境的此服务（不能影响测试环境原本的服务闭环）。将测试环境的短信/邮件服务也向开发环境注册一份，只注册（其依赖的服务必须还是测试环境的）
服务提供者配置禁止订阅subscribe="false"
<dubbo:registry protocol="zookeeper" subscribe="false"/>
九、异步调用
Dubbo 的异步调用是非阻塞的NIO 调用，一个线程可同时并发调用多个远程服务，每个服务的调用都是非阻塞的，线程立即返回。就是对java 中Futrue模式的扩展支持。
如上图，userThread 发出调用后，IOThread 会立即返回，并在RPC 上下文RpcContext 中设置Future。userThread 后续可以从RpcContext 中取得此Future，然后wait 这个Future 其它的事情都由IOThread 完成。总之，userThread 发出调用后IOThread 会立刻返回，而不是等调用在服务端
执行完代码、返回结果后返回。用户返回后可以去做点其它事情，比如调用另外一个服务，然后回头等待前一个调用完成。从上图可以看出，异步调用完全是Consumer 端的行为。
客户端配置：
<dubbo:reference id="xxxService" interface="com.xxx.XxxService">
<dubbo:method name="doSomething" async="true" /></dubbo:reference>
async=true 表示异步调用，可以看到配置发生在Consumer 端，能精确到方法
方法异步调用后，Consumer 端的代码写法：
// 此方法异步后不再有返回值，会立刻返回NULL
xxxService.doSomething(xxx);
// 立刻得到当前调用的Future 实例，当发生新的调用时这个东西将会被覆盖
Future<XXX> xxxFuture = RpcContext.getContext().getFuture();
// 等待调用完成，线程会进入Sleep 状态，当调用完成后被唤醒。
Foo foo = fooFuture.get();
配置是否等待IOThread 发送完Request 后再返回：
sent="true" ，等待请求发送出去后再返回，如果发送失败直接抛出异常。
sent="false" ，将调用交给IOThread 后立即返回。实际这个时候请求进入到IOThread 的队列，排除等着被发送出去。
<dubbo:method name="xxx" async="true" sent="true" />
如果对返回结果没有兴趣：
<dubbo:method name="xxx" async="true" return="false" />
十、事件通知
对于一次远程方法调用，有oninvoke、onreturn、onthrow 三个事件，分别为调用之前、返回之后，抛出异常三个事件。在Consumer 端，可以为三个事件指定事件处理方法。
首先，需要在SpringIOC 容器中，创建一个实现了回调接口的Bean，假设id=callback，方法中第一个参数是远程方法的返回值，其它是方法的参数。
interface Callback {
public void onreturn(Person msg, Integer id);
public void onthrow(Throwable ex, Integer id);
}
然后在Dubbo 中配置：
<dubbo:reference interface="com.xxx.XxxService" >
<dubbo:method name="doSomeThing" async="true" onreturn = "callback.onreturn" onthrow="callback.onthrow" />
</dubbo:reference>
异步回调模式：async=true onreturn="xxx"
同步回调模式：async=false onreturn="xxx"
异步无回调：async=true
同步无回调：async=false
十一、Provider 端应尽量配置的属性
Dubbo 的属性配置优先度上，遵循如下顺序：reference 属性》service 属性》Consumer 属性
其中reference 和Consumer 是消费端配置，service 是服务端配置。而对于服务调用的超时时间、重试次数等属性，服务的提供方比消费方更了解服务性能，因此我们应该在Provider 端尽量多配置Consumer 端属性让其漫游到消费端发挥作用。
Provider 端尽量多配置Consumer 端的属性，也让Provider 的实现者一开始就思考Provider 端的
服务特点和服务质量等问题。建议在Provider 端配置的Consumer 端属性有：
timeout：方法调用的超时时间
retries：失败重试次数
loadbalance：负载均衡算法，缺省是随机random。
actives：消费者端的最大并发调用限制，即当Consumer 对一个服务的并发调用到上限后，新调用会阻塞直到超时，在方法上配置dubbo:method 则针对该方法进行并发限制，在接口上配置dubbo:service，则针对该服务进行并发限制
<dubbo:service interface="com.xxx.xxxService" timeout="300" retries="2" loadbalance="random"
actives="0" >
<dubbo:method name="xxx" timeout="10000" retries="9" loadbalance="leastactive" actives="5" /><dubbo:service/>
建议在Provider 端配置的Provider 端属性有：
threads：服务线程池大小
executes：一个服务提供者并行执行请求上限，即当Provider 对一个服务的并发调用达到上限后，新调用会阻塞，此时Consumer 可能会超时。
在方法上配置dubbo:method 则针对该方法进行并发限制，在接口上配置dubbo:service，则针对该服务进行并发限制
<dubbo:protocol threads="200" />
<dubbo:service interface="com.xxx.xxxService" version="1.0.0" ref="xxxService" executes="200" >
<dubbo:method name="xxx" executes="50" /></dubbo:service>
十二、服务拆分最佳实现
1、分包
建议将服务接口、服务模型、服务异常等均放在API 包中，因为服务模型和异常也是API 的一部分，这样做也符合分包原则：重用发布等价原则(REP：复用的粒度即是发布的粒度，我们所重用的任何东西必须同时被发布和跟踪)，共同重用原则(CRP：如果你重用了一个组件中的一个类，那么就要重用包中的所有类)。
2、粒度
服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将面临分布式事务问题，Dubbo 暂未提供分布式事务支持。
不建议使用过于抽象的通用接口，如：Map query(Map)，这样的接口没有明确语义，会给后期维护带来不便。
3、版本
每个接口都应定义版本号，为后续不兼容升级提供可能，如：<dubbo:service interface="com.xxx.XxxService" version="1.0" />。
建议使用两位版本号，因为第三位版本号通常表示兼容升级，只有不兼容时才需要变更服务版本。
当不兼容时，先升级一半提供者为新版本，再将消费者全部升为新版本，然后将剩下的一半提供者升为新版本。
4、异常
建议使用异常汇报错误，而不是返回错误码，异常信息能携带更多信息，并且语义更友好。