53_降级容错解决的维度要求

好，同学们，我们继续。那么根据上面的结论，我们呢？有故障表现不佳，出现了转圈，服务器响应缓慢，甚至会导致超时调用和宕机，所以我们才需要有降级、容错、限流等技术诞生，好植入主题。怎么解决，你解决的要求有哪一些？那么现在我们呢，引入了刚才的看热闹不嫌事大，八零是也过来，那么坦白讲。80012自己线程打满了，自己都已经是力不从心了，八零还要去找8001要求你提供服务，那么这样的话，这个自己离菩萨过江，自身难保，这个不怕死，还往前冲，那么是不是导致服务器死的更快，并且客户端是不是长久等待，所以说8001你要解决，巴黎你要解决，那么这两个提供方和消费者应该各自怎么处理呢？

来。第一个问题，我们的解决维度。超时导致服务器变慢，刚才看到转圈，那么按照我们业务逻辑规定，某些服务，比方说三秒钟以内能接受超过三秒超时，但是超时说实话，那么同学们是不是不大合适超时的时候把这种报错的？IO配置错误，页面打到前台给客户端给客户看到啊，那这个时候是不是客户这个表情包就是这样的了，那。我们超时的话应该怎么办？别再等待了不起，我现在在美团上下个单，突然告诉我，抱歉，对方系统繁忙，请稍后再试。这个是不是总比。I page错误页面反馈给客户端要好啊，而且客服也知道说啊，现在比较繁忙，那我就不再点了，这样是不是可以给我们的8001服务的提供方有更好的保护，访问的人少了嘛，此路不通，大家别来。

第二种情况出错，那什么意思呢？比方说我们现在这个8001突然宕机了，我去访问一个死的服务器，或者运行着以后程序出错了，那么要求出错要有兜底，那么我们是不是说过if else if else if else if最后是要有个兜底的L所以说我们的解决主要是从这两个维度那么落地实现。第一个。对方8001服务提供者超时了，我现在要求去处去处理，平时三秒钟就OK，这次8001干了八秒钟都没有返回，那么超过八秒了。不等，超过三秒了不等，因为三秒钟就已经是超时，八秒钟更不应该等，所以说调用者三秒钟以后拿不到，我不能一直卡死等待吧，那么这个界面你现在的支付正在付款中，请稍等三秒钟以内，客户端那么肯定。

还是可以接受吧，勉强其实三秒都很慢了啊，我随口说的，但是呢，八零不能一直卡死等待，必须要有服务降级，第二个对方服务器宕机了，八零不能一直卡死等待，必须要有服务降级，就是对方超时了，宕机了都不OK，第三一个对方服务是OK的，什么意思呢？就是假设对方五秒钟。确实完成了，他只是慢一点。但是抱歉，我们调用者八零自己出故障，或者我有自我要求，比方说我八零这侧我只能等三秒，你五秒钟处理完，我三秒钟等到十，就是八零消费者自己的等待时间小于服务的业务逻辑提供者处理的真实时间，那么八零自己就处理一下降级，我不愿意等了，所以说我们如何解决及解决的降级维度要求就是上述，那么这是我们的大纲，后续工作中，那么希望同学们照着这个是超时了，是出程序运行出错了，还是宕机了，那么这块要对双方都要做好保护。

八零，不要一直等待，超时了咱就先撤。回头再来说，那么8001也不要什么特别猛，让所有人都打满，我把8001给耗死了，所以说这个我们围绕着将会在下面的东东给大家进行介绍，好，理论知识先给大家讲到这儿。