dubbo消费端设置全局的服务降级

大家好，我是图宁课堂的北冥。今天我们来聊聊这道面试题啊，如何去基于 double 去进行服务治理，服务降级失败从事以及超时从事呢？ 那么首先第一个服务治理。如果是说面试官问你这个问题的时候，他其实就想看看哎，你有没有服务治理的一个思想，只要是哎，我们做过一些复杂一点的微服架构的人，他肯定会遇到这方面的问题。 还有一个就是哎，我们去评判一个程序员好坏的一个标准。首先第一点你是你能不能够按照要求哎去把对应的功能完成。那么第二个是哎，你有没有去考虑到一些异常的情况，那么这个点是非常重要的。 好，那么来讲第二点服务降级。那么这个呢，是涉及到一些比较复杂的一些分布式系统里面一个非常重要的一个话题啊，因为我们整个分布式系统来是来回调用的对吧？如果是说中间一个系统出现 故障的话，哎，如果是说你不降级，那么你整条链路就调不通了，对吧？所以说这个呢，也是一个很重要的知识点。那么第三个失败重试。就是说在我们整个分布式系统里面，我们的一整个网络调呢，是非常频繁的。如果是说哎，因为网络问题不小心失败了，那么这个时候我们是不是要去做重试对吧？好，那么这个呢就是我们的失败重试。那么第四点 超时从事，实际上跟我们上面一样啊。如果是说哎，我们的网络不小心慢了一点，哎，他已经超时了，那么这个时候怎么做从事呢？好，那么我们就针对这四点来跟大家去进一个剖析啊。首先第一个就是我们的服务治理。我们都知道一个大型的分布式系统， 或者是说哎，比较流行的微服务架构对吧？他都是由一个大量的服务组成的。那么这些服务之间是怎么相互调用的呢？哎，那么他的一个调用面路是什么呢？事实上哎，只要发展到一定程度哎，几乎没有人搞得清楚了哎，因为服务真的实在太 太多了。你几个服务你还能够捋清楚哎，如果说几百个几千个微服务哎，那这个时候你可能就捋不清楚了。那么在我们的 double 里面，哎，他可以对我们各个服务的调用，自动的把我们记录下来。然后我们就可以根据这各个服务之间的一个依赖关系，把我们的一整个调工念录给我们生成出来哎，做成一张图显示出来。 就比如说我们可以看到下面这张图对吧？那么这个呢，就是我们讲的第一点，哎，调用链路的一个自动生成。好，我们来讲我们的第二点 就说哎，我们服务的一个访问压力，包括我们的一些时长统计，这个怎么做呢？事实上这个是分为两个层面啊。首先第一个级别 就是我们一个接口的力度，比如说我们每一个对外提供服务的接口哎，他每天调用了多少次？那么包括我们的 t p 五零， t p 九零， t p 九九哎，这三个档次分别他们的一个请求延时是多少？那么这个呢，也是需要记录的。那么第二个 级别什么呢？我们从源头开始，我们一整个完整的念路，就比如说我们从 a 到 b， 然后 b 到一对吧。那么首先第一个就是 a 一个完整的念路，它的一个总耗时是多少，包括我一整个全念路的 a， 它的一个 t p 五零， t p 九零， t p 九九，分别是多少？ 只有当我们把这些东西搞清楚了之后，哎，我们才能够看到我们整个系统的一个主要压力瓶颈是在哪个位置，然后我们才能针对性的去进行扩容啊，去进行优化等等。然后再包括一些其他关于服务自己的东西，就比如说 我们服务要分层，然后我们要去避免一个循环依赖对吧？哎，包括我们整个调用链路的一些失败监控，包括一些报警，然后包括我们一整个服务的一些健全，然后包括我们每一个服务的一些可用性的监控，比如说我们接口调用成功率是多少啊，有几个九对吧，我们能达到两个九呢，就可以称之为高可用了等等等等。那么这些呢？是关于服务治理方面的 东西，我们我们可以从这几个维度来去进行回答。好，我们来讲我们的第二个服务降级。比如说我们的服务 a 去调用我们服务 b 的时候，哎，假设我们的服务 b 挂了，当他遇到失败，哎，从事之后还是不行，那么这个时候我们对外提供的服务 a 是不是就无法提供正常的响应了，对吧？那么这个时候呢，我们不能直接去返回一个错误， 那么这个时候我们就可以去走我们的服务降级了，哎，我们去选用一个备用的逻辑给用户返回一个请求，嗯，比如说我们要请求一些列表对吧？我们可以返回一个默认的列表，或者是说哎，我们可以返回一些空列表对吧？但是我们尽量不要把错误哎返回给用户。 那么这个呢？是关于我们服务降级的一些东西啊。我们再来去讲一讲我们失败从事和超时从事。那么失败从事呢？理解起来也非常简单，就是说我们的这个消费者哎，去调我们的这个提供者，如果是说哎调用失败了，跑异常了，那么这个时候我们是不是应该从事对吧？ 或者说哎，我们超时时间可能设置两秒哎，但是数量比较大，他超过了两秒，那我们是不是也可以去进行从事啊？那么关于这两点呢？我们就可以去结合我们自己具体的业务，然后去讲讲哎，我们怎么去设置这些参数的哎，比如说超时对吧？我们一般比如说可能设置一个两百毫秒，包括也有一些公司 比较复杂一些业务，它本身的使用时间比较长，我们也可以设置成一秒两秒之类的对吧？但是超过这个时间，如果说没有返回的话哎，那就说明他可能碰到了一些异常。 那么第二点呢，我们是不是要去配置我们一个失败的一个重试次数对吧？我们一般在一些读的停用场景的时候，比如说我们要查询一个数据，如果是说哎，我们设置了这个失败重试的一个次数 哎，假设第一次没读到报错，那么比如说我们设置了三次，如果说三次还没读到，那么是不是我们就可以确定哎，这个伏币肯定发生了一个异常对吧？那么这个呢？就是我们的一个重试次数。 那么我们在回答失败从事和和超时从事的时候，我们就可以基于我们的一个超时时间和一个从事次数来去进一个回答。那么这个呢？就是我们今天基于 double 所聊的一些东西。好，那么我们下节课再见。

