田小波
TA的个人档案
田小波个人页面-阿里云开发者社区
文章
39
问答
0
个人介绍
我的个人小站 http://www.tianxiaobo.com，不定期发文章，欢迎访问
擅长的技术
- Java
- 高分内容
- 最新动态
- 文章
- 问答
-
发表了文章 2018-11-21
Dubbo 源码分析 - 集群容错之 Router
1. 简介 上一篇文章分析了集群容错的第一部分 -- 服务目录 Directory。服务目录在刷新 Invoker 列表的过程中，会通过 Router 进行服务路由。上一篇文章关于服务路由相关逻辑没有细致分析，一笔带过了，本篇文章将对此进行详细的分析。首先，先来介绍一下服务目录是什么。服务路由包含一条路由规则，路由规则决定了服务消费者的调用目标，即规定了服务消费者可调用哪些服务提供者。Dubbo 目前提供了三种服务路由实现，分别为条件路由 ConditionRouter、脚本路由 ScriptRouter 和标签路由 TagRouter。其中条件路由是我们最常使用的，标签路由暂未在我所分析的 2.6.4 版本中提供，该实现会在 2.7.0 版本中提供。本篇文章将分析条件路由相关源码，脚本路由和标签路由这里就不分析了。下面进入正题。 2. 源码分析 条件路由规则有两个条件组成，分别用于对服务消费者和提供者进行匹配。比如有这样一条规则： host = 10.20.153.10 => host = 10.20.153.11 该条规则表示 IP 为 10.20.153.10 的服务消费者只可调用 IP 为 10.20.153.11 机器上的服务，不可调用其他机器上的服务。条件路由规则的格式如下： [服务消费者匹配条件] => [服务提供者匹配条件] 如果服务消费者匹配条件为空，表示不对服务消费者进行限制。如果服务提供者匹配条件为空，表示对某些服务消费者禁用服务。Dubbo 官方文档对条件路由进行了比较详细的介绍，大家可以参考下，这里就不过多说明了。 条件路由实现类 ConditionRouter 需要对用户配置的路由规则进行解析，得到一系列的条件。然后再根据这些条件对服务进行路由。本章将分两节进行说明，2.1节介绍表达式解析过程。2.2 节介绍服务路由的过程。接下来，我们先从表达式解析过程看起。 2.1 表达式解析 条件路由规则是一条字符串，对于 Dubbo 来说，它并不能直接理解字符串的意思，需要将其解析成内部格式才行。条件表达式的解析过程始于 ConditionRouter 的构造方法，下面一起看一下： public ConditionRouter(URL url) { this.url = url; // 获取 priority 和 force 配置 this.priority = url.getParameter(Constants.PRIORITY_KEY, 0); this.force = url.getParameter(Constants.FORCE_KEY, false); try { // 获取路由规则 String rule = url.getParameterAndDecoded(Constants.RULE_KEY); if (rule == null || rule.trim().length() == 0) { throw new IllegalArgumentException("Illegal route rule!"); } rule = rule.replace("consumer.", "").replace("provider.", ""); // 定位 => 分隔符 int i = rule.indexOf("=>"); // 分别获取服务消费者和提供者匹配规则 String whenRule = i < 0 ? null : rule.substring(0, i).trim(); String thenRule = i < 0 ? rule.trim() : rule.substring(i + 2).trim(); // 解析服务消费者匹配规则 Map<String, MatchPair> when = StringUtils.isBlank(whenRule) || "true".equals(whenRule) ? new HashMap<String, MatchPair>() : parseRule(whenRule); // 解析服务提供者匹配规则 Map<String, MatchPair> then = StringUtils.isBlank(thenRule) || "false".equals(thenRule) ? null : parseRule(thenRule); this.whenCondition = when; this.thenCondition = then; } catch (ParseException e) { throw new IllegalStateException(e.getMessage(), e); } } 如上，ConditionRouter 构造方法先是对路由规则做预处理，然后调用 parseRule 方法分别对服务提供者和消费者规则进行解析，最后将解析结果赋值给 whenCondition 和 thenCondition 成员变量。ConditionRouter 构造方法不是很复杂，这里就不多说了。下面我们把重点放在 parseRule 方法上，在详细介绍这个方法之前，我们先来看一个内部类。 private static final class MatchPair { final Set<String> matches = new HashSet<String>(); final Set<String> mismatches = new HashSet<String>(); } MatchPair 内部包含了两个 Set 型的成员变量，分别用于存放匹配和不匹配的条件。这个类两个成员变量会在 parseRule 方法中被用到，下面来看一下。 private static Map<String, MatchPair> parseRule(String rule) throws ParseException { // 定义条件映射集合 Map<String, MatchPair> condition = new HashMap<String, MatchPair>(); if (StringUtils.isBlank(rule)) { return condition; } MatchPair pair = null; Set<String> values = null; // 通过正则表达式匹配路由规则，ROUTE_PATTERN = ([&!=,]*)\s*([^&!=,\s]+) // 这个表达式看起来不是很好理解，第一个括号内的表达式用于匹配"&", "!", "=" 和 "," 等符号。 // 第二括号内的用于匹配英文字母，数字等字符。举个例子说明一下： // host = 2.2.2.2 & host != 1.1.1.1 & method = hello // 匹配结果如下： // 括号一 括号二 // 1. null host // 2. = 2.2.2.2 // 3. & host // 4. != 1.1.1.1 // 5. & method // 6. = hello final Matcher matcher = ROUTE_PATTERN.matcher(rule); while (matcher.find()) { // 获取括号一内的匹配结果 String separator = matcher.group(1); // 获取括号二内的匹配结果 String content = matcher.group(2); // 分隔符为空，表示匹配的是表达式的开始部分 if (separator == null || separator.length() == 0) { // 创建 MatchPair 对象 pair = new MatchPair(); // 存储 <匹配项, MatchPair> 键值对，比如 <host, MatchPair> condition.put(content, pair); } // 如果分隔符为 &，表明接下来也是一个条件 else if ("&".equals(separator)) { // 尝试从 condition 获取 MatchPair if (condition.get(content) == null) { // 未获取到 MatchPair，重新创建一个，并放入 condition 中 pair = new MatchPair(); condition.put(content, pair); } else { pair = condition.get(content); } } // 分隔符为 = else if ("=".equals(separator)) { if (pair == null) throw new ParseException("Illegal route rule ..."); values = pair.matches; // 将 content 存入到 MatchPair 的 matches 集合中 values.add(content); } // 分隔符为 != else if ("!=".equals(separator)) { if (pair == null) throw new ParseException("Illegal route rule ..."); values = pair.mismatches; // 将 content 存入到 MatchPair 的 mismatches 集合中 values.add(content); } // 分隔符为 , else if (",".equals(separator)) { if (values == null || values.isEmpty()) throw new ParseException("Illegal route rule ..."); // 将 content 存入到上一步获取到的 values 中，可能是 matches，也可能是 mismatches values.add(content); } else { throw new ParseException("Illegal route rule ..."); } } return condition; } 以上就是路由规则的解析逻辑，该逻辑由正则表达式 + 一个 while 循环 + 数个条件分支组成。下面使用一个示例对解析逻辑进行演绎。示例为 host = 2.2.2.2 & host != 1.1.1.1 & method = hello。正则解析结果如下： 括号一 括号二 1. null host 2. = 2.2.2.2 3. & host 4. != 1.1.1.1 5. & method 6. = hello 现在线程进入 while 循环： 第一次循环：分隔符 separator = null，content = "host"。此时创建 MatchPair 对象，并存入到 condition 中，condition = {"host": MatchPair@123} 第二次循环：分隔符 separator = "="，content = "2.2.2.2"，pair = MatchPair@123。此时将 2.2.2.2 放入到 MatchPair@123 对象的 matches 集合中。 第三次循环：分隔符 separator = "&"，content = "host"。host 已存在于 condition 中，因此 pair = MatchPair@123。 第四次循环：分隔符 separator = "!="，content = "1.1.1.1"，pair = MatchPair@123。此时将 1.1.1.1 放入到 MatchPair@123 对象的 mismatches 集合中。 第五次循环：分隔符 separator = "&"，content = "method"。condition.get("method") = null，因此新建一个 MatchPair 对象，并放入到 condition 中。此时 condition = {"host": MatchPair@123, "method": MatchPair@ 456} 第六次循环：分隔符 separator = "="，content = "2.2.2.2"，pair = MatchPair@456。此时将 hello 放入到 MatchPair@456 对象的 matches 集合中。 循环结束，此时 condition 的内容如下： { "host": { "matches": ["2.2.2.2"], "mismatches": ["1.1.1.1"] }, "method": { "matches": ["hello"], "mismatches": [] } } 路由规则的解析过程稍微有点复杂，大家可通过 ConditionRouter 的测试类对该逻辑进行测试。并且找一个表达式，对照上面的代码走一遍，加深理解。关于路由规则的解析过程就先到这，我们继续往下看。 2.2 服务路由 服务路由的入口方法是 ConditionRouter 的 router 方法，该方法定义在 Router 接口中。实现代码如下： public <T> List<Invoker<T>> route(List<Invoker<T>> invokers, URL url, Invocation invocation) throws RpcException { if (invokers == null || invokers.isEmpty()) { return invokers; } try { // 先对服务消费者条件进行匹配，如果匹配失败，表明当前消费者 url 不符合匹配规则， // 无需进行后续匹配，直接返回 Invoker 列表即可。比如下面的规则： // host = 10.20.153.10 => host = 10.0.0.10 // 这条路由规则希望 IP 为 10.20.153.10 的服务消费者调用 IP 为 10.0.0.10 机器上的服务。 // 当消费者 ip 为 10.20.153.11 时，matchWhen 返回 false，表明当前这条路由规则不适用于 // 当前的服务消费者，此时无需再进行后续匹配，直接返回即可。 if (!matchWhen(url, invocation)) { return invokers; } List<Invoker<T>> result = new ArrayList<Invoker<T>>(); // 服务提供者匹配条件未配置，表明对指定的服务消费者禁用服务，也就是服务消费者在黑名单中 if (thenCondition == null) { logger.warn("The current consumer in the service blacklist..."); return result; } // 这里可以简单的把 Invoker 理解为服务提供者，现在使用服务消费者匹配规则对 // Invoker 列表进行匹配 for (Invoker<T> invoker : invokers) { // 匹配成功，表明当前 Invoker 符合服务提供者匹配规则。 // 此时将 Invoker 添加到 result 列表中 if (matchThen(invoker.getUrl(), url)) { result.add(invoker); } } // 返回匹配结果，如果 result 为空列表，且 force = true，表示强制返回空列表， // 否则路由结果为空的路由规则将自动失效 if (!result.isEmpty()) { return result; } else if (force) { logger.warn("The route result is empty and force execute ..."); return result; } } catch (Throwable t) { logger.error("Failed to execute condition router rule: ..."); } // 原样返回，此时 force = false，表示该条路由规则失效 return invokers; } router 方法先是调用 matchWhen 对服务消费者进行匹配，如果匹配失败，直接返回 Invoker 列表。如果匹配成功，再对服务提供者进行匹配，匹配逻辑封装在了 matchThen 方法中。下面来看一下这两个方法的逻辑： boolean matchWhen(URL url, Invocation invocation) { // 服务消费者条件为 null 或空，均返回 true，比如： // => host != 172.22.3.91 // 表示所有的服务消费者都不得调用 IP 为 172.22.3.91 的机器上的服务 return whenCondition == null || whenCondition.isEmpty() || matchCondition(whenCondition, url, null, invocation); // 进行条件匹配 } private boolean matchThen(URL url, URL param) { // 服务提供者条件为 null 或空，表示禁用服务 return !(thenCondition == null || thenCondition.isEmpty()) && matchCondition(thenCondition, url, param, null); // 进行条件匹配 } 这两个方法长的有点像，不过逻辑上还是有差别的，大家注意看。这两个方法均调用了 matchCondition 方法，不过它们所传入的参数是不同的，这个需要特别注意。不然后面的逻辑不好弄懂。下面我们对这几个参数进行溯源。matchWhen 方法向 matchCondition 方法传入的参数为 [whenCondition, url, null, invocation]，第一个参数 whenCondition 为服务消费者匹配条件，这个前面分析过。第二个参数 url 源自 route 方法的参数列表，该参数由外部类调用 route 方法时传入。有代码为证，如下： private List<Invoker<T>> route(List<Invoker<T>> invokers, String method) { Invocation invocation = new RpcInvocation(method, new Class<?>[0], new Object[0]); List<Router> routers = getRouters(); if (routers != null) { for (Router router : routers) { if (router.getUrl() != null) { // 注意第二个参数 invokers = router.route(invokers, getConsumerUrl(), invocation); } } } return invokers; } 上面这段代码来自 RegistryDirectory，第二个参数表示的是服务消费者 url。matchCondition 的 invocation 参数也是从这里传入的。 接下来再来看看 matchThen 向 matchCondition 方法传入的参数 [thenCondition, url, param, null]。第一个参数不用解释了。第二个和第三个参数来自 matchThen 方法的参数列表，这两个参数分别为服务提供者 url 和服务消费者 url。搞清楚这些参数来源后，接下俩就可以分析 matchCondition 了。 private boolean matchCondition(Map<String, MatchPair> condition, URL url, URL param, Invocation invocation) { // 将服务提供者或消费者 url 转成 Map Map<String, String> sample = url.toMap(); boolean result = false; // 遍历 condition 列表 for (Map.Entry<String, MatchPair> matchPair : condition.entrySet()) { // 获取匹配项名称，比如 host、method 等 String key = matchPair.getKey(); String sampleValue; // 如果 invocation 不为空，且 key 为 mehtod(s)，表示进行方法匹配 if (invocation != null && (Constants.METHOD_KEY.equals(key) || Constants.METHODS_KEY.equals(key))) { // 从 invocation 获取调用方法名称 sampleValue = invocation.getMethodName(); } else { // 从服务提供者或消费者 url 中获取指定字段值，比如 host、application 等 sampleValue = sample.get(key); if (sampleValue == null) { // 尝试通过 default.xxx 获取相应的值 sampleValue = sample.get(Constants.DEFAULT_KEY_PREFIX + key); } } // -------------------- 分割线 -------------------- // if (sampleValue != null) { // 调用 MatchPair 的 isMatch 方法进行匹配 if (!matchPair.getValue().isMatch(sampleValue, param)) { // 只要有一个规则匹配失败，立即返回 false 结束方法逻辑 return false; } else { result = true; } } else { // sampleValue 为空，表明服务提供者或消费者 url 中不包含相关字段。此时如果 // MatchPair 的 matches 不为空，表示匹配失败，返回 false。比如我们有这样 // 一条匹配条件 loadbalance = random，假设 url 中并不包含 loadbalance 参数， // 此时 sampleValue = null。既然路由规则里限制了 loadbalance = random， // 但 sampleValue = null，明显不符合规则，因此返回 false if (!matchPair.getValue().matches.isEmpty()) { return false; } else { result = true; } } } return result; } 如上，matchCondition 方法看起来有点复杂，这里简单缕缕。分割线以上的代码实际上主要是用于获取 sampleValue 的值，分割线以下才是进行条件匹配。条件匹配调用的逻辑封装在 isMatch 中，代码如下： private boolean isMatch(String value, URL param) { // 情况一：matches 非空，mismatches 为空 if (!matches.isEmpty() && mismatches.isEmpty()) { // 遍历 matches 集合，检测入参 value 是否能被 matches 集合元素匹配到。 // 举个例子，如果 value = 10.20.153.11，matches = [10.20.153.*], // 此时 isMatchGlobPattern 方法返回 true for (String match : matches) { if (UrlUtils.isMatchGlobPattern(match, value, param)) { return true; } } // 如果所有匹配项都无法匹配到入参，则返回 false return false; } // 情况二：matches 为空，mismatches 非空 if (!mismatches.isEmpty() && matches.isEmpty()) { for (String mismatch : mismatches) { // 只要入参被 mismatches 集合中的任意一个元素匹配到，就返回 false if (UrlUtils.isMatchGlobPattern(mismatch, value, param)) { return false; } } // mismatches 集合中所有元素都无法匹配到入参，此时返回 true return true; } // 情况三：matches 非空，mismatches 非空 if (!matches.isEmpty() && !mismatches.isEmpty()) { // matches 和 mismatches 均为非空，此时优先使用 mismatches 集合元素对入参进行匹配。 // 只要 mismatches 集合中任意一个元素与入参匹配成功，就立即返回 false，结束方法逻辑 for (String mismatch : mismatches) { if (UrlUtils.isMatchGlobPattern(mismatch, value, param)) { return false; } } // mismatches 集合元素无法匹配到入参，此时使用 matches 继续匹配 for (String match : matches) { // 只要 matches 集合中任意一个元素与入参匹配成功，就立即返回 true if (UrlUtils.isMatchGlobPattern(match, value, param)) { return true; } } return false; } // 情况四：matches 和 mismatches 均为空，此时返回 false return false; } isMatch 方法逻辑比较清晰，由三个条件分支组成，用于处理四种情况。这里对四种情况下的匹配逻辑进行简单的总结，如下： 条件 动作 情况一 matches 非空，mismatches 为空 遍历 matches 集合元素，并与入参进行匹配。只要有一个元素成功匹配入参，即可返回 true。若全部失配，则返回 false。 情况二 matches 为空，mismatches 非空 遍历 mismatches 集合元素，并与入参进行匹配。只要有一个元素成功匹配入参，立即 false。若全部失配，则返回 true。 情况三 matches 非空，mismatches 非空 优先使用 mismatches 集合元素对入参进行匹配，只要任一元素与入参匹配成功，就立即返回 false，结束方法逻辑。否则再使用 matches 中的集合元素进行匹配，只要有任意一个元素匹配成功，即可返回 true。若全部失配，则返回 false 情况四 matches 为空，mismatches 为空 直接返回 false isMatch 方法逻辑不是很难理解，大家自己再看看。下面继续分析 isMatchGlobPattern 方法。 public static boolean isMatchGlobPattern(String pattern, String value, URL param) { if (param != null && pattern.startsWith("$")) { // 引用服务消费者参数，param 参数为服务消费者 url pattern = param.getRawParameter(pattern.substring(1)); } // 调用重载方法继续比较 return isMatchGlobPattern(pattern, value); } public static boolean isMatchGlobPattern(String pattern, String value) { // 对 * 通配符提供支持 if ("*".equals(pattern)) // 匹配规则为通配符 *，直接返回 true 即可 return true; if ((pattern == null || pattern.length() == 0) && (value == null || value.length() == 0)) // pattern 和 value 均为空，此时可认为两者相等，返回 true return true; if ((pattern == null || pattern.length() == 0) || (value == null || value.length() == 0)) // pattern 和 value 其中有一个为空，两者不相等，返回 false return false; // 查找 * 通配符位置 int i = pattern.lastIndexOf('*'); if (i == -1) { // 匹配规则中不包含通配符，此时直接比较 value 和 pattern 是否相等即可，并返回比较结果 return value.equals(pattern); } // 通配符 "*" 在匹配规则尾部，比如 10.0.21.* else if (i == pattern.length() - 1) { // 检测 value 是否以不含通配符的匹配规则开头，并返回结果。比如: // pattern = 10.0.21.*，value = 10.0.21.12，此时返回 true return value.startsWith(pattern.substring(0, i)); } // 通配符 "*" 在匹配规则头部 else if (i == 0) { // 检测 value 是否以不含通配符的匹配规则结尾，并返回结果 return value.endsWith(pattern.substring(i + 1)); } // 通配符 "*" 在匹配规则中间位置 else { // 通过通配符将 pattern 分成两半，得到 prefix 和 suffix String prefix = pattern.substring(0, i); String suffix = pattern.substring(i + 1); // 检测 value 是否以 prefix 变量开头，且以 suffix 变量结尾，并返回结果 return value.startsWith(prefix) && value.endsWith(suffix); } } 以上就是 isMatchGlobPattern 两个重载方法的全部逻辑，这两个方法分别对普通的匹配，以及”引用消费者参数“和通配符匹配做了支持。这两个方法的逻辑并不是很复杂，而且我也在代码上进行了比较详细的注释，大家自己看看吧，就不多说了。 3. 总结 本篇文章对条件路由的表达式解析和服务路由过程进行了较为细致的分析。总的来说，条件路由的代码还是有一些复杂的，需要耐下心来看。在阅读条件路由代码的过程中，要多调试。一般的框架都会有单元测试，Dubbo 也不例外，因此大家可以直接通过 ConditionRouterTest 对条件路由进行调试，无需自己手写测试用例。 好了，关于条件路由就先分析到这，谢谢阅读。 附录：Dubbo 源码分析系列文章 时间 文章 2018-10-01 Dubbo 源码分析 - SPI 机制 2018-10-13 Dubbo 源码分析 - 自适应拓展原理 2018-10-31 Dubbo 源码分析 - 服务导出 2018-11-12 Dubbo 源码分析 - 服务引用 2018-11-17 Dubbo 源码分析 - 集群容错之 Directory 2018-11-20 Dubbo 源码分析 - 集群容错之 Router 本文在知识共享许可协议 4.0 下发布，转载需在明显位置处注明出处作者：田小波本文同步发布在我的个人博客：http://www.tianxiaobo.com 本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。
-
发表了文章 2018-11-19
Dubbo 源码分析 - 集群容错之 Directory
1. 简介 前面文章分析了服务的导出与引用过程，从本篇文章开始，我将开始分析 Dubbo 集群容错方面的源码。这部分源码包含四个部分，分别是服务目录 Directory、服务路由 Router、集群 Cluster 和负载均衡 LoadBalance。这几个部分的源码逻辑比较独立，我会分四篇文章进行分析。本篇文章作为集群容错的开篇文章，将和大家一起分析服务目录相关的源码。在进行深入分析之前，我们先来了解一下服务目录是什么。服务目录中存储了一些和服务提供者有关的信息，通过服务目录，服务消费者可获取到服务提供者的信息，比如 ip、端口、服务协议等。通过这些信息，服务消费者就可通过 Netty 等客户端进行远程调用。在一个服务集群中，服务提供者数量并不是一成不变的，如果集群中新增了一台机器，相应地在服务目录中就要新增一条服务提供者记录。或者，如果服务提供者的配置修改了，服务目录中的记录也要做相应的更新。如果这样说，服务目录和注册中心的功能不就雷同了吗。确实如此，这里这么说是为了方便大家理解。实际上服务目录在获取注册中心的服务配置信息后，会为每条配置信息生成一个 Invoker 对象，并把这个 Invoker 对象存储起来，这个 Invoker 才是服务目录最终持有的对象。Invoker 有什么用呢？看名字就知道了，这是一个具有远程调用功能的对象。讲到这大家应该知道了什么是服务目录了，它可以看做是 Invoker 集合，且这个集合中的元素会随注册中心的变化而进行动态调整。 好了，关于服务目录这里就先介绍这些，大家先有个大致印象即可。接下来我们通过继承体系图来了解一下服务目录的家族成员都有哪些。 2. 继承体系 服务目录目前内置的实现有两个，分别为 StaticDirectory 和 RegistryDirectory，它们均是 AbstractDirectory 的子类。AbstractDirectory 实现了 Directory 接口，这个接口包含了一个重要的方法定义，即 list(Invocation)，用于列举 Invoker。下面我们来看一下他们的继承体系图。 如上，Directory 继承自 Node 接口，Node 这个接口继承者比较多，像 Registry、Monitor、Invoker 等继承了这个接口。这个接口包含了一个获取配置信息的方法 getUrl，实现该接口的类可以向外提供配置信息。另外，大家注意看 RegistryDirectory 实现了 NotifyListener 接口，当注册中心节点信息发生变化后，RegistryDirectory 可以通过此接口方法得到变更信息，并根据变更信息动态调整内部 Invoker 列表。 现在大家对服务目录的继承体系应该比较清楚了，下面我们深入到源码中，探索服务目录是如何实现的。 3. 源码分析 本章我将分析 AbstractDirectory 和它两个子类的源码。这里之所以要分析 AbstractDirectory，而不是直接分析子类是有一定原因的。AbstractDirectory 封装了 Invoker 列举流程，具体的列举逻辑则由子类实现，这是典型的模板模式。所以，接下来我们先来看一下 AbstractDirectory 的源码。 public List<Invoker<T>> list(Invocation invocation) throws RpcException { if (destroyed) { throw new RpcException("Directory already destroyed..."); } // 调用 doList 方法列举 Invoker，这里的 doList 是模板方法，由子类实现 List<Invoker<T>> invokers = doList(invocation); // 获取路由器 List<Router> localRouters = this.routers; if (localRouters != null && !localRouters.isEmpty()) { for (Router router : localRouters) { try { // 获取 runtime 参数，并根据参数决定是否进行路由 if (router.getUrl() == null || router.getUrl().getParameter(Constants.RUNTIME_KEY, false)) { // 进行服务路由 invokers = router.route(invokers, getConsumerUrl(), invocation); } } catch (Throwable t) { logger.error("Failed to execute router: ..."); } } } return invokers; } // 模板方法，由子类实现 protected abstract List<Invoker<T>> doList(Invocation invocation) throws RpcException; 上面就是 AbstractDirectory 的 list 方法源码，这个方法封装了 Invoker 的列举过程。如下： 调用 doList 获取 Invoker 列表 根据 Router 的 getUrl 返回值为空与否，以及 runtime 参数决定是否进行服务路由 以上步骤中，doList 是模板方法，需由子类实现。Router 的 runtime 参数这里简单说明一下，这个参数决定了是否在每次调用服务时都执行路由规则。如果 runtime 为 true，那么每次调用服务前，都需要进行服务路由。这个对性能造成影响，慎重配置。关于该参数更详细的说明，请参考官方文档。 介绍完 AbstractDirectory，接下来我们开始分析子类的源码。 3.1 StaticDirectory StaticDirectory 即静态服务目录，顾名思义，它内部存放的 Invoker 是不会变动的。所以，理论上它和不可变 List 的功能很相似。下面我们来看一下这个类的实现。 public class StaticDirectory<T> extends AbstractDirectory<T> { // Invoker 列表 private final List<Invoker<T>> invokers; // 省略构造方法 @Override public Class<T> getInterface() { // 获取接口类 return invokers.get(0).getInterface(); } // 检测服务目录是否可用 @Override public boolean isAvailable() { if (isDestroyed()) { return false; } for (Invoker<T> invoker : invokers) { if (invoker.isAvailable()) { // 只要有一个 Invoker 是可用的，就任务当前目录是可用的 return true; } } return false; } @Override public void destroy() { if (isDestroyed()) { return; } // 调用父类销毁逻辑 super.destroy(); // 遍历 Invoker 列表，并执行相应的销毁逻辑 for (Invoker<T> invoker : invokers) { invoker.destroy(); } invokers.clear(); } @Override protected List<Invoker<T>> doList(Invocation invocation) throws RpcException { // 列举 Inovker，也就是直接返回 invokers 成员变量 return invokers; } } 以上就是 StaticDirectory 的代码逻辑，很简单，大家都能看懂，我就不多说了。下面来看看 RegistryDirectory，这个类的逻辑比较复杂。 3.2 RegistryDirectory RegistryDirectory 是一种动态服务目录，它实现了 NotifyListener 接口。当注册中心服务配置发生变化后，RegistryDirectory 可收到与当前服务相关的变化。收到变更通知后，RegistryDirectory 可根据配置变更信息刷新 Invoker 列表。RegistryDirectory 中有几个比较重要的逻辑，第一是 Invoker 的列举逻辑，第二是接受服务配置变更的逻辑，第三是 Invoker 的刷新逻辑。接下来，我将按顺序对这三块逻辑。 3.2.1 列举 Invoker Invoker 列举逻辑封装在 doList 方法中，这是个模板方法，前面已经介绍过了。那这里就不过多啰嗦了，我们直入主题吧。 public List<Invoker<T>> doList(Invocation invocation) { if (forbidden) { // 服务提供者关闭或禁用了服务，此时抛出 No provider 异常 throw new RpcException(RpcException.FORBIDDEN_EXCEPTION, "No provider available from registry ...); } List<Invoker<T>> invokers = null; // 获取 Invoker 本地缓存 Map<String, List<Invoker<T>>> localMethodInvokerMap = this.methodInvokerMap; if (localMethodInvokerMap != null && localMethodInvokerMap.size() > 0) { // 获取方法名和参数列表 String methodName = RpcUtils.getMethodName(invocation); Object[] args = RpcUtils.getArguments(invocation); // 检测参数列表的第一个参数是否为 String 或 enum 类型 if (args != null && args.length > 0 && args[0] != null && (args[0] instanceof String || args[0].getClass().isEnum())) { // 通过 方法名 + 第一个参数名称 查询 Invoker 列表，具体的使用场景暂时没想到 invokers = localMethodInvokerMap.get(methodName + "." + args[0]); } if (invokers == null) { // 通过方法名获取 Invoker 列表 invokers = localMethodInvokerMap.get(methodName); } if (invokers == null) { // 通过星号 * 获取 Invoker 列表 invokers = localMethodInvokerMap.get(Constants.ANY_VALUE); } if (invokers == null) { Iterator<List<Invoker<T>>> iterator = localMethodInvokerMap.values().iterator(); if (iterator.hasNext()) { // 通过迭代器获取 Invoker 列表 invokers = iterator.next(); } } } // 返回 Invoker 列表 return invokers == null ? new ArrayList<Invoker<T>>(0) : invokers; } 以上代码进行多次尝试，以期从 localMethodInvokerMap 中获取到 Invoker 列表。一般情况下，普通的调用可通过方法名获取到对应的 Invoker 列表，泛化调用可通过 获取到 Invoker 列表。按现有的逻辑，不管什么情况下， 到 Invoker 列表的映射关系 <*, invokers> 总是存在的，也就意味着 localMethodInvokerMap.get(Constants.ANY_VALUE) 总是有值返回。除非这个值是 null，才会通过通过迭代器获取 Invoker 列表。至于什么情况下为空，我暂时未完全搞清楚，我猜测是被路由规则（用户可基于 Router 接口实现自定义路由器）处理后，可能会得到一个 null。目前仅是猜测，未做验证。 本节的逻辑主要是从 localMethodInvokerMap 中获取 Invoker，localMethodInvokerMap 源自 RegistryDirectory 类的成员变量 methodInvokerMap。doList 方法可以看做是对 methodInvokerMap 变量的读操作，至于对 methodInvokerMap 变量的写操作，这个将在后续进行分析。 3.2.2 接收服务变更通知 RegistryDirectory 是一个动态服务目录，它需要接受注册中心配置进行动态调整。因此 RegistryDirectory 实现了 NotifyListener 接口，通过这个接口获取注册中心变更通知。下面我们来看一下具体的逻辑。 public synchronized void notify(List<URL> urls) { // 定义三个集合，分别用于存放服务提供者 url，路由 url，配置器 url List<URL> invokerUrls = new ArrayList<URL>(); List<URL> routerUrls = new ArrayList<URL>(); List<URL> configuratorUrls = new ArrayList<URL>(); for (URL url : urls) { String protocol = url.getProtocol(); // 获取 category 参数 String category = url.getParameter(Constants.CATEGORY_KEY, Constants.DEFAULT_CATEGORY); // 根据 category 参数将 url 分别放到不同的列表中 if (Constants.ROUTERS_CATEGORY.equals(category) || Constants.ROUTE_PROTOCOL.equals(protocol)) { // 添加路由器 url routerUrls.add(url); } else if (Constants.CONFIGURATORS_CATEGORY.equals(category) || Constants.OVERRIDE_PROTOCOL.equals(protocol)) { // 添加配置器 url configuratorUrls.add(url); } else if (Constants.PROVIDERS_CATEGORY.equals(category)) { // 添加服务提供者 url invokerUrls.add(url); } else { // 忽略不支持的 category logger.warn("Unsupported category ..."); } } if (configuratorUrls != null && !configuratorUrls.isEmpty()) { // 将 url 转成 Configurator this.configurators = toConfigurators(configuratorUrls); } if (routerUrls != null && !routerUrls.isEmpty()) { // 将 url 转成 Router List<Router> routers = toRouters(routerUrls); if (routers != null) { setRouters(routers); } } List<Configurator> localConfigurators = this.configurators; this.overrideDirectoryUrl = directoryUrl; if (localConfigurators != null && !localConfigurators.isEmpty()) { for (Configurator configurator : localConfigurators) { // 配置 overrideDirectoryUrl this.overrideDirectoryUrl = configurator.configure(overrideDirectoryUrl); } } // 刷新 Invoker 列表 refreshInvoker(invokerUrls); } 如上，notify 方法首先是根据 url 的 category 参数对 url 进行分门别类存储，然后通过 toRouters 和 toConfigurators 将 url 列表转成 Router 和 Configurator 列表。最后调用 refreshInvoker 方法刷新 Invoker 列表。这里的 toRouters 和 toConfigurators 方法逻辑不复杂，大家自行分析。接下来，我们把重点放在 refreshInvoker 方法上。 3.2.3 刷新 Invoker 列表 接着上一节继续分析，refreshInvoker 方法是保证 RegistryDirectory 随注册中心变化而变化的关键所在。这一块逻辑比较多，接下来一一进行分析。 private void refreshInvoker(List<URL> invokerUrls) { // invokerUrls 仅有一个元素，且 url 协议头为 empty，此时表示禁用所有服务 if (invokerUrls != null && invokerUrls.size() == 1 && invokerUrls.get(0) != null && Constants.EMPTY_PROTOCOL.equals(invokerUrls.get(0).getProtocol())) { // 设置 forbidden 为 true this.forbidden = true; this.methodInvokerMap = null; // 销毁所有 Invoker destroyAllInvokers(); } else { this.forbidden = false; Map<String, Invoker<T>> oldUrlInvokerMap = this.urlInvokerMap; if (invokerUrls.isEmpty() && this.cachedInvokerUrls != null) { // 添加缓存 url 到 invokerUrls 中 invokerUrls.addAll(this.cachedInvokerUrls); } else { this.cachedInvokerUrls = new HashSet<URL>(); // 缓存 invokerUrls this.cachedInvokerUrls.addAll(invokerUrls); } if (invokerUrls.isEmpty()) { return; } // 将 url 转成 Invoker Map<String, Invoker<T>> newUrlInvokerMap = toInvokers(invokerUrls); // 将 newUrlInvokerMap 转成方法名到 Invoker 列表的映射 Map<String, List<Invoker<T>>> newMethodInvokerMap = toMethodInvokers(newUrlInvokerMap); // 转换出错，直接打印异常，并返回 if (newUrlInvokerMap == null || newUrlInvokerMap.size() == 0) { logger.error(new IllegalStateException("urls to invokers error ...")); return; } // 合并多个组的 Invoker this.methodInvokerMap = multiGroup ? toMergeMethodInvokerMap(newMethodInvokerMap) : newMethodInvokerMap; // 保存为本地缓存 this.urlInvokerMap = newUrlInvokerMap; try { // 销毁无用 Invoker destroyUnusedInvokers(oldUrlInvokerMap, newUrlInvokerMap); } catch (Exception e) { logger.warn("destroyUnusedInvokers error. ", e); } } } 上面方法的代码不是很多，但是逻辑却不少。首先时根据入参 invokerUrls 的数量和协议头判断是否禁用所有的服务，如果禁用，则将 forbidden 设为 true，并销毁所有的 Invoker。若不禁用，则将 url 转成 Invoker，得到 <url, Invoker> 的映射关系。然后进一步进行转换，得到 <methodName, Invoker 列表>。之后进行多组 Invoker 合并操作，并将合并结果赋值给 methodInvokerMap。methodInvokerMap 变量在 doList 方法中会被用到，doList 会对该变量进行读操作，在这里是写操作。当新的 Invoker 列表生成后，还要一个重要的工作要做，就是销毁无用的 Invoker，避免服务消费者调用已下线的服务的服务。 接下里，我将对上面涉及到的调用进行分析。按照顺序，这里先来分析 url 到 Invoker 的转换过程。 private Map<String, Invoker<T>> toInvokers(List<URL> urls) { Map<String, Invoker<T>> newUrlInvokerMap = new HashMap<String, Invoker<T>>(); if (urls == null || urls.isEmpty()) { return newUrlInvokerMap; } Set<String> keys = new HashSet<String>(); // 获取服务消费端配置的协议 String queryProtocols = this.queryMap.get(Constants.PROTOCOL_KEY); for (URL providerUrl : urls) { if (queryProtocols != null && queryProtocols.length() > 0) { boolean accept = false; String[] acceptProtocols = queryProtocols.split(","); // 检测服务提供者协议是否被服务消费者所支持 for (String acceptProtocol : acceptProtocols) { if (providerUrl.getProtocol().equals(acceptProtocol)) { accept = true; break; } } if (!accept) { // 若服务消费者协议头不被消费者所支持，则忽略当前 providerUrl continue; } } // 忽略 empty 协议 if (Constants.EMPTY_PROTOCOL.equals(providerUrl.getProtocol())) { continue; } // 通过 SPI 检测服务端协议是否被消费端支持 if (!ExtensionLoader.getExtensionLoader(Protocol.class).hasExtension(providerUrl.getProtocol())) { logger.error(new IllegalStateException("Unsupported protocol...")); continue; } // 合并 url URL url = mergeUrl(providerUrl); String key = url.toFullString(); if (keys.contains(key)) { // 忽略重复 url continue; } keys.add(key); // 本地 Invoker 缓存列表 Map<String, Invoker<T>> localUrlInvokerMap = this.urlInvokerMap; Invoker<T> invoker = localUrlInvokerMap == null ? null : localUrlInvokerMap.get(key); // 缓存未命中 if (invoker == null) { try { boolean enabled = true; if (url.hasParameter(Constants.DISABLED_KEY)) { // 获取 disable 配置，并修改 enable 变量 enabled = !url.getParameter(Constants.DISABLED_KEY, false); } else { enabled = url.getParameter(Constants.ENABLED_KEY, true); } if (enabled) { // 调用 refer 获取 Invoker invoker = new InvokerDelegate<T>(protocol.refer(serviceType, url), url, providerUrl); } } catch (Throwable t) { logger.error("Failed to refer invoker for interface..."); } if (invoker != null) { // 缓存 Invoker 实例 newUrlInvokerMap.put(key, invoker); } } else { // 缓存命中，将 invoker 存储到 newUrlInvokerMap 中 newUrlInvokerMap.put(key, invoker); } } keys.clear(); return newUrlInvokerMap; } toInvokers 方法一开始会对服务提供者 url 进行检测，若服务消费端的配置不支持服务端的协议，或服务端 url 协议头为 empty 时，toInvokers 均会忽略服务提供方 url。必要的检测做完后，紧接着是合并 url，然后访问缓存，尝试获取与 url 对应的 invoker。如果缓存命中，直接将 Invoker 存入 newUrlInvokerMap 中即可。如果未命中，则需要新建 Invoker。Invoker 是通过 Protocol 的 refer 方法创建的，这个我在上一篇文章中已经分析过了，这里就不赘述了。 toInvokers 方法返回的是 <url, Invoker> 映射关系表，接下来还要对这个结果进行进一步处理，得到方法名到 Invoker 列表的映射关系。这个过程由 toMethodInvokers 方法完成，如下： private Map<String, List<Invoker<T>>> toMethodInvokers(Map<String, Invoker<T>> invokersMap) { // 方法名 -> Invoker 列表 Map<String, List<Invoker<T>>> newMethodInvokerMap = new HashMap<String, List<Invoker<T>>>(); List<Invoker<T>> invokersList = new ArrayList<Invoker<T>>(); if (invokersMap != null && invokersMap.size() > 0) { for (Invoker<T> invoker : invokersMap.values()) { // 获取 methods 参数 String parameter = invoker.getUrl().getParameter(Constants.METHODS_KEY); if (parameter != null && parameter.length() > 0) { // 切分 methods 参数值，得到方法名数组 String[] methods = Constants.COMMA_SPLIT_PATTERN.split(parameter); if (methods != null && methods.length > 0) { for (String method : methods) { // 方法名不为 * if (method != null && method.length() > 0 && !Constants.ANY_VALUE.equals(method)) { // 根据方法名获取 Invoker 列表 List<Invoker<T>> methodInvokers = newMethodInvokerMap.get(method); if (methodInvokers == null) { methodInvokers = new ArrayList<Invoker<T>>(); newMethodInvokerMap.put(method, methodInvokers); } // 存储 Invoker 到列表中 methodInvokers.add(invoker); } } } } invokersList.add(invoker); } } // 进行服务级别路由，参考：https://github.com/apache/incubator-dubbo/pull/749 List<Invoker<T>> newInvokersList = route(invokersList, null); // 存储 <*, newInvokersList> 映射关系 newMethodInvokerMap.put(Constants.ANY_VALUE, newInvokersList); if (serviceMethods != null && serviceMethods.length > 0) { for (String method : serviceMethods) { List<Invoker<T>> methodInvokers = newMethodInvokerMap.get(method); if (methodInvokers == null || methodInvokers.isEmpty()) { methodInvokers = newInvokersList; } // 进行方法级别路由 newMethodInvokerMap.put(method, route(methodInvokers, method)); } } // 排序，转成不可变列表 for (String method : new HashSet<String>(newMethodInvokerMap.keySet())) { List<Invoker<T>> methodInvokers = newMethodInvokerMap.get(method); Collections.sort(methodInvokers, InvokerComparator.getComparator()); newMethodInvokerMap.put(method, Collections.unmodifiableList(methodInvokers)); } return Collections.unmodifiableMap(newMethodInvokerMap); } 上面方法主要做了三件事情， 第一是对入参进行遍历，然后获取 methods 参数，并切分成数组。随后以方法名为键，Invoker 列表为值，将映射关系存储到 newMethodInvokerMap 中。第二是分别基于类和方法对 Invoker 列表进行路由操作。第三是对 Invoker 列表进行排序，并转成不可变列表。关于 toMethodInvokers 方法就先分析到这，我们继续向下分析，这次要分析的多组服务的合并逻辑。 private Map<String, List<Invoker<T>>> toMergeMethodInvokerMap(Map<String, List<Invoker<T>>> methodMap) { Map<String, List<Invoker<T>>> result = new HashMap<String, List<Invoker<T>>>(); // 遍历入参 for (Map.Entry<String, List<Invoker<T>>> entry : methodMap.entrySet()) { String method = entry.getKey(); List<Invoker<T>> invokers = entry.getValue(); // group -> Invoker 列表 Map<String, List<Invoker<T>>> groupMap = new HashMap<String, List<Invoker<T>>>(); // 遍历 Invoker 列表 for (Invoker<T> invoker : invokers) { // 获取分组配置 String group = invoker.getUrl().getParameter(Constants.GROUP_KEY, ""); List<Invoker<T>> groupInvokers = groupMap.get(group); if (groupInvokers == null) { groupInvokers = new ArrayList<Invoker<T>>(); // 缓存 <group, List<Invoker>> 到 groupMap 中 groupMap.put(group, groupInvokers); } // 存储 invoker 到 groupInvokers groupInvokers.add(invoker); } if (groupMap.size() == 1) { // 如果 groupMap 中仅包含一组键值对，此时直接取出该键值对的值即可 result.put(method, groupMap.values().iterator().next()); // groupMap 中包含多组键值对，比如： // { // "dubbo": [invoker1, invoker2, invoker3, ...], // "hello": [invoker4, invoker5, invoker6, ...] // } } else if (groupMap.size() > 1) { List<Invoker<T>> groupInvokers = new ArrayList<Invoker<T>>(); for (List<Invoker<T>> groupList : groupMap.values()) { // 通过集群类合并每个分组对应的 Invoker 列表 groupInvokers.add(cluster.join(new StaticDirectory<T>(groupList))); } // 缓存结果 result.put(method, groupInvokers); } else { result.put(method, invokers); } } return result; } 上面方法首先是生成 group 到 Invoker 类比的映射关系表，若关系表中的映射关系数量大于1，表示有多组服务。此时通过集群类合并每组 Invoker，并将合并结果存储到 groupInvokers 中。之后将方法名与 groupInvokers 存到到 result 中，并返回，整个逻辑结束。 接下来我们再来看一下 Invoker 列表刷新逻辑的最后一个动作 -- 删除无用 Invoker。如下： private void destroyUnusedInvokers(Map<String, Invoker<T>> oldUrlInvokerMap, Map<String, Invoker<T>> newUrlInvokerMap) { if (newUrlInvokerMap == null || newUrlInvokerMap.size() == 0) { destroyAllInvokers(); return; } List<String> deleted = null; if (oldUrlInvokerMap != null) { // 获取新生成的 Invoker 列表 Collection<Invoker<T>> newInvokers = newUrlInvokerMap.values(); // 遍历老的 <url, Invoker> 映射表 for (Map.Entry<String, Invoker<T>> entry : oldUrlInvokerMap.entrySet()) { // 检测 newInvokers 中是否包含老的 Invoker if (!newInvokers.contains(entry.getValue())) { if (deleted == null) { deleted = new ArrayList<String>(); } // 若不包含，则将老的 Invoker 对应的 url 存入 deleted 列表中 deleted.add(entry.getKey()); } } } if (deleted != null) { // 遍历 deleted 集合，并到老的 <url, Invoker> 映射关系表查出 Invoker，销毁之 for (String url : deleted) { if (url != null) { // 从 oldUrlInvokerMap 中移除 url 对应的 Invoker Invoker<T> invoker = oldUrlInvokerMap.remove(url); if (invoker != null) { try { // 销毁 Invoker invoker.destroy(); } catch (Exception e) { logger.warn("destroy invoker..."); } } } } } } destroyUnusedInvokers 方法的主要逻辑是通过 newUrlInvokerMap 找出待删除 Invoker 对应的 url，并将 url 存入到 deleted 列表中。然后再遍历 deleted 列表，并从 oldUrlInvokerMap 中移除相应的 Invoker，销毁之。整个逻辑大致如此，不是很难理解。 到此关于 Invoker 列表的刷新逻辑就分析了，这里对整个过程进行简单总结。如下： 检测入参是否仅包含一个 url，且 url 协议头为 empty 若第一步检测结果为 true，表示禁用所有服务，此时销毁所有的 Invoker 若第一步检测结果为 false，此时将入参转为 Invoker 列表 对将上一步逻辑删除的结果进行进一步处理，得到方法名到 Invoker 的映射关系表 合并多组 Invoker 销毁无用 Invoker Invoker 的刷新逻辑还是比较复杂的，大家在看的过程中多写点 demo 进行调试。好了，本节就到这。 4. 总结 本篇文章对 Dubbo 服务目录进行了较为详细的分析，篇幅主要集中在 RegistryDirectory 的源码分析上。分析下来，不由得感叹，想让本地服务目录和注册中心保持一致还是需要做很多事情的，并不简单。服务目录是 Dubbo 集群容错的一部分，也是比较基础的部分，所以大家务必搞懂。 好了，本篇文章就先到这了。感谢大家阅读。 本文在知识共享许可协议 4.0 下发布，转载需在明显位置处注明出处作者：田小波本文同步发布在我的个人博客：http://www.tianxiaobo.com 本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。
-
发表了文章 2018-11-13
Dubbo 源码分析 - 服务引用
1. 简介 在上一篇文章中，我详细的分析了服务导出的原理。本篇文章我们趁热打铁，继续分析服务引用的原理。在 Dubbo 中，我们可以通过两种方式引用远程服务。第一种是使用服务直联的方式引用服务，第二种方式是基于注册中心进行引用。服务直联的方式仅适合在调试或测试服务的场景下使用，不适合在线上环境使用。因此，本文我将重点分析通过注册中心引用服务的过程。从注册中心中获取服务配置只是服务引用过程中的一环，除此之外，服务消费者还需要经历 Invoker 创建、代理类创建等步骤。这些步骤，我将在后续章节中一一进行分析。 2.服务引用原理 Dubbo 服务引用的时机有两个，第一个是在 Spring 容器调用 ReferenceBean 的 afterPropertiesSet 方法时引用服务，第二个是在 ReferenceBean 对应的服务被注入到其他类中时引用。这两个引用服务的时机区别在于，第一个是饿汉式的，第二个是懒汉式的。默认情况下，Dubbo 使用懒汉式引用服务。如果需要使用饿汉式，可通过配置 <dubbo:reference> 的 init 属性开启。下面我们按照 Dubbo 默认配置进行分析，整个分析过程从 ReferenceBean 的 getObject 方法开始。当我们的服务被注入到其他类中时，Spring 会第一时间调用 getObject 方法，并由该方法执行服务引用逻辑。按照惯例，在进行具体工作之前，需先进行配置检查与收集工作。接着根据收集到的信息决定服务用的方式，有三种，第一种是引用本地 (JVM) 服务，第二是通过直联方式引用远程服务，第三是通过注册中心引用远程服务。不管是哪种引用方式，最后都会得到一个 Invoker 实例。如果有多个注册中心，多个服务提供者，这个时候会得到一组 Invoker 实例，此时需要通过集群管理类 Cluster 将多个 Invoker 合并成一个实例。合并后的 Invoker 实例已经具备调用本地或远程服务的能力了，但并不能将此实例暴露给用户使用，这会对用户业务代码造成侵入。此时框架还需要通过代理工厂类 (ProxyFactory) 为服务接口生成代理类，并让代理类去调用 Invoker 逻辑。避免了 Dubbo 框架代码对业务代码的侵入，同时也让框架更容易使用。 以上就是 Dubbo 引用服务的大致原理，下面我们深入到代码中，详细分析服务引用细节。 3.源码分析 服务引用的入口方法为 ReferenceBean 的 getObject 方法，该方法定义在 Spring 的 FactoryBean 接口中，ReferenceBean 实现了这个方法。实现代码如下： public Object getObject() throws Exception { return get(); } public synchronized T get() { if (destroyed) { throw new IllegalStateException("Already destroyed!"); } // 检测 ref 是否为空，为空则通过 init 方法创建 if (ref == null) { // init 方法主要用于处理配置，以及调用 createProxy 生成代理类 init(); } return ref; } 这里两个方法代码都比较简短，并不难理解。不过这里需要特别说明一下，如果大家从 getObject 方法进行代码调试时，会碰到比较诧异的问题。这里假设你使用 IDEA，且保持了 IDEA 的默认配置。当你面调试到 get 方法的if (ref == null)时，你会惊奇的发现 ref 不为空，导致你无法进入到 init 方法中继续调试。导致这个现象的原因是 Dubbo 框架本身有点小问题，这个小问题会引发一些让人诧异的现象。关于这个问题，我进行了将近两个小时的排查。查明问题后，我给 Dubbo 提交了一个 pull request (#2754 ) 介绍这个问题，有兴趣的朋友可以去看看。大家如果想规避这个问题，可以修改一下 IDEA 的配置。在配置面板中搜索 toString，然后取消Enable 'toString' object view前的对号。具体如下： 讲完需要注意的点，我们继续向下分析，接下来将分析配置的处理过程。 3.1 处理配置 Dubbo 提供了丰富的配置，用于调整和优化框架行为，性能等。Dubbo 在引用或导出服务时，首先会对这些配置进行检查和处理，以保证配置到正确性。如果大家不是很熟悉 Dubbo 配置，建议先阅读以下官方文档。配置解析的方法为 ReferenceConfig 的 init 方法，下面来看一下方法逻辑。 private void init() { if (initialized) { return; } initialized = true; if (interfaceName == null || interfaceName.length() == 0) { throw new IllegalStateException("interface not allow null!"); } // 检测 consumer 变量是否为空，为空则创建 checkDefault(); appendProperties(this); if (getGeneric() == null && getConsumer() != null) { // 设置 generic setGeneric(getConsumer().getGeneric()); } // 检测是否为泛化接口 if (ProtocolUtils.isGeneric(getGeneric())) { interfaceClass = GenericService.class; } else { try { // 加载类 interfaceClass = Class.forName(interfaceName, true, Thread.currentThread() .getContextClassLoader()); } catch (ClassNotFoundException e) { throw new IllegalStateException(e.getMessage(), e); } checkInterfaceAndMethods(interfaceClass, methods); } // ------------------------------- 分割线1 ------------------------------ // 从系统变量中获取与接口名对应的属性值 String resolve = System.getProperty(interfaceName); String resolveFile = null; if (resolve == null || resolve.length() == 0) { // 从系统属性中获取解析文件路径 resolveFile = System.getProperty("dubbo.resolve.file"); if (resolveFile == null || resolveFile.length() == 0) { // 从指定位置加载配置文件 File userResolveFile = new File(new File(System.getProperty("user.home")), "dubbo-resolve.properties"); if (userResolveFile.exists()) { // 获取文件绝对路径 resolveFile = userResolveFile.getAbsolutePath(); } } if (resolveFile != null && resolveFile.length() > 0) { Properties properties = new Properties(); FileInputStream fis = null; try { fis = new FileInputStream(new File(resolveFile)); // 从文件中加载配置 properties.load(fis); } catch (IOException e) { throw new IllegalStateException("Unload ..., cause:..."); } finally { try { if (null != fis) fis.close(); } catch (IOException e) { logger.warn(e.getMessage(), e); } } // 获取与接口名对应的配置 resolve = properties.getProperty(interfaceName); } } if (resolve != null && resolve.length() > 0) { // 将 resolve 赋值给 url url = resolve; } // ------------------------------- 分割线2 ------------------------------ if (consumer != null) { if (application == null) { // 从 consumer 中获取 Application 实例，下同 application = consumer.getApplication(); } if (module == null) { module = consumer.getModule(); } if (registries == null) { registries = consumer.getRegistries(); } if (monitor == null) { monitor = consumer.getMonitor(); } } if (module != null) { if (registries == null) { registries = module.getRegistries(); } if (monitor == null) { monitor = module.getMonitor(); } } if (application != null) { if (registries == null) { registries = application.getRegistries(); } if (monitor == null) { monitor = application.getMonitor(); } } // 检测本地 Application 和本地存根配置合法性 checkApplication(); checkStubAndMock(interfaceClass); // ------------------------------- 分割线3 ------------------------------ Map<String, String> map = new HashMap<String, String>(); Map<Object, Object> attributes = new HashMap<Object, Object>(); // 添加 side、协议版本信息、时间戳和进程号等信息到 map 中 map.put(Constants.SIDE_KEY, Constants.CONSUMER_SIDE); map.put(Constants.DUBBO_VERSION_KEY, Version.getProtocolVersion()); map.put(Constants.TIMESTAMP_KEY, String.valueOf(System.currentTimeMillis())); if (ConfigUtils.getPid() > 0) { map.put(Constants.PID_KEY, String.valueOf(ConfigUtils.getPid())); } if (!isGeneric()) { // 非泛化服务 // 获取版本 String revision = Version.getVersion(interfaceClass, version); if (revision != null && revision.length() > 0) { map.put("revision", revision); } // 获取接口方法列表，并添加到 map 中 String[] methods = Wrapper.getWrapper(interfaceClass).getMethodNames(); if (methods.length == 0) { map.put("methods", Constants.ANY_VALUE); } else { map.put("methods", StringUtils.join(new HashSet<String>(Arrays.asList(methods)), ",")); } } map.put(Constants.INTERFACE_KEY, interfaceName); // 将 ApplicationConfig、ConsumerConfig、ReferenceConfig 等对象的字段信息添加到 map 中 appendParameters(map, application); appendParameters(map, module); appendParameters(map, consumer, Constants.DEFAULT_KEY); appendParameters(map, this); // ------------------------------- 分割线4 ------------------------------ String prefix = StringUtils.getServiceKey(map); if (methods != null && !methods.isEmpty()) { // 遍历 MethodConfig 列表 for (MethodConfig method : methods) { appendParameters(map, method, method.getName()); String retryKey = method.getName() + ".retry"; // 检测 map 是否包含 methodName.retry if (map.containsKey(retryKey)) { String retryValue = map.remove(retryKey); if ("false".equals(retryValue)) { // 添加重试次数配置 methodName.retries map.put(method.getName() + ".retries", "0"); } } // 添加 MethodConfig 中的“属性”字段到 attributes // 比如 onreturn、onthrow、oninvoke 等 appendAttributes(attributes, method, prefix + "." + method.getName()); checkAndConvertImplicitConfig(method, map, attributes); } } // ------------------------------- 分割线5 ------------------------------ // 获取服务消费者 ip 地址 String hostToRegistry = ConfigUtils.getSystemProperty(Constants.DUBBO_IP_TO_REGISTRY); if (hostToRegistry == null || hostToRegistry.length() == 0) { hostToRegistry = NetUtils.getLocalHost(); } else if (isInvalidLocalHost(hostToRegistry)) { throw new IllegalArgumentException("Specified invalid registry ip from property..." ); } map.put(Constants.REGISTER_IP_KEY, hostToRegistry); // 存储 attributes 到系统上下文中 StaticContext.getSystemContext().putAll(attributes); // 创建代理类 ref = createProxy(map); // 根据服务名，ReferenceConfig，代理类构建 ConsumerModel， // 并将 ConsumerModel 存入到 ApplicationModel 中 ConsumerModel consumerModel = new ConsumerModel(getUniqueServiceName(), this, ref, interfaceClass.getMethods()); ApplicationModel.initConsumerModel(getUniqueServiceName(), consumerModel); } 上面的代码很长，做的事情比较多。这里我根据代码逻辑，对代码进行了分块，下面我们一起来看一下。 首先是方法开始到分割线1之间的代码。这段代码主要用于检测 ConsumerConfig 实例是否存在，如不存在则创建一个新的实例，然后通过系统变量或 dubbo.properties 配置文件填充 ConsumerConfig 的字段。接着是检测泛化配置，并根据配置设置 interfaceClass 的值。本段代码逻辑大致就是这些，接着来看分割线1到分割线2之间的逻辑。这段逻辑用于从系统属性或配置文件中加载与接口名相对应的配置，并将解析结果赋值给 url 字段。url 字段的作用一般是用于点对点调用。继续向下看，分割线2和分割线3之间的代码用于检测几个核心配置类是否为空，为空则尝试从其他配置类中获取。分割线3与分割线4之间的代码主要是用于收集各种配置，并将配置存储到 map 中。分割线4和分割线5之间的代码用于处理 MethodConfig 实例。该实例包含了事件通知配置，比如 onreturn、onthrow、oninvoke 等。分割线5到方法结尾的代码主要用于解析服务消费者 ip，以及调用 createProxy 创建代理对象。关于该方法的详细分析，将会在接下来的章节中展开。 到这里，关于配置的检查与处理过长就分析完了。这部分逻辑不是很难理解，但比较繁杂，大家需要耐心看一下。好了，本节先到这，接下来分析服务引用的过程。 3.2 引用服务 本节我们要从 createProxy 开始看起。createProxy 这个方法表面上看起来只是用于创建代理对象，但实际上并非如此。该方法还会调用其他方法构建以及合并 Invoker 实例。具体细节如下。 private T createProxy(Map<String, String> map) { URL tmpUrl = new URL("temp", "localhost", 0, map); final boolean isJvmRefer; if (isInjvm() == null) { // url 配置被指定，则不做本地引用 if (url != null && url.length() > 0) { isJvmRefer = false; // 根据 url 的协议、scope 以及 injvm 等参数检测是否需要本地引用 // 比如如果用户显式配置了 scope=local，此时 isInjvmRefer 返回 true } else if (InjvmProtocol.getInjvmProtocol().isInjvmRefer(tmpUrl)) { isJvmRefer = true; } else { isJvmRefer = false; } } else { // 获取 injvm 配置值 isJvmRefer = isInjvm().booleanValue(); } // 本地引用 if (isJvmRefer) { // 生成本地引用 URL，协议为 injvm URL url = new URL(Constants.LOCAL_PROTOCOL, NetUtils.LOCALHOST, 0, interfaceClass.getName()).addParameters(map); // 调用 refer 方法构建 InjvmInvoker 实例 invoker = refprotocol.refer(interfaceClass, url); // 远程引用 } else { // url 不为空，表明用户可能想进行点对点调用 if (url != null && url.length() > 0) { // 当需要配置多个 url 时，可用分号进行分割，这里会进行切分 String[] us = Constants.SEMICOLON_SPLIT_PATTERN.split(url); if (us != null && us.length > 0) { for (String u : us) { URL url = URL.valueOf(u); if (url.getPath() == null || url.getPath().length() == 0) { // 设置接口全限定名为 url 路径 url = url.setPath(interfaceName); } // 检测 url 协议是否为 registry，若是，表明用户想使用指定的注册中心 if (Constants.REGISTRY_PROTOCOL.equals(url.getProtocol())) { // 将 map 转换为查询字符串，并作为 refer 参数的值添加到 url 中 urls.add(url.addParameterAndEncoded(Constants.REFER_KEY, StringUtils.toQueryString(map))); } else { // 合并 url，移除服务提供者的一些配置（这些配置来源于用户配置的 url 属性）， // 比如线程池相关配置。并保留服务提供者的部分配置，比如版本，group，时间戳等 // 最后将合并后的配置设置为 url 查询字符串中。 urls.add(ClusterUtils.mergeUrl(url, map)); } } } } else { // 加载注册中心 url List<URL> us = loadRegistries(false); if (us != null && !us.isEmpty()) { for (URL u : us) { URL monitorUrl = loadMonitor(u); if (monitorUrl != null) { map.put(Constants.MONITOR_KEY, URL.encode(monitorUrl.toFullString())); } // 添加 refer 参数到 url 中，并将 url 添加到 urls 中 urls.add(u.addParameterAndEncoded(Constants.REFER_KEY, StringUtils.toQueryString(map))); } } // 未配置注册中心，抛出异常 if (urls.isEmpty()) { throw new IllegalStateException("No such any registry to reference..."); } } // 单个注册中心或服务提供者(服务直联，下同) if (urls.size() == 1) { // 调用 RegistryProtocol 的 refer 构建 Invoker 实例 invoker = refprotocol.refer(interfaceClass, urls.get(0)); // 多个注册中心或多个服务提供者，或者两者混合 } else { List<Invoker<?>> invokers = new ArrayList<Invoker<?>>(); URL registryURL = null; // 获取所有的 Invoker for (URL url : urls) { // 通过 refprotocol 调用 refer 构建 Invoker，refprotocol 会在运行时 // 根据 url 协议头加载指定的 Protocol 实例，并调用实例的 refer 方法 invokers.add(refprotocol.refer(interfaceClass, url)); if (Constants.REGISTRY_PROTOCOL.equals(url.getProtocol())) { registryURL = url; } } if (registryURL != null) { // 如果注册中心链接不为空，则将使用 AvailableCluster URL u = registryURL.addParameter(Constants.CLUSTER_KEY, AvailableCluster.NAME); // 创建 StaticDirectory 实例，并由 Cluster 对多个 Invoker 进行合并 invoker = cluster.join(new StaticDirectory(u, invokers)); } else { invoker = cluster.join(new StaticDirectory(invokers)); } } } Boolean c = check; if (c == null && consumer != null) { c = consumer.isCheck(); } if (c == null) { c = true; } // invoker 可用性检查 if (c && !invoker.isAvailable()) { throw new IllegalStateException("No provider available for the service..."); } // 生成代理类 return (T) proxyFactory.getProxy(invoker); } 上面代码很多，不过逻辑比较清晰。首先根据配置检查是否为本地调用，若是，则调用 InjvmProtocol 的 refer 方法生成 InjvmInvoker 实例。若不是，则读取直联配置项，或注册中心 url，并将读取到的 url 存储到 urls 中。然后，根据 urls 元素数量进行后续操作。若 urls 元素数量为1，则直接通过 Protocol 自适应拓展构建 Invoker 实例接口。若 urls 元素数量大于1，即存在多个注册中心或服务直联 url，此时先根据 url 构建 Invoker。然后再通过 Cluster 合并多个 Invoker，最后调用 ProxyFactory 生成代理类。这里，Invoker 的构建过程以及代理类的过程比较重要，因此我将分两小节对这两个过程进行分析。 3.2.1 创建 Invoker Invoker 是 Dubbo 的核心模型，代表一个可执行体。在服务提供方，Invoker 用于调用服务提供类。在服务消费方，Invoker 用于执行远程调用。Invoker 在 Dubbo 中的位置十分重要，因此我们有必要去搞懂它。从前面的代码中可知，Invoker 是由 Protocol 实现类构建的。Protocol 实现类有很多，这里我会分析最常用的两个，分别是 RegistryProtocol 和 DubboProtocol，其他的大家自行分析。下面先来分析 DubboProtocol 的 refer 方法源码。如下： public <T> Invoker<T> refer(Class<T> serviceType, URL url) throws RpcException { optimizeSerialization(url); // 创建 DubboInvoker DubboInvoker<T> invoker = new DubboInvoker<T>(serviceType, url, getClients(url), invokers); invokers.add(invoker); return invoker; } 上面方法看起来比较简单，不过这里有一个调用需要我们注意一下，即 getClients。这个方法用于获取客户端实例，实例类型为 ExchangeClient。ExchangeClient 实际上并不具备通信能力，因此它需要更底层的客户端实例进行通信。比如 NettyClient、MinaClient 等，默认情况下，Dubbo 使用 NettyClient 进行通信。接下来，我们简单看一下 getClients 方法的逻辑。 private ExchangeClient[] getClients(URL url) { // 是否共享连接 boolean service_share_connect = false; // 获取连接数，默认为0，表示未配置 int connections = url.getParameter(Constants.CONNECTIONS_KEY, 0); // 如果未配置 connections，则共享连接 if (connections == 0) { service_share_connect = true; connections = 1; } ExchangeClient[] clients = new ExchangeClient[connections]; for (int i = 0; i < clients.length; i++) { if (service_share_connect) { // 获取共享客户端 clients[i] = getSharedClient(url); } else { // 初始化新的客户端 clients[i] = initClient(url); } } return clients; } 这里根据 connections 数量决定是获取共享客户端还是创建新的客户端实例，默认情况下，使用共享客户端实例。不过 getSharedClient 方法中也会调用 initClient 方法，因此下面我们一起看一下这两个方法。 private ExchangeClient getSharedClient(URL url) { String key = url.getAddress(); // 获取带有“引用计数”功能的 ExchangeClient ReferenceCountExchangeClient client = referenceClientMap.get(key); if (client != null) { if (!client.isClosed()) { // 增加引用计数 client.incrementAndGetCount(); return client; } else { referenceClientMap.remove(key); } } locks.putIfAbsent(key, new Object()); synchronized (locks.get(key)) { if (referenceClientMap.containsKey(key)) { return referenceClientMap.get(key); } // 创建 ExchangeClient 客户端 ExchangeClient exchangeClient = initClient(url); // 将 ExchangeClient 实例传给 ReferenceCountExchangeClient，这里明显用了装饰模式 client = new ReferenceCountExchangeClient(exchangeClient, ghostClientMap); referenceClientMap.put(key, client); ghostClientMap.remove(key); locks.remove(key); return client; } } 上面方法先访问缓存，若缓存未命中，则通过 initClient 方法创建新的 ExchangeClient 实例，并将该实例传给 ReferenceCountExchangeClient 构造方法创建一个带有引用技术功能的 ExchangeClient 实例。ReferenceCountExchangeClient 内部实现比较简单，就不分析了。下面我们再来看一下 initClient 方法的代码。 private ExchangeClient initClient(URL url) { // 获取客户端类型，默认为 netty String str = url.getParameter(Constants.CLIENT_KEY, url.getParameter(Constants.SERVER_KEY, Constants.DEFAULT_REMOTING_CLIENT)); // 添加编解码和心跳包参数到 url 中 url = url.addParameter(Constants.CODEC_KEY, DubboCodec.NAME); url = url.addParameterIfAbsent(Constants.HEARTBEAT_KEY, String.valueOf(Constants.DEFAULT_HEARTBEAT)); // 检测客户端类型是否存在，不存在则抛出异常 if (str != null && str.length() > 0 && !ExtensionLoader.getExtensionLoader(Transporter.class).hasExtension(str)) { throw new RpcException("Unsupported client type: ..."); } ExchangeClient client; try { // 获取 lazy 配置，并根据配置值决定创建的客户端类型 if (url.getParameter(Constants.LAZY_CONNECT_KEY, false)) { // 创建懒加载 ExchangeClient 实例 client = new LazyConnectExchangeClient(url, requestHandler); } else { // 创建普通 ExchangeClient 实例 client = Exchangers.connect(url, requestHandler); } } catch (RemotingException e) { throw new RpcException("Fail to create remoting client for service..."); } return client; } initClient 方法首先获取用户配置的客户端类型，默认为 netty。然后检测用户配置的客户端类型是否存在，不存在则抛出异常。最后根据 lazy 配置决定创建什么类型的客户端。这里的 LazyConnectExchangeClient 代码并不是很复杂，该类会在 request 方法被调用时通过 Exchangers 的 connect 方法创建 ExchangeClient 客户端，这里就不分析 LazyConnectExchangeClient 的代码了。下面我们分析一下 Exchangers 的 connect 方法。 public static ExchangeClient connect(URL url, ExchangeHandler handler) throws RemotingException { if (url == null) { throw new IllegalArgumentException("url == null"); } if (handler == null) { throw new IllegalArgumentException("handler == null"); } url = url.addParameterIfAbsent(Constants.CODEC_KEY, "exchange"); // 获取 Exchanger 实例，默认为 HeaderExchangeClient return getExchanger(url).connect(url, handler); } 如上，getExchanger 会通过 SPI 加载 HeaderExchangeClient 实例，这个方法比较简单，大家自己看一下吧。接下来分析 HeaderExchangeClient 的实现。 public ExchangeClient connect(URL url, ExchangeHandler handler) throws RemotingException { // 这里包含了多个调用，分别如下： // 1. 创建 HeaderExchangeHandler 对象 // 2. 创建 DecodeHandler 对象 // 3. 通过 Transporters 构建 Client 实例 // 4. 创建 HeaderExchangeClient 对象 return new HeaderExchangeClient(Transporters.connect(url, new DecodeHandler(new HeaderExchangeHandler(handler))), true); } 这里的调用比较多，我们这里重点看一下 Transporters 的 connect 方法。如下： public static Client connect(URL url, ChannelHandler... handlers) throws RemotingException { if (url == null) { throw new IllegalArgumentException("url == null"); } ChannelHandler handler; if (handlers == null || handlers.length == 0) { handler = new ChannelHandlerAdapter(); } else if (handlers.length == 1) { handler = handlers[0]; } else { // 如果 handler 数量大于1，则创建一个 ChannelHandler 分发器 handler = new ChannelHandlerDispatcher(handlers); } // 获取 Transporter 自适应拓展类，并调用 connect 方法生成 Client 实例 return getTransporter().connect(url, handler); } 这里，getTransporter 方法返回的是自适应拓展类，该类会在运行时根据客户端类型加载指定的 Transporter 实现类。若用户未显示配置客户端类型，则默认加载 NettyTransporter，并调用该类的 connect 方法。如下： public Client connect(URL url, ChannelHandler listener) throws RemotingException { // 创建 NettyClient 对象 return new NettyClient(url, listener); } 到这里就不继续跟下去了，在往下就是通过 Netty 提供的接口构建 Netty 客户端了，大家有兴趣自己看看。到这里，关于 DubboProtocol 的 refer 方法就分析完了。接下来，继续分析 RegistryProtocol 的 refer 方法逻辑。 public <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException { // 取 registry 参数值，并将其设置为协议头 url = url.setProtocol(url.getParameter(Constants.REGISTRY_KEY, Constants.DEFAULT_REGISTRY)).removeParameter(Constants.REGISTRY_KEY); // 获取注册中心实例 Registry registry = registryFactory.getRegistry(url); // 这个判断暂时不知道有什么意图，为什么要给 RegistryService 类型生成 Invoker ？ if (RegistryService.class.equals(type)) { return proxyFactory.getInvoker((T) registry, type, url); } // 将 url 查询字符串转为 Map Map<String, String> qs = StringUtils.parseQueryString(url.getParameterAndDecoded(Constants.REFER_KEY)); // 获取 group 配置 String group = qs.get(Constants.GROUP_KEY); if (group != null && group.length() > 0) { if ((Constants.COMMA_SPLIT_PATTERN.split(group)).length > 1 || "*".equals(group)) { // 通过 SPI 加载 MergeableCluster 实例，并调用 doRefer 继续执行引用服务逻辑 return doRefer(getMergeableCluster(), registry, type, url); } } // 调用 doRefer 继续执行引用服务逻辑 return doRefer(cluster, registry, type, url); } 上面代码首先为 url 设置协议头，然后根据 url 参数加载注册中心实例。接下来对 RegistryService 继续针对性处理，这个处理逻辑我不是很明白，不知道为什么要为 RegistryService 类型生成 Invoker，有知道同学麻烦告知一下。然后就是获取 group 配置，根据 group 配置决定 doRefer 第一个参数的类型。这里的重点是 doRefer 方法，如下： private <T> Invoker<T> doRefer(Cluster cluster, Registry registry, Class<T> type, URL url) { // 创建 RegistryDirectory 实例 RegistryDirectory<T> directory = new RegistryDirectory<T>(type, url); // 设置注册中心和协议 directory.setRegistry(registry); directory.setProtocol(protocol); Map<String, String> parameters = new HashMap<String, String>(directory.getUrl().getParameters()); // 生成服务消费者链接 URL subscribeUrl = new URL(Constants.CONSUMER_PROTOCOL, parameters.remove(Constants.REGISTER_IP_KEY), 0, type.getName(), parameters); // 注册服务消费者，在 consumers 目录下新节点 if (!Constants.ANY_VALUE.equals(url.getServiceInterface()) && url.getParameter(Constants.REGISTER_KEY, true)) { registry.register(subscribeUrl.addParameters(Constants.CATEGORY_KEY, Constants.CONSUMERS_CATEGORY, Constants.CHECK_KEY, String.valueOf(false))); } // 订阅 providers、configurators、routers 等节点数据 directory.subscribe(subscribeUrl.addParameter(Constants.CATEGORY_KEY, Constants.PROVIDERS_CATEGORY + "," + Constants.CONFIGURATORS_CATEGORY + "," + Constants.ROUTERS_CATEGORY)); // 一个注册中心可能有多个服务提供者，因此这里需要将多个服务提供者合并为一个 Invoker invoker = cluster.join(directory); ProviderConsumerRegTable.registerConsumer(invoker, url, subscribeUrl, directory); return invoker; } 如上，doRefer 方法创建一个 RegistryDirectory 实例，然后生成服务者消费者链接，并向注册中心进行注册。注册完毕后，紧接着订阅 providers、configurators、routers 等节点下的数据。完成订阅后，RegistryDirectory 会收到这几个节点下的子节点信息，比如可以获取到服务提供者的配置信息。由于一个服务可能部署在多台服务器上，这样就会在 providers 产生多个节点，这个时候就需要 Cluster 将多个服务节点合并为一个，并生成一个 Invoker。关于 RegistryDirectory 和 Cluster，本文不打算进行分析，相关分析将会在随后的文章中展开。 好了，关于 Invoker 的创建的逻辑就先分析到这。逻辑比较多，大家耐心看一下。 3.2.2 创建代理 Invoker 创建完毕后，接下来要做的事情是为服务接口生成代理对象。有了代理对象，我们就可以通过代理对象进行远程调用。代理对象生成的入口方法为在 ProxyFactory 的 getProxy，接下来进行分析。 public <T> T getProxy(Invoker<T> invoker) throws RpcException { // 调用重载方法 return getProxy(invoker, false); } public <T> T getProxy(Invoker<T> invoker, boolean generic) throws RpcException { Class<?>[] interfaces = null; // 获取接口列表 String config = invoker.getUrl().getParameter("interfaces"); if (config != null && config.length() > 0) { // 切分接口列表 String[] types = Constants.COMMA_SPLIT_PATTERN.split(config); if (types != null && types.length > 0) { interfaces = new Class<?>[types.length + 2]; // 设置服务接口类和 EchoService.class 到 interfaces 中 interfaces[0] = invoker.getInterface(); interfaces[1] = EchoService.class; for (int i = 0; i < types.length; i++) { // 加载接口类 interfaces[i + 1] = ReflectUtils.forName(types[i]); } } } if (interfaces == null) { interfaces = new Class<?>[]{invoker.getInterface(), EchoService.class}; } // 为 http 和 hessian 协议提供泛化调用支持，参考 pull request #1827 if (!invoker.getInterface().equals(GenericService.class) && generic) { int len = interfaces.length; Class<?>[] temp = interfaces; // 创建新的 interfaces 数组 interfaces = new Class<?>[len + 1]; System.arraycopy(temp, 0, interfaces, 0, len); // 设置 GenericService.class 到数组中 interfaces[len] = GenericService.class; } // 调用重载方法 return getProxy(invoker, interfaces); } public abstract <T> T getProxy(Invoker<T> invoker, Class<?>[] types); 如上，上面大段代码都是用来获取 interfaces 数组的，因此我们需要继续往下看。getProxy(Invoker, Class<?>[]) 这个方法是一个抽象方法，下面我们到 JavassistProxyFactory 类中看一下该方法的实现代码。 public <T> T getProxy(Invoker<T> invoker, Class<?>[] interfaces) { // 生成 Proxy 子类（Proxy 是抽象类）。并调用Proxy 子类的 newInstance 方法生成 Proxy 实例 return (T) Proxy.getProxy(interfaces).newInstance(new InvokerInvocationHandler(invoker)); } 上面代码并不多，首先是通过 Proxy 的 getProxy 方法获取 Proxy 子类，然后创建 InvokerInvocationHandler 对象，并将该对象传给 newInstance 生成 Proxy 实例。InvokerInvocationHandler 实现自 JDK 的 InvocationHandler 接口，具体的用途是拦截接口类调用。该类逻辑比较简单，这里就不分析了。下面我们重点关注一下 Proxy 的 getProxy 方法，如下。 public static Proxy getProxy(Class<?>... ics) { // 调用重载方法 return getProxy(ClassHelper.getClassLoader(Proxy.class), ics); } public static Proxy getProxy(ClassLoader cl, Class<?>... ics) { if (ics.length > 65535) throw new IllegalArgumentException("interface limit exceeded"); StringBuilder sb = new StringBuilder(); // 遍历接口列表 for (int i = 0; i < ics.length; i++) { String itf = ics[i].getName(); // 检测类型是否为接口 if (!ics[i].isInterface()) throw new RuntimeException(itf + " is not a interface."); Class<?> tmp = null; try { // 重新加载接口类 tmp = Class.forName(itf, false, cl); } catch (ClassNotFoundException e) { } // 检测接口是否相同，这里 tmp 有可能为空 if (tmp != ics[i]) throw new IllegalArgumentException(ics[i] + " is not visible from class loader"); // 拼接接口全限定名，分隔符为 ; sb.append(itf).append(';'); } // 使用拼接后接口名作为 key String key = sb.toString(); Map<String, Object> cache; synchronized (ProxyCacheMap) { cache = ProxyCacheMap.get(cl); if (cache == null) { cache = new HashMap<String, Object>(); ProxyCacheMap.put(cl, cache); } } Proxy proxy = null; synchronized (cache) { do { // 从缓存中获取 Reference<Proxy> 实例 Object value = cache.get(key); if (value instanceof Reference<?>) { proxy = (Proxy) ((Reference<?>) value).get(); if (proxy != null) { return proxy; } } // 多线程控制，保证只有一个线程可以进行后续操作 if (value == PendingGenerationMarker) { try { // 其他线程在此处进行等待 cache.wait(); } catch (InterruptedException e) { } } else { // 放置标志位到缓存中，并跳出 while 循环进行后续操作 cache.put(key, PendingGenerationMarker); break; } } while (true); } long id = PROXY_CLASS_COUNTER.getAndIncrement(); String pkg = null; ClassGenerator ccp = null, ccm = null; try { // 创建 ClassGenerator 对象 ccp = ClassGenerator.newInstance(cl); Set<String> worked = new HashSet<String>(); List<Method> methods = new ArrayList<Method>(); for (int i = 0; i < ics.length; i++) { // 检测接口访问级别是否为 protected 或 privete if (!Modifier.isPublic(ics[i].getModifiers())) { // 获取接口包名 String npkg = ics[i].getPackage().getName(); if (pkg == null) { pkg = npkg; } else { if (!pkg.equals(npkg)) // 非 public 级别的接口必须在同一个包下，否者抛出异常 throw new IllegalArgumentException("non-public interfaces from different packages"); } } // 添加接口到 ClassGenerator 中 ccp.addInterface(ics[i]); // 遍历接口方法 for (Method method : ics[i].getMethods()) { // 获取方法描述，可理解为方法签名 String desc = ReflectUtils.getDesc(method); // 如果已包含在 worked 中，则忽略。考虑这种情况， // A 接口和 B 接口中包含一个完全相同的方法 if (worked.contains(desc)) continue; worked.add(desc); int ix = methods.size(); // 获取方法返回值类型 Class<?> rt = method.getReturnType(); // 获取参数列表 Class<?>[] pts = method.getParameterTypes(); // 生成 Object[] args = new Object[1...N] StringBuilder code = new StringBuilder("Object[] args = new Object[").append(pts.length).append("];"); for (int j = 0; j < pts.length; j++) // 生成 args[1...N] = ($w)$1...N; code.append(" args[").append(j).append("] = ($w)$").append(j + 1).append(";"); // 生成 InvokerHandler 接口的 invoker 方法调用语句，如下： // Object ret = handler.invoke(this, methods[1...N], args); code.append(" Object ret = handler.invoke(this, methods[" + ix + "], args);"); // 返回值不为 void if (!Void.TYPE.equals(rt)) // 生成返回语句，形如 return (java.lang.String) ret; code.append(" return ").append(asArgument(rt, "ret")).append(";"); methods.add(method); // 添加方法名、访问控制符、参数列表、方法代码等信息到 ClassGenerator 中 ccp.addMethod(method.getName(), method.getModifiers(), rt, pts, method.getExceptionTypes(), code.toString()); } } if (pkg == null) pkg = PACKAGE_NAME; // 构建接口代理类名称：pkg + ".proxy" + id，比如 com.tianxiaobo.proxy0 String pcn = pkg + ".proxy" + id; ccp.setClassName(pcn); ccp.addField("public static java.lang.reflect.Method[] methods;"); // 生成 private java.lang.reflect.InvocationHandler handler; ccp.addField("private " + InvocationHandler.class.getName() + " handler;"); // 为接口代理类添加带有 InvocationHandler 参数的构造方法，比如： // porxy0(java.lang.reflect.InvocationHandler arg0) { // handler=$1; // } ccp.addConstructor(Modifier.PUBLIC, new Class<?>[]{InvocationHandler.class}, new Class<?>[0], "handler=$1;"); // 为接口代理类添加默认构造方法 ccp.addDefaultConstructor(); // 生成接口代理类 Class<?> clazz = ccp.toClass(); clazz.getField("methods").set(null, methods.toArray(new Method[0])); // 构建 Proxy 子类名称，比如 Proxy1，Proxy2 等 String fcn = Proxy.class.getName() + id; ccm = ClassGenerator.newInstance(cl); ccm.setClassName(fcn); ccm.addDefaultConstructor(); ccm.setSuperClass(Proxy.class); // 为 Proxy 的抽象方法 newInstance 生成实现代码，形如： // public Object newInstance(java.lang.reflect.InvocationHandler h) { // return new com.tianxiaobo.proxy0($1); // } ccm.addMethod("public Object newInstance(" + InvocationHandler.class.getName() + " h){ return new " + pcn + "($1); }"); // 生成 Proxy 实现类 Class<?> pc = ccm.toClass(); // 通过反射创建 Proxy 实例 proxy = (Proxy) pc.newInstance(); } catch (RuntimeException e) { throw e; } catch (Exception e) { throw new RuntimeException(e.getMessage(), e); } finally { if (ccp != null) // 释放资源 ccp.release(); if (ccm != null) ccm.release(); synchronized (cache) { if (proxy == null) cache.remove(key); else // 写缓存 cache.put(key, new WeakReference<Proxy>(proxy)); // 唤醒其他等待线程 cache.notifyAll(); } } return proxy; } 上面代码比较复杂，我也写了很多注释。大家在阅读这段代码时，要搞清楚 ccp 和 ccm 的用途，不然会被搞晕。ccp 用于为服务接口生成代理类，比如我们有一个 DemoService 接口，这个接口代理类就是由 ccp 生成的。ccm 则是用于为 org.apache.dubbo.common.bytecode.Proxy 抽象类生成子类，主要是实现 Proxy 的抽象方法。下面以 org.apache.dubbo.demo.DemoService 这个接口为例，来看一下该接口代理类代码大致是怎样的（忽略 EchoService 接口）。 package org.apache.dubbo.common.bytecode; public class proxy0 implements org.apache.dubbo.demo.DemoService { public static java.lang.reflect.Method[] methods; private java.lang.reflect.InvocationHandler handler; public proxy0() { } public proxy0(java.lang.reflect.InvocationHandler arg0) { handler = $1; } public java.lang.String sayHello(java.lang.String arg0) { Object[] args = new Object[1]; args[0] = ($w) $1; Object ret = handler.invoke(this, methods[0], args); return (java.lang.String) ret; } } 好了，到这里代理类生成逻辑就分析完了。整个过程比较复杂，大家需要耐心看一下，本节点到这里。 4.总结 本篇文章对服务引用的过程进行了较为详尽的分析，之所以说是较为详尽，是因为还有一些地方没有分析到。比如 Directory、Cluster 等实现类的代码并未进行详细分析，由于这些类功能比较独立，因此我打算后续单独成文进行分析。暂时我们可以先把这些类看成黑盒，只要知道这些类的用途即可。引用服务过程涉及到的调用也非常多，大家在阅读相关代码的中耐心些，并多进行调试。 好了，本篇文章就先到这里了。谢谢阅读。 本文在知识共享许可协议 4.0 下发布，转载需在明显位置处注明出处作者：田小波本文同步发布在我的个人博客：http://www.tianxiaobo.com 本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。
-
发表了文章 2018-11-01
Dubbo 源码分析 - 服务导出
1.服务导出过程 本篇文章，我们来研究一下 Dubbo 导出服务的过程。Dubbo 服务导出过程始于 Spring 容器发布刷新事件，Dubbo 在接收到事件后，会立即执行服务导出逻辑。整个逻辑大致可分为三个部分，第一是前置工作，主要用于检查参数，组装 URL。第二是导出服务，包含导出服务到本地 (JVM)，和导出服务到远程两个过程。第三是向注册中心注册服务，用于服务发现。本篇文章将会对这三个部分代码进行详细的分析，在分析之前，我们先来了解一下服务的导出过程。 Dubbo 支持两种服务导出方式，分别延迟导出和立即导出。延迟导出的入口是 ServiceBean 的 afterPropertiesSet 方法，立即导出的入口是 ServiceBean 的 onApplicationEvent 方法。本文打算分析服务延迟导出过程，因此不会分析 afterPropertiesSet 方法。下面从 onApplicationEvent 方法说起，该方法收到 Spring 容器的刷新事件后，会调用 export 方法执行服务导出操作。服务导出之前，要进行对一系列的配置进行检查，以及生成 URL。准备工作做完，随后开始导出服务。首先导出到本地，然后再导出到远程。导出到本地就是将服务导出到 JVM 中，此过程比较简单。导出到远程的过程则要复杂的多，以 dubbo 协议为例，DubboProtocol 类的 export 方法将会被调用。该方法主要用于创建 Exporter 和 ExchangeServer。ExchangeServer 本身并不具备通信能力，需要借助更底层的 Server 实现通信功能。因此，在创建 ExchangeServer 实例时，需要先创建 NettyServer 或者 MinaServer 实例，并将实例作为参数传给 ExchangeServer 实现类的构造方法。ExchangeServer 实例创建完成后，导出服务到远程的过程也就接近尾声了。服务导出结束后，服务消费者即可通过直联的方式消费服务。当然，一般我们不会使用直联的方式消费服务。所以，在服务导出结束后，紧接着要做的事情是向注册中心注册服务。此时，客户端即可从注册中心发现服务。 以上就是 Dubbo 服务导出的过程，比较复杂。下面开始分析源码，从源码的角度展现整个过程。 2.源码分析 一场 Dubbo 源码分析的马拉松比赛即将开始，现在我们站在赛道的起点进行热身准备。本次比赛的起点位置位于 ServiceBean 的 onApplicationEvent 方法处。好了，发令枪响了，我将和一些朋友从 onApplicationEvent 方法处出发，探索 Dubbo 服务导出的全过程。下面我们来看一下 onApplicationEvent 方法的源码。 public void onApplicationEvent(ContextRefreshedEvent event) { // 是否有延迟导出 && 是否已导出 && 是不是已被取消导出 if (isDelay() && !isExported() && !isUnexported()) { // 导出服务 export(); } } onApplicationEvent 是一个事件响应方法，该方法会在收到 Spring 上下文刷新事件后执行。这个方法首先会根据条件决定是否导出服务，比如有些服务设置了延时导出，那么此时就不应该在此处导出。还有一些服务已经被导出了，或者当前服务被取消导出了，此时也不能再次导出相关服务。注意这里的 isDelay 方法，这个方法字面意思是“是否延迟导出服务”，返回 true 表示延迟导出，false 表示不延迟导出。但是该方法真实意思却并非如此，当方法返回 true 时，表示无需延迟导出。返回 false 时，表示需要延迟导出。与字面意思恰恰相反，让人觉得很奇怪。下面我们来看一下这个方法的逻辑。 // -- ServiceBean private boolean isDelay() { // 获取 delay Integer delay = getDelay(); ProviderConfig provider = getProvider(); if (delay == null && provider != null) { // 如果前面获取的 delay 为空，这里继续获取 delay = provider.getDelay(); } // 判断 delay 是否为空，或者等于 -1 return supportedApplicationListener && (delay == null || delay == -1); } 暂时忽略 supportedApplicationListener 这个条件，当 delay 为空，或者等于-1时，该方法返回 true，而不是 false。这个方法的返回值让人有点困惑，因此我重构了该方法的代码，并给 Dubbo 提了一个 Pull Request，最终这个 PR 被合到了 Dubbo 主分支中。详细请参见 Dubbo #2686。 现在解释一下 supportedApplicationListener 变量含义，该变量用于表示当前的 Spring 容器是否支持 ApplicationListener，这个值初始为 false。在 Spring 容器将自己设置到 ServiceBean 中时，ServiceBean 的 setApplicationContext 方法会检测 Spring 容器是否支持 ApplicationListener。若支持，则将 supportedApplicationListener 置为 true。代码就不分析了，大家自行查阅了解。 ServiceBean 是 Dubbo 与 Spring 框架进行整合的关键，可以看做是两个框架之间的桥梁。具有同样作用的类还有 ReferenceBean。ServiceBean 实现了 Spring 的一些拓展接口，有 FactoryBean、ApplicationContextAware、ApplicationListener、DisposableBean 和 BeanNameAware。这些接口我在 Spring 源码分析系列文章中介绍过，大家可以参考一下，这里就不赘述了。 现在我们知道了 Dubbo 服务导出过程的起点。那么接下来，我们快马加鞭，继续进行比赛。赛程预告，下一站是“服务导出的前置工作”。 2.1 前置工作 前置工作主要包含两个部分，分别是配置检查，以及 URL 装配。在导出服务之前，Dubbo 需要检查用户的配置是否合理，或者为用户补充缺省配置。配置检查完成后，接下来需要根据这些配置组装 URL。在 Dubbo 中，URL 的作用十分重要。Dubbo 使用 URL 作为配置载体，所有的拓展点都是通过 URL 获取配置。这一点，官方文档中有所说明。 采用 URL 作为配置信息的统一格式，所有扩展点都通过传递 URL 携带配置信息。 接下来，我们先来分析配置检查部分的源码，随后再来分析 URL 组装部分的源码。 2.1.1 检查配置 本节我们接着前面的源码向下分析，前面说过 onApplicationEvent 方法在经过一些判断后，会决定是否调用 export 方法导出服务。那么下面我们从 export 方法开始进行分析，如下： public synchronized void export() { if (provider != null) { // 获取 export 和 delay 配置 if (export == null) { export = provider.getExport(); } if (delay == null) { delay = provider.getDelay(); } } // 如果 export 为 false，则不导出服务 if (export != null && !export) { return; } if (delay != null && delay > 0) { // delay > 0，延时导出服务 delayExportExecutor.schedule(new Runnable() { @Override public void run() { doExport(); } }, delay, TimeUnit.MILLISECONDS); } else { // 立即导出服务 doExport(); } } export 对两个配置进行了检查，并配置执行相应的动作。首先是 export，这个配置决定了是否导出服务。有时候我们只是想本地启动服务进行一些调试工作，这个时候我们并不希望把本地启动的服务暴露出去给别人调用。此时，我们就可以通过配置 export 禁止服务导出，比如： <dubbo:provider export="false" /> delay 见名知意了，用于延迟导出服务。下面，我们继续分析源码，这次要分析的是 doExport 方法。 protected synchronized void doExport() { if (unexported) { throw new IllegalStateException("Already unexported!"); } if (exported) { return; } exported = true; // 检测 interfaceName 是否合法 if (interfaceName == null || interfaceName.length() == 0) { throw new IllegalStateException("interface not allow null!"); } // 检测 provider 是否为空，为空则新建一个，并通过系统变量为其初始化 checkDefault(); // 下面几个 if 语句用于检测 provider、application 等核心配置类对象是否为空， // 若为空，则尝试从其他配置类对象中获取相应的实例。 if (provider != null) { if (application == null) { application = provider.getApplication(); } if (module == null) { module = provider.getModule(); } if (registries == null) {...} if (monitor == null) {...} if (protocols == null) {...} } if (module != null) { if (registries == null) { registries = module.getRegistries(); } if (monitor == null) {...} } if (application != null) { if (registries == null) { registries = application.getRegistries(); } if (monitor == null) {...} } // 检测 ref 是否泛化服务类型 if (ref instanceof GenericService) { // 设置 interfaceClass 为 GenericService.class interfaceClass = GenericService.class; if (StringUtils.isEmpty(generic)) { // 设置 generic = "true" generic = Boolean.TRUE.toString(); } } else { // ref 非 GenericService 类型 try { interfaceClass = Class.forName(interfaceName, true, Thread.currentThread() .getContextClassLoader()); } catch (ClassNotFoundException e) { throw new IllegalStateException(e.getMessage(), e); } // 对 interfaceClass，以及 <dubbo:method> 必要字段进行检查 checkInterfaceAndMethods(interfaceClass, methods); // 对 ref 合法性进行检测 checkRef(); // 设置 generic = "false" generic = Boolean.FALSE.toString(); } // local 属性 Dubbo 官方文档中没有说明，不过 local 和 stub 在功能应该是一致的，用于配置本地存根 if (local != null) { if ("true".equals(local)) { local = interfaceName + "Local"; } Class<?> localClass; try { // 获取本地存根类 localClass = ClassHelper.forNameWithThreadContextClassLoader(local); } catch (ClassNotFoundException e) { throw new IllegalStateException(e.getMessage(), e); } // 检测本地存根类是否可赋值给接口类，若不可赋值则会抛出异常，提醒使用者本地存根类类型不合法 if (!interfaceClass.isAssignableFrom(localClass)) { throw new IllegalStateException("The local implementation class " + localClass.getName() + " not implement interface " + interfaceName); } } // stub 和 local 均用于配置本地存根 if (stub != null) { // 此处的代码和上一个 if 分支的代码基本一致，这里省略了 } // 检测各种对象是否为空，为空则新建，或者抛出异常 checkApplication(); checkRegistry(); checkProtocol(); appendProperties(this); checkStubAndMock(interfaceClass); if (path == null || path.length() == 0) { path = interfaceName; } // 导出服务 doExportUrls(); // ProviderModel 表示服务提供者模型，此对象中存储了和服务提供者相关的信息。 // 比如服务的配置信息，服务实例等。每个被导出的服务对应一个 ProviderModel。 // ApplicationModel 持有所有的 ProviderModel。 ProviderModel providerModel = new ProviderModel(getUniqueServiceName(), this, ref); ApplicationModel.initProviderModel(getUniqueServiceName(), providerModel); } 以上就是配置检查的相关分析，代码比较多，需要大家耐心看一下。下面对配置检查的逻辑进行简单的总结，如下： 检测 <dubbo:service> 标签的 interface 属性合法性，不合法则抛出异常 检测 ProviderConfig、ApplicationConfig 等核心配置类对象是否为空，若为空，则尝试从其他配置类对象中获取相应的实例。 检测并处理泛化服务和普通服务类 检测本地存根配置，并进行相应的处理 对 ApplicationConfig、RegistryConfig 等配置类进行检测，为空则尝试创建，若无法创建则抛出异常 配置检查并非本文重点，因此我不打算对 doExport 方法所调用的方法进行分析（doExportUrls 方法除外）。在这些方法中，除了 appendProperties 方法稍微复杂一些，其他方法都还好。因此，大家可自行进行分析。好了，其他的就不多说了，继续向下分析。 2.1.2 多协议多注册中心导出服务 Dubbo 允许我们使用不同的协议导出服务，也允许我们向多个注册中心注册服务。Dubbo 在 doExportUrls 方法中对多协议，多注册中心进行了支持。相关代码如下： private void doExportUrls() { // 加载注册中心链接 List<URL> registryURLs = loadRegistries(true); // 遍历 protocols，导出每个服务 for (ProtocolConfig protocolConfig : protocols) { doExportUrlsFor1Protocol(protocolConfig, registryURLs); } } 上面代码比较简单，首先是通过 loadRegistries 加载注册中心链接，然后再遍历 ProtocolConfig 集合导出每个服务。并在导出服务的过程中，将服务注册到注册中心处。下面，我们先来看一下 loadRegistries 方法的逻辑。 protected List<URL> loadRegistries(boolean provider) { // 检测是否存在注册中心配置类，不存在则抛出异常 checkRegistry(); List<URL> registryList = new ArrayList<URL>(); if (registries != null && !registries.isEmpty()) { for (RegistryConfig config : registries) { String address = config.getAddress(); if (address == null || address.length() == 0) { // 若 address 为空，则将其设为 0.0.0.0 address = Constants.ANYHOST_VALUE; } // 从系统属性中加载注册中心地址 String sysaddress = System.getProperty("dubbo.registry.address"); if (sysaddress != null && sysaddress.length() > 0) { address = sysaddress; } // 判断 address 是否合法 if (address.length() > 0 && !RegistryConfig.NO_AVAILABLE.equalsIgnoreCase(address)) { Map<String, String> map = new HashMap<String, String>(); // 添加 ApplicationConfig 中的字段信息到 map 中 appendParameters(map, application); // 添加 RegistryConfig 字段信息到 map 中 appendParameters(map, config); map.put("path", RegistryService.class.getName()); map.put("dubbo", Version.getProtocolVersion()); map.put(Constants.TIMESTAMP_KEY, String.valueOf(System.currentTimeMillis())); if (ConfigUtils.getPid() > 0) { map.put(Constants.PID_KEY, String.valueOf(ConfigUtils.getPid())); } if (!map.containsKey("protocol")) { if (ExtensionLoader.getExtensionLoader(RegistryFactory.class).hasExtension("remote")) { map.put("protocol", "remote"); } else { map.put("protocol", "dubbo"); } } // 解析得到 URL 列表，address 可能包含多个注册中心 ip， // 因此解析得到的是一个 URL 列表 List<URL> urls = UrlUtils.parseURLs(address, map); for (URL url : urls) { url = url.addParameter(Constants.REGISTRY_KEY, url.getProtocol()); // 将 URL 协议头设置为 registry url = url.setProtocol(Constants.REGISTRY_PROTOCOL); // 通过判断条件，决定是否添加 url 到 registryList 中，条件如下： // (服务提供者 && register = true 或 null) // || (非服务提供者 && subscribe = true 或 null) if ((provider && url.getParameter(Constants.REGISTER_KEY, true)) || (!provider && url.getParameter(Constants.SUBSCRIBE_KEY, true))) { registryList.add(url); } } } } } return registryList; } 上面代码不是很复杂，包含如下逻辑： 检测是否存在注册中心配置类，不存在则抛出异常 构建参数映射集合，也就是 map 构建注册中心链接列表 遍历链接列表，并根据条件决定是否将其添加到 registryList 中 关于多协议多注册中心导出服务就先分析到这，代码不是很多，就不过多叙述了。接下来分析 URL 组装过程。 2.1.3 组装 URL 配置检查完毕后，紧接着要做的事情是根据配置，以及其他一些信息组装 URL。前面说过，URL 是 Dubbo 配置的载体，通过 URL 可让 Dubbo 的各种配置在各个模块之间传递。URL 之于 Dubbo，犹如水之于鱼，非常重要。大家在阅读 Dubbo 服务导出相关源码的过程中，要注意 URL 内容的变化。既然 URL 如此重要，那么下面我们来了解一下 URL 组装的过程。 private void doExportUrlsFor1Protocol(ProtocolConfig protocolConfig, List<URL> registryURLs) { String name = protocolConfig.getName(); // 如果协议名为空，或空串，则将协议名变量设置为 dubbo if (name == null || name.length() == 0) { name = "dubbo"; } Map<String, String> map = new HashMap<String, String>(); // 添加 side、版本、时间戳以及进程号等信息到 map 中 map.put(Constants.SIDE_KEY, Constants.PROVIDER_SIDE); map.put(Constants.DUBBO_VERSION_KEY, Version.getProtocolVersion()); map.put(Constants.TIMESTAMP_KEY, String.valueOf(System.currentTimeMillis())); if (ConfigUtils.getPid() > 0) { map.put(Constants.PID_KEY, String.valueOf(ConfigUtils.getPid())); } // 通过反射将对象的字段信息到 map 中 appendParameters(map, application); appendParameters(map, module); appendParameters(map, provider, Constants.DEFAULT_KEY); appendParameters(map, protocolConfig); appendParameters(map, this); // methods 为 MethodConfig 集合，MethodConfig 中存储了 <dubbo:method> 标签的配置信息 if (methods != null && !methods.isEmpty()) { // 这段代码用于添加 Callback 配置到 map 中，代码太长，待会单独分析 } // 检测 generic 是否为 "true"，并根据检测结果向 map 中添加不同的信息 if (ProtocolUtils.isGeneric(generic)) { map.put(Constants.GENERIC_KEY, generic); map.put(Constants.METHODS_KEY, Constants.ANY_VALUE); } else { String revision = Version.getVersion(interfaceClass, version); if (revision != null && revision.length() > 0) { map.put("revision", revision); } // 为接口生成包裹类 Wrapper，Wrapper 中包含了接口的详细信息，比如接口方法名数组，字段信息等 String[] methods = Wrapper.getWrapper(interfaceClass).getMethodNames(); // 添加方法名到 map 中，如果包含多个方法名，则用逗号隔开，比如 method = init,destroy if (methods.length == 0) { logger.warn("NO method found in service interface ..."); map.put(Constants.METHODS_KEY, Constants.ANY_VALUE); } else { // 将逗号作为分隔符连接方法名，并将连接后的字符串放入 map 中 map.put(Constants.METHODS_KEY, StringUtils.join(new HashSet<String>(Arrays.asList(methods)), ",")); } } // 添加 token 到 map 中 if (!ConfigUtils.isEmpty(token)) { if (ConfigUtils.isDefault(token)) { map.put(Constants.TOKEN_KEY, UUID.randomUUID().toString()); } else { map.put(Constants.TOKEN_KEY, token); } } // 判断协议名是否为 injvm if (Constants.LOCAL_PROTOCOL.equals(protocolConfig.getName())) { protocolConfig.setRegister(false); map.put("notify", "false"); } // 获取上下文路径 String contextPath = protocolConfig.getContextpath(); if ((contextPath == null || contextPath.length() == 0) && provider != null) { contextPath = provider.getContextpath(); } // 获取 host 和 port String host = this.findConfigedHosts(protocolConfig, registryURLs, map); Integer port = this.findConfigedPorts(protocolConfig, name, map); // 组装 URL URL url = new URL(name, host, port, (contextPath == null || contextPath.length() == 0 ? "" : contextPath + "/") + path, map); // 省略无关代码 } 上面的代码首先是将一些信息，比如版本、时间戳、方法名以及各种配置对象的字段信息放入到 map 中，map 中的内容将作为 URL 的查询字符串。构建好 map 后，紧接着是获取上下文路径、主机名以及端口号等信息。最后将 map 和主机名等数据传给 URL 构造方法创建 URL 对象。需要注意的是，这里出现的 URL 并非 java.net.URL，而是 com.alibaba.dubbo.common.URL。 上面省略了一段代码，这里简单分析一下。这段代码用于检测 <dubbo:argument> 标签中的配置信息，并将相关配置添加到 map 中。代码如下： private void doExportUrlsFor1Protocol(ProtocolConfig protocolConfig, List<URL> registryURLs) { // ... // methods 为 MethodConfig 集合，MethodConfig 中存储了 <dubbo:method> 标签的配置信息 if (methods != null && !methods.isEmpty()) { for (MethodConfig method : methods) { // 添加 MethodConfig 对象的字段信息到 map 中，键 = 方法名.属性名。 // 比如存储 <dubbo:method name="sayHello" retries="2"> 对应的 MethodConfig， // 键 = sayHello.retries，map = {"sayHello.retries": 2, "xxx": "yyy"} appendParameters(map, method, method.getName()); String retryKey = method.getName() + ".retry"; if (map.containsKey(retryKey)) { String retryValue = map.remove(retryKey); // 检测 MethodConfig retry 是否为 false，若是，则设置重试次数为0 if ("false".equals(retryValue)) { map.put(method.getName() + ".retries", "0"); } } // 获取 ArgumentConfig 列表 List<ArgumentConfig> arguments = method.getArguments(); if (arguments != null && !arguments.isEmpty()) { for (ArgumentConfig argument : arguments) { // 检测 type 属性是否为空，或者空串（分支1 ⭐️） if (argument.getType() != null && argument.getType().length() > 0) { Method[] methods = interfaceClass.getMethods(); if (methods != null && methods.length > 0) { for (int i = 0; i < methods.length; i++) { String methodName = methods[i].getName(); // 比对方法名，查找目标方法 if (methodName.equals(method.getName())) { Class<?>[] argtypes = methods[i].getParameterTypes(); if (argument.getIndex() != -1) { // 检测 ArgumentConfig 中的 type 属性与方法参数列表 // 中的参数名称是否一致，不一致则抛出异常(分支2 ⭐️) if (argtypes[argument.getIndex()].getName().equals(argument.getType())) { // 添加 ArgumentConfig 字段信息到 map 中， // 键前缀 = 方法名.index，比如: // map = {"sayHello.3": true} appendParameters(map, argument, method.getName() + "." + argument.getIndex()); } else { throw new IllegalArgumentException("argument config error: ..."); } } else { // 分支3 ⭐️ for (int j = 0; j < argtypes.length; j++) { Class<?> argclazz = argtypes[j]; // 从参数类型列表中查找类型名称为 argument.type 的参数 if (argclazz.getName().equals(argument.getType())) { appendParameters(map, argument, method.getName() + "." + j); if (argument.getIndex() != -1 && argument.getIndex() != j) { throw new IllegalArgumentException("argument config error: ..."); } } } } } } } // 用户未配置 type 属性，但配置了 index 属性，且 index != -1 } else if (argument.getIndex() != -1) { // 分支4 ⭐️ // 添加 ArgumentConfig 字段信息到 map 中 appendParameters(map, argument, method.getName() + "." + argument.getIndex()); } else { throw new IllegalArgumentException("argument config must set index or type"); } } } } } // ... } 上面这段代码 for 循环和 if else 分支嵌套太多，导致层次太深，不利于阅读，需要耐心看一下。大家在看这段代码时，注意把几个重要的条件分支找出来。只要理解了这几个分支的意图，就可以弄懂这段代码。我在上面代码中用⭐️符号标识出了4个重要的分支，下面用伪代码解释一下这几个分支的含义。 // 获取 ArgumentConfig 列表 for (遍历 ArgumentConfig 列表) { if (type 不为 null，也不为空串) { // 分支1 1. 通过反射获取 interfaceClass 的方法列表 for (遍历方法列表) { 1. 比对方法名，查找目标方法 2. 通过反射获取目标方法的参数类型数组 argtypes if (index != -1) { // 分支2 1. 从 argtypes 数组中获取下标 index 处的元素 argType 2. 检测 argType 的名称与 ArgumentConfig 中的 type 属性是否一致 3. 添加 ArgumentConfig 字段信息到 map 中，或抛出异常 } else { // 分支3 1. 遍历参数类型数组 argtypes，查找 argument.type 类型的参数 2. 添加 ArgumentConfig 字段信息到 map 中 } } } else if (index != -1) { // 分支4 1. 添加 ArgumentConfig 字段信息到 map 中 } } 在本节分析的源码中，appendParameters 这个方法出现的次数比较多，该方法用于将对象字段信息添加到 map 中。实现上则是通过反射获取目标对象的 getter 方法，并调用该方法获取属性值。然后再通过 getter 方法名解析出属性名，比如从方法名 getName 中可解析出属性 name。如果用户传入了属性名前缀，此时需要将属性名加入前缀内容。最后将 <属性名，属性值> 键值对存入到 map 中就行了。限于篇幅原因，这里就不分析 appendParameters 方法的源码了，大家请自行分析。 2.2 导出 Dubbo 服务 前置工作做完，接下来就可以进行服务导出工作。服务导出，分为导出到本地 (JVM)，和导出到远程。在深入分析服务导出源码前，我们先来从宏观层面上看一下服务导出逻辑。如下： private void doExportUrlsFor1Protocol(ProtocolConfig protocolConfig, List<URL> registryURLs) { // 省略无关代码 if (ExtensionLoader.getExtensionLoader(ConfiguratorFactory.class) .hasExtension(url.getProtocol())) { // 加载 ConfiguratorFactory，并生成 Configurator 配置 url url = ExtensionLoader.getExtensionLoader(ConfiguratorFactory.class) .getExtension(url.getProtocol()).getConfigurator(url).configure(url); } String scope = url.getParameter(Constants.SCOPE_KEY); // 如果 scope = none，则什么都不做 if (!Constants.SCOPE_NONE.toString().equalsIgnoreCase(scope)) { // scope != remote，导出到本地 if (!Constants.SCOPE_REMOTE.toString().equalsIgnoreCase(scope)) { exportLocal(url); } // scope != local，导出到远程 if (!Constants.SCOPE_LOCAL.toString().equalsIgnoreCase(scope)) { if (registryURLs != null && !registryURLs.isEmpty()) { for (URL registryURL : registryURLs) { url = url.addParameterIfAbsent(Constants.DYNAMIC_KEY, registryURL.getParameter(Constants.DYNAMIC_KEY)); // 加载监视器链接 URL monitorUrl = loadMonitor(registryURL); if (monitorUrl != null) { // 将监视器链接作为参数添加到 url 中 url = url.addParameterAndEncoded(Constants.MONITOR_KEY, monitorUrl.toFullString()); } String proxy = url.getParameter(Constants.PROXY_KEY); if (StringUtils.isNotEmpty(proxy)) { registryURL = registryURL.addParameter(Constants.PROXY_KEY, proxy); } // 为服务提供类(ref)生成 Invoker Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, registryURL.addParameterAndEncoded(Constants.EXPORT_KEY, url.toFullString())); // DelegateProviderMetaDataInvoker 仅用于持有 Invoker 和 ServiceConfig DelegateProviderMetaDataInvoker wrapperInvoker = new DelegateProviderMetaDataInvoker(invoker, this); // 导出服务，并生成 Exporter Exporter<?> exporter = protocol.export(wrapperInvoker); exporters.add(exporter); } } else { // 不存在注册中心，仅导出服务 Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, url); DelegateProviderMetaDataInvoker wrapperInvoker = new DelegateProviderMetaDataInvoker(invoker, this); Exporter<?> exporter = protocol.export(wrapperInvoker); exporters.add(exporter); } } } this.urls.add(url); } 上面代码根据 url 中的 scope 参数决定服务导出方式，分别如下： scope = none，不导出服务 scope != remote，导出到本地 scope != local，导出到远程 不管是导出到本地，还是远程。进行服务导出之前，均需要先创建 Invoker。这是一个很重要的步骤，因此接下来我会先分析 Invoker 的创建过程。 2.2.1 Invoker 创建过程 在 Dubbo 中，Invoker 是一个非常重要的模型。在服务提供端，以及服务引用端均会出现 Invoker。Dubbo 官方文档中对 Invoker 进行了说明，这里引用一下。 Invoker 是实体域，它是 Dubbo 的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起 invoke 调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。 既然 Invoker 如此重要，那么我们很有必要搞清楚 Invoker 的用途。Invoker 是由 ProxyFactory 创建而来，Dubbo 默认的 ProxyFactory 实现类是 JavassistProxyFactory。下面我们到 JavassistProxyFactory 代码中，探索 Invoker 的创建过程。如下： -- JavassistProxyFactory public <T> Invoker<T> getInvoker(T proxy, Class<T> type, URL url) { // 为目标类创建 Wrapper final Wrapper wrapper = Wrapper.getWrapper(proxy.getClass().getName().indexOf('$') < 0 ? proxy.getClass() : type); // 创建匿名 Invoker 类对象，并实现 doInvoke 方法。 return new AbstractProxyInvoker<T>(proxy, type, url) { @Override protected Object doInvoke(T proxy, String methodName, Class<?>[] parameterTypes, Object[] arguments) throws Throwable { // 调用 Wrapper 的 invokeMethod 方法，invokeMethod 最终会调用目标方法 return wrapper.invokeMethod(proxy, methodName, parameterTypes, arguments); } }; } 如上，JavassistProxyFactory 创建了一个继承自 AbstractProxyInvoker 类的匿名对象，并覆写了抽象方法 doInvoke。覆写后的 doInvoke 逻辑比较简单，仅是将调用请求转发给了 Wrapper 类的 invokeMethod 方法。Wrapper 用于“包裹”目标类，Wrapper 是一个抽象类，仅可通过 getWrapper(Class) 方法创建子类。在创建 Wrapper 子类的过程中，子类代码生成逻辑会对 getWrapper 方法传入的 Class 对象进行解析，拿到诸如类方法，类成员变量等信息。以及生成 invokeMethod 方法代码，和其他一些方法代码。代码生成完毕后，通过 Javassist 生成 Class 对象，最后再通过反射创建 Wrapper 实例。相关的代码如下： public static Wrapper getWrapper(Class<?> c) { while (ClassGenerator.isDynamicClass(c)) c = c.getSuperclass(); if (c == Object.class) return OBJECT_WRAPPER; // 访存 Wrapper ret = WRAPPER_MAP.get(c); if (ret == null) { // 缓存未命中，创建 Wrapper ret = makeWrapper(c); // 写入缓存 WRAPPER_MAP.put(c, ret); } return ret; } getWrapper 方法只是包含了一些缓存操作逻辑，非重点。下面我们重点关注 makeWrapper 方法。 private static Wrapper makeWrapper(Class<?> c) { // 检测 c 是否为私有类型，若是则抛出异常 if (c.isPrimitive()) throw new IllegalArgumentException("Can not create wrapper for primitive type: " + c); String name = c.getName(); ClassLoader cl = ClassHelper.getClassLoader(c); // c1 用于存储 setPropertyValue 方法代码 StringBuilder c1 = new StringBuilder("public void setPropertyValue(Object o, String n, Object v){ "); // c2 用于存储 getPropertyValue 方法代码 StringBuilder c2 = new StringBuilder("public Object getPropertyValue(Object o, String n){ "); // c3 用于存储 invokeMethod 方法代码 StringBuilder c3 = new StringBuilder("public Object invokeMethod(Object o, String n, Class[] p, Object[] v) throws " + InvocationTargetException.class.getName() + "{ "); // 生成类型转换代码及异常捕捉代码，比如： // DemoService w; try { w = ((DemoServcie) $1); }}catch(Throwable e){ throw new IllegalArgumentException(e); } c1.append(name).append(" w; try{ w = ((").append(name).append(")$1); }catch(Throwable e){ throw new IllegalArgumentException(e); }"); c2.append(name).append(" w; try{ w = ((").append(name).append(")$1); }catch(Throwable e){ throw new IllegalArgumentException(e); }"); c3.append(name).append(" w; try{ w = ((").append(name).append(")$1); }catch(Throwable e){ throw new IllegalArgumentException(e); }"); // pts 用于存储成员变量名和类型 Map<String, Class<?>> pts = new HashMap<String, Class<?>>(); // ms 用于存储方法描述信息（可理解为方法签名）及 Method 实例 Map<String, Method> ms = new LinkedHashMap<String, Method>(); // mns 为方法名列表 List<String> mns = new ArrayList<String>(); // dmns 用于存储定义在当前类中的方法的名称 List<String> dmns = new ArrayList<String>(); // -------------------------------- 分割线1 ------------------------------------- // 获取 public 访问级别的字段，并为所有字段生成条件判断语句 for (Field f : c.getFields()) { String fn = f.getName(); Class<?> ft = f.getType(); if (Modifier.isStatic(f.getModifiers()) || Modifier.isTransient(f.getModifiers())) // 忽略关键字 static 或 transient 修饰的变量 continue; // 生成条件判断及赋值语句，比如： // if( $2.equals("name") ) { w.name = (java.lang.String) $3; return;} // if( $2.equals("age") ) { w.age = ((Number) $3).intValue(); return;} c1.append(" if( $2.equals(\"").append(fn).append("\") ){ w.").append(fn).append("=").append(arg(ft, "$3")).append("; return; }"); // 生成条件判断及返回语句，比如： // if( $2.equals("name") ) { return ($w)w.name; } c2.append(" if( $2.equals(\"").append(fn).append("\") ){ return ($w)w.").append(fn).append("; }"); // 存储 <字段名, 字段类型> 键值对到 pts 中 pts.put(fn, ft); } // -------------------------------- 分割线2 ------------------------------------- Method[] methods = c.getMethods(); // 检测 c 中是否包含在当前类中声明的方法 boolean hasMethod = hasMethods(methods); if (hasMethod) { c3.append(" try{"); } for (Method m : methods) { if (m.getDeclaringClass() == Object.class) // 忽略 Object 中定义的方法 continue; String mn = m.getName(); // 生成方法名判断语句，示例如下： // if ( "sayHello".equals( $2 ) c3.append(" if( \"").append(mn).append("\".equals( $2 ) "); int len = m.getParameterTypes().length; // 生成运行时传入参数的数量与方法的参数列表长度判断语句，示例如下： // && $3.length == 2 c3.append(" && ").append(" $3.length == ").append(len); boolean override = false; for (Method m2 : methods) { // 检测方法是否存在重载情况，条件为：方法对象不同 && 方法名相同 if (m != m2 && m.getName().equals(m2.getName())) { override = true; break; } } // 对重载方法进行处理，考虑下面的方法： // 1. void sayHello(Integer, String) // 2. void sayHello(Integer, Integer) // 方法名相同，参数列表长度也相同，因此不能仅通过这两项判断两个方法是否相等。 // 需要进一步判断方法的参数类型 if (override) { if (len > 0) { for (int l = 0; l < len; l++) { // && $3[0].getName().equals("java.lang.Integer") // && $3[1].getName().equals("java.lang.String") c3.append(" && ").append(" $3[").append(l).append("].getName().equals(\"") .append(m.getParameterTypes()[l].getName()).append("\")"); } } } // 添加 ) {，完成方法判断语句，此时生成的方法可能如下（已格式化）： // if ("sayHello".equals($2) // && $3.length == 2 // && $3[0].getName().equals("java.lang.Integer") // && $3[1].getName().equals("java.lang.String")) { c3.append(" ) { "); // 根据返回值类型生成目标方法调用语句 if (m.getReturnType() == Void.TYPE) // w.sayHello((java.lang.Integer)$4[0], (java.lang.String)$4[1]); return null; c3.append(" w.").append(mn).append('(').append(args(m.getParameterTypes(), "$4")).append(");").append(" return null;"); else // return w.sayHello((java.lang.Integer)$4[0], (java.lang.String)$4[1]); c3.append(" return ($w)w.").append(mn).append('(').append(args(m.getParameterTypes(), "$4")).append(");"); // 添加 }, 当前”方法判断条件“代码生成完毕，示例代码如下（已格式化）： // if ("sayHello".equals($2) // && $3.length == 2 // && $3[0].getName().equals("java.lang.Integer") // && $3[1].getName().equals("java.lang.String")) { // // w.sayHello((java.lang.Integer)$4[0], (java.lang.String)$4[1]); // return null; // } c3.append(" }"); // 添加方法名到 mns 集合中 mns.add(mn); // 检测当前方法是否在 c 中被声明的 if (m.getDeclaringClass() == c) // 若是，则将当前方法名添加到 dmns 中 dmns.add(mn); ms.put(ReflectUtils.getDesc(m), m); } if (hasMethod) { // 添加异常捕捉语句 c3.append(" } catch(Throwable e) { "); c3.append(" throw new java.lang.reflect.InvocationTargetException(e); "); c3.append(" }"); } // 添加 NoSuchMethodException 异常抛出代码 c3.append(" throw new " + NoSuchMethodException.class.getName() + "(\"Not found method \\\"\"+$2+\"\\\" in class " + c.getName() + ".\"); }"); // -------------------------------- 分割线3 ------------------------------------- Matcher matcher; // 处理 get/set 方法 for (Map.Entry<String, Method> entry : ms.entrySet()) { String md = entry.getKey(); Method method = (Method) entry.getValue(); // 匹配以 get 开头的方法 if ((matcher = ReflectUtils.GETTER_METHOD_DESC_PATTERN.matcher(md)).matches()) { // 获取属性名 String pn = propertyName(matcher.group(1)); // 生成属性判断以及返回语句，示例如下： // if( $2.equals("name") ) { return ($w).w.getName(); } c2.append(" if( $2.equals(\"").append(pn).append("\") ){ return ($w)w.").append(method.getName()).append("(); }"); pts.put(pn, method.getReturnType()); // 匹配以 is/has/can 开头的方法 } else if ((matcher = ReflectUtils.IS_HAS_CAN_METHOD_DESC_PATTERN.matcher(md)).matches()) { String pn = propertyName(matcher.group(1)); // 生成属性判断以及返回语句，示例如下： // if( $2.equals("dream") ) { return ($w).w.hasDream(); } c2.append(" if( $2.equals(\"").append(pn).append("\") ){ return ($w)w.").append(method.getName()).append("(); }"); pts.put(pn, method.getReturnType()); // 匹配以 set 开头的方法 } else if ((matcher = ReflectUtils.SETTER_METHOD_DESC_PATTERN.matcher(md)).matches()) { Class<?> pt = method.getParameterTypes()[0]; String pn = propertyName(matcher.group(1)); // 生成属性判断以及 setter 调用语句，示例如下： // if( $2.equals("name") ) { w.setName((java.lang.String)$3); return; } c1.append(" if( $2.equals(\"").append(pn).append("\") ){ w.").append(method.getName()).append("(").append(arg(pt, "$3")).append("); return; }"); pts.put(pn, pt); } } // 添加 NoSuchPropertyException 异常抛出代码 c1.append(" throw new " + NoSuchPropertyException.class.getName() + "(\"Not found property \\\"\"+$2+\"\\\" filed or setter method in class " + c.getName() + ".\"); }"); c2.append(" throw new " + NoSuchPropertyException.class.getName() + "(\"Not found property \\\"\"+$2+\"\\\" filed or setter method in class " + c.getName() + ".\"); }"); // -------------------------------- 分割线4 ------------------------------------- long id = WRAPPER_CLASS_COUNTER.getAndIncrement(); // 创建类生成器 ClassGenerator cc = ClassGenerator.newInstance(cl); // 设置类名及超类 cc.setClassName((Modifier.isPublic(c.getModifiers()) ? Wrapper.class.getName() : c.getName() + "$sw") + id); cc.setSuperClass(Wrapper.class); // 添加默认构造方法 cc.addDefaultConstructor(); // 添加字段 cc.addField("public static String[] pns;"); cc.addField("public static " + Map.class.getName() + " pts;"); cc.addField("public static String[] mns;"); cc.addField("public static String[] dmns;"); for (int i = 0, len = ms.size(); i < len; i++) cc.addField("public static Class[] mts" + i + ";"); // 添加方法代码 cc.addMethod("public String[] getPropertyNames(){ return pns; }"); cc.addMethod("public boolean hasProperty(String n){ return pts.containsKey($1); }"); cc.addMethod("public Class getPropertyType(String n){ return (Class)pts.get($1); }"); cc.addMethod("public String[] getMethodNames(){ return mns; }"); cc.addMethod("public String[] getDeclaredMethodNames(){ return dmns; }"); cc.addMethod(c1.toString()); cc.addMethod(c2.toString()); cc.addMethod(c3.toString()); try { // 生成类 Class<?> wc = cc.toClass(); // 设置字段值 wc.getField("pts").set(null, pts); wc.getField("pns").set(null, pts.keySet().toArray(new String[0])); wc.getField("mns").set(null, mns.toArray(new String[0])); wc.getField("dmns").set(null, dmns.toArray(new String[0])); int ix = 0; for (Method m : ms.values()) wc.getField("mts" + ix++).set(null, m.getParameterTypes()); // 创建 Wrapper 实例 return (Wrapper) wc.newInstance(); } catch (RuntimeException e) { throw e; } catch (Throwable e) { throw new RuntimeException(e.getMessage(), e); } finally { cc.release(); ms.clear(); mns.clear(); dmns.clear(); } } 上面代码很长，大家耐心看一下。我在上面代码中做了大量的注释，并按功能对代码进行了分块，以帮助大家理解代码逻辑。下面对这段代码进行讲解。首先我们把目光移到分割线1之上的代码，这段代码主要用于进行一些初始化操作。比如创建 c1、c2、c3 以及 pts、ms、mns 等变量，以及向 c1、c2、c3 中添加方法定义和类型类型转换代码。接下来是分割线1到分割线2之间的代码，这段代码用于为 public 级别的字段生成条件判断取值与赋值代码。这段代码不是很难看懂，就不多说了。继续向下看，分割线2和分隔线3之间的代码用于为定义在当前类中的方法生成判断语句，和方法调用语句。因为需要对方法重载进行校验，因此到这这段代码看起来有点复杂。不过耐心开一下，也不是很难理解。接下来是分割线3和分隔线4之间的代码，这段代码用于处理 getter、setter 以及以 is/has/can 开头的方法。处理方式是通过正则表达式获取方法类型（get/set/is/...），以及属性名。之后为属性名生成判断语句，然后为方法生成调用语句。最后我们再来看一下分隔线4以下的代码，这段代码通过 ClassGenerator 为刚刚生成的代码构建 Class 类，并通过反射创建对象。ClassGenerator 是 Dubbo 自己封装的，该类的核心是 toClass() 的重载方法 toClass(ClassLoader, ProtectionDomain)，该方法通过 javassist 构建 Class。这里就不分析 toClass 方法了，大家请自行分析。 阅读 Wrapper 类代码需要对 javassist 框架有所了解。关于 javassist，大家如果不熟悉，请自行查阅资料，本节不打算介绍 javassist 相关内容。 好了，关于 Wrapper 类生成过程就分析到这。如果大家看的不是很明白，可以单独为 Wrapper 创建单元测试，然后单步调试。并将生成的代码拷贝出来，格式化后再进行观察和理解。好了，本节先到这。 2.2.2 导出服务到本地 本节我们来看一下服务导出相关的代码，按照代码执行顺序，本节先来分析导出服务到本地的过程。相关代码如下： private void exportLocal(URL url) { // 如果 URL 的协议头等于 injvm，说明已经导出到本地了，无需再次导出 if (!Constants.LOCAL_PROTOCOL.equalsIgnoreCase(url.getProtocol())) { URL local = URL.valueOf(url.toFullString()) .setProtocol(Constants.LOCAL_PROTOCOL) // 设置协议头为 injvm .setHost(LOCALHOST) .setPort(0); ServiceClassHolder.getInstance().pushServiceClass(getServiceClass(ref)); // 创建 Invoker，并导出服务，这里的 protocol 会在运行时调用 InjvmProtocol 的 export 方法 Exporter<?> exporter = protocol.export( proxyFactory.getInvoker(ref, (Class) interfaceClass, local)); exporters.add(exporter); } } exportLocal 方法比较简单，首先根据 URL 协议头决定是否导出服务。若需导出，则创建一个新的 URL 并将协议头、主机名以及端口设置成新的值。然后创建 Invoker，并调用 InjvmProtocol 的 export 方法导出服务。下面我们来看一下 InjvmProtocol 的 export 方法都做了哪些事情。 public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException { // 创建 InjvmExporter return new InjvmExporter<T>(invoker, invoker.getUrl().getServiceKey(), exporterMap); } 如上，InjvmProtocol 的 export 方法仅创建了一个 InjvmExporter，无其他逻辑。到此导出服务到本地就分析完了，接下来，我们继续分析导出服务到远程的过程。 2.2.3 导出服务到远程 与导出服务到本地相比，导出服务到远程的过程要复杂不少，其包含了服务导出与服务注册两个过程。这两个过程涉及到了大量的调用，因此比较复杂。不过不管再难，我们都要看一下，万一看懂了呢。按照代码执行顺序，本节先来分析服务导出逻辑，服务注册逻辑将在下一节进行分析。下面开始分析，我们把目光移动到 RegistryProtocol 的 export 方法上。 public <T> Exporter<T> export(final Invoker<T> originInvoker) throws RpcException { // 导出服务 final ExporterChangeableWrapper<T> exporter = doLocalExport(originInvoker); // 获取注册中心 URL，以 zookeeper 注册中心为例，得到的示例 URL 如下： // zookeeper://127.0.0.1:2181/com.alibaba.dubbo.registry.RegistryService?application=demo-provider&dubbo=2.0.2&export=dubbo%3A%2F%2F172.17.48.52%3A20880%2Fcom.alibaba.dubbo.demo.DemoService%3Fanyhost%3Dtrue%26application%3Ddemo-provider URL registryUrl = getRegistryUrl(originInvoker); // 根据 URL 加载 Registry 实现类，比如 ZookeeperRegistry final Registry registry = getRegistry(originInvoker); // 获取已注册的服务提供者 URL，比如： // dubbo://172.17.48.52:20880/com.alibaba.dubbo.demo.DemoService?anyhost=true&application=demo-provider&dubbo=2.0.2&generic=false&interface=com.alibaba.dubbo.demo.DemoService&methods=sayHello final URL registeredProviderUrl = getRegisteredProviderUrl(originInvoker); // 获取 register 参数 boolean register = registeredProviderUrl.getParameter("register", true); // 向服务提供者与消费者注册表中注册服务提供者 ProviderConsumerRegTable.registerProvider(originInvoker, registryUrl, registeredProviderUrl); // 根据 register 的值决定是否注册服务 if (register) { // 向注册中心注册服务 register(registryUrl, registeredProviderUrl); ProviderConsumerRegTable.getProviderWrapper(originInvoker).setReg(true); } // 获取订阅 URL，比如： // provider://172.17.48.52:20880/com.alibaba.dubbo.demo.DemoService?category=configurators&check=false&anyhost=true&application=demo-provider&dubbo=2.0.2&generic=false&interface=com.alibaba.dubbo.demo.DemoService&methods=sayHello final URL overrideSubscribeUrl = getSubscribedOverrideUrl(registeredProviderUrl); // 创建监听器 final OverrideListener overrideSubscribeListener = new OverrideListener(overrideSubscribeUrl, originInvoker); overrideListeners.put(overrideSubscribeUrl, overrideSubscribeListener); // 向注册中心进行订阅 override 数据 registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener); // 创建并返回 DestroyableExporter return new DestroyableExporter<T>(exporter, originInvoker, overrideSubscribeUrl, registeredProviderUrl); } 上面代码看起来比较复杂，主要做如下一些操作： 调用 doLocalExport 导出服务 向注册中心注册服务 向注册中心进行订阅 override 数据 创建并返回 DestroyableExporter 在以上操作中，除了创建并返回 DestroyableExporter 没啥难度外，其他几步操作都不是很简单。这其中，导出服务和注册服务是本章要重点分析的逻辑。 订阅 override 数据这个是非重点内容，后面会简单介绍一下。下面开始本节的分析，先来分析 doLocalExport 方法的逻辑，如下： private <T> ExporterChangeableWrapper<T> doLocalExport(final Invoker<T> originInvoker) { String key = getCacheKey(originInvoker); // 访问缓存 ExporterChangeableWrapper<T> exporter = (ExporterChangeableWrapper<T>) bounds.get(key); if (exporter == null) { synchronized (bounds) { exporter = (ExporterChangeableWrapper<T>) bounds.get(key); if (exporter == null) { // 创建 Invoker 为委托类对象 final Invoker<?> invokerDelegete = new InvokerDelegete<T>(originInvoker, getProviderUrl(originInvoker)); // 调用 protocol 的 export 方法导出服务 exporter = new ExporterChangeableWrapper<T>((Exporter<T>) protocol.export(invokerDelegete), originInvoker); // 写缓存 bounds.put(key, exporter); } } } return exporter; } 上面的代码是典型的双重检查，这个大家应该都知道。接下来，我们把重点放在 Protocol 的 export 方法上。假设运行时协议为 dubbo，此处的 protocol 会在运行时加载 DubboProtocol，并调用 DubboProtocol 的 export 方法。我们目光转移到 DubboProtocol 的 export 方法上，相关分析如下： public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException { URL url = invoker.getUrl(); // 获取服务标识，理解成服务坐标也行。由服务组名，服务名，服务版本号以及端口组成。比如： // demoGroup/com.alibaba.dubbo.demo.DemoService:1.0.1:20880 String key = serviceKey(url); // 创建 DubboExporter DubboExporter<T> exporter = new DubboExporter<T>(invoker, key, exporterMap); // 将 <key, exporter> 键值对放入缓存中 exporterMap.put(key, exporter); // 以下代码应该和本地存根有关，代码不难看懂，但具体用途暂时不清楚，先忽略 Boolean isStubSupportEvent = url.getParameter(Constants.STUB_EVENT_KEY, Constants.DEFAULT_STUB_EVENT); Boolean isCallbackservice = url.getParameter(Constants.IS_CALLBACK_SERVICE, false); if (isStubSupportEvent && !isCallbackservice) { String stubServiceMethods = url.getParameter(Constants.STUB_EVENT_METHODS_KEY); if (stubServiceMethods == null || stubServiceMethods.length() == 0) { // 省略日志打印代码 } else { stubServiceMethodsMap.put(url.getServiceKey(), stubServiceMethods); } } // 启动服务器 openServer(url); // 优化序列化 optimizeSerialization(url); return exporter; } 如上，我们重点关注 DubboExporter 的创建以及 openServer 方法，其他逻辑看不懂也没关系，不影响理解服务导出过程。另外，DubboExporter 的代码比较简单，就不分析了。下面分析 openServer 方法。 private void openServer(URL url) { // 获取 host:port，并将其作为服务器实例的 key，用于标识当前的服务器实例 String key = url.getAddress(); boolean isServer = url.getParameter(Constants.IS_SERVER_KEY, true); if (isServer) { // 访问缓存 ExchangeServer server = serverMap.get(key); if (server == null) { // 创建服务器实例 serverMap.put(key, createServer(url)); } else { // 服务器已创建，则根据 url 中的配置重置服务器 server.reset(url); } } } 如上，在同一台机器上（单网卡），同一个端口上仅允许启动一个服务器实例。若某个端口上已有服务器实例，此时则调用 reset 方法重置服务器的一些配置。考虑到篇幅问题，关于服务器实例重置的代码就不分析了。接下来分析服务器实例的创建过程。如下： private ExchangeServer createServer(URL url) { url = url.addParameterIfAbsent(Constants.CHANNEL_READONLYEVENT_SENT_KEY, // 添加心跳检测配置到 url 中 url = url.addParameterIfAbsent(Constants.HEARTBEAT_KEY, String.valueOf(Constants.DEFAULT_HEARTBEAT)); // 获取 server 参数，默认为 netty String str = url.getParameter(Constants.SERVER_KEY, Constants.DEFAULT_REMOTING_SERVER); // 通过 SPI 检测是否存在 server 参数所代表的 Transporter 拓展，不存在则抛出异常 if (str != null && str.length() > 0 && !ExtensionLoader.getExtensionLoader(Transporter.class).hasExtension(str)) throw new RpcException("Unsupported server type: " + str + ", url: " + url); // 添加编码解码器参数 url = url.addParameter(Constants.CODEC_KEY, DubboCodec.NAME); ExchangeServer server; try { // 创建 ExchangeServer server = Exchangers.bind(url, requestHandler); } catch (RemotingException e) { throw new RpcException("Fail to start server..."); } // 获取 client 参数，可指定 netty，mina str = url.getParameter(Constants.CLIENT_KEY); if (str != null && str.length() > 0) { // 获取所有的 Transporter 实现类名称集合，比如 supportedTypes = [netty, mina] Set<String> supportedTypes = ExtensionLoader.getExtensionLoader(Transporter.class).getSupportedExtensions(); // 检测当前 Dubbo 所支持的 Transporter 实现类名称列表中， // 是否包含 client 所表示的 Transporter，若不包含，则抛出异常 if (!supportedTypes.contains(str)) { throw new RpcException("Unsupported client type..."); } } return server; } 如上，createServer 包含三个核心的操作。第一是检测是否存在 server 参数所代表的 Transporter 拓展，不存在则抛出异常。第二是创建服务器实例。第三是检测是否支持 client 参数所表示的 Transporter 拓展，不存在也是抛出异常。两次检测操作所对应的代码比较直白了，无需多说。但创建服务器的操作目前还不是很清晰，我们继续往下看。 public static ExchangeServer bind(URL url, ExchangeHandler handler) throws RemotingException { if (url == null) { throw new IllegalArgumentException("url == null"); } if (handler == null) { throw new IllegalArgumentException("handler == null"); } url = url.addParameterIfAbsent(Constants.CODEC_KEY, "exchange"); // 获取 Exchanger，默认为 HeaderExchanger。 // 紧接着调用 HeaderExchanger 的 bind 方法创建 ExchangeServer 实例 return getExchanger(url).bind(url, handler); } 上面代码比较简单，就不多说了。下面看一下 HeaderExchanger 的 bind 方法。 public ExchangeServer bind(URL url, ExchangeHandler handler) throws RemotingException { // 创建 HeaderExchangeServer 实例，该方法包含了多步操作，本别如下： // 1. new HeaderExchangeHandler(handler) // 2. new DecodeHandler(new HeaderExchangeHandler(handler)) // 3. Transporters.bind(url, new DecodeHandler(new HeaderExchangeHandler(handler))) return new HeaderExchangeServer(Transporters.bind(url, new DecodeHandler(new HeaderExchangeHandler(handler)))); } HeaderExchanger 的 bind 方法包含的逻辑比较多，但目前我们仅需关心 Transporters 的 bind 方法逻辑即可。该方法的代码如下： public static Server bind(URL url, ChannelHandler... handlers) throws RemotingException { if (url == null) { throw new IllegalArgumentException("url == null"); } if (handlers == null || handlers.length == 0) { throw new IllegalArgumentException("handlers == null"); } ChannelHandler handler; if (handlers.length == 1) { handler = handlers[0]; } else { // 如果 handlers 元素数量大于1，则创建 ChannelHandler 分发器 handler = new ChannelHandlerDispatcher(handlers); } // 获取自适应 Transporter 实例，并调用实例方法 return getTransporter().bind(url, handler); } 如上，getTransporter() 方法获取的 Transporter 是在运行时动态创建的，类名为 Transporter$Adaptive，也就是自适应拓展类。我在上一篇文章中详细分析了自适应拓展类的生成过程，对自适应拓展类不了解的同学可以参考我之前的文章，这里不再赘述。Transporter$Adaptive 会在运行时根据传入的 URL 参数决定加载什么类型的 Transporter，默认为 NettyTransporter。下面我们继续跟下去，这次分析的是 NettyTransporter 的 bind 方法。 public Server bind(URL url, ChannelHandler listener) throws RemotingException { // 创建 NettyServer return new NettyServer(url, listener); } 这里仅有一句创建 NettyServer 的代码，没啥好讲的，我们继续向下看。 public class NettyServer extends AbstractServer implements Server { public NettyServer(URL url, ChannelHandler handler) throws RemotingException { // 调用父类构造方法 super(url, ChannelHandlers.wrap(handler, ExecutorUtil.setThreadName(url, SERVER_THREAD_POOL_NAME))); } } public abstract class AbstractServer extends AbstractEndpoint implements Server { public AbstractServer(URL url, ChannelHandler handler) throws RemotingException { // 调用父类构造方法，这里就不用跟进去了，没什么复杂逻辑 super(url, handler); localAddress = getUrl().toInetSocketAddress(); // 获取 ip 和端口 String bindIp = getUrl().getParameter(Constants.BIND_IP_KEY, getUrl().getHost()); int bindPort = getUrl().getParameter(Constants.BIND_PORT_KEY, getUrl().getPort()); if (url.getParameter(Constants.ANYHOST_KEY, false) || NetUtils.isInvalidLocalHost(bindIp)) { // 设置 ip 为 0.0.0.0 bindIp = NetUtils.ANYHOST; } bindAddress = new InetSocketAddress(bindIp, bindPort); // 获取最大可接受连接数 this.accepts = url.getParameter(Constants.ACCEPTS_KEY, Constants.DEFAULT_ACCEPTS); this.idleTimeout = url.getParameter(Constants.IDLE_TIMEOUT_KEY, Constants.DEFAULT_IDLE_TIMEOUT); try { // 调用模板方法 doOpen 启动服务器 doOpen(); } catch (Throwable t) { throw new RemotingException("Failed to bind "); } DataStore dataStore = ExtensionLoader.getExtensionLoader(DataStore.class).getDefaultExtension(); executor = (ExecutorService) dataStore.get(Constants.EXECUTOR_SERVICE_COMPONENT_KEY, Integer.toString(url.getPort())); } protected abstract void doOpen() throws Throwable; protected abstract void doClose() throws Throwable; } 上面多数代码为赋值代码，不需要多讲。我们重点关注 doOpen 抽象方法，该方法需要子类实现。下面回到 NettyServer 中。 protected void doOpen() throws Throwable { NettyHelper.setNettyLoggerFactory(); // 创建 boss 和 worker 线程池 ExecutorService boss = Executors.newCachedThreadPool(new NamedThreadFactory("NettyServerBoss", true)); ExecutorService worker = Executors.newCachedThreadPool(new NamedThreadFactory("NettyServerWorker", true)); ChannelFactory channelFactory = new NioServerSocketChannelFactory(boss, worker, getUrl().getPositiveParameter(Constants.IO_THREADS_KEY, Constants.DEFAULT_IO_THREADS)); // 创建 ServerBootstrap bootstrap = new ServerBootstrap(channelFactory); final NettyHandler nettyHandler = new NettyHandler(getUrl(), this); channels = nettyHandler.getChannels(); bootstrap.setOption("child.tcpNoDelay", true); // 设置 PipelineFactory bootstrap.setPipelineFactory(new ChannelPipelineFactory() { @Override public ChannelPipeline getPipeline() { NettyCodecAdapter adapter = new NettyCodecAdapter(getCodec(), getUrl(), NettyServer.this); ChannelPipeline pipeline = Channels.pipeline(); pipeline.addLast("decoder", adapter.getDecoder()); pipeline.addLast("encoder", adapter.getEncoder()); pipeline.addLast("handler", nettyHandler); return pipeline; } }); // 绑定到指定的 ip 和端口上 channel = bootstrap.bind(getBindAddress()); } 以上就是 NettyServer 创建的过程，dubbo 默认使用的 NettyServer 是基于 netty 3.x 版本实现的，比较老了。因此 Dubbo 中另外提供了 netty 4.x 版本的 NettyServer，大家可在使用 Dubbo 的过程中按需进行配置。 到此，关于服务导出的过程就分析完了。整个过程比较复杂，大家在分析的过程中耐心一些。并且多写 Demo 进行进行调试，以便能够更好的理解代码逻辑。好了，本节内容先到这里，接下来分析服务导出的另一块逻辑 -- 服务注册。 2.2.4 服务注册 本节我们来分析服务注册过程，服务注册操作对于 Dubbo 来说不是必需的，通过服务直连的方式就可以绕过注册中心。但通常我们不会这么做，直连方式不利于服务治理，仅推荐在测试环境测试服务时使用。对于 Dubbo 来说，注册中心虽不是必需，但却是必要的。因此，关于注册中心以及服务注册相关逻辑，我们也需要搞懂。 本节内容以 Zookeeper 注册中心作为分析目标，其他类型注册中心大家可自行分析。下面从服务注册的入口方法开始分析，我们把目光再次移到 RegistryProtocol 的 export 方法上。如下： public <T> Exporter<T> export(final Invoker<T> originInvoker) throws RpcException { // ${导出服务} // 省略其他代码 boolean register = registeredProviderUrl.getParameter("register", true); if (register) { // 注册服务 register(registryUrl, registeredProviderUrl); ProviderConsumerRegTable.getProviderWrapper(originInvoker).setReg(true); } final URL overrideSubscribeUrl = getSubscribedOverrideUrl(registeredProviderUrl); final OverrideListener overrideSubscribeListener = new OverrideListener(overrideSubscribeUrl, originInvoker); overrideListeners.put(overrideSubscribeUrl, overrideSubscribeListener); // 订阅 override 数据 registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener); // 省略部分代码 } RegistryProtocol 的 export 方法包含了服务导出，注册，以及数据订阅等逻辑。其中服务导出逻辑上一节已经分析过了，本节将分析服务注册逻辑，数据订阅逻辑将在下一节进行分析。下面开始本节的分析，相关代码如下： public void register(URL registryUrl, URL registedProviderUrl) { // 获取 Registry Registry registry = registryFactory.getRegistry(registryUrl); // 注册服务 registry.register(registedProviderUrl); } register 方法包含两步操作，第一步是获取注册中心实例，第二步是向注册中心注册服务。接下来，我分两节内容对这两步操作进行分析。按照顺序，先来分析获取注册中心的逻辑。 2.2.4.1 创建注册中心 本节内容以 Zookeeper 注册中心为例进行分析。下面先来看一下 getRegistry 方法的源码，这个方法由 AbstractRegistryFactory 实现。如下： public Registry getRegistry(URL url) { url = url.setPath(RegistryService.class.getName()) .addParameter(Constants.INTERFACE_KEY, RegistryService.class.getName()) .removeParameters(Constants.EXPORT_KEY, Constants.REFER_KEY); String key = url.toServiceString(); LOCK.lock(); try { // 访问缓存 Registry registry = REGISTRIES.get(key); if (registry != null) { return registry; } // 缓存未命中，创建 Registry 实例 registry = createRegistry(url); if (registry == null) { throw new IllegalStateException("Can not create registry..."); } // 写入缓存 REGISTRIES.put(key, registry); return registry; } finally { LOCK.unlock(); } } protected abstract Registry createRegistry(URL url); 如上，getRegistry 方法先访问缓存，缓存未命中则调用 createRegistry 创建 Registry，然后写入缓存。这里的 createRegistry 是一个模板方法，由具体的子类实现。因此，下面我们到 ZookeeperRegistryFactory 中探究一番。 public class ZookeeperRegistryFactory extends AbstractRegistryFactory { // zookeeperTransporter 由 SPI 在运行时注入，类型为 ZookeeperTransporter$Adaptive private ZookeeperTransporter zookeeperTransporter; public void setZookeeperTransporter(ZookeeperTransporter zookeeperTransporter) { this.zookeeperTransporter = zookeeperTransporter; } @Override public Registry createRegistry(URL url) { // 创建 ZookeeperRegistry return new ZookeeperRegistry(url, zookeeperTransporter); } } ZookeeperRegistryFactory 的 createRegistry 方法仅包含一句代码，无需解释，继续跟下去。 public ZookeeperRegistry(URL url, ZookeeperTransporter zookeeperTransporter) { super(url); if (url.isAnyHost()) { throw new IllegalStateException("registry address == null"); } // 获取组名，默认为 dubbo String group = url.getParameter(Constants.GROUP_KEY, DEFAULT_ROOT); if (!group.startsWith(Constants.PATH_SEPARATOR)) { // group = "/" + group group = Constants.PATH_SEPARATOR + group; } this.root = group; // 创建 Zookeeper 客户端，默认为 CuratorZookeeperTransporter zkClient = zookeeperTransporter.connect(url); // 添加状态监听器 zkClient.addStateListener(new StateListener() { @Override public void stateChanged(int state) { if (state == RECONNECTED) { try { recover(); } catch (Exception e) { logger.error(e.getMessage(), e); } } } }); } 在上面的代码代码中，我们重点关注 ZookeeperTransporter 的 connect 方法调用，这个方法用于创建 Zookeeper 客户端。创建好 Zookeeper 客户端，意味着注册中心的创建过程就结束了。不过，显然我们不能就此停止，难道大家没有兴趣了解一下 Zookeeper 客户端的创建过程吗？如果有，那么继续向下看。没有的话，直接跳到下一节。那我接着分析了。 前面说过，这里的 zookeeperTransporter 类型为自适应拓展类，因此 connect 方法会在被调用时决定加载什么类型的 ZookeeperTransporter 拓展，默认为 CuratorZookeeperTransporter。下面我们到 CuratorZookeeperTransporter 中看一看。 public ZookeeperClient connect(URL url) { // 创建 CuratorZookeeperClient return new CuratorZookeeperClient(url); } 上面方法仅用于创建 CuratorZookeeperClient 实例，没什么好说的，继续往下看。 public class CuratorZookeeperClient extends AbstractZookeeperClient<CuratorWatcher> { private final CuratorFramework client; public CuratorZookeeperClient(URL url) { super(url); try { // 创建 CuratorFramework 构造器 CuratorFrameworkFactory.Builder builder = CuratorFrameworkFactory.builder() .connectString(url.getBackupAddress()) .retryPolicy(new RetryNTimes(1, 1000)) .connectionTimeoutMs(5000); String authority = url.getAuthority(); if (authority != null && authority.length() > 0) { builder = builder.authorization("digest", authority.getBytes()); } // 构建 CuratorFramework 实例 client = builder.build(); // 添加监听器 client.getConnectionStateListenable().addListener(new ConnectionStateListener() { @Override public void stateChanged(CuratorFramework client, ConnectionState state) { if (state == ConnectionState.LOST) { CuratorZookeeperClient.this.stateChanged(StateListener.DISCONNECTED); } else if (state == ConnectionState.CONNECTED) { CuratorZookeeperClient.this.stateChanged(StateListener.CONNECTED); } else if (state == ConnectionState.RECONNECTED) { CuratorZookeeperClient.this.stateChanged(StateListener.RECONNECTED); } } }); // 启动客户端 client.start(); } catch (Exception e) { throw new IllegalStateException(e.getMessage(), e); } } } CuratorZookeeperClient 构造方法主要用于创建和启动 CuratorFramework 实例。以上基本上都是 Curator 框架的代码，大家如果对 Curator 框架不是很了解，可以参考 Curator 官方文档，并写点 Demo 跑跑。 本节分析了 ZookeeperRegistry 实例的创建过程，整个过程并不是很复杂。大家在看完分析后，可以自行调试，以加深印象。现在注册中心实例创建好了，接下来要做的事情是向注册中心注册服务，我们继续往下看。 2.2.4.2 节点创建 以 Zookeeper 为例，所谓的服务注册，本质上是将服务配置数据写入到 Zookeeper 的某个路径的节点下。为了验证这个说法，下面我们将 Dobbo 官方提供提供的实例跑起来，然后通过 Zookeeper 可视化客户端 ZooInspector 查看节点数据。如下： 从上图中可以看到 com.alibaba.dubbo.demo.DemoService 这个服务对应的配置信息（存储在 URL 中）最终被注册到了 /dubbo/com.alibaba.dubbo.demo.DemoService/providers/ 节点下。搞懂了服务注册的本质，那么接下来我们就可以去阅读服务注册的代码了。服务注册的接口为 register(URL)，这个方法定义在 FailbackRegistry 抽象类中。方法代码如下： public void register(URL url) { super.register(url); failedRegistered.remove(url); failedUnregistered.remove(url); try { // 模板方法，由子类实现 doRegister(url); } catch (Exception e) { Throwable t = e; // 获取 check 参数，若 check = true 将会直接抛出异常 boolean check = getUrl().getParameter(Constants.CHECK_KEY, true) && url.getParameter(Constants.CHECK_KEY, true) && !Constants.CONSUMER_PROTOCOL.equals(url.getProtocol()); boolean skipFailback = t instanceof SkipFailbackWrapperException; if (check || skipFailback) { if (skipFailback) { t = t.getCause(); } throw new IllegalStateException("Failed to register"); } else { logger.error("Failed to register"); } // 记录注册失败的链接 failedRegistered.add(url); } } protected abstract void doRegister(URL url); 如上，我们重点关注 doRegister 方法调用即可，其他的代码先忽略。doRegister 方法是一个模板方法，因此我们到 FailbackRegistry 子类 ZookeeperRegistry 中进行分析。如下： protected void doRegister(URL url) { try { // 通过 Zookeeper 客户端创建节点，节点路径由 toUrlPath 方法生成，路径格式如下: // /${group}/${serviceInterface}/providers/${url} // 比如 // /dubbo/com.tianxiaobo.DemoService/providers/dubbo%3A%2F%2F127.0.0.1...... zkClient.create(toUrlPath(url), url.getParameter(Constants.DYNAMIC_KEY, true)); } catch (Throwable e) { throw new RpcException("Failed to register..."); } } 如上，ZookeeperRegistry 在 doRegister 中调用了 Zookeeper 客户端创建服务节点。节点路径由 toUrlPath 方法生成，该方法逻辑不难理解，就不分析了。接下来分析 create 方法，如下： public void create(String path, boolean ephemeral) { if (!ephemeral) { // 如果要创建的节点类型非临时节点，那么这里要检测节点是否存在 if (checkExists(path)) { return; } } int i = path.lastIndexOf('/'); if (i > 0) { create(path.substring(0, i), false); // 递归创建上一级路径 } // 根据 ephemeral 的值创建临时或持久节点 if (ephemeral) { createEphemeral(path); } else { createPersistent(path); } } 上面方法先是通过递归创建当前节点的上一级路径，然后再根据 ephemeral 的值决定创建临时还是持久节点。createEphemeral 和 createPersistent 这两个方法都比较简单，这里简单分析其中的一个。如下： public void createEphemeral(String path) { try { // 通过 Curator 框架创建节点 client.create().withMode(CreateMode.EPHEMERAL).forPath(path); } catch (NodeExistsException e) { } catch (Exception e) { throw new IllegalStateException(e.getMessage(), e); } } 好了，到此关于服务注册的过程就分析完了。整个过程可简单总结为：先创建注册中心实例，之后再通过注册中心实例注册服务。本节先到这，接下来分析数据订阅过程。 2.2.5 订阅 override 数据 订阅 override 数据对应的代码我粗略看了一遍，这部分代码的主要目的是为了在服务配置发生变化时，重新导出服务。具体的使用场景应该当我们通过 Dubbo 管理后台修改了服务配置后，Dubbo 得到服务配置被修改的通知，然后重新导出服务。这个使用场景只是猜测，我并未进行过验证。如果大家有兴趣可以自行验证。 override 数据订阅相关代码也不是很少，考虑到文章篇幅问题以及重要性，遂决定不对此逻辑进行详细的分析。如果大家有兴趣，可自行分析。 3.总结 本篇文章详细分析了 Dubbo 服务导出过程，包括配置检测，URL 组装，Invoker 创建过程、导出服务以及注册服务等等。篇幅比较大，需要大家耐心阅读。对于这篇文章，我建议大家当成一个工具书使用。需要的时候跳到指定章节看一下，通读可能会有点累。由于文章篇幅比较大，因此可能会隐藏一些我没意识到的错误。若大家在阅读的过程中发现了错误，还请指出。如果能够不吝赐教，那就更好了，先在这里说声谢谢。 好了，本篇文章就到这了。谢谢阅读。 本文在知识共享许可协议 4.0 下发布，转载需在明显位置处注明出处作者：田小波本文同步发布在我的个人博客：http://www.tianxiaobo.com 本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。
-
发表了文章 2018-10-15
Dubbo 源码分析 - 自适应拓展原理
1.原理 我在上一篇文章中分析了 Dubbo 的 SPI 机制，Dubbo SPI 是 Dubbo 框架的核心。Dubbo 中的很多拓展都是通过 SPI 机制进行加载的，比如 Protocol、Cluster、LoadBalance 等。有时，有些拓展并非想在框架启动阶段被加载，而是希望在拓展方法被调用时，根据运行时参数进行加载。这听起来有些矛盾。拓展未被加载，那么拓展方法就无法被调用（静态方法除外）。拓展方法未被调用，就无法进行加载，这似乎是个死结。不过好在也有相应的解决办法，通过代理模式就可以解决这个问题，这里我们将具有代理功能的拓展称之为自适应拓展。Dubbo 并未直接通过代理模式实现自适应拓展，而是代理代理模式基础上，封装了一个更炫的实现方式。Dubbo 首先会为拓展接口生成具有代理功能的代码，然后通过 javassist 或 jdk 编译这段代码，得到 Class 类，最后在通过反射创建代理类。整个过程比较复杂、炫丽。如此复杂的过程最终的目的是为拓展生成代理对象，但实际上每个代理对象的代理逻辑基本一致，均是从 URL 中获取欲加载实现类的名称。因此，我们完全可以把代理逻辑抽出来，并通过动态代理的方式实现自适应拓展。这样做的好处显而易见，方便维护，也方便源码学习者学习和调试代码。本文将在随后实现一个动态代理版的自适应拓展，有兴趣的同学可以继续往下读。 接下来，我们通过一个示例演示自适应拓展类。这个示例取自 Dubbo 官方文档，我这里进行了一定的拓展。这是一个与汽车相关的例子，我们有一个车轮制造厂接口 WheelMaker： public interface WheelMaker { Wheel makeWheel(URL url); } WheelMaker 接口的 Adaptive 实现类如下： public class AdaptiveWheelMaker implements WheelMaker { public Wheel makeWheel(URL url) { if (url == null) { throw new IllegalArgumentException("url == null"); } // 1.从 URL 中获取 WheelMaker 名称 String wheelMakerName = url.getParameter("Wheel.maker"); if (name == null) { throw new IllegalArgumentException("wheelMakerName == null"); } // 2.通过 SPI 加载具体的 WheelMaker WheelMaker wheelMaker = ExtensionLoader .getExtensionLoader(WheelMaker.class).getExtension(wheelMakerName); // 3.调用目标方法 return wheelMaker.makeWheel(URL url); } } AdaptiveWheelMaker 是一个代理类，它主要做了三件事情： 从 URL 中获取 WheelMaker 名称 通过 SPI 加载具体的 WheelMaker 调用目标方法 接下来，我们来看看汽车制造厂 CarMaker 接口与其实现类。 public interface CarMaker { Car makeCar(URL url); } public class RaceCarMaker implements CarMaker { WheelMaker wheelMaker; // 通过 setter 注入 AdaptiveWheelMaker public setWheelMaker(WheelMaker wheelMaker) { this.wheelMaker = wheelMaker; } public Car makeCar(URL url) { Wheel wheel = wheelMaker.makeWheel(url); return new RaceCar(wheel, ...); } } RaceCarMaker 持有一个 WheelMaker 类型从成员变量，在程序启动时，我们可以将 AdaptiveWheelMaker 通过 setter 方法注入到 RaceCarMaker 中。在运行时，假设有这样一个 URL 类型的参数： dubbo://192.168.0.101:20880/XxxService?wheel.maker=MichelinWheelMaker RaceCarMaker 的 makeCar 方法将上面的 url 作为参数传给 AdaptiveWheelMaker 的 makeWheel 方法，makeWheel 方法从 url 中提取 wheel.maker 参数，得到 MichelinWheelMaker。之后再通过 SPI 加载名为 MichelinWheelMaker 的实现类，得到具体的 WheelMaker 实例。 上面这个示例展示了自适应拓展类的核心实现 -- 在组件方法被调用时，通过代理的方式加载指定的实现类，并调用被代理的方法。 经过以上说明，大家应该搞懂了自适应拓展的原理。接下来，我们深入到源码中，探索自适应拓展生成的过程。 2.源码分析 在对自适应拓展生成过程进行深入分析之前，我们先来看一下与自适应拓展息息相关的一个注解，即 Adaptive 注解。该注解的定义如下： @Documented @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.TYPE, ElementType.METHOD}) public @interface Adaptive { String[] value() default {}; } 从上面的代码中可知，Adaptive 可注解在类或方法上。注解在类上时，Dubbo 不会为该类生成代理类。注解上方法（接口方法）上时，Dubbo 会为为该方法生成代理逻辑。Adaptive 注解在类上的情况很少，在 Dubbo 中，仅有两个类被 Adaptive 注解了，分别是 AdaptiveCompiler 和 AdaptiveExtensionFactory。此种情况表示拓展的加载逻辑由人工编码完成。更多时候，Adaptive 是注解在接口方法上的，表示拓展的加载逻辑需由框架自动生成。Adaptive 注解的地方不同，相应的处理逻辑也是不同的。注解在类上时，处理逻辑比较简单，本文就不分析了。注解在接口方法上时，处理逻辑较为复杂，本章将会重点分析此块逻辑。接下来，我们从 getAdaptiveExtension 方法进行分析。代码如下： 2.1 获取自适应拓展 public T getAdaptiveExtension() { // 从缓存中获取自适应拓展 Object instance = cachedAdaptiveInstance.get(); if (instance == null) { // 缓存未命中 if (createAdaptiveInstanceError == null) { synchronized (cachedAdaptiveInstance) { instance = cachedAdaptiveInstance.get(); if (instance == null) { try { // 创建自适应拓展 instance = createAdaptiveExtension(); // 设置拓展到缓存中 cachedAdaptiveInstance.set(instance); } catch (Throwable t) { createAdaptiveInstanceError = t; throw new IllegalStateException("..."); } } } } else { throw new IllegalStateException("..."); } } return (T) instance; } getAdaptiveExtension 方法首先会检查缓存，缓存未命中，则调用 createAdaptiveExtension 方法创建自适应拓展。下面，我们看一下 createAdaptiveExtension 方法的代码。 private T createAdaptiveExtension() { try { // 获取自适应拓展类，并通过反射实例化 return injectExtension((T) getAdaptiveExtensionClass().newInstance()); } catch (Exception e) { throw new IllegalStateException("..."); } } createAdaptiveExtension 方法代码比较少，但却包含了三个动作，分别如下： 调用 getAdaptiveExtensionClass 方法获取自适应拓展 Class 对象 通过反射进行实例化 调用 injectExtension 方法向拓展实例中注入依赖 前两个动作比较好理解，第三个动作不好理解，这里简单说明一下。injectExtension 方法通过 setter 方法向目标对象中注入依赖，可以看做是一个简单 IOC 的实现。前面说过，Dubbo 中有两种类型的自适应拓展，一种是手工编码的，一种是自动生成的。手工编码的 Adaptive 拓展中可能存在着一些依赖，而自动生成的 Adaptive 拓展则不会依赖其他类。这里调用 injectExtension 方法的目的是为手工编码的自适应拓展注入依赖，这一点需要大家注意一下。关于 injectExtension 方法，我在[上一篇文章]()中已经分析过了，这里不再赘述。接下来，分析 getAdaptiveExtensionClass 方法的逻辑。 private Class<?> getAdaptiveExtensionClass() { // 通过 SPI 获取所有的拓展类 getExtensionClasses(); // 检查缓存，若缓存不为空，则直接返回缓存 if (cachedAdaptiveClass != null) { return cachedAdaptiveClass; } // 创建自适应拓展类 return cachedAdaptiveClass = createAdaptiveExtensionClass(); } getAdaptiveExtensionClass 方法也包含了三个步骤，如下： 调用 getExtensionClasses 获取所有的拓展类 检查缓存，若缓存不为空，则返回缓存 若缓存为空，则调用 createAdaptiveExtensionClass 创建自适应拓展类 这三个步骤看起来平淡无奇，似乎没有多讲的必要。但是这些平淡无奇的代码中隐藏了一些细节，需要说明一下。首先从第一个步骤说起，getExtensionClasses 这个方法用于获取某个接口的所有实现类。比如该方法可以获取 Protocol 接口的 DubboProtocol、HttpProtocol、InjvmProtocol 等实现类。在获取实现类的过程中，如果某个某个实现类被 Adaptive 注解修饰了，那么该类就会被赋值给 cachedAdaptiveClass 变量。此时，上面步骤中的第二步条件成立（缓存不为空），直接返回 cachedAdaptiveClass 即可。如果所有的实现类均未被 Adaptive 注解修饰，那么执行第三步逻辑，创建自适应拓展类。相关代码如下： private Class<?> createAdaptiveExtensionClass() { // 构建自适应拓展代码 String code = createAdaptiveExtensionClassCode(); ClassLoader classLoader = findClassLoader(); // 获取编译器实现类 com.alibaba.dubbo.common.compiler.Compiler compiler = ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.common.compiler.Compiler.class).getAdaptiveExtension(); // 编译代码，生成 Class return compiler.compile(code, classLoader); } createAdaptiveExtensionClass 方法用于生成自适应拓展类，该方法首先会生成自适应拓展类的源码，然后通过 Compiler 实例（Dubbo 默认使用 javassist 作为编译器）编译源码，得到代理类 Class 实例。接下来，我将重点分析代理类代码生成逻辑。至于代码编译的过程，并非本文范畴，这里就不分析了，大家有兴趣可以自己看看。下面，我们把目光聚焦在 createAdaptiveExtensionClassCode 方法上。 2.2 自适应拓展类代码生成 createAdaptiveExtensionClassCode 方法代码略多，约有两百行代码。因此在本节中，我将会对该方法的代码进行拆分分析，以帮助大家更好的理解代码含义。 2.2.1 Adaptive 注解检测 在生成代理类源码之前，createAdaptiveExtensionClassCode 方法首先会通过反射检测接口方法是否包含 Adaptive 注解。对于要生成自适应拓展的接口，Dubbo 要求该接口至少有一个方法被 Adaptive 注解修饰。若不满足此条件，就会抛出运行时异常。相关代码如下： // 通过反射获取所有的方法 Method[] methods = type.getMethods(); boolean hasAdaptiveAnnotation = false; // 遍历方法列表 for (Method m : methods) { // 检测方法上是否有 Adaptive 注解 if (m.isAnnotationPresent(Adaptive.class)) { hasAdaptiveAnnotation = true; break; } } if (!hasAdaptiveAnnotation) // 若所有的方法上均无 Adaptive 注解，则抛出异常 throw new IllegalStateException("..."); 2.2.2 生成类 通过 Adaptive 注解检测后，即可开始生成代码。代码生成的顺序与 Java 文件内容顺序一致，首先会生成 package 语句，然后生成 import 语句，紧接着生成类名等代码。整个逻辑如下： // 生成 package 代码：package + type 所在包 codeBuilder.append("package ").append(type.getPackage().getName()).append(";"); // 生成 import 代码：import + ExtensionLoader 全限定名 codeBuilder.append("\nimport ").append(ExtensionLoader.class.getName()).append(";"); // 生成类代码：public class + type简单名称 + $Adaptive + implements + type全限定名 + { codeBuilder.append("\npublic class ") .append(type.getSimpleName()) .append("$Adaptive") .append(" implements ") .append(type.getCanonicalName()) .append(" {"); // ${生成方法} codeBuilder.append("\n}"); 这里，我用 ${...} 占位符代表其他代码的生成逻辑，该部分逻辑我将在随后进行分析。上面代码不是很难理解，这里我直接通过一个例子展示该段代码所生成的内容。以 Dubbo 的 Protocol 接口为例，生成的代码如下： package com.alibaba.dubbo.rpc; import com.alibaba.dubbo.common.extension.ExtensionLoader; public class Protocol$Adaptive implements com.alibaba.dubbo.rpc.Protocol { // 省略方法代码 } 2.2.3 生成方法 一个方法可以被 Adaptive 注解修饰，也可以不被修饰。这里将未被 Adaptive 注解修饰的方法称为“无 Adaptive 注解方法”，下面我们先来看看此种方法的代码生成逻辑是怎样的。 2.2.3.1 无 Adaptive 注解方法代码生成 对于接口方法，我们可以按照需求标注 Adaptive 注解。以 Protocol 接口为例，该接口的 destroy 和 getDefaultPort 未标注 Adaptive 注解，其他方法均标注了 Adaptive 注解。Dubbo 不会为没有标注 Adaptive 注解的方法生成代理逻辑，对于该种类型的方法，仅会生成一句抛出异常的代码。生成逻辑如下： for (Method method : methods) { // 省略无关逻辑 Adaptive adaptiveAnnotation = method.getAnnotation(Adaptive.class); StringBuilder code = new StringBuilder(512); // 如果方法上无 Adaptive 注解，则生成 throw new UnsupportedOperationException(...) 代码 if (adaptiveAnnotation == null) { // 生成规则： // throw new UnsupportedOperationException( // "method " + 方法签名 + of interface + 全限定接口名 + is not adaptive method!”) code.append("throw new UnsupportedOperationException(\"method ") .append(method.toString()).append(" of interface ") .append(type.getName()).append(" is not adaptive method!\");"); } else { // 省略无关逻辑 } // 省略无关逻辑 } 以 Protocol 接口的 destroy 方法为例，上面代码生成的内容如下： throw new UnsupportedOperationException( "method public abstract void com.alibaba.dubbo.rpc.Protocol.destroy() of interface com.alibaba.dubbo.rpc.Protocol is not adaptive method!"); 2.2.3.2 获取 URL 数据 前面说过方法代理逻辑会从 URL 中提取目标拓展的名称，因此代码生成逻辑的一个重要的任务是从方法的参数列表获取其他参数中获取 URL 数据。举个例子说明一下，我们要为 Protocol 接口的 refer 和 export 方法生成代理逻辑。在运行时，通过反射得到的方法定义大致如下： Invoker refer(Class<T> arg0, URL arg1) throws RpcException; Exporter export(Invoker<T> arg0) throws RpcException; 对于 refer 方法，通过遍历 refer 的参数列表即可获取 URL 数据，这个还比较简单。对于 export 方法，获取 URL 数据则要麻烦一些。export 参数列表中没有 URL 参数，因此需要从 Invoker 参数中获取 URL 数据。获取方式是调用 Invoker 中可返回 URL 的 getter 方法，比如 getUrl。如果 Invoker 中无相关 getter 方法，此时则会抛出异常。整个逻辑如下： for (Method method : methods) { Class<?> rt = method.getReturnType(); Class<?>[] pts = method.getParameterTypes(); Class<?>[] ets = method.getExceptionTypes(); Adaptive adaptiveAnnotation = method.getAnnotation(Adaptive.class); StringBuilder code = new StringBuilder(512); if (adaptiveAnnotation == null) { // ${无 Adaptive 注解方法代码生成} } else { int urlTypeIndex = -1; // 遍历参数列表，确定 URL 参数位置 for (int i = 0; i < pts.length; ++i) { if (pts[i].equals(URL.class)) { urlTypeIndex = i; break; } } if (urlTypeIndex != -1) { // 参数列表中存在 URL 参数 // 为 URL 类型参数生成判空代码，格式如下： // if (arg + urlTypeIndex == null) // throw new IllegalArgumentException("url == null"); String s = String.format("\nif (arg%d == null) throw new IllegalArgumentException(\"url == null\");", urlTypeIndex); code.append(s); // 为 URL 类型参数生成赋值代码，即 URL url = arg1 或 arg2，或 argN s = String.format("\n%s url = arg%d;", URL.class.getName(), urlTypeIndex); code.append(s); } else { // 参数列表中不存在 URL 类型参数 String attribMethod = null; LBL_PTS: // 遍历方法的参数类型列表 for (int i = 0; i < pts.length; ++i) { // 获取某一类型参数的全部方法 Method[] ms = pts[i].getMethods(); // 遍历方法列表，寻找可返回 URL 的 getter 方法 for (Method m : ms) { String name = m.getName(); // 1. 方法名以 get 开头，或方法名大于3个字符 // 2. 方法的访问权限为 public // 3. 方法非静态类型 // 4. 方法参数数量为0 // 5. 方法返回值类型为 URL if ((name.startsWith("get") || name.length() > 3) && Modifier.isPublic(m.getModifiers()) && !Modifier.isStatic(m.getModifiers()) && m.getParameterTypes().length == 0 && m.getReturnType() == URL.class) { urlTypeIndex = i; attribMethod = name; // 结束 for (int i = 0; i < pts.length; ++i) 循环 break LBL_PTS; } } } if (attribMethod == null) { // 如果所有参数中均不包含可返回 URL 的 getter 方法，则抛出异常 throw new IllegalStateException("..."); } // 为包含可返回 URL 的参数生成判空代码，格式如下： // if (arg + urlTypeIndex == null) // throw new IllegalArgumentException("参数全限定名 + argument == null"); String s = String.format("\nif (arg%d == null) throw new IllegalArgumentException(\"%s argument == null\");", urlTypeIndex, pts[urlTypeIndex].getName()); code.append(s); // 为 getter 方法返回的 URL 生成判空代码，格式如下： // if (argN.getter方法名() == null) // throw new IllegalArgumentException(参数全限定名 + argument getUrl() == null); s = String.format("\nif (arg%d.%s() == null) throw new IllegalArgumentException(\"%s argument %s() == null\");", urlTypeIndex, attribMethod, pts[urlTypeIndex].getName(), attribMethod); code.append(s); // 生成赋值语句，格式如下： // URL全限定名 url = argN.getter方法名()，比如 // com.alibaba.dubbo.common.URL url = invoker.getUrl(); s = String.format("%s url = arg%d.%s();", URL.class.getName(), urlTypeIndex, attribMethod); code.append(s); } // 省略无关代码 } // 省略无关代码 } 上面代码有点多，但并不是很难看懂。这段代码主要是为了获取 URL 数据，并为之生成判空和赋值代码。以 Protocol 的 refer 和 export 方法为例，上面代码会为它们生成如下内容（代码已格式化）： refer: if (arg1 == null) throw new IllegalArgumentException("url == null"); com.alibaba.dubbo.common.URL url = arg1; export: if (arg0 == null) throw new IllegalArgumentException("com.alibaba.dubbo.rpc.Invoker argument == null"); if (arg0.getUrl() == null) throw new IllegalArgumentException("com.alibaba.dubbo.rpc.Invoker argument getUrl() == null"); com.alibaba.dubbo.common.URL url = arg0.getUrl(); 2.2.3.3 获取 Adaptive 注解值 Adaptive 注解值 value 类型为 String[]，可填写多个值，默认情况下为空数组。若 value 为非空数组，直接获取数组内容即可。若 value 为空数组，则需进行额外处理。处理的过程是将类名转换为字符数组，然后遍历字符数组，并将字符加入到 StringBuilder 中。若字符为大写字母，则向 StringBuilder 中添加点号，随后将字符变为小写存入 StringBuilder 中。比如 LoadBalance 经过处理后，得到 load.balance。 for (Method method : methods) { Class<?> rt = method.getReturnType(); Class<?>[] pts = method.getParameterTypes(); Class<?>[] ets = method.getExceptionTypes(); Adaptive adaptiveAnnotation = method.getAnnotation(Adaptive.class); StringBuilder code = new StringBuilder(512); if (adaptiveAnnotation == null) { // ${无 Adaptive 注解方法代码生成} } else { // ${获取 URL 数据} String[] value = adaptiveAnnotation.value(); // value 为空数组 if (value.length == 0) { // 获取类名，并将类名转换为字符数组 char[] charArray = type.getSimpleName().toCharArray(); StringBuilder sb = new StringBuilder(128); // 遍历字节数组 for (int i = 0; i < charArray.length; i++) { // 检测当前字符是否为大写字母 if (Character.isUpperCase(charArray[i])) { if (i != 0) { // 向 sb 中添加点号 sb.append("."); } // 将字符变为小写，并添加到 sb 中 sb.append(Character.toLowerCase(charArray[i])); } else { // 添加字符到 sb 中 sb.append(charArray[i]); } } value = new String[]{sb.toString()}; } // 省略无关代码 } // 省略无关逻辑 } 2.2.3.4 检测 Invocation 参数 此段逻辑是检测方法列表中是否存在 Invocation 类型的参数，若存在，则为其生成判空代码和其他一些代码。相应的逻辑如下： for (Method method : methods) { Class<?> rt = method.getReturnType(); Class<?>[] pts = method.getParameterTypes(); // 获取参数类型列表 Class<?>[] ets = method.getExceptionTypes(); Adaptive adaptiveAnnotation = method.getAnnotation(Adaptive.class); StringBuilder code = new StringBuilder(512); if (adaptiveAnnotation == null) { // ${无 Adaptive 注解方法代码生成} } else { // ${获取 URL 数据} // ${获取 Adaptive 注解值} boolean hasInvocation = false; // 遍历参数类型列表 for (int i = 0; i < pts.length; ++i) { // 判断当前参数名称是否等于 com.alibaba.dubbo.rpc.Invocation if (pts[i].getName().equals("com.alibaba.dubbo.rpc.Invocation")) { // 为 Invocation 类型参数生成判空代码 String s = String.format("\nif (arg%d == null) throw new IllegalArgumentException(\"invocation == null\");", i); code.append(s); // 生成 getMethodName 方法调用代码，格式为： // String methodName = argN.getMethodName(); s = String.format("\nString methodName = arg%d.getMethodName();", i); code.append(s); // 设置 hasInvocation 为 true hasInvocation = true; break; } } } // 省略无关逻辑 } 2.2.3.5 生成拓展名获取逻辑 本段逻辑用于根据 SPI 和 Adaptive 注解值生成“拓展名获取逻辑”，同时生成逻辑也受 Invocation 类型参数影响，综合因素导致本段逻辑相对复杂。本段逻辑可以会生成但不限于下面的代码： String extName = (url.getProtocol() == null ? "dubbo" : url.getProtocol()); 或 String extName = url.getMethodParameter(methodName, "loadbalance", "random"); 亦或是 String extName = url.getParameter("client", url.getParameter("transporter", "netty")); 本段逻辑复杂指出在于条件分支比较多，大家在阅读源码时需要知道每个条件分支的意义是什么，否则不太容易看懂相关代码。好了，其他的就不多说了，开始分析本段逻辑。 for (Method method : methods) { Class<?> rt = method.getReturnType(); Class<?>[] pts = method.getParameterTypes(); Class<?>[] ets = method.getExceptionTypes(); Adaptive adaptiveAnnotation = method.getAnnotation(Adaptive.class); StringBuilder code = new StringBuilder(512); if (adaptiveAnnotation == null) { // $无 Adaptive 注解方法代码生成} } else { // ${获取 URL 数据} // ${获取 Adaptive 注解值} // ${检测 Invocation 参数} // 设置默认拓展名，cachedDefaultName = SPI 注解值，比如 Protocol 接口上标注的 // SPI 注解值为 dubbo。默认情况下，SPI 注解值为空串，此时 cachedDefaultName = null String defaultExtName = cachedDefaultName; String getNameCode = null; // 遍历 value，这里的 value 是 Adaptive 的注解值，2.2.3.3 节分析过 value 变量的获取过程。 // 此处循环目的是生成从 URL 中获取拓展名的代码，生成的代码会赋值给 getNameCode 变量。注意这 // 个循环的遍历顺序是由后向前遍历的。 for (int i = value.length - 1; i >= 0; --i) { if (i == value.length - 1) { // 当 i 为最后一个元素的坐标时 if (null != defaultExtName) { // 默认拓展名非空 // protocol 是 url 的一部分，可通过 getProtocol 方法获取，其他的则是从 // URL 参数中获取。所以这里要判断 value[i] 是否为 protocol if (!"protocol".equals(value[i])) // hasInvocation 用于标识方法参数列表中是否有 Invocation 类型参数 if (hasInvocation) // 生成的代码功能等价于下面的代码： // url.getMethodParameter(methodName, value[i], defaultExtName) // 以 LoadBalance 接口的 select 方法为例，最终生成的代码如下： // url.getMethodParameter(methodName, "loadbalance", "random") getNameCode = String.format("url.getMethodParameter(methodName, \"%s\", \"%s\")", value[i], defaultExtName); else // 生成的代码功能等价于下面的代码： // url.getParameter(value[i], defaultExtName) getNameCode = String.format("url.getParameter(\"%s\", \"%s\")", value[i], defaultExtName); else // 生成的代码功能等价于下面的代码： // ( url.getProtocol() == null ? defaultExtName : url.getProtocol() ) getNameCode = String.format("( url.getProtocol() == null ? \"%s\" : url.getProtocol() )", defaultExtName); } else { // 默认拓展名为空 if (!"protocol".equals(value[i])) if (hasInvocation) // 生成代码格式同上 getNameCode = String.format("url.getMethodParameter(methodName, \"%s\", \"%s\")", value[i], defaultExtName); else // 生成的代码功能等价于下面的代码： // url.getParameter(value[i]) getNameCode = String.format("url.getParameter(\"%s\")", value[i]); else // 生成从 url 中获取协议的代码，比如 "dubbo" getNameCode = "url.getProtocol()"; } } else { if (!"protocol".equals(value[i])) if (hasInvocation) // 生成代码格式同上 getNameCode = String.format("url.getMethodParameter(methodName, \"%s\", \"%s\")", value[i], defaultExtName); else // 生成的代码功能等价于下面的代码： // url.getParameter(value[i], getNameCode) // 以 Transporter 接口的 connect 方法为例，最终生成的代码如下： // url.getParameter("client", url.getParameter("transporter", "netty")) getNameCode = String.format("url.getParameter(\"%s\", %s)", value[i], getNameCode); else // 生成的代码功能等价于下面的代码： // url.getProtocol() == null ? getNameCode : url.getProtocol() // 以 Protocol 接口的 connect 方法为例，最终生成的代码如下： // url.getProtocol() == null ? "dubbo" : url.getProtocol() getNameCode = String.format("url.getProtocol() == null ? (%s) : url.getProtocol()", getNameCode); } } // 生成 extName 赋值代码 code.append("\nString extName = ").append(getNameCode).append(";"); // 生成 extName 判空代码 String s = String.format("\nif(extName == null) " + "throw new IllegalStateException(\"Fail to get extension(%s) name from url(\" + url.toString() + \") use keys(%s)\");", type.getName(), Arrays.toString(value)); code.append(s); } // 省略无关逻辑 } 上面代码已经进行了大量的注释，不过看起来任然不是很好理解。既然如此，那么建议大家写点测试代码，对 Protocol、LoadBalance 以及 Transporter 等接口的自适应拓展类代码生成过程进行调试。这里我以 Transporter 接口的自适应拓展类代码生成过程进行分析。首先看一下 Transporter 接口的定义，如下： @SPI("netty") public interface Transporter { // @Adaptive({server, transporter}) @Adaptive({Constants.SERVER_KEY, Constants.TRANSPORTER_KEY}) Server bind(URL url, ChannelHandler handler) throws RemotingException; // @Adaptive({client, transporter}) @Adaptive({Constants.CLIENT_KEY, Constants.TRANSPORTER_KEY}) Client connect(URL url, ChannelHandler handler) throws RemotingException; } 下面对 connect 方法代理逻辑生成的过程进行分析，此时生成代理逻辑所用到的变量和值如下： String defaultExtName = "netty"; boolean hasInvocation = false; String getNameCode = null; String[] value = ["client", "transporter"]; 下面对 value 数组进行遍历，此时 i = 1, value[i] = "transporter"，生成的代码如下： getNameCode = url.getParameter("transporter", "netty"); 接下来，for 循环继续执行，此时 i = 0, value[i] = "client"，生成的代码如下： getNameCode = url.getParameter("client", url.getParameter("transporter", "netty")); for 循环结束运行，现在生成 extName 变量及判空代码，如下： String extName = url.getParameter("client", url.getParameter("transporter", "netty")); if (extName == null) { throw new IllegalStateException( "Fail to get extension(com.alibaba.dubbo.remoting.Transporter) name from url(" + url.toString() + ") use keys([client, transporter])"); } 到此，connect 方法的拓展名获取代码就生成好了。如果大家不是很明白，建议自己调试走一遍。好了，本节先到这里。 2.2.3.6 生成拓展加载与目标方法调用逻辑 上一节的逻辑生成拓展名 extName 获取逻辑，接下来要做的是根据拓展名加载拓展实例，并调用拓展实例的目标方法。相关逻辑如下： for (Method method : methods) { Class<?> rt = method.getReturnType(); Class<?>[] pts = method.getParameterTypes(); Class<?>[] ets = method.getExceptionTypes(); Adaptive adaptiveAnnotation = method.getAnnotation(Adaptive.class); StringBuilder code = new StringBuilder(512); if (adaptiveAnnotation == null) { // $无 Adaptive 注解方法代码生成} } else { // ${获取 URL 数据} // ${获取 Adaptive 注解值} // ${检测 Invocation 参数} // ${生成拓展名获取逻辑} // 生成拓展获取代码，格式如下： // type全限定名 extension = (type全限定名)ExtensionLoader全限定名 // .getExtensionLoader(type全限定名.class).getExtension(extName); // Tips: 格式化字符串中的 %<s 表示使用前一个转换符所描述的参数，即 type 全限定名 s = String.format("\n%s extension = (%<s)%s.getExtensionLoader(%s.class).getExtension(extName);", type.getName(), ExtensionLoader.class.getSimpleName(), type.getName()); code.append(s); // 如果方法有返回值类型非 void，则生成 return 语句。 if (!rt.equals(void.class)) { code.append("\nreturn "); } // 生成目标方法调用逻辑，格式为： // extension.方法名(arg0, arg2, ..., argN); s = String.format("extension.%s(", method.getName()); code.append(s); for (int i = 0; i < pts.length; i++) { if (i != 0) code.append(", "); code.append("arg").append(i); } code.append(");"); } // 省略无关逻辑 } 以 Protocol 接口举例说明，上面代码生成的内容如下： com.alibaba.dubbo.rpc.Protocol extension = (com.alibaba.dubbo.rpc.Protocol) ExtensionLoader .getExtensionLoader(com.alibaba.dubbo.rpc.Protocol.class).getExtension(extName); return extension.refer(arg0, arg1); 2.2.3.7 生成完整的方法 本节进行代码生成的收尾工作，主要用于生成方法定义的代码。相关逻辑如下： for (Method method : methods) { Class<?> rt = method.getReturnType(); Class<?>[] pts = method.getParameterTypes(); Class<?>[] ets = method.getExceptionTypes(); Adaptive adaptiveAnnotation = method.getAnnotation(Adaptive.class); StringBuilder code = new StringBuilder(512); if (adaptiveAnnotation == null) { // $无 Adaptive 注解方法代码生成} } else { // ${获取 URL 数据} // ${获取 Adaptive 注解值} // ${检测 Invocation 参数} // ${生成拓展名获取逻辑} // ${生成拓展加载与目标方法调用逻辑} } } // public + 返回值全限定名 + 方法名 + ( codeBuilder.append("\npublic ") .append(rt.getCanonicalName()) .append(" ") .append(method.getName()) .append("("); // 添加参数列表代码 for (int i = 0; i < pts.length; i++) { if (i > 0) { codeBuilder.append(", "); } codeBuilder.append(pts[i].getCanonicalName()); codeBuilder.append(" "); codeBuilder.append("arg").append(i); } codeBuilder.append(")"); // 添加异常抛出代码 if (ets.length > 0) { codeBuilder.append(" throws "); for (int i = 0; i < ets.length; i++) { if (i > 0) { codeBuilder.append(", "); } codeBuilder.append(ets[i].getCanonicalName()); } } codeBuilder.append(" {"); codeBuilder.append(code.toString()); codeBuilder.append("\n}"); 以 Protocol 的 refer 方法为例，上面代码生成的内容如下： public com.alibaba.dubbo.rpc.Invoker refer(java.lang.Class arg0, com.alibaba.dubbo.common.URL arg1) { // 方法体 } 3.基于动态代理实现知识与拓展 我在第一章介绍自适应拓展原理时说过，Dubbo 通过生成和编译代码实现自适应拓展的方式有点复杂，不利于维护。另外，这样做对源码学习读者来说，也不是很友好。我敢肯定，有同学会像我一样，在开始调试 Dubbo 源码时，不知道如何调试各种自适应拓展类，比如 Protocol$Adaptive。如果你也有类似的困惑，这里教大家一个方法。如下： 在 createAdaptiveExtensionClass 方法的第一行打个断点 启动测试代码，代码运行到端点处，单步越过断点，此时可以得到生成的代码。 拷贝出刚刚获取到的代码，到指定的包下创建同名类，并将代码拷过去，格式化一下即可 以 Protocol 接口为例，当代码越过断点后，调试信息如下： 从调试信息中可知，Protocol$Adaptive 所在包为 com.alibaba.dubbo.rpc。因此接下来到 com.alibaba.dubbo.rpc 包下创建 Protocol$Adaptive 类，并把 code 变量值拷贝到刚创建的文件中。当我们再次进行调试时，就能进入内部了。比如： 既然 Dubbo 实现的 Adaptive 机制不利于调试，那么我们可以对其进行改造。改造后的代码如下： public class AdaptiveInvokeHandler implements InvocationHandler { private String defaultExtName; public AdaptiveInvokeHandler(String defaultExtName) { this.defaultExtName = defaultExtName; } public Object getProxy(Class clazz) { if (!clazz.isInterface()) { throw new IllegalStateException("Only create the proxy for interface."); } return Proxy.newProxyInstance(this.getClass().getClassLoader(), new Class[]{clazz}, this); } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { Class<?> type = method.getDeclaringClass(); if (type.equals(Object.class)) { throw new UnsupportedOperationException("Cannot invoke the method of Object"); } Adaptive adaptiveAnnotation = method.getAnnotation(Adaptive.class); if (adaptiveAnnotation == null) { throw new UnsupportedOperationException("method " + method.toString() + " of interface " + type.getName() + " is not adaptive method!"); } // 获取 URL 数据 URL url = getUrlData(method, args); // 获取 Adaptive 注解值 String[] value = getAdaptiveAnnotationValue(method); // 获取 Invocation 参数 Object invocation = getInvocationArgument(method, args); // 获取拓展名 String extName = getExtensionName(url, value, invocation); if (StringUtils.isEmpty(extName)) { throw new IllegalStateException( "Fail to get extension(" + type.getName() + ") name from url(" + url.toString() + ") use keys(" + Arrays.toString(value) +")"); } // 获取拓展实例 Object extension = ExtensionLoader.getExtensionLoader(type).getExtension(extName); Class<?> extType = extension.getClass(); Method targetMethod = extType.getMethod(method.getName(), method.getParameterTypes()); // 通过反射调用目标方法 return targetMethod.invoke(extension, args); } } 这样看起来是不是简单了一些，不过这并不是全部的代码。我将 URL 数据以及 Adaptive 注解值的获取逻辑封装在了私有方法中，相应的代码如下： private URL getUrlData(Method method, Object[] args) throws InvocationTargetException, IllegalAccessException { URL url = null; Class<?>[] pts = method.getParameterTypes(); for (int i = 0; i < pts.length; i++) { if (pts[i].equals(URL.class)) { url = (URL) args[i]; if (url == null) { throw new IllegalArgumentException("url == null"); } break; } } if (url == null) { int urlTypeIndex = -1; Method getter = null; LBL_PTS: for (int i = 0; i < pts.length; ++i) { Method[] ms = pts[i].getMethods(); for (Method m : ms) { String name = m.getName(); if ((name.startsWith("get") || name.length() > 3) && Modifier.isPublic(m.getModifiers()) && !Modifier.isStatic(m.getModifiers()) && m.getParameterTypes().length == 0 && m.getReturnType() == URL.class) { urlTypeIndex = i; getter = m; break LBL_PTS; } } } if (urlTypeIndex == -1) { throw new IllegalArgumentException("Cannot find URL argument."); } if (args[urlTypeIndex] == null) { throw new IllegalArgumentException(pts[urlTypeIndex].getName() + " argument == null"); } url = (URL) getter.invoke(args[urlTypeIndex]); if (url == null) { throw new IllegalArgumentException(pts[urlTypeIndex].getName() + " argument " + getter.getName() + "() == null"); } } return url; } private String[] getAdaptiveAnnotationValue(Method method) { Adaptive adaptiveAnnotation = method.getAnnotation(Adaptive.class); Class type = method.getDeclaringClass(); if (adaptiveAnnotation == null) { throw new IllegalArgumentException("method " + method.toString() + " of interface " + type.getName() + " is not adaptive method!"); } String[] value = adaptiveAnnotation.value(); if (value.length == 0) { char[] charArray = type.getSimpleName().toCharArray(); StringBuilder sb = new StringBuilder(128); for (int i = 0; i < charArray.length; i++) { if (Character.isUpperCase(charArray[i])) { if (i != 0) { sb.append("."); } sb.append(Character.toLowerCase(charArray[i])); } else { sb.append(charArray[i]); } } value = new String[]{sb.toString()}; } return value; } private Object getInvocationArgument(Method method, Object[] args) { Class<?>[] pts = method.getParameterTypes(); for (int i = 0; i < pts.length; ++i) { if (pts[i].getName().equals("com.alibaba.dubbo.rpc.Invocation")) { Object invocation = args[i]; if (invocation == null) { throw new IllegalArgumentException("invocation == null"); } return invocation; } } return null; } private String getExtensionName(URL url, String[] value, Invocation invocation) { String methodName = null; boolean hasInvocation = invocation != null; if (hasInvocation) { Class<?> clazz = invocation.getClass(); Method method = clazz.getMethod("getMethodName"); methodName = (String) method.invoke(invocation); } String extName = null; for (int i = 0; i < value.length; i++) { if (!"protocol".equals(value[i])) { if (hasInvocation) { extName = url.getMethodParameter(methodName, value[i], defaultExtName); } else { extName = url.getParameter(value[i]); } } else { extName = url.getProtocol(); } if (StringUtils.isNotEmpty(extName)) { break; } if (i == value.length -1 && StringUtils.isEmpty(extName)) { extName = defaultExtName; } } return extName; } 现在我们将 AdaptiveInvokeHandler 放置到 ExtensionLoader 所在包下，并对 ExtensionLoader 的 createAdaptiveExtension 方法代码进行改造。如下： private T createAdaptiveExtension() { try { getExtensionClasses(); T extension = null; if (cachedAdaptiveClass != null) { extension = (T) cachedAdaptiveClass.newInstance(); } if (extension == null) { extension = (T) new AdaptiveInvokeHandler(cachedDefaultName).getProxy(type); } return injectExtension(extension); } catch (Exception e) { throw new IllegalStateException("Can not create adaptive extension " + type + ", cause: " + e.getMessage(), e); } } 以上就是改造后的代码，需要特别说明的是，上面的代码仅供演示使用，代码逻辑并不是十分严谨。如果你有更好的写法，欢迎分享。 4.总结 到此，关于自适应拓展的原理，实现以及改造过程就分析完了。总的来说自适应拓展整个逻辑还是很复杂的，并不是很容易弄懂。因此，大家在阅读该部分源码时，耐心一些，同时多进行调试。亦或是通过生成好的代码思考生成逻辑。当然，大家也可以将代码生成逻辑看成一个黑盒，不懂细节也没关系，只要知道自适应拓展原理即可。 好了，本篇文章先到这里，感谢大家的阅读。 本文在知识共享许可协议 4.0 下发布，转载需在明显位置处注明出处作者：田小波本文同步发布在我的个人博客：http://www.tianxiaobo.com 本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。
滑动查看更多
暂无更多信息
-
发表了文章
2018-11-21
Dubbo 源码分析 - 集群容错之 Router
-
发表了文章
2018-11-19
Dubbo 源码分析 - 集群容错之 Directory
-
发表了文章
2018-11-13
Dubbo 源码分析 - 服务引用
-
发表了文章
2018-11-01
Dubbo 源码分析 - 服务导出
-
发表了文章
2018-10-15
Dubbo 源码分析 - 自适应拓展原理
-
发表了文章
2018-10-09
Dubbo 源码分析 - SPI 机制
-
发表了文章
2018-09-11
MyBatis 源码分析系列文章合集
-
发表了文章
2018-01-09
TreeMap 源码分析
-
发表了文章
2018-01-22
HashMap 源码详细分析（JDK1.8）
-
发表了文章
2018-01-24
LinkedHashMap 源码详细分析（JDK1.8）
-
发表了文章
2018-01-25
科普：String hashCode 方法为什么选择数字31作为乘子
-
发表了文章
2018-01-26
自己动手实现一个简单的JSON解析器
-
发表了文章
2018-01-29
ArrayList 源码详细分析
-
发表了文章
2018-01-31
LinkedList 源码分析(JDK 1.8)
-
发表了文章
2018-02-09
I/O模型简述
-
发表了文章
2018-03-02
基于epoll实现简单的web服务器
-
发表了文章
2018-03-05
Java NIO之缓冲区
-
发表了文章
2018-03-26
JAVA NIO之文件通道
-
发表了文章
2018-03-27
Java NIO之套接字通道
-
发表了文章
2018-04-08
Java NIO之选择器
滑动查看更多
暂无更多信息