Dubbo基础（一）
一、引言
在目前分布式领域，Dubbo算是比较常用的框架了，一般都是用Dubbo+ZK组合搭建一个分布式应用的。虽然个人使用上更偏向于Spring Cloud些，毕竟自带全家桶，整合各种组件都很方便。不过Dubbo既然作为国内多数公司在使用的分布式框架，也自然有他的可取之处。（注：本篇的内容都是根据Dubbo官网介绍的版本，即dubbo-2.6.4来学习的）
二、架构###
上图是取自Dubbo官网的架构图。可以看到，Dubbo框架主要由四个节点组成：
- 注册中心 Registry
- 服务提供者 Provider（启动需要基于容器Container来启动）
- 服务消费者 Consummer
- 监控中心 Monitor
下面将分别介绍上述的几个节点：
1、注册中心（Registry）
注册中心，顾名思义，就是用来管理注册信息的中心机构。从Dubbo的架构图可看出，首先是提供者向注册中心注册提供者的信息，然后是接受消费者的订阅请求，最后把含有提供者信息的列表发通知给消费者，后续就不参与提供者与消费之间的交互了，即不转发请求，只负责服务的发现与注册，给消费者提供一个提供者的目录。
所以可以知道注册中心的主要功能就两个：服务发现、服务注册。
先说服务发现，服务发现是基于SPI（Service Provider Interface）机制。这个机制其实就是把接口的实现类（全限定名）配置在文件里，在服务加载器读取配置文件时，这个实现类就会被加载到。这样一来，就可以动态地给接口替换实现类，只要服务一注册，新的实现类就会加载进来。
不过Dubbo的SPI机制与JAVA的SPI机制（JAVA的SPI机制应用很广，想常见的JDBC、JDNI就是类SPI设计的）不同，Dubbo是重新实现了一套功能更强的SPI机制（JAVA的是全限定名列表，要获取只能通过遍历把所有的实现类都加在一遍，这点比较不好，Dubbo则改成用K,V形式的列表，要获取时就不用去遍历加载其他类了），下面将根据Dubbo官网的文档来理解下Dubbo SPI。
关于Dubbo SPI的使用，我们直接拿官网的例子来讲。
-
定义要扩展的接口，并在上面加上@SPI注解
@SPI("Robot") public interface Robot { void sayHello(); } -
在META-INF/dubbo路径下加配置文件，配置的内容如下（里面写的两个类为接口类的实现类，配置形式key=value【全限定名】）：
optimusPrime = org.apache.spi.OptimusPrime bumblebee = org.apache.spi.Bumblebee -
下方代码为测试示例：
public class DubboSPITest { @Test public void sayHello() throws Exception { //获取一个Robot类的ExtensionLoader实例 ExtensionLoader<Robot> extensionLoader = ExtensionLoader.getExtensionLoader(Robot.class); //得到扩展类的对象 Robot optimusPrime = extensionLoader.getExtension("optimusPrime"); //调用扩展类的方法 optimusPrime.sayHello(); Robot bumblebee = extensionLoader.getExtension("bumblebee"); bumblebee.sayHello(); } }
根据官网描述，Dubbo SPI把相关的逻辑封装在了ExtensionLoader类中，我们要加载实现类时就要用到这个东东，它是扩展点的载入器，用来载入Dubbo一些可配置的组件，比如说负载均衡策略、协议、集群、动态代理方式、拦截器、注册中心类型之类的。ExtensionLoader类使用的大概流程就是：
- 用ExtensionLoader类getExtensionLoader方法获取一个ExtensionLoader的实例。值得注意的是，getExtensionLoader方法是从缓存中取得扩展类对应的ExtensionLoader对象。若是缓存没有命中，就新建一个ExtensionLoader实例；
- 再通过getExtension得到扩展类的对象；
1.1获取所有的扩展类
大概了解了ExtensionLoader的工作过程，下面看下源码，来理解下它的工作原理。先从getExtensionLoader方法入手：
public T getExtension(String name) {
if (name == null || name.length() == 0)
throw new IllegalArgumentException("Extension name == null");
if ("true".equals(name)) {
// 获取默认的拓展实现类
return getDefaultExtension();
}
// Holder，顾名思义，用于持有目标对象
Holder<Object> holder = cachedInstances.get(name);
if (holder == null) {
cachedInstances.putIfAbsent(name, new Holder<Object>());
holder = cachedInstances.get(name);
}
Object instance = holder.get，可以防止();
// 双重检查
if (instance == null) {
synchronized (holder) {
instance = holder.get();
if (instance == null) {
// 创建拓展实例
instance = createExtension(name);
// 设置实例到 holder 中
holder.set(instance);
}
}
}
return (T) instance;
}
这个方法的操作简而言之就是，看下我们要获取的这个name能不能命中缓存，能从缓存里取东西直接返回，不行的话就通过createExtension这个方法来创建一个我们需要名称为name的扩展对象。值得一体的是，这块的操作使用了双检锁（双重检查锁，简称双检锁，可以防止在多线程下，instance被实例化多次，并被不同对象持有的情况）
接下来看下用来创建拓展对象的createExtension方法：
private T createExtension(String name) {
// 从配置文件中加载所有的拓展类，可得到“配置项名称”到“配置类”的映射关系表
Class<?> clazz = getExtensionClasses().get(name);
if (clazz == null) {
throw findException(name);
}
try {
T instance = (T) EXTENSION_INSTANCES.get(clazz);
if (instance == null) {
// 通过反射创建实例
EXTENSION_INSTANCES.putIfAbsent(clazz, clazz.newInstance());
instance = (T) EXTENSION_INSTANCES.get(clazz);
}
// 向实例中注入依赖
injectExtension(instance);
Set<Class<?>> wrapperClasses = cachedWrapperClasses;
if (wrapperClasses != null && !wrapperClasses.isEmpty()) {
// 循环创建 Wrapper 实例
for (Class<?> wrapperClass : wrapperClasses) {
// 将当前 instance 作为参数传给 Wrapper 的构造方法，并通过反射创建 Wrapper 实例。
// 然后向 Wrapper 实例中注入依赖，最后将 Wrapper 实例再次赋值给 instance 变量
instance = injectExtension(
(T) wrapperClass.getConstructor(type).newInstance(instance));
}
}
return instance;
} catch (Throwable t) {
throw new IllegalStateException("...");
}
}
可以看出这个方法大概做了如下操作：
- 调getExtensionClasses方法获取所有的拓展类，然后再get(name)获取对应的拓展类；
- 接下来通过反射来创建对应的实例；
- 通过injectExtension方法向实例注入依赖；
- 官网的说法是将实例包裹在相应的Wrapper对象中（其实就是源码里的：循环、创建Wrapper实例、向Wrapper实例注入依赖），最后，再把Wrapper实例赋值给instance变量。
接着再来看下createExtension方法里用的getExtensionClasses方法是做了啥操作来获取所有拓展类的吧：
private Map<String, Class<?>> getExtensionClasses() {
// 从缓存中获取已加载的拓展类
Map<String, Class<?>> classes = cachedClasses.get();
// 双重检查
if (classes == null) {
synchronized (cachedClasses) {
classes = cachedClasses.get();
if (classes == null) {
// 加载拓展类
classes = loadExtensionClasses();
cachedClasses.set(classes);
}
}
}
return classes;
}
这个操作似曾相识啊，还是那个查缓存，还是那个双检锁，不过这次的操作没有传name参数了，直接查全部的。不过有小小的不同，若缓存没有命中，则加锁，然后再去看下能不能命中缓存。还不行，就调loadExtensionClasses方法来加载拓展类了。
接下来再看看loadExtensionClasses方法的源码吧：
private Map<String, Class<?>> loadExtensionClasses() {
// 获取 SPI 注解，这里的 type 变量是在调用 getExtensionLoader 方法时传入的
final SPI defaultAnnotation = type.getAnnotation(SPI.class);
if (defaultAnnotation != null) {
String value = defaultAnnotation.value();
if ((value = value.trim()).length() > 0) {
// 对 SPI 注解内容进行切分
String[] names = NAME_SEPARATOR.split(value);
// 检测 SPI 注解内容是否合法，不合法则抛出异常
if (names.length > 1) {
throw new IllegalStateException("more than 1 default extension name on extension...");
}
// 设置默认名称，参考 getDefaultExtension 方法
if (names.length == 1) {
cachedDefaultName = names[0];
}
}
}
Map<String, Class<?>> extensionClasses = new HashMap<String, Class<?>>();
// 加载指定文件夹下的配置文件
loadDirectory(extensionClasses, DUBBO_INTERNAL_DIRECTORY);
loadDirectory(extensionClasses, DUBBO_DIRECTORY);
loadDirectory(extensionClasses, SERVICES_DIRECTORY);
return extensionClasses;
}
源码的注释已经写得很详细了，总的来说就两步操作：1、获取SPI注解并作解析；2、通过loadDirectory方法来加载指定文件夹下的配置文件（这就是为啥配置文件要扔META-INF/dubbo下，因为方法里把路径都给指定死了）。解析SPI的过程没啥好说的，来看下loadDirectory方法做了啥吧：
private void loadDirectory(Map<String, Class<?>> extensionClasses, String dir) {
// fileName = 文件夹路径 + type 全限定名
String fileName = dir + type.getName();
try {
Enumeration<java.net.URL> urls;
ClassLoader classLoader = findClassLoader();
// 根据文件名加载所有的同名文件
if (classLoader != null) {
urls = classLoader.getResources(fileName);
} else {
urls = ClassLoader.getSystemResources(fileName);
}
if (urls != null) {
while (urls.hasMoreElements()) {
java.net.URL resourceURL = urls.nextElement();
// 加载资源
loadResource(extensionClasses, classLoader, resourceURL);
}
}
} catch (Throwable t) {
logger.error("...");
}
}
整个过程没啥好说的，就是拿全限定名和目录拼个路径，然后去加载这个资源文件。不过这里面的loadResource方法还需要再看下，毕竟这样看也看不出它咋加载的资源文件，所以，再往下深入，看下loadResource方法的源码：
private void loadResource(Map<String, Class<?>> extensionClasses,
ClassLoader classLoader, java.net.URL resourceURL) {
try {
BufferedReader reader = new BufferedReader(
new InputStreamReader(resourceURL.openStream(), "utf-8"));
try {
String line;
// 按行读取配置内容
while ((line = reader.readLine()) != null) {
// 定位 # 字符
final int ci = line.indexOf('#');
if (ci >= 0) {
// 截取 # 之前的字符串，# 之后的内容为注释，需要忽略
line = line.substring(0, ci);
}
line = line.trim();
if (line.length() > 0) {
try {
String name = null;
int i = line.indexOf('=');
if (i > 0) {
// 以等于号 = 为界，截取键与值
name = line.substring(0, i).trim();
line = line.substring(i + 1).trim();
}
if (line.length() > 0) {
// 加载类，并通过 loadClass 方法对类进行缓存
loadClass(extensionClasses, resourceURL,
Class.forName(line, true, classLoader), name);
}
} catch (Throwable t) {
IllegalStateException e = new IllegalStateException("Failed to load extension class...");
}
}
}
} finally {
reader.close();
}
} catch (Throwable t) {
logger.error("Exception when load extension class...");
}
}
这个方法前面的部分平平无奇，就是解析配置文件的一些常规操作，通过BufferedReader按行读取，然后注释那些该跳过的跳过，该解析的解析。往下继续看，当解析到需要加载的类的信息时，调了loadClass这个方法来加载类，并对类进行缓存。。。。。。这兜兜转转有点多啊，只能再看下loadClass的源码了：
private void loadClass(Map<String, Class<?>> extensionClasses, java.net.URL resourceURL,
Class<?> clazz, String name) throws NoSuchMethodException {
if (!type.isAssignableFrom(clazz)) {
throw new IllegalStateException("...");
}
// 检测目标类上是否有 Adaptive 注解
if (clazz.isAnnotationPresent(Adaptive.class)) {
if (cachedAdaptiveClass == null) {
// 设置 cachedAdaptiveClass缓存
cachedAdaptiveClass = clazz;
} else if (!cachedAdaptiveClass.equals(clazz)) {
throw new IllegalStateException("...");
}
// 检测 clazz 是否是 Wrapper 类型
} else if (isWrapperClass(clazz)) {
Set<Class<?>> wrappers = cachedWrapperClasses;
if (wrappers == null) {
cachedWrapperClasses = new ConcurrentHashSet<Class<?>>();
wrappers = cachedWrapperClasses;
}
// 存储 clazz 到 cachedWrapperClasses 缓存中
wrappers.add(clazz);
// 程序进入此分支，表明 clazz 是一个普通的拓展类
} else {
// 检测 clazz 是否有默认的构造方法，如果没有，则抛出异常
clazz.getConstructor();
if (name == null || name.length() == 0) {
// 如果 name 为空，则尝试从 Extension 注解中获取 name，或使用小写的类名作为 name
name = findAnnotationName(clazz);
if (name.length() == 0) {
throw new IllegalStateException("...");
}
}
// 切分 name
String[] names = NAME_SEPARATOR.split(name);
if (names != null && names.length > 0) {
Activate activate = clazz.getAnnotation(Activate.class);
if (activate != null) {
// 如果类上有 Activate 注解，则使用 names 数组的第一个元素作为键，
// 存储 name 到 Activate 注解对象的映射关系
cachedActivates.put(names[0], activate);
}
for (String n : names) {
if (!cachedNames.containsKey(clazz)) {
// 存储 Class 到名称的映射关系
cachedNames.put(clazz, n);
}
Class<?> c = extensionClasses.get(n);
if (c == null) {
// 存储名称到 Class 的映射关系
extensionClasses.put(n, clazz);
} else if (c != clazz) {
throw new IllegalStateException("...");
}
}
}
}
}
来康康这个类下的几个分支：1、首先，检测目标类上是否有Adaptive注解（这注解是啥。。。先跳过，后面再来看下）；2、若果没有那个注解，就检测clazz是不是Wrapper类型（这clazz是啥。。。看下上一级的是怎么传的——Class.forName(line, true, classLoader)，这东东其实就是返回一个Class对象的），是的话就存储 clazz 到 cachedWrapperClasses 缓存中；3、最后呢，检测 clazz 是否有默认的构造方法，如果没有，则抛出异常。总之，上面的这些操作其实就是缓存、缓存、缓存。这样子后面去操作就能命中缓存啦。
1.2Adaptive注解
接下来再来看下Adaptive注解吧，看源码里就是一堆注释，大概翻译下吧，大意是说：
决定注入哪个目标扩展。目标扩展名由URL中传递的参数决定，参数名由此方法给出。
如果在url中找不到指定的参数，则默认扩展名将用于依赖注入（在其接口的spi中指定）。
例如，给定一个字符串数组{“key1”，“key2”}，根据这个数组依次在url中查找参数key1，key2。假设key1找不到或者值为空，就尝试用key2作为拓展名称，如果key2也没有，就使用默认扩展名，否则就抛出illegalstateexception异常。
要是spi上又凑巧没给出默认扩展名（也就是@SPI的值没给出），那么将使用以下规则根据接口的类名生成一个名称：将类名从大写字符分为多个部分，并用*点“.”，例如：对于com.alibaba.dubbo.xxx.yyyinvokerwrapper，其默认名称为字符串数组：{“yyy.invoker.wrapper”}。此名称将用于从URL搜索参数。
上面就是我基于源码注释的大致理解，就是说这个东东主要是为了识别扩展类的，用注释里的原话说就是为extensionloader注入依赖项扩展实例提供有用信息。
感觉概念说了一堆，但还不是很清晰。看下它要怎么使用吧。引用某博主的一句话：@Adaptive可以用在类、接口和方法上。
@Adaptive代表dubbo的SPI的动态适应能力，如果@Adaptive注解在扩展点实现类上那个该扩展点就是一个包装真实扩展点实例的装饰类；如果注解在方法上那么扩展点的实例就是一个动态代理类，例如Protocol$Adaptive对象。感觉一下子清楚了好多。这个注解还有很多内容，暂时不再做扩展了，后面应该会再提到，这个涉及到Dubbo的自适应扩展机制。
1.3Dubbo IOC
接下来说下Dubbo SPI的一来注入方式，Dubbo IOC。Dubbo IOC是通过setter方法来注入以来的。大致的流程如下：
-
Dubbo通过反射取到实例所有方法；
-
遍历这个实例的方法列表，检测遍历到的方法是否具有setter方法特征（就是判断遍历到的是不是setter方法啦）；
-
如果有，就通过ObjectFactory获取依赖对象，然后通过反射调这个setter方法把历来设置到目标对象里。这个官网上也给出了例子，如下：
private T injectExtension(T instance) { try { if (objectFactory != null) { // 遍历目标类的所有方法 for (Method method : instance.getClass().getMethods()) { // 检测方法是否以 set 开头，且方法仅有一个参数，且方法访问级别为 public if (method.getName().startsWith("set") && method.getParameterTypes().length == 1 && Modifier.isPublic(method.getModifiers())) { // 获取 setter 方法参数类型 Class<?> pt = method.getParameterTypes()[0]; try { // 获取属性名，比如 setName 方法对应属性名 name String property = method.getName().length() > 3 ? method.getName().substring(3, 4).toLowerCase() + method.getName().substring(4) : ""; // 从 ObjectFactory 中获取依赖对象 Object object = objectFactory.getExtension(pt, property); if (object != null) { // 通过反射调用 setter 方法设置依赖 method.invoke(instance, object); } } catch (Exception e) { logger.error("fail to inject via method..."); } } } } } catch (Exception e) { logger.error(e.getMessage(), e); } return instance; }
上面的代码中objectFactory是一个AdaptiveExtensionFactory类型的变量，AdaptiveExtensionFactory 内部维护了一个 ExtensionFactory 列表，用于存储其他类型的 ExtensionFactory。
分别是 SpiExtensionFactory 和 SpringExtensionFactory。前者用于创建自适应的拓展，后者是用于从 Spring 的 IOC 容器中获取所需的拓展。（这段直接抄官网的）
总的来说呢，Dubbo虽然没有Spring Cloud那么多组件，但是因为有Dubbo SPI的存在，所以自己去实现一个也是可以的。关于Dubbo的基础这篇先了解到注册中心这里，后面继续研究其他部分。
参考内容来源：
https://http://dubbo.apache.org/zh-cn/docs/source_code_guide/dubbo-spi.html
http://dubbo.apache.org/zh-cn/docs/user/preface/architecture.html
扫一扫
203
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