大家好，今天我们来继续学习大伯野马剖析服务降级墨客中的第二个操作者，消防的 mark， 以及这个墨壳是怎么合法性检测的，其实他在启动的时候就做了一定的合法性检测。好，我们来看一下这个墨壳到底是个什么东西呢？ 既然是墨可，那他就他就是个消费方，那他消费方的话，我就得准备一个这个墨可的消费方。然后我们上一节不是弄了一个什么 jk 什么服务的，这个我就拿这个来改一下，改一下啊，别说 莫克，莫克斯文看什么 好。我进行了墨可之后呢？那其实我需要一个泪，我要叫你来叫一个墨可的泪，墨可泪的话就是这个的 加一个后缀，然后加一个后缀，肯定是实现这个接口嘛。 我们看一下这个里面他真实的是一个什么逻辑， 是好是一个这样逻辑，那我就超过来了， 好墨可版本也不要了，就这样，然后 买手机，然后买手机打印一下， 这个累了， 因为我要去启动，我需要去启动的话，那我就可以设设置默可，默可什么呢处， 然后这个线程其实是没用的，我们就放，因为对我们本章节其实没用， 我就删掉。好，我们来起一下我们的服务方，服务方的话，其实我可以用刚刚的那个 护发，还是用这个这个吧，就来起一下。 然后起完了之后，我们来试一下我们的消费方到底能不能起到墨壳的作用， 好来运行一下 啊，其实是报错的。呃，这个时候我们就来看一下，就是 do not find a max 是不是这样的，那我们就来看一下，既然他出错在这，那我们就断点到这来， 然后这个时候是优斯啊，不对的，佛萨的，你既然进来了，那我们就来看他的调用法。 那他的调验方的话，他其实是在我们消费方启动的时候，他这个接口是优势而不对的，复杂的，你看这，他这里就来了一个什么切克的动作。因此 哦，这里讲的就是消费方的墨客，以及合法性检测。检测。其实在启动时的时候就会做一个这个检测的动作。他检测什么东西呢？ 我们可以来看一下他检测的话，他首先他获他通过墨客的东西获取一个数据，比如说获取他通过这个获取一个这个所谓的 dford 东西，那 dford 东西他往下走的话， 就走到这来，那么这个里面的货车，那我来看一下这个东西又计算出来是一个什么东西呢？ 这里也是个处。好，那这里也是个处。那最终呢， 得失的结，这个结果是个什么东西呢？我们再来 是一个 apius update 的佛萨的莫可，一个这个东西，但是你看他的莫可的泪和我们的泪一样吗？ 我们可以来看一下，就是这个类是 comm 这个 consome 点墨客和这个类其实不一样，那不一样的话怎么办呢？我们再稍微往下看一下， 就发现他下面还有一个反色的类。那么我们尝试，如果我能走到下面来，那是不是挺好的？ 所以那就意味着我这个东西要得出我的这个权利名。那这个东西再往上走， 那是不是意味着传进来的这个东西我得去得到这个类的全路径，那么我就得往这个方法里面看，我怎么才能得到这个全路径，而且得到全路径之后，你看他这里有 start 的位置 reton， 然后这里有 start 的位置 stro， 然后呢，你竟然是一个类名，那么这两个逻辑你完全可以不用进去。那么你相当于你进到这个逻辑里面来，你只要把莫克特兹想办法让他得到 你的类名。然后我们再来分析看一下，这是我的莫克的值。 这首先这个莫可是我莫可的那个值，然后莫可填的值现在是全类名，不等于闹，没关系去么之后还是全类名。然后全类名并不是微特开头的，也进不去。然后也不是 fel， 也不是 force 开头，也进不去。 然后再往后走，你也不是 fail， 也不是 force， 也不是 return， 也不是 snow。 从这几个上面来看，我们可以发现，就是我们的木盒可以填一些东西，比如说填 fir， 填 fos， 填 slow， 填 retoon， 你想怎么填，你就按照他的规矩来。那么 我刚刚说那权利名这些都进不去，那么是不是这里就来了一个权利名。好，那 我我们其实就可以这样填 好，我变成这样看行不行呢？这个时候我把它断掉，我们的看 super， 把它断掉，我再来第八个一次， 这个手我就提前一点， 提前了。之后呢，我们我们就进去看一下， 你看他等于闹不成立，往下走，然后确模一下，他还是全列名，认识等于零，不等于零，没关系，他肯定也不是微腾开头的，这里也进不去。 然后呢，他也不是什么 dford 什么之类，也不是 mork， 什么 first fell 也进不去。好，他也不是 return 开，也不是 非要开头的，那也进不去，那也不是 forse 开头的，也进不去，那也不是瑞特，也不是 snow 开头的，那也进不去好，那就往下走。 然后这里也不是微腾开头的，往下走。然后也不是 no 开头的，往下走好，就进到这来了。然后进到这来之后呢？然后看这个东西是不是 dfort 呢？ 来看他也是 pose 好，那就往下走。那往下走的话，我拿着这个类名，我能不能从反射拿到东西呢？我就往下来看。 哎，他没报错。没报错意味着莫克科拉斯的这个对象已经有了。那他已经有了的话，那他就做了一个创建实力的一个这样的动作。 如果能 ok， 没报错好，那么就往下走 啊。这个时候是以之前的一些断点跳，呃，干掉，这个也干掉，然后 lot five 也干掉。然后这个是钓友 好。发现没？其实是能拿到结果了。但是呢，有没有想为什么能拿到结果？这是什么原因？ 因为我明明墨渴了，但是没有数据怎么办？这个时候我稍微调整一下，比如说 我把这里的 set time out 变为一毫秒，如果变为一毫秒的话，但是我此刻的 setter retreat 我不尝试，我就掉。呃，对，我就掉一次。 来看一下。 好。这个时候大家发现没，就是我们的结果就出来了，他已经走到我们的墨壳里面去了。墨壳现在打了，打了两次。那说明他还是进行了长。 我不，那个呢？ 这个长不长是我们后面再来看。然后今天我们主要得出的结果就是 我设置了超时一毫秒，一毫秒拿不到结果，那么他就会尝试去取莫克的数据，那么相当于我一个远程调研一毫秒，肯定是拿不到数据的嘛。那 既然拿不到数据，那他就会走莫克的逻辑。那走莫克的逻辑，那不就是走到我们写的这段逻辑里面来了吗？是不是？好，那今天就给大家介绍。 就是说呃，一个消费方的默可数据，以及合法性检测。消费方默可数据。其实比较简单，主要你想办法针对这个接口写一个后缀，带默可的类。 但是呢，这个墨可后面是不是墨可呢？其实也可以不是墨可。嗯，然后因为我们刚刚看了，就是我们有一个检测。检测在哪里呢？就是在消防启动的时候。 呃， reference 康飞哥，他在启动的时候，他会拿那个接口。就是 就是拿我们这个接口进行切口启动引用，启动引用的时候就直接检测。检测的时候呢？ 这里我们墨客里面做了很多一些业务逻辑。当然这里的一些提示也告诉我们了。如果你是 read ten， 你舔那个 rat 就是你墨可的纸。 如果是等于 reto 的话，他会把我告诉你给你返回 reto。 no。 如果是 fel， 他会给你返回一个 dfort， 如果是 force， 他会给你个 dfort。 如果你是非要冒号 return or snow full， 它就会把冒号之后的东西给你丢回去。然后 first 冒号，什么 snow return full， 它就把冒号之后 后的东西给你丢回去。这也是这里面这一大坨逻辑。当你这一大坨逻辑， 你看你这一坨东西你都进不去的话，那那么好，那你进来是啥就是啥，那就是我莫可，我配啥，你就返回啥。 然后结果就是又会根据什么瑞特的前缀，然后 snow 的前缀做一些判断。然后总而言之呢，他是能得到一些想办法去返回数据的一个这个额外的处理。然后当你也是一个什么 类的全民的话，这里肯定也进不去，然后这里也进不去。那好，那就来到这。来到这的话，他又会有一个检测，就来看你是不是 dford 的，就是如果不是 dfat。 好，那没关系，我就拿着你的全类名直接 去反射，看能不能。嗯，能不能创建这个对象。如果能 ok， 那说明你这个莫可的泪在你当前这个应用工程里面。所以下一次进行莫可拿数据的时候，就直接就能继续使用了。好，那今天就讲到这。

在实际生产环境中，由于高并发和海量数据的访问，我们一般会把软件系统从单体应用升级成集群架构的模式，而在这个过程中就多多少少会接触到一些开源的 rbc 框架，而 double 作为一款优秀的开源框架， 很多程序原因小伙伴应该都比较熟悉了，他有很多优秀的特性来辅助我们程序员，保障系统的健壮和稳定。 今天的话主要来分享一下他的自动从事机制。呃，相信很多开发的小伙伴应该都遇到过因网络抖动等不可控的外部因素而导致的系统偶发性不合用现象。 在这类场景中，一般我们都会采取服务从事来尽可能保障我们服务系统服务的可用性。呃，在开发中我们一般是 是配置 w 的超时间跟从事的次数，具体的话如下图，琐事 w 对于服务超时从事的实现，新老版本还是做了很多的升级优化， 包括新版本采用时间轮批量调度的模式，取代了老版本中每个请求都只有一个超时调度器的模式， 这也是节省了 cpu 资源的开销。当然还有取很多其他方面的性能优化，由于视频的时间问题就不一一列出来了。