You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@dubbo.apache.org by gi...@apache.org on 2020/01/26 04:54:02 UTC
[dubbo-website] branch asf-site updated: Automated deployment: Sun
Jan 26 04:53:55 UTC 2020 5fb6d4e8c7c64f6b851f8c9301e6c8adca7e3cb1
This is an automated email from the ASF dual-hosted git repository.
github-bot pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/dubbo-website.git
The following commit(s) were added to refs/heads/asf-site by this push:
new 21098e0 Automated deployment: Sun Jan 26 04:53:55 UTC 2020 5fb6d4e8c7c64f6b851f8c9301e6c8adca7e3cb1
21098e0 is described below
commit 21098e057db756e07af0eb4132d0339ead5e64c2
Author: lovepoem <lo...@users.noreply.github.com>
AuthorDate: Sun Jan 26 04:53:55 2020 +0000
Automated deployment: Sun Jan 26 04:53:55 UTC 2020 5fb6d4e8c7c64f6b851f8c9301e6c8adca7e3cb1
---
build/blogDetail.js | 2 +-
build/documentation.js | 4 ++--
zh-cn/docs/source_code_guide/adaptive-extension.html | 4 ++--
zh-cn/docs/source_code_guide/adaptive-extension.json | 2 +-
zh-cn/docs/source_code_guide/cluster.html | 4 ++--
zh-cn/docs/source_code_guide/cluster.json | 2 +-
zh-cn/docs/source_code_guide/directory.html | 4 ++--
zh-cn/docs/source_code_guide/directory.json | 2 +-
zh-cn/docs/source_code_guide/refer-service.html | 2 +-
zh-cn/docs/source_code_guide/refer-service.json | 2 +-
zh-cn/docs/source_code_guide/router.html | 4 ++--
zh-cn/docs/source_code_guide/router.json | 2 +-
12 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/build/blogDetail.js b/build/blogDetail.js
index 46ed005..b2e096d 100644
--- a/build/blogDetail.js
+++ b/build/blogDetail.js
@@ -1,4 +1,4 @@
-!function(e){function t(r){if(n[r])return n[r].exports;var o=n[r]={i:r,l:!1,exports:{}};return e[r].call(o.exports,o,o.exports,t),o.l=!0,o.exports}var n={};t.m=e,t.c=n,t.i=function(e){return e},t.d=function(e,n,r){t.o(e,n)||Object.defineProperty(e,n,{configurable:!1,enumerable:!0,get:r})},t.n=function(e){var n=e&&e.__esModule?function(){return e.default}:function(){return e};return t.d(n,"a",n),n},t.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},t.p="/build/",t(t.s=318 [...]
+!function(e){function t(r){if(n[r])return n[r].exports;var o=n[r]={i:r,l:!1,exports:{}};return e[r].call(o.exports,o,o.exports,t),o.l=!0,o.exports}var n={};t.m=e,t.c=n,t.i=function(e){return e},t.d=function(e,n,r){t.o(e,n)||Object.defineProperty(e,n,{configurable:!1,enumerable:!0,get:r})},t.n=function(e){var n=e&&e.__esModule?function(){return e.default}:function(){return e};return t.d(n,"a",n),n},t.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},t.p="/build/",t(t.s=318 [...]
Copyright (c) 2017 Jed Watson.
Licensed under the MIT License (MIT), see
http://jedwatson.github.io/classnames
diff --git a/build/documentation.js b/build/documentation.js
index d5fcba1..6eaf97c 100644
--- a/build/documentation.js
+++ b/build/documentation.js
@@ -1,6 +1,6 @@
-!function(e){function t(r){if(n[r])return n[r].exports;var o=n[r]={i:r,l:!1,exports:{}};return e[r].call(o.exports,o,o.exports,t),o.l=!0,o.exports}var n={};t.m=e,t.c=n,t.i=function(e){return e},t.d=function(e,n,r){t.o(e,n)||Object.defineProperty(e,n,{configurable:!1,enumerable:!0,get:r})},t.n=function(e){var n=e&&e.__esModule?function(){return e.default}:function(){return e};return t.d(n,"a",n),n},t.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},t.p="/build/",t(t.s=320 [...]
+!function(e){function t(r){if(n[r])return n[r].exports;var o=n[r]={i:r,l:!1,exports:{}};return e[r].call(o.exports,o,o.exports,t),o.l=!0,o.exports}var n={};t.m=e,t.c=n,t.i=function(e){return e},t.d=function(e,n,r){t.o(e,n)||Object.defineProperty(e,n,{configurable:!1,enumerable:!0,get:r})},t.n=function(e){var n=e&&e.__esModule?function(){return e.default}:function(){return e};return t.d(n,"a",n),n},t.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},t.p="/build/",t(t.s=320 [...]
Copyright (c) 2017 Jed Watson.
Licensed under the MIT License (MIT), see
http://jedwatson.github.io/classnames
*/
-!function(){"use strict";function n(){for(var e=[],t=0;t<arguments.length;t++){var r=arguments[t];if(r){var o=typeof r;if("string"===o||"number"===o)e.push(r);else if(Array.isArray(r)&&r.length){var l=n.apply(null,r);l&&e.push(l)}else if("object"===o)for(var s in r)i.call(r,s)&&r[s]&&e.push(s)}}return e.join(" ")}var i={}.hasOwnProperty;void 0!==e&&e.exports?(n.default=n,e.exports=n):(r=[],void 0!==(o=function(){return n}.apply(t,r))&&(e.exports=o))}()},50:function(e,t,n){"use strict";fu [...]
\ No newline at end of file
+!function(){"use strict";function n(){for(var e=[],t=0;t<arguments.length;t++){var r=arguments[t];if(r){var o=typeof r;if("string"===o||"number"===o)e.push(r);else if(Array.isArray(r)&&r.length){var l=n.apply(null,r);l&&e.push(l)}else if("object"===o)for(var s in r)i.call(r,s)&&r[s]&&e.push(s)}}return e.join(" ")}var i={}.hasOwnProperty;void 0!==e&&e.exports?(n.default=n,e.exports=n):(r=[],void 0!==(o=function(){return n}.apply(t,r))&&(e.exports=o))}()},50:function(e,t,n){"use strict";fu [...]
\ No newline at end of file
diff --git a/zh-cn/docs/source_code_guide/adaptive-extension.html b/zh-cn/docs/source_code_guide/adaptive-extension.html
index f8c2113..5df6996 100644
--- a/zh-cn/docs/source_code_guide/adaptive-extension.html
+++ b/zh-cn/docs/source_code_guide/adaptive-extension.html
@@ -143,7 +143,7 @@
<li>检查缓存，若缓存不为空，则返回缓存</li>
<li>若缓存为空，则调用 createAdaptiveExtensionClass 创建自适应拓展类</li>
</ol>
-<p>这三个逻辑看起来平淡无奇，似乎没有多讲的必要。但是这些平淡无奇的代码中隐藏了着一些细节，需要说明一下。首先从第一个逻辑说起，getExtensionClasses 这个方法用于获取某个接口的所有实现类。比如该方法可以获取 Protocol 接口的 DubboProtocol、HttpProtocol、InjvmProtocol 等实现类。在获取实现类的过程中，如果某个某个实现类被 Adaptive 注解修饰了，那么该类就会被赋值给 cachedAdaptiveClass 变量。此时，上面步骤中的第二步条件成立（缓存不为空），直接返回 cachedAdaptiveClass 即可。如果所有的实现类均未被 Adaptive 注解修饰，那么执行第三步逻辑，创建自适应拓展类。相关代码如下：</p>
+<p>这三个逻辑看起来平淡无奇，似乎没有多讲的必要。但是这些平淡无奇的代码中隐藏了着一些细节，需要说明一下。首先从第一个逻辑说起，getExtensionClasses 这个方法用于获取某个接口的所有实现类。比如该方法可以获取 Protocol 接口的 DubboProtocol、HttpProtocol、InjvmProtocol 等实现类。在获取实现类的过程中，如果某个实现类被 Adaptive 注解修饰了，那么该类就会被赋值给 cachedAdaptiveClass 变量。此时，上面步骤中的第二步条件成立（缓存不为空），直接返回 cachedAdaptiveClass 即可。如果所有的实现类均未被 Adaptive 注解修饰，那么执行第三步逻辑，创建自适应拓展类。相关代码如下：</p>
<pre><code class="language-java"><span class="hljs-keyword">private</span> Class<?> createAdaptiveExtensionClass() {
<span class="hljs-comment">// 构建自适应拓展代码</span>
String code = createAdaptiveExtensionClassCode();
@@ -426,7 +426,7 @@ com.alibaba.dubbo.common.URL url = arg0.getUrl();
}
</code></pre>
<h5>2.2.3.5 生成拓展名获取逻辑</h5>
-<p>本段逻辑用于根据 SPI 和 Adaptive 注解值生成“获取拓展名逻辑”，同时生成逻辑也受 Invocation 类型参数影响，综合因素导致本段逻辑相对复杂。本段逻辑可以会生成但不限于下面的代码：</p>
+<p>本段逻辑用于根据 SPI 和 Adaptive 注解值生成“获取拓展名逻辑”，同时生成逻辑也受 Invocation 类型参数影响，综合因素导致本段逻辑相对复杂。本段逻辑可能会生成但不限于下面的代码：</p>
<pre><code class="language-java">String extName = (url.getProtocol() == <span class="hljs-keyword">null</span> ? <span class="hljs-string">"dubbo"</span> : url.getProtocol());
</code></pre>
<p>或</p>
diff --git a/zh-cn/docs/source_code_guide/adaptive-extension.json b/zh-cn/docs/source_code_guide/adaptive-extension.json
index 71f3a68..4f28e09 100644
--- a/zh-cn/docs/source_code_guide/adaptive-extension.json
+++ b/zh-cn/docs/source_code_guide/adaptive-extension.json
@@ -1,6 +1,6 @@
{
"filename": "adaptive-extension.md",
- "__html": "<h2>1.原理</h2>\n<p>在 Dubbo 中，很多拓展都是通过 SPI 机制进行加载的，比如 Protocol、Cluster、LoadBalance 等。有时，有些拓展并不想在框架启动阶段被加载，而是希望在拓展方法被调用时，根据运行时参数进行加载。这听起来有些矛盾。拓展未被加载，那么拓展方法就无法被调用（静态方法除外）。拓展方法未被调用，拓展就无法被加载。对于这个矛盾的问题，Dubbo 通过自适应拓展机制很好的解决了。自适应拓展机制的实现逻辑比较复杂，首先 Dubbo 会为拓展接口生成具有代理功能的代码。然后通过 javassist 或 jdk 编译这段代码，得到 Class 类。最后再通过反射创建代理类，整个过程比较复杂。为了让大家对自适应拓展有一个感性的认识，下面我们通过一个示例进行演示。这是一个与汽车相关的例子，我们有一个车轮制造厂接口 WheelMaker：</p>\n<p
re><code class=\"language-java\"><span class=\"hljs-keyword\">public</span> < [...]
+ "__html": "<h2>1.原理</h2>\n<p>在 Dubbo 中，很多拓展都是通过 SPI 机制进行加载的，比如 Protocol、Cluster、LoadBalance 等。有时，有些拓展并不想在框架启动阶段被加载，而是希望在拓展方法被调用时，根据运行时参数进行加载。这听起来有些矛盾。拓展未被加载，那么拓展方法就无法被调用（静态方法除外）。拓展方法未被调用，拓展就无法被加载。对于这个矛盾的问题，Dubbo 通过自适应拓展机制很好的解决了。自适应拓展机制的实现逻辑比较复杂，首先 Dubbo 会为拓展接口生成具有代理功能的代码。然后通过 javassist 或 jdk 编译这段代码，得到 Class 类。最后再通过反射创建代理类，整个过程比较复杂。为了让大家对自适应拓展有一个感性的认识，下面我们通过一个示例进行演示。这是一个与汽车相关的例子，我们有一个车轮制造厂接口 WheelMaker：</p>\n<p
re><code class=\"language-java\"><span class=\"hljs-keyword\">public</span> < [...]
"link": "/zh-cn/docs/source_code_guide/adaptive-extension.html",
"meta": {
"title": "SPI 自适应拓展",
diff --git a/zh-cn/docs/source_code_guide/cluster.html b/zh-cn/docs/source_code_guide/cluster.html
index fd8a2c8..e45f9cb 100644
--- a/zh-cn/docs/source_code_guide/cluster.html
+++ b/zh-cn/docs/source_code_guide/cluster.html
@@ -18,7 +18,7 @@
<h2>2. 集群容错</h2>
<p>在对集群相关代码进行分析之前，这里有必要先来介绍一下集群容错的所有组件。包含 Cluster、Cluster Invoker、Directory、Router 和 LoadBalance 等。</p>
<p><img src="./sources/images/cluster.jpg" alt=""></p>
-<p>集群工作过程可分为两个阶段，第一个阶段是在服务消费者初始化期间，集群 Cluster 实现类为服务消费者创建 Cluster Invoker 实例，即上图中的 merge 操作。第二个阶段是在服务消费者进行远程调用时。以 FailoverClusterInvoker 为例，该类型 Cluster Invoker 首先会调用 Directory 的 list 方法列举 Invoker 列表（可将 Invoker 简单理解为服务提供者）。Directory 的用途是保存 Invoker，可简单类比为 List<Invoker>。其实现类 RegistryDirectory 是一个动态服务目录，可感知注册中心配置的变化，它所持有的 Invoker 列表会随着注册中心内容的变化而变化。每次变化后，RegistryDirectory 会动态增删 Invoker，并调用 Router 的 route 方法进行路由，过滤掉不符合路由规则的 Invoker。当 FailoverClusterInvoker 拿到 Directory 返回的 Invoker 列表后，它会 [...]
+<p>集群工作过程可分为两个阶段，第一个阶段是在服务消费者初始化期间，集群 Cluster 实现类为服务消费者创建 Cluster Invoker 实例，即上图中的 merge 操作。第二个阶段是在服务消费者进行远程调用时。以 FailoverClusterInvoker 为例，该类型 Cluster Invoker 首先会调用 Directory 的 list 方法列举 Invoker 列表（可将 Invoker 简单理解为服务提供者）。Directory 的用途是保存 Invoker，可简单类比为 List<Invoker>。其实现类 RegistryDirectory 是一个动态服务目录，可感知注册中心配置的变化，它所持有的 Invoker 列表会随着注册中心内容的变化而变化。每次变化后，RegistryDirectory 会动态增删 Invoker，并调用 Router 的 route 方法进行路由，过滤掉不符合路由规则的 Invoker。当 FailoverClusterInvoker 拿到 Directory 返回的 Invoker 列表后，它会 [...]
<p>以上就是集群工作的整个流程，这里并没介绍集群是如何容错的。Dubbo 主要提供了这样几种容错方式：</p>
<ul>
<li>Failover Cluster - 失败自动切换</li>
@@ -94,7 +94,7 @@
</code></pre>
<p>如上，AbstractClusterInvoker 中的 list 方法做的事情很简单，只是简单的调用了 Directory 的 list 方法，没有其他更多的逻辑了。Directory 即相关实现类在前文已经分析过，这里就不多说了。接下来，我们把目光转移到 AbstractClusterInvoker 的各种实现类上，来看一下这些实现类是如何实现 doInvoke 方法逻辑的。</p>
<h4>3.2.1 FailoverClusterInvoker</h4>
-<p>FailoverClusterInvoker 在调用失败时，会自动切换 Invoker 进行重试。默认确配置下，Dubbo 会使用这个类作为缺省 Cluster Invoker。下面来看一下该类的逻辑。</p>
+<p>FailoverClusterInvoker 在调用失败时，会自动切换 Invoker 进行重试。默认配置下，Dubbo 会使用这个类作为缺省 Cluster Invoker。下面来看一下该类的逻辑。</p>
<pre><code class="language-java"><span class="hljs-keyword">public</span> <span class="hljs-class"><span class="hljs-keyword">class</span> <span class="hljs-title">FailoverClusterInvoker</span><<span class="hljs-title">T</span>> <span class="hljs-keyword">extends</span> <span class="hljs-title">AbstractClusterInvoker</span><<span class="hljs-title">T</span>> </span>{
<span class="hljs-comment">// 省略部分代码</span>
diff --git a/zh-cn/docs/source_code_guide/cluster.json b/zh-cn/docs/source_code_guide/cluster.json
index da99296..b2b763a 100644
--- a/zh-cn/docs/source_code_guide/cluster.json
+++ b/zh-cn/docs/source_code_guide/cluster.json
@@ -1,6 +1,6 @@
{
"filename": "cluster.md",
- "__html": "<h2>1.简介</h2>\n<p>为了避免单点故障，现在的应用通常至少会部署在两台服务器上。对于一些负载比较高的服务，会部署更多的服务器。这样，在同一环境下的服务提供者数量会大于1。对于服务消费者来说，同一环境下出现了多个服务提供者。这时会出现一个问题，服务消费者需要决定选择哪个服务提供者进行调用。另外服务调用失败时的处理措施也是需要考虑的，是重试呢，还是抛出异常，亦或是只打印异常等。为了处理这些问题，Dubbo 定义了集群接口 Cluster 以及 Cluster Invoker。集群 Cluster 用途是将多个服务提供者合并为一个 Cluster Invoker，并将这个 Invoker 暴露给服务消费者。这样一来，服务消费者只需通过这个 Invoker 进行远程调用即可，至于具体调用哪个服务提供者，以及调用失败后如何处理等问题，现在都交给集群模块去处理。集�
�模块是服务提供者和服务消费者的中间层，为服务消费者屏蔽了服务提供者的情况，这样服务消费者就可以专心处理远程调用相关事宜。比如发请求，接受服务提供者返回的数据等。这就是集群的作用。< [...]
+ "__html": "<h2>1.简介</h2>\n<p>为了避免单点故障，现在的应用通常至少会部署在两台服务器上。对于一些负载比较高的服务，会部署更多的服务器。这样，在同一环境下的服务提供者数量会大于1。对于服务消费者来说，同一环境下出现了多个服务提供者。这时会出现一个问题，服务消费者需要决定选择哪个服务提供者进行调用。另外服务调用失败时的处理措施也是需要考虑的，是重试呢，还是抛出异常，亦或是只打印异常等。为了处理这些问题，Dubbo 定义了集群接口 Cluster 以及 Cluster Invoker。集群 Cluster 用途是将多个服务提供者合并为一个 Cluster Invoker，并将这个 Invoker 暴露给服务消费者。这样一来，服务消费者只需通过这个 Invoker 进行远程调用即可，至于具体调用哪个服务提供者，以及调用失败后如何处理等问题，现在都交给集群模块去处理。集�
�模块是服务提供者和服务消费者的中间层，为服务消费者屏蔽了服务提供者的情况，这样服务消费者就可以专心处理远程调用相关事宜。比如发请求，接受服务提供者返回的数据等。这就是集群的作用。< [...]
"link": "/zh-cn/docs/source_code_guide/cluster.html",
"meta": {
"title": "集群",
diff --git a/zh-cn/docs/source_code_guide/directory.html b/zh-cn/docs/source_code_guide/directory.html
index 54e819b..b1a4f58 100644
--- a/zh-cn/docs/source_code_guide/directory.html
+++ b/zh-cn/docs/source_code_guide/directory.html
@@ -439,7 +439,7 @@
<span class="hljs-keyword">return</span> result;
}
</code></pre>
-<p>上面方法首先是生成 group 到 Invoker 类比的映射关系表，若关系表中的映射关系数量大于1，表示有多组服务。此时通过集群类合并每组 Invoker，并将合并结果存储到 groupInvokers 中。之后将方法名与 groupInvokers 存到到 result 中，并返回，整个逻辑结束。</p>
+<p>上面方法首先是生成 group 到 Invoker 列表的映射关系表，若关系表中的映射关系数量大于1，表示有多组服务。此时通过集群类合并每组 Invoker，并将合并结果存储到 groupInvokers 中。之后将方法名与 groupInvokers 存到到 result 中，并返回，整个逻辑结束。</p>
<p>接下来我们再来看一下 Invoker 列表刷新逻辑的最后一个动作 — 删除无用 Invoker。如下：</p>
<pre><code class="language-java"><span class="hljs-function"><span class="hljs-keyword">private</span> <span class="hljs-keyword">void</span> <span class="hljs-title">destroyUnusedInvokers</span><span class="hljs-params">(Map<String, Invoker<T>> oldUrlInvokerMap, Map<String, Invoker<T>> newUrlInvokerMap)</span> </span>{
<span class="hljs-keyword">if</span> (newUrlInvokerMap == <span class="hljs-keyword">null</span> || newUrlInvokerMap.size() == <span class="hljs-number">0</span>) {
@@ -489,7 +489,7 @@
<li>检测入参是否仅包含一个 url，且 url 协议头为 empty</li>
<li>若第一步检测结果为 true，表示禁用所有服务，此时销毁所有的 Invoker</li>
<li>若第一步检测结果为 false，此时将入参转为 Invoker 列表</li>
-<li>对将上一步逻辑生成的结果进行进一步处理，得到方法名到 Invoker 的映射关系表</li>
+<li>对上一步逻辑生成的结果进行进一步处理，得到方法名到 Invoker 的映射关系表</li>
<li>合并多组 Invoker</li>
<li>销毁无用 Invoker</li>
</ol>
diff --git a/zh-cn/docs/source_code_guide/directory.json b/zh-cn/docs/source_code_guide/directory.json
index 6ecda00..1a6d3ba 100644
--- a/zh-cn/docs/source_code_guide/directory.json
+++ b/zh-cn/docs/source_code_guide/directory.json
@@ -1,6 +1,6 @@
{
"filename": "directory.md",
- "__html": "<h2>1. 简介</h2>\n<p>本篇文章，将开始分析 Dubbo 集群容错方面的源码。集群容错源码包含四个部分，分别是服务目录 Directory、服务路由 Router、集群 Cluster 和负载均衡 LoadBalance。这几个部分的源码逻辑相对比较独立，我们将会分四篇文章进行分析。本篇文章作为集群容错的开篇文章，将和大家一起分析服务目录相关的源码。在进行深入分析之前，我们先来了解一下服务目录是什么。服务目录中存储了一些和服务提供者有关的信息，通过服务目录，服务消费者可获取到服务提供者的信息，比如 ip、端口、服务协议等。通过这些信息，服务消费者就可通过 Netty 等客户端进行远程调用。在一个服务集群中，服务提供者数量并不是一成不变的，如果集群中新增了一台机器，相应地在服务目录中就要新增一条服务提供者记录。或者，如果服务提供者
的配置修改了，服务目录中的记录也要做相应的更新。如果这样说，服务目录和注册中心的功能不就雷同了吗？确实如此，这里这么说是为了方便大家理解。实际上服务目录在获取注册中心的服务配置信息后，会为每条配置信息生成一 [...]
+ "__html": "<h2>1. 简介</h2>\n<p>本篇文章，将开始分析 Dubbo 集群容错方面的源码。集群容错源码包含四个部分，分别是服务目录 Directory、服务路由 Router、集群 Cluster 和负载均衡 LoadBalance。这几个部分的源码逻辑相对比较独立，我们将会分四篇文章进行分析。本篇文章作为集群容错的开篇文章，将和大家一起分析服务目录相关的源码。在进行深入分析之前，我们先来了解一下服务目录是什么。服务目录中存储了一些和服务提供者有关的信息，通过服务目录，服务消费者可获取到服务提供者的信息，比如 ip、端口、服务协议等。通过这些信息，服务消费者就可通过 Netty 等客户端进行远程调用。在一个服务集群中，服务提供者数量并不是一成不变的，如果集群中新增了一台机器，相应地在服务目录中就要新增一条服务提供者记录。或者，如果服务提供者
的配置修改了，服务目录中的记录也要做相应的更新。如果这样说，服务目录和注册中心的功能不就雷同了吗？确实如此，这里这么说是为了方便大家理解。实际上服务目录在获取注册中心的服务配置信息后，会为每条配置信息生成一 [...]
"link": "/zh-cn/docs/source_code_guide/directory.html",
"meta": {
"title": "服务目录",
diff --git a/zh-cn/docs/source_code_guide/refer-service.html b/zh-cn/docs/source_code_guide/refer-service.html
index d8e66cd..c8560dd 100644
--- a/zh-cn/docs/source_code_guide/refer-service.html
+++ b/zh-cn/docs/source_code_guide/refer-service.html
@@ -613,7 +613,7 @@
<span class="hljs-keyword">return</span> (T) Proxy.getProxy(interfaces).newInstance(<span class="hljs-keyword">new</span> InvokerInvocationHandler(invoker));
}
</code></pre>
-<p>上面代码并不多，首先是通过 Proxy 的 getProxy 方法获取 Proxy 子类，然后创建 InvokerInvocationHandler 对象，并将该对象传给 newInstance 生成 Proxy 实例。InvokerInvocationHandler 实现自 JDK 的 InvocationHandler 接口，具体的用途是拦截接口类调用。该类逻辑比较简单，这里就不分析了。下面我们重点关注一下 Proxy 的 getProxy 方法，如下。</p>
+<p>上面代码并不多，首先是通过 Proxy 的 getProxy 方法获取 Proxy 子类，然后创建 InvokerInvocationHandler 对象，并将该对象传给 newInstance 生成 Proxy 实例。InvokerInvocationHandler 实现 JDK 的 InvocationHandler 接口，具体的用途是拦截接口类调用。该类逻辑比较简单，这里就不分析了。下面我们重点关注一下 Proxy 的 getProxy 方法，如下。</p>
<pre><code class="language-java">public static Proxy getProxy(Class<?>... ics) {
// 调用重载方法
return getProxy(ClassHelper.getClassLoader(Proxy.class), ics);
diff --git a/zh-cn/docs/source_code_guide/refer-service.json b/zh-cn/docs/source_code_guide/refer-service.json
index 70e73d5..4ecf408 100644
--- a/zh-cn/docs/source_code_guide/refer-service.json
+++ b/zh-cn/docs/source_code_guide/refer-service.json
@@ -1,6 +1,6 @@
{
"filename": "refer-service.md",
- "__html": "<h2>1. 简介</h2>\n<p>上一篇文章详细分析了服务导出的过程，本篇文章我们趁热打铁，继续分析服务引用过程。在 Dubbo 中，我们可以通过两种方式引用远程服务。第一种是使用服务直连的方式引用服务，第二种方式是基于注册中心进行引用。服务直连的方式仅适合在调试或测试服务的场景下使用，不适合在线上环境使用。因此，本文我将重点分析通过注册中心引用服务的过程。从注册中心中获取服务配置只是服务引用过程中的一环，除此之外，服务消费者还需要经历 Invoker 创建、代理类创建等步骤。这些步骤，将在后续章节中一一进行分析。</p>\n<h2>2.服务引用原理</h2>\n<p>Dubbo 服务引用的时机有两个，第一个是在 Spring 容器调用 ReferenceBean 的 afterPropertiesSet 方法时引用服务，第二个是在 ReferenceBean 对应的服务被注入到其他类中时引用。这两�
��引用服务的时机区别在于，第一个是饿汉式的，第二个是懒汉式的。默认情况下，Dubbo 使用懒汉式引用服务。如果需要使用饿汉式，可通过配置 < [...]
+ "__html": "<h2>1. 简介</h2>\n<p>上一篇文章详细分析了服务导出的过程，本篇文章我们趁热打铁，继续分析服务引用过程。在 Dubbo 中，我们可以通过两种方式引用远程服务。第一种是使用服务直连的方式引用服务，第二种方式是基于注册中心进行引用。服务直连的方式仅适合在调试或测试服务的场景下使用，不适合在线上环境使用。因此，本文我将重点分析通过注册中心引用服务的过程。从注册中心中获取服务配置只是服务引用过程中的一环，除此之外，服务消费者还需要经历 Invoker 创建、代理类创建等步骤。这些步骤，将在后续章节中一一进行分析。</p>\n<h2>2.服务引用原理</h2>\n<p>Dubbo 服务引用的时机有两个，第一个是在 Spring 容器调用 ReferenceBean 的 afterPropertiesSet 方法时引用服务，第二个是在 ReferenceBean 对应的服务被注入到其他类中时引用。这两�
��引用服务的时机区别在于，第一个是饿汉式的，第二个是懒汉式的。默认情况下，Dubbo 使用懒汉式引用服务。如果需要使用饿汉式，可通过配置 < [...]
"link": "/zh-cn/docs/source_code_guide/refer-service.html",
"meta": {
"title": "服务引用",
diff --git a/zh-cn/docs/source_code_guide/router.html b/zh-cn/docs/source_code_guide/router.html
index 467ef13..95d1470 100644
--- a/zh-cn/docs/source_code_guide/router.html
+++ b/zh-cn/docs/source_code_guide/router.html
@@ -173,7 +173,7 @@
</code></pre>
<p>路由规则的解析过程稍微有点复杂，大家可通过 ConditionRouter 的测试类对该逻辑进行测试。并且找一个表达式，对照上面的代码走一遍，加深理解。</p>
<h3>2.2 服务路由</h3>
-<p>服务路由的入口方法是 ConditionRouter 的 router 方法，该方法定义在 Router 接口中。实现代码如下：</p>
+<p>服务路由的入口方法是 ConditionRouter 的 route 方法，该方法定义在 Router 接口中。实现代码如下：</p>
<pre><code class="language-java"><span class="hljs-keyword">public</span> <T> List<Invoker<T>> route(List<Invoker<T>> invokers, URL url, Invocation invocation) <span class="hljs-keyword">throws</span> RpcException {
<span class="hljs-keyword">if</span> (invokers == <span class="hljs-keyword">null</span> || invokers.isEmpty()) {
<span class="hljs-keyword">return</span> invokers;
@@ -220,7 +220,7 @@
<span class="hljs-keyword">return</span> invokers;
}
</code></pre>
-<p>router 方法先是调用 matchWhen 对服务消费者进行匹配，如果匹配失败，直接返回 Invoker 列表。如果匹配成功，再对服务提供者进行匹配，匹配逻辑封装在了 matchThen 方法中。下面来看一下这两个方法的逻辑：</p>
+<p>route 方法先是调用 matchWhen 对服务消费者进行匹配，如果匹配失败，直接返回 Invoker 列表。如果匹配成功，再对服务提供者进行匹配，匹配逻辑封装在了 matchThen 方法中。下面来看一下这两个方法的逻辑：</p>
<pre><code class="language-java"><span class="hljs-function"><span class="hljs-keyword">boolean</span> <span class="hljs-title">matchWhen</span><span class="hljs-params">(URL url, Invocation invocation)</span> </span>{
<span class="hljs-comment">// 服务消费者条件为 null 或空，均返回 true，比如：</span>
<span class="hljs-comment">// => host != 172.22.3.91</span>
diff --git a/zh-cn/docs/source_code_guide/router.json b/zh-cn/docs/source_code_guide/router.json
index a552707..6216566 100644
--- a/zh-cn/docs/source_code_guide/router.json
+++ b/zh-cn/docs/source_code_guide/router.json
@@ -1,6 +1,6 @@
{
"filename": "router.md",
- "__html": "<h2>1. 简介</h2>\n<p>上一篇文章分析了集群容错的第一部分 — 服务目录 Directory。服务目录在刷新 Invoker 列表的过程中，会通过 Router 进行服务路由，筛选出符合路由规则的服务提供者。在详细分析服务路由的源码之前，先来介绍一下服务路由是什么。服务路由包含一条路由规则，路由规则决定了服务消费者的调用目标，即规定了服务消费者可调用哪些服务提供者。Dubbo 目前提供了三种服务路由实现，分别为条件路由 ConditionRouter、脚本路由 ScriptRouter 和标签路由 TagRouter。其中条件路由是我们最常使用的，标签路由是一个新的实现，暂时还未发布，该实现预计会在 2.7.x 版本中发布。本篇文章将分析条件路由相关源码，脚本路由和标签路由这里就不分析了。</p>\n<h2>2. 源码分析</h2>\n<p>条件路由规则由两个条件组成，分别用于对服务消费者和提�
��者进行匹配。比如有这样一条规则：</p>\n<p><code>host = 10.20.153.10 => host = 10.20 [...]
+ "__html": "<h2>1. 简介</h2>\n<p>上一篇文章分析了集群容错的第一部分 — 服务目录 Directory。服务目录在刷新 Invoker 列表的过程中，会通过 Router 进行服务路由，筛选出符合路由规则的服务提供者。在详细分析服务路由的源码之前，先来介绍一下服务路由是什么。服务路由包含一条路由规则，路由规则决定了服务消费者的调用目标，即规定了服务消费者可调用哪些服务提供者。Dubbo 目前提供了三种服务路由实现，分别为条件路由 ConditionRouter、脚本路由 ScriptRouter 和标签路由 TagRouter。其中条件路由是我们最常使用的，标签路由是一个新的实现，暂时还未发布，该实现预计会在 2.7.x 版本中发布。本篇文章将分析条件路由相关源码，脚本路由和标签路由这里就不分析了。</p>\n<h2>2. 源码分析</h2>\n<p>条件路由规则由两个条件组成，分别用于对服务消费者和提�
��者进行匹配。比如有这样一条规则：</p>\n<p><code>host = 10.20.153.10 => host = 10.20 [...]
"link": "/zh-cn/docs/source_code_guide/router.html",
"meta": {
"title": "服务路由",