This is an automated email from the ASF dual-hosted git repository. wangxin pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/dubbo-website.git
The following commit(s) were added to refs/heads/master by this push: new 5fb6d4e Update source_code_guide (#560) 5fb6d4e is described below commit 5fb6d4e8c7c64f6b851f8c9301e6c8adca7e3cb1 Author: 兰染 <evange...@sina.com> AuthorDate: Sun Jan 26 12:52:26 2020 +0800 Update source_code_guide (#560) --- docs/zh-cn/source_code_guide/adaptive-extension.md | 4 ++-- docs/zh-cn/source_code_guide/cluster.md | 4 ++-- docs/zh-cn/source_code_guide/directory.md | 4 ++-- docs/zh-cn/source_code_guide/refer-service.md | 2 +- docs/zh-cn/source_code_guide/router.md | 4 ++-- 5 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/zh-cn/source_code_guide/adaptive-extension.md b/docs/zh-cn/source_code_guide/adaptive-extension.md index 24d4627..cd1e727 100644 --- a/docs/zh-cn/source_code_guide/adaptive-extension.md +++ b/docs/zh-cn/source_code_guide/adaptive-extension.md @@ -165,7 +165,7 @@ getAdaptiveExtensionClass 方法同样包含了三个逻辑,如下: 2. 检查缓存,若缓存不为空,则返回缓存 3. 若缓存为空,则调用 createAdaptiveExtensionClass 创建自适应拓展类 -这三个逻辑看起来平淡无奇,似乎没有多讲的必要。但是这些平淡无奇的代码中隐藏了着一些细节,需要说明一下。首先从第一个逻辑说起,getExtensionClasses 这个方法用于获取某个接口的所有实现类。比如该方法可以获取 Protocol 接口的 DubboProtocol、HttpProtocol、InjvmProtocol 等实现类。在获取实现类的过程中,如果某个某个实现类被 Adaptive 注解修饰了,那么该类就会被赋值给 cachedAdaptiveClass 变量。此时,上面步骤中的第二步条件成立(缓存不为空),直接返回 cachedAdaptiveClass 即可。如果所有的实现类均未被 Adaptive 注解修饰,那么执行第三步逻辑,创建自适应拓展类。相关代码如下: +这三个逻辑看起来平淡无奇,似乎没有多讲的必要。但是这些平淡无奇的代码中隐藏了着一些细节,需要说明一下。首先从第一个逻辑说起,getExtensionClasses 这个方法用于获取某个接口的所有实现类。比如该方法可以获取 Protocol 接口的 DubboProtocol、HttpProtocol、InjvmProtocol 等实现类。在获取实现类的过程中,如果某个实现类被 Adaptive 注解修饰了,那么该类就会被赋值给 cachedAdaptiveClass 变量。此时,上面步骤中的第二步条件成立(缓存不为空),直接返回 cachedAdaptiveClass 即可。如果所有的实现类均未被 Adaptive 注解修饰,那么执行第三步逻辑,创建自适应拓展类。相关代码如下: ```java private Class<?> createAdaptiveExtensionClass() { @@ -493,7 +493,7 @@ for (Method method : methods) { ##### 2.2.3.5 生成拓展名获取逻辑 -本段逻辑用于根据 SPI 和 Adaptive 注解值生成“获取拓展名逻辑”,同时生成逻辑也受 Invocation 类型参数影响,综合因素导致本段逻辑相对复杂。本段逻辑可以会生成但不限于下面的代码: +本段逻辑用于根据 SPI 和 Adaptive 注解值生成“获取拓展名逻辑”,同时生成逻辑也受 Invocation 类型参数影响,综合因素导致本段逻辑相对复杂。本段逻辑可能会生成但不限于下面的代码: ```java String extName = (url.getProtocol() == null ? "dubbo" : url.getProtocol()); diff --git a/docs/zh-cn/source_code_guide/cluster.md b/docs/zh-cn/source_code_guide/cluster.md index 6fe7a95..4a8961c 100644 --- a/docs/zh-cn/source_code_guide/cluster.md +++ b/docs/zh-cn/source_code_guide/cluster.md @@ -16,7 +16,7 @@ Dubbo 提供了多种集群实现,包含但不限于 Failover Cluster、Failfa ![](./sources/images/cluster.jpg) -集群工作过程可分为两个阶段,第一个阶段是在服务消费者初始化期间,集群 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 列表后,它会通过 Load [...] +集群工作过程可分为两个阶段,第一个阶段是在服务消费者初始化期间,集群 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 列表后,它会通过 Load [...] 以上就是集群工作的整个流程,这里并没介绍集群是如何容错的。Dubbo 主要提供了这样几种容错方式: @@ -112,7 +112,7 @@ protected List<Invoker<T>> list(Invocation invocation) throws RpcException { #### 3.2.1 FailoverClusterInvoker -FailoverClusterInvoker 在调用失败时,会自动切换 Invoker 进行重试。默认确配置下,Dubbo 会使用这个类作为缺省 Cluster Invoker。下面来看一下该类的逻辑。 +FailoverClusterInvoker 在调用失败时,会自动切换 Invoker 进行重试。默认配置下,Dubbo 会使用这个类作为缺省 Cluster Invoker。下面来看一下该类的逻辑。 ```java public class FailoverClusterInvoker<T> extends AbstractClusterInvoker<T> { diff --git a/docs/zh-cn/source_code_guide/directory.md b/docs/zh-cn/source_code_guide/directory.md index 9c71e76..5e9caf7 100644 --- a/docs/zh-cn/source_code_guide/directory.md +++ b/docs/zh-cn/source_code_guide/directory.md @@ -476,7 +476,7 @@ private Map<String, List<Invoker<T>>> toMergeMethodInvokerMap(Map<String, List<I } ``` -上面方法首先是生成 group 到 Invoker 类比的映射关系表,若关系表中的映射关系数量大于1,表示有多组服务。此时通过集群类合并每组 Invoker,并将合并结果存储到 groupInvokers 中。之后将方法名与 groupInvokers 存到到 result 中,并返回,整个逻辑结束。 +上面方法首先是生成 group 到 Invoker 列表的映射关系表,若关系表中的映射关系数量大于1,表示有多组服务。此时通过集群类合并每组 Invoker,并将合并结果存储到 groupInvokers 中。之后将方法名与 groupInvokers 存到到 result 中,并返回,整个逻辑结束。 接下来我们再来看一下 Invoker 列表刷新逻辑的最后一个动作 — 删除无用 Invoker。如下: @@ -531,7 +531,7 @@ destroyUnusedInvokers 方法的主要逻辑是通过 newUrlInvokerMap 找出待 1. 检测入参是否仅包含一个 url,且 url 协议头为 empty 2. 若第一步检测结果为 true,表示禁用所有服务,此时销毁所有的 Invoker 3. 若第一步检测结果为 false,此时将入参转为 Invoker 列表 -4. 对将上一步逻辑生成的结果进行进一步处理,得到方法名到 Invoker 的映射关系表 +4. 对上一步逻辑生成的结果进行进一步处理,得到方法名到 Invoker 的映射关系表 5. 合并多组 Invoker 6. 销毁无用 Invoker diff --git a/docs/zh-cn/source_code_guide/refer-service.md b/docs/zh-cn/source_code_guide/refer-service.md index 3ce1976..7102b36 100644 --- a/docs/zh-cn/source_code_guide/refer-service.md +++ b/docs/zh-cn/source_code_guide/refer-service.md @@ -666,7 +666,7 @@ public <T> T getProxy(Invoker<T> invoker, Class<?>[] interfaces) { } ``` -上面代码并不多,首先是通过 Proxy 的 getProxy 方法获取 Proxy 子类,然后创建 InvokerInvocationHandler 对象,并将该对象传给 newInstance 生成 Proxy 实例。InvokerInvocationHandler 实现自 JDK 的 InvocationHandler 接口,具体的用途是拦截接口类调用。该类逻辑比较简单,这里就不分析了。下面我们重点关注一下 Proxy 的 getProxy 方法,如下。 +上面代码并不多,首先是通过 Proxy 的 getProxy 方法获取 Proxy 子类,然后创建 InvokerInvocationHandler 对象,并将该对象传给 newInstance 生成 Proxy 实例。InvokerInvocationHandler 实现 JDK 的 InvocationHandler 接口,具体的用途是拦截接口类调用。该类逻辑比较简单,这里就不分析了。下面我们重点关注一下 Proxy 的 getProxy 方法,如下。 ```java public static Proxy getProxy(Class<?>... ics) { diff --git a/docs/zh-cn/source_code_guide/router.md b/docs/zh-cn/source_code_guide/router.md index f2835db..38037dc 100644 --- a/docs/zh-cn/source_code_guide/router.md +++ b/docs/zh-cn/source_code_guide/router.md @@ -201,7 +201,7 @@ private static Map<String, MatchPair> parseRule(String rule) ### 2.2 服务路由 -服务路由的入口方法是 ConditionRouter 的 router 方法,该方法定义在 Router 接口中。实现代码如下: +服务路由的入口方法是 ConditionRouter 的 route 方法,该方法定义在 Router 接口中。实现代码如下: ```java public <T> List<Invoker<T>> route(List<Invoker<T>> invokers, URL url, Invocation invocation) throws RpcException { @@ -251,7 +251,7 @@ public <T> List<Invoker<T>> route(List<Invoker<T>> invokers, URL url, Invocation } ``` -router 方法先是调用 matchWhen 对服务消费者进行匹配,如果匹配失败,直接返回 Invoker 列表。如果匹配成功,再对服务提供者进行匹配,匹配逻辑封装在了 matchThen 方法中。下面来看一下这两个方法的逻辑: +route 方法先是调用 matchWhen 对服务消费者进行匹配,如果匹配失败,直接返回 Invoker 列表。如果匹配成功,再对服务提供者进行匹配,匹配逻辑封装在了 matchThen 方法中。下面来看一下这两个方法的逻辑: ```java boolean matchWhen(URL url, Invocation invocation) {