dubbo源码解析-集群容错架构设计

前言

原本是想把整个dubbo源码解析一次性弄完，再作成一个系列来发布的，可是正巧最近有位好朋友要去杭州面试，就和我交流了一下。本着对dubbo源码略有心得的心态，在交流过程当中也发表了我的的一些粗劣的拙见。可是很是不幸的是，交流过程当中我这位朋友问到了几个问题，我却没能回答得上，让我感到十分惭愧。故而将原计划提早，而且按期整理，作到按期更新一篇dubbo源码解析，好让本身的知识盲点尽早暴露出来。本篇讲的就是dubbo的一个重要概念，集群容错。既然你已经在看源码解析了，那么我就假设你对dubbo的使用上有必定的经验,对集群容错的简单介绍。

前期铺垫

 

 

 

 

 

官网介绍图

这张是官网的对于集群容错的架构设计图，即便你有必定的使用经验，第一眼看到这个图可能仍是有些懵逼。由于这个图是从设计的角度画出来的，而不是使用的角度。可是即便这个图你看不懂也不影响你对本文的阅读，可是你必需要记住三个关键词，由于这三个关键词接下来会贯穿全文，他们就是Directory、Router、LoadBalance。

再接下来给你们一张"地图"，"地图"上我已经标记了序号，再下面的源码分析中，我也会实时提醒咱们所在的位置，以致于不会迷失方向。

 

 

 

 

 

执行时序图

 

环境准备

既然是集群，那么首先要启动两个Provider，我这里是一个虚拟机，一个本地的方式，由于环境准备不是本文重点，所以略过。本文所用到的源码是2.5.4版本，能够在guihub上找到。

正式发车

此次示例选用的源码用dubbo-demo的dubbo-demo-consumer，若是对dubbo原理有些简单的了解就知道，他给接口注入的不是接口的实现类，而是一个代理类，以下图：

 

 

 

 

接着天然是到了代理类的invoke方法里，从图中咱们也能够看出，他用的是jdk的动态代理。

 

 

 

 

下面要开始紧盯着地图了，他如今就要开始执行地图中的序号1，此时咱们抵达MockClusterInvoker这个类。

 

 

 

 

执行invoke就要开始进入到集群，也就是Cluster，如今第一个关键词Directory已经浮出水面了。

 

 

 

 

 

 

 

 

如今到了AbstractDirectory，也就是序号3。

 

 

 

 

这个methodInvokerMap也比较重要，后面的文章会讲一下这个，可是咱们这部分代码就能够从出，他是要从methodInvokerMap中取出invokers如图所示：

 

 

 

 

 

 

 

 

将invokers返回后(序号5)，下面来到了第二个关键词，Router，开始进入路由，如今咱们到了序号6，此时到了MockInvokersSelector类，不要看类名和Router没有关系，其实他是Router接口的实现类，从官网的介绍图中咱们也能够看到Router分为Script和Condition两种，翻译过来也就是脚本路由和条件路由这个后面再详细介绍，本篇主要介绍总体架构。

 

 

 

 

源码的命名是很规范的，从getNormalInvokers就能够得知，他是要拿到能正常执行的invokers，并将其返回，也就是序号7。

 

 

 

 

 

 

 

 

这个时候咱们再次回到了AbstractClusterInvoker这个类，咱们先不急着往下走，先适时作个总结。由于三个关键词，如今都已经出现了两个，那这个时候要回忆一下上面这些步骤，作一个总结。上面出现的这两个关键词，其实无非就是作两件事：

• 在Directory中找出本次集群中的所有invokers
• 在Router中,将上一步的所有invokers挑选出能正常执行的invokers

 

对应到"地图"，也就是序号5和序号7。(再次提醒，必定要紧跟地图的序号，否则很容易迷失方向)。

从上面步骤咱们也知道，已经挑选出能正常执行的invokers了，可是假如2个作集群，可是这两个都是正常的，我到底要执行哪个呢？带着这个问题，咱们继续往下看。

 

 

 

 

 

 

 

 

根据官网的描述：

在集群调用失败时，Dubbo 提供了多种容错方案，缺省为 failover 重试。

 

因此这个时候是到了FailoverClusterInvoker类，可是若是你配置的是Failover Cluster（快速失败），Failsafe Cluster（失败安全），Failback Cluster（失败自动恢复），Forking Cluster（并行调用多个服务器，只要一个成功即返回），Broadcast Cluster（广播调用全部提供者，逐个调用，任意一台报错则报错）他也会到达相应的类。

 

 

 

 

 

 

 

 

下面就要开始第三个关键词浮出水面，也就是LoadBalance(负载均衡)，此时的位置是序号11，仔细留心源码的注释，其实这里能够出一个面试题，好比：

dubbo的负载均衡策略是怎么样的?

 

为何这能够做为一道面试题，由于他能够区分三个层次的人。

• 若是是没有使用过，或者一直停留在使用层次的人，确定不会留级到这个负载均衡策略；
• 根据官网介绍在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 random 随机调用。若是能回答出，缺省为随机调用的，说明仍是有必定的使用经验，留意到官网的介绍；
• 若是能回答出，缺省为随机调用，可是若是集群的数量为2，那么将退化成轮询。若是能回答到这个，那这我的就是有必定追求，不只留心文档介绍，并且是看过源码，注意细节的人(好比本文做者肥朝 ^_^ )。

 

根据前面咱们知道，如今已经有两个备选的invokers，可是究竟哪个能执行，这个须要LoadBalance来决定。这里涉及到了必定的算法，后面我也会有一篇文章加以介绍。剧透一下，这个在2.5.4的版本中，这个算法仍是存在一些小的bug，此时咱们的位置是序号13。

 

 

 

 

 

 

 

 

到达终点站，咱们回忆总结一下，文初提到的三个关键词，在这个集群容错的总体架构过程当中，dubbo究竟作了什么？其实也就是三件事：

• 在Directory中找出本次集群中的所有invokers
• 在Router中，将上一步的所有invokers挑选出能正常执行的invokers
• 在LoadBalance中，将上一步的能正常的执行invokers中，根据配置的负载均衡策略,挑选出须要执行的invoker