Dubbo源码---集群容错之服务目录分析了集群容错的第一部分 — 服务目录 Directory。服务目录在刷新 Invoker 列表的过程中(RegistryDirectory#notify方法)，会通过 Router 进行服务路由，筛选出符合路由规则的服务提供者。在详细分析服务路由的源码之前，先来介绍一下服务路由是什么。服务路由包含一条路由规则，路由规则决定了服务消费者的调用目标，即规定了服务消费者可调用哪些服务提供者。Dubbo 目前提供了三种服务路由实现，分别为条件路由 ConditionRouter、脚本路由 ScriptRouter 和标签路由 TagRouter。其中条件路由是我们最常使用的。
条件路由ConditionRouter
简介
条件路由规则由两个条件组成，分别用于对服务消费者和提供者进行匹配。比如有这样一条规则：
host = 10.20.153.10 => host = 10.20.153.11
该条规则表示 IP 为 10.20.153.10 的服务消费者只可调用 IP 为 10.20.153.11 机器上的服务，不可调用其他机器上的服务。条件路由规则的格式如下：
[服务消费者匹配条件] => [服务提供者匹配条件]
如果服务消费者匹配条件为空，表示不对服务消费者进行限制。如果服务提供者匹配条件为空，表示对某些服务消费者禁用服务。官方文档中对条件路由进行了比较详细的介绍，大家可以参考下，这里就不过多说明了。
条件路由实现类 ConditionRouter 在进行工作前，需要先对用户配置的路由规则进行解析，得到一系列的条件。然后再根据这些条件对服务进行路由。
- 应用粒度
# app1的消费者只能消费所有端口为20880的服务实例
# app2的消费者只能消费所有端口为20881的服务实例
---
scope: application
force: true
runtime: true
enabled: true
key: governance-conditionrouter-consumer
conditions:
- application=app1 => address=*:20880
- application=app2 => address=*:20881
...
- 服务粒度
# DemoService的sayHello方法只能消费所有端口为20880的服务实例
# DemoService的sayHi方法只能消费所有端口为20881的服务实例
---
scope: service
force: true
runtime: true
enabled: true
key: org.apache.dubbo.samples.governance.api.DemoService
conditions:
- method=sayHello => address=*:20880
- method=sayHi => address=*:20881
...
规则详解
各字段含义
- scope表示路由规则的作用粒度，scope的取值会决定key的取值。必填
- service 服务粒度
- application 应用粒度
- Key明确规则体作用在哪个服务或应用。必填
- scope=service时，key取值为[{group}:]{service}[:{version}]的组合
- scope=application时，key取值为application名称
- enabled=true 当前路由规则是否生效，可不填，缺省生效。
- force=false当路由结果为空时，是否强制执行，如果不强制执行，路由结果为空的路由规则将自动失效，可不填，缺省为 false。
- runtime=false是否在每次调用时执行路由规则，否则只在提供者地址列表变更时预先执行并缓存结果，调用时直接从缓存中获取路由结果。如果用了参数路由，必须设为 true，需要注意设置会影响调用的性能，可不填，缺省为 false。
- priority=1路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为 0。
- conditions定义具体的路由规则内容。必填。
conditions规则体
`conditions`部分是规则的主体，由1到任意多条规则组成，下面我们就每个规则的配置语法做详细说明：
-
格式
-
=>之前的为消费者匹配条件，所有参数和消费者的 URL 进行对比，当消费者满足匹配条件时，对该消费者执行后面的过滤规则。 -
=>之后为提供者地址列表的过滤条件，所有参数和提供者的 URL 进行对比，消费者最终只拿到过滤后的地址列表。 -
如果匹配条件为空，表示对所有消费方应用，如：
=> host != 10.20.153.11 -
如果过滤条件为空，表示禁止访问，如：
host = 10.20.153.10 =>
-
-
表达式
- 参数支持
- 服务调用信息，如：method, argument 等，暂不支持参数路由
- URL 本身的字段，如：protocol, host, port 等
- 以及 URL 上的所有参数，如：application, organization 等
- 条件支持
- 等号
=表示"匹配"，如：host = 10.20.153.10 - 不等号
!=表示"不匹配"，如：host != 10.20.153.10
- 等号
- 值支持
- 以逗号
,分隔多个值，如：host != 10.20.153.10,10.20.153.11 - 以星号
*结尾，表示通配，如：host != 10.20.* - 以美元符
$开头，表示引用消费者参数，如：host = $host
- 以逗号
- 参数支持
-
condition示例
-
排除预发布机：
=> host != 172.22.3.91 -
白名单：一个服务只能有一条白名单规则，否则两条规则交叉，就都被筛选掉了
register.ip != 10.20.153.10,10.20.153.11 => -
黑名单
register.ip = 10.20.153.10,10.20.153.11 => -
服务寄宿在应用上，只暴露一部分的机器，防止整个集群挂掉：
=> host = 172.22.3.1*,172.22.3.2* -
为重要应用提供额外的机器：
application != kylin => host != 172.22.3.95,172.22.3.96 -
读写分离：
method = find*,list*,get*,is* => host = 172.22.3.94,172.22.3.95,172.22.3.96 method != find*,list*,get*,is* => host = 172.22.3.97,172.22.3.98 -
前后台分离：
application = bops => host = 172.22.3.91,172.22.3.92,172.22.3.93 application != bops => host = 172.22.3.94,172.22.3.95,172.22.3.96 -
隔离不同机房网段：
host != 172.22.3.* => host != 172.22.3.* -
提供者与消费者部署在同集群内，本机只访问本机的服务：
=> host = $host
-
源码
表达式解析
条件路由规则是一条字符串，对于 Dubbo 来说，它并不能直接理解字符串的意思，需要将其解析成内部格式才行。条件表达式的解析过程始于 ConditionRouter 的构造方法，下面一起看一下：
public ConditionRouter(URL url) {
this.url = url;
this.priority = url.getParameter(PRIORITY_KEY, 0);
this.force = url.getParameter(FORCE_KEY, false);
this.enabled = url.getParameter(ENABLED_KEY, true);
// 获取路由规则
init(url.getParameterAndDecoded(RULE_KEY));
}
public void init(String rule) {
try {
// rule为null或""抛出异常
if (rule == null || rule.trim().length() == 0) {
throw new IllegalArgumentException("Illegal route rule!");
}
// 替换"consumer."和"provider."为""
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);
// 将解析出的匹配规则分别赋值给 whenCondition 和 thenCondition 成员变量
// NOTE:应在业务层面确定“When条件”是否可以为空。
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);
// Try to match one by one
while (matcher.find()) {
// 获取括号一内的匹配结果
String separator = matcher.group(1);
// 获取括号二内的匹配结果
String content = matcher.group(2);
// 条件表达式的开始部分
// 分隔符为空，表示匹配的是表达式的开始部分
if (StringUtils.isEmpty(separator)) {
// 创建 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 \""
+ rule + "\", The error char '" + separator
+ "' at index " + matcher.start() + " before \""
+ content + "\".", matcher.start());
}
values = pair.matches;
// 将 content 存入到 MatchPair 的 matches 集合中
values.add(content);
}
// 分隔符为 !=
else if ("!=".equals(separator)) {
if (pair == null) {
throw new ParseException("Illegal route rule \""
+ rule + "\", The error char '" + separator
+ "' at index " + matcher.start() + " before \""
+ content + "\".", matcher.start());
}
values = pair.mismatches;
// 将 content 存入到 MatchPair 的 mismatches 集合中
values.add(content);
}
// 分隔符为 ,
else if (",".equals(separator)) {
if (values == null || values.isEmpty()) {
throw new ParseException("Illegal route rule \""
+ rule + "\", The error char '" + separator
+ "' at index " + matcher.start() + " before \""
+ content + "\".", matcher.start());
}
// 将 content 存入到上一步获取到的 values 中，可能是 matches，也可能是 mismatches
values.add(content);
} else {
throw new ParseException("Illegal route rule \"" + rule
+ "\", The error char '" + separator + "' at index "
+ matcher.start() + " before \"" + content + "\".", matcher.start());
}
}
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 的测试类对该逻辑进行测试。并且找一个表达式，对照上面的代码走一遍，加深理解。
服务路由
服务路由的入口方法是 ConditionRouter#route 方法，该方法定义在 Router 接口中。实现代码如下：
public <T> List<Invoker<T>> route(List<Invoker<T>> invokers, URL url, Invocation invocation)
throws RpcException {
if (!enabled) {
return invokers;
}
if (CollectionUtils.isEmpty(invokers)) {
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. consumer: " + NetUtils.getLocalHost() + ", service: " + url.getServiceKey());
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. consumer: " + NetUtils.getLocalHost() + ", service: " + url.getServiceKey() + ", router: " + url.getParameterAndDecoded(RULE_KEY));
return result;
}
} catch (Throwable t) {
logger.error("Failed to execute condition router rule: " + getUrl() + ", invokers: " + invokers + ", cause: " + t.getMessage(), t);
}
// 原样返回，此时 force = false，表示该条路由规则失效
return invokers;
}
route 方法先是调用 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 为 method(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;
}
}
// 全部失配，则返回 false
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 方法是通过 UrlUtils 的 isMatchGlobPattern 方法进行匹配，因此下面我们再来看看 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 两个重载方法的全部逻辑，这两个方法分别对普通的匹配过程，以及”引用消费者参数“和通配符匹配等特性提供了支持。这两个方法的逻辑不是很复杂，且代码中也进行了比较详细的注释，因此就不多说了。
脚本路由ScriptRouter
简介
脚本路由规则 4 支持 JDK 脚本引擎的所有脚本，比如：javascript, jruby, groovy 等，通过 type=javascript 参数设置脚本类型，缺省为 javascript。
规则详解
function route(invokers, invocation, context){
var result = new java.util.ArrayList(invokers.size());
var targetHost = new java.util.ArrayList();
targetHost.add("10.134.108.2");
for (var i = 0; i < invokers.length; i++) {
if(targetHost.contains(invokers[i].getUrl().getHost())){
result.add(invokers[i]);
}
}
return result;
}
# 表示立即执行
route(invokers, invocation, context)
源码
初始化
public ScriptRouter(URL url) {
this.url = url;
// 优先级
this.priority = url.getParameter(PRIORITY_KEY, SCRIPT_ROUTER_DEFAULT_PRIORITY);
// 脚本引擎
engine = getEngine(url);
// 获取规则
rule = getRule(url);
try {
Compilable compilable = (Compilable) engine;
// 编译路由脚本
function = compilable.compile(rule);
} catch (ScriptException e) {
logger.error("route error, rule has been ignored. rule: " + rule +
", url: " + RpcContext.getContext().getUrl(), e);
}
}
从构造方法来看，其做了以下几件事：
- 获取脚本引擎
- 获取路由规则
- 编译路由脚本，获取编译脚本
服务路由
服务路由的入口方法是ScriptRouter#router方法：
public <T> List<Invoker<T>> route(List<Invoker<T>> invokers, URL url, Invocation invocation) throws RpcException {
try {
// 创建bindings
Bindings bindings = createBindings(invokers, invocation);
if (function == null) {
return invokers;
}
// 这里有两个步骤 1、执行路由脚本 2、根据路由脚本执行结果获取Invokers
return getRoutedInvokers(function.eval(bindings));
} catch (ScriptException e) {
logger.error("route error, rule has been ignored. rule: " + rule + ", method:" +
invocation.getMethodName() + ", url: " + RpcContext.getContext().getUrl(), e);
return invokers;
}
}
此方法的逻辑也相对简单，首先是创建Bindngs，然后是根据bindings执行路由脚本，再通过路由脚本获取Invokers。
标签路由TagRouter
简介
标签路由通过将某一个或多个服务的提供者划分到同一个分组，约束流量只在指定分组中流转，从而实现流量隔离的目的，可以作为蓝绿发布、灰度发布等场景的能力基础。
provider
标签主要是指对Provider端应用实例的分组，目前有两种方式可以完成实例分组，分别是动态规则打标和静态规则打标，其中动态规则相较于静态规则优先级更高，而当两种规则同时存在且出现冲突时，将以动态规则为准。
- 动态规则打标，可随时在服务治理控制台下发标签归组规则
# governance-tagrouter-provider应用增加了两个标签分组tag1和tag2
# tag1包含一个实例 127.0.0.1:20880
# tag2包含一个实例 127.0.0.1:20881
---
force: false
runtime: true
enabled: true
key: governance-tagrouter-provider
tags:
- name: tag1
addresses: ["127.0.0.1:20880"]
- name: tag2
addresses: ["127.0.0.1:20881"]
...
- 静态打标
<dubbo:provider tag="tag1"/>
or
<dubbo:service tag="tag1"/>
or
java -jar xxx-provider.jar -Ddubbo.provider.tag={the tag you want, may come from OS ENV}
Consumer
RpcContext.getContext().setAttachment(Constants.REQUEST_TAG_KEY,"tag1");
请求标签的作用域为每一次 invocation，使用 attachment 来传递请求标签，注意保存在 attachment 中的值将会在一次完整的远程调用中持续传递，得益于这样的特性，我们只需要在起始调用时，通过一行代码的设置，达到标签的持续传递。
目前仅仅支持 hardcoding 的方式设置 requestTag。注意到 RpcContext 是线程绑定的，优雅的使用 TagRouter 特性，建议通过 servlet 过滤器(在 web 环境下)，或者定制的 SPI 过滤器设置 requestTag。
规则详解
格式
-
Key明确规则体作用到哪个应用。必填。
-
enabled=true 当前路由规则是否生效，可不填，缺省生效。
-
force=false 当路由结果为空时，是否强制执行，如果不强制执行，路由结果为空的路由规则将自动失效，可不填，缺省为
false。 -
runtime=false` 是否在每次调用时执行路由规则，否则只在提供者地址列表变更时预先执行并缓存结果，调用时直接从缓存中获取路由结果。如果用了参数路由，必须设为 true，需要注意设置会影响调用的性能，可不填，缺省为 false。
-
priority=1 路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为 0。
-
tags定义具体的标签分组内容，可定义任意n（n>=1）个标签并为每个标签指定实例列表。必填
- name， 标签名称
-
addresses， 当前标签包含的实例列表
降级约定
- dubbo.tag=tag1 时优先选择 标记了tag=tag1 的 provider。若集群中不存在与请求标记对应的服务，默认将降级请求 tag为空的provider；如果要改变这种默认行为，即找不到匹配tag1的provider返回异常，需设置dubbo.force.tag=true。
- dubbo.tag未设置时，只会匹配tag为空的provider。即使集群中存在可用的服务，若 tag 不匹配也就无法调用，这与约定1不同，携带标签的请求可以降级访问到无标签的服务，但不携带标签/携带其他种类标签的请求永远无法访问到其他标签的服务。
源码
TagRouter继承了AbstractRouter，实现了ConfigurationListener，TagRouter通过Router#route方法实现服务路由，通过Router#notify初始化路由配置信息，主要在服务订阅的notify中被调用，通过ConfigurationListener#process解析路由变更的配置，接下来会依次分析这三个方法
路由配置解析
public synchronized void process(ConfigChangedEvent event) {
if (logger.isDebugEnabled()) {
logger.debug("Notification of tag rule, change type is: " + event.getChangeType() + ", raw rule is:\n " +
event.getContent());
}
try {
// 如果配置变更类型为delete，直接将tagRouterRule改为null
if (event.getChangeType().equals(ConfigChangeType.DELETED)) {
this.tagRouterRule = null;
} else {
// 解析
this.tagRouterRule = TagRuleParser.parse(event.getContent());
}
} catch (Exception e) {
logger.error("Failed to parse the raw tag router rule and it will not take effect, please check if the " +
"rule matches with the template, the raw rule is:\n ", e);
}
}
此方法很简单，这里不做分析，其中解析配置文件的方法自行分析，其主要触发时机为Router#notify及配置修改的通知，不同配置中心通知方式不一样。
路由初始化
此方法的发生时间是在RegsitryService#subscribe方法的通知逻辑中被调用
public <T> void notify(List<Invoker<T>> invokers) {
if (CollectionUtils.isEmpty(invokers)) {
return;
}
// 校验provider invoker
Invoker<T> invoker = invokers.get(0);
URL url = invoker.getUrl();
String providerApplication = url.getParameter(CommonConstants.REMOTE_APPLICATION_KEY);
// 如果应用名称为null直接抛出异常
if (StringUtils.isEmpty(providerApplication)) {
logger.error("TagRouter must getConfig from or subscribe to a specific application, but the application " +
"in this TagRouter is not specified.");
return;
}
// 对象锁
synchronized (this) {
// 初始化前，application为null
if (!providerApplication.equals(application)) {
// 如果application不为null，删除监听器
if (!StringUtils.isEmpty(application)) {
ruleRepository.removeListener(application + RULE_SUFFIX, this);
}
String key = providerApplication + RULE_SUFFIX;
// 添加监听器
ruleRepository.addListener(key, this);
application = providerApplication;
// 获取路由配置
String rawRule = ruleRepository.getRule(key, DynamicConfiguration.DEFAULT_GROUP);
if (StringUtils.isNotEmpty(rawRule)) {
// 解析路由配置
this.process(new ConfigChangedEvent(key, DynamicConfiguration.DEFAULT_GROUP, rawRule));
}
}
}
}
这里的逻辑也很简单，不做深入分析，主要要清楚此方法的触发是在RegistryService#subscribe中被执行。
服务路由
public <T> List<Invoker<T>> route(List<Invoker<T>> invokers, URL url, Invocation invocation) throws RpcException {
if (CollectionUtils.isEmpty(invokers)) {
return invokers;
}
// 由于该规则可以通过配置中心更改，我们应该复制一个使用.
final TagRouterRule tagRouterRuleCopy = tagRouterRule;
// tagRouterRule为null或tagRouterRule不可用或tagRouterRule无效
if (tagRouterRuleCopy == null || !tagRouterRuleCopy.isValid() || !tagRouterRuleCopy.isEnabled()) {
return filterUsingStaticTag(invokers, url, invocation);
}
List<Invoker<T>> result = invokers;
// tag获取，如果Invocation#attachment中不存在，则从refer URL(ReferenceConfig)中获取
String tag = StringUtils.isEmpty(invocation.getAttachment(TAG_KEY)) ? url.getParameter(TAG_KEY) :
invocation.getAttachment(TAG_KEY);
// 指定了标签
if (StringUtils.isNotEmpty(tag)) {
// 获取标签对应的address，格式为:127.0.0.1:20880
List<String> addresses = tagRouterRuleCopy.getTagnameToAddresses().get(tag);
if (CollectionUtils.isNotEmpty(addresses)) {
// 首先按动态标签组进行过滤
// 1、遍历invokers
// 2、根据Invoker中的URL对地址进行匹配过滤invoker
result = filterInvoker(invokers, invoker -> addressMatches(invoker.getUrl(), addresses));
// 如果result不是null或者是null但force=true，直接返回结果
if (CollectionUtils.isNotEmpty(result) || tagRouterRuleCopy.isForce()) {
return result;
}
} else {
// 动态标签组中没有任何与请求的应用程序相关的条目，或者经过动态标签组过滤后为空，但force=false。检查静态标签
result = filterInvoker(invokers, invoker -> tag.equals(invoker.getUrl().getParameter(TAG_KEY)));
}
// 如果没有与当前标记请求匹配的标记提供程序. force.tag默认设置为false，这意味着它将调用任何没有标记的提供程序，除非它被显式地禁止
if (CollectionUtils.isNotEmpty(result) || isForceUseTag(invocation)) {
return result;
}
// FAILOVER: 返回所有没有任何标记的提供程序。
else {
List<Invoker<T>> tmp = filterInvoker(invokers, invoker -> addressNotMatches(invoker.getUrl(),
tagRouterRuleCopy.getAddresses()));
return filterInvoker(tmp, invoker -> StringUtils.isEmpty(invoker.getUrl().getParameter(TAG_KEY)));
}
// 未指定标签
} else {
// 返回动态标签组中的所有地址。
List<String> addresses = tagRouterRuleCopy.getAddresses();
// 标签组不为空
if (CollectionUtils.isNotEmpty(addresses)) {
// 过滤invokers
result = filterInvoker(invokers, invoker -> addressNotMatches(invoker.getUrl(), addresses));
// 1. 所有地址都在动态标签组中，返回空列表。
if (CollectionUtils.isEmpty(result)) {
return result;
}
// 2. 如果有不属于任何动态标签组的地址，则继续使用静态标签组进行过滤。
}
return filterInvoker(result, invoker -> {
String localTag = invoker.getUrl().getParameter(TAG_KEY);
return StringUtils.isEmpty(localTag) || !tagRouterRuleCopy.getTagNames().contains(localTag);
});
}
}
此方法的逻辑非常清晰，根据refer URL(ReferenceConfig)的dubbo.tag参数获取路由标签，从服务提供者列表中筛选出符合规则的invoker并返回，详细的逻辑不做分析，代码中的注释写的挺清晰了。
