45_OpenFeign超时控制

好，同学们，我们继续这一节，我们给大家介绍open的超时控制，那通过上一讲我们的演示和小总结。就这张图，那大家都清楚，所谓的份，当然我这说的份也就是我们后续新的这个open份了啊，我们就解读了，那么我们的主要就是服务接口，客户端服务接口，根据分client所显示的微服务名称去调用我们。服务册所能够暴露对外提供的服务方法，那么之前哈，在没有学到fan之前，我们大家都清楚，我们用的是ribbon加我们的rest template这么一个模式。都OK的，但是现在为什么出个饭呢？那么public class。我们Java程序嘛，都喜欢写叉叉叉controltr了。没问题吧，那么这个CTRL呢，如果说一般我们现在大家都清楚是不是都是面向接口。

边长。好，那么面向接口的以后。这个时候啊，不是不可以，但是就是CTRL去调另外一个rest template，它是不是已经提供了一个第三方类啊，那么一般而言面向接口加微服调用，所以说我们现在呢，还是习惯于比如说我们这有个订单order CTR了，我们还是去调其他叉叉叉service服务接口，那么应运而生的分就满足于大家程序员这样的一种思维方式和习惯调用方法，那么所以说我们上一讲就给大家充分的演示了我们的接口加注解的调用，好，那么接下来这个问题是。消费侧去掉服务侧，这是两个不同的微服务，那一定会存在一种现象叫超时，比如说我现在对于服务的提供者支付微服务，我这个业务逻辑处理完成，我需要三秒钟在我微服务提供方案，我认为这是自然。

正常和健康的，但是对于消费者而言，可能我等不了三秒钟，我只能愿意等两秒钟，那么这样的话呢，提供者认为处理完这个业务三秒钟是正常。但是消费者只愿意等两秒钟，那么这样是不是会产生一种时间差，就会导致我们的超时调用报错好。那么这样的报错程序上没什么问题，关键就是这个时间，双方在消费者和提供者之间，你们就要约定好什么样的业务下面允许，比如说这个业务确实是个长流程业务默认。两秒钟或者一秒钟调补完，这个都是正常的，我们两个约定好。这个业务一定要要用四秒钟好，那么这个时候你过来，你就不要按照默认的假设是一秒钟，你就报这个超时报错OK好，那么接下来我们先演示。

首先超时设置，故意设置超时演示出错的情况啊，那么同学们，我们现在请看服务提供方8001故意写。暂停的程序，那过来吧，我们这个呢，是我们的服务提供图案8001，比如说啊，我们帕。那么在这呢，我们就写个payment。在。Time out这么一个方法。他呢，干的活呢，很简单。直接在这，我们这就停三秒钟，没有任何的这个业务逻辑，同学们没问题吧，那么返回的东西呢，也就是我们前面定义定义过的report，返回一个端口，它没有什么业务，业务上的啊，那么这块啊，是我故意写的，那么大家请看，说穿了就是程序进来了以后，停三秒钟以后返回这个程序100%没有什么业务逻辑的错误，我故意要让他。

运行超过三秒钟，OK，模拟就是我们这个业务可能是个长流程，调用可能是个复杂业务，处理上就需要用三秒钟，好，那么接下来我们呢。Map那么老规矩，我们的value。那么在这儿我们就。Payment，然后呢，我们分吧，这是分time out超时的一个测试，那么这个是我们的8001微服务提供者，提供者的意思就是说有这么一个payment time out。这么一个测试方法，这么一个耗时的方法，那么现在欧了我清楚了，那么清楚以后现在对于我们的八零，我们是不是也要可以根据这个微服务名称找到我们的c client微服务下面对外暴露出的rest风格地址啊，那么好了，这些东东同学们。不写了，写过一遍以后直接后面粘贴。

那么来同学们请看这个时候说白了就是我们的fan接口，在这个微辅名称下面去找我们暴露的rest风格的调用地址，OK，那么这一波也应该相信没有什么太大的问题，那么第三轮第三步同学们，我们找到了我们的订单册。那这个时候呢，和我们刚才呢一回事，你这块是不是一个方法投啊，那么我也拿过来，那么这些啊，没有什么技术含量，只是说给同学们一步一步的演示清楚，那么老规矩。我们这儿是不是consumer这一波没问题吧，相当于说只要是我们的客户消费侧我都加这么一个啊，那么现在。这个open。Open fun，我们都明白它底层是不是。OK吧，那么他呢？客户端也就是我们的消费者啊。一八。

默认。等待。一秒钟清楚啊，就是我们一个份的调用，一般就是一秒钟就要拿到结果，但是抱歉我故意要让支付测做三秒钟的长业务，那接下来同学们都清楚这块是不是我人为的故意要给你报错呀，那么对于我们的service第2TIMEMENT timeout OK，那么接下来我们呢，写完我们的全部演示好，那么此时的话呢，我们再来看看啊，我们巴黎巴零呢，注册到7001 7002有瑞卡集群，那么再启动我们的8001，再启动我们的带着find的这个拨打八零总计四个微服务给大家演示好，那们演示又要演示重启，非常耗时，暂停一下录屏启动完成，我们继续，同学们请看，此时我打开7001上面我们的支付微服务8001已经成功注册，那接下来啊，我们来演示啊，首先先来看看自己。

那么来，同学们，我们先来看看我们的8001啊，我们先不找我们的八零，那么8001你是不是应该有个东西叫自测通过？好，此时我反问，8001，大家请看这是不是在转圈圈，说穿了，这什么意思啊？这个时候8001能够正常访问，没有任何程序的问题，只不过这耗时就要超过三秒钟，OK，只是说时间长一点，没有任何问题。那接下来，那么同学们。我们把这个网址换成我们的consumer，那么同学们，此时就是我们的consumer过来了，大家请看一运行。什么东东？是不是one timeout们？换句话说，这个报错页面就是一个读取，Timeout是个超时的意思，为什么？因为再次强调你。8001这块故意写的暂停程序，三秒钟，你那块无所谓，但是open phone它默认只是等待一秒钟，超过一秒以后得不到。

微服务的提供者提供的结果，我客服端我就给你直接报错，所以说请同学们要注意，这块就要商量好。默认是一秒钟，假设我们现在这个业务确确实实需要超过三秒钟，那么这个时候我们客户端open phone消费侧这一端愿意更多时间的等待，那么所以说我们就需要把我们的open phone碰上这样的情况，给他的等待时间提高一些，那接下来可以看一下phone客服端只等待一秒钟，但是服务端处理超过了一秒钟，刚才我们看到我们是不是故意让他处理超过了三秒钟，导致分客户端它超过了他的默认一秒钟，他就不想等了，直接反馈报错，Read time out，为了避免这种情况，我有时候呢，我们需要设置phone客服端的超时时间。默认用一秒，当然越快返回越好，但某些服务，某些接口的调用，我们希望呢，可能需要超过一秒钟，那么这块我们就需要在样本文件中开启我们的配置啊，那这请大家都知道。

前面也给大家提过一嘴，这儿看一下架包结构，对于我们这个蓝色的这工程带着FIND80接口的订单消费者，我们引入了open phone，人家自己天生就带着rib本听懂，所以说上一讲我们也说过，那么fan呢，由于天生带着rib本整合了自己支持负载均衡，那么它的超时控制也由最底子的rib本来进行限制啊，那我们的样M文件里面就可以把这段。粘贴过去，那么这个时候找到我们的分ORDER80为章，同学们请看设置分客户端的超时时间，要建立的所连接的时间啊，这边一个是。5000就代表是五秒钟的意思啊，那么建立连接，一个是建立连接时间，然后是建连接时候读取资源所用的时间，那么你的消费侧啊这块我们刚才看到了三秒钟，但是这次的时候我可以等你五秒钟，那么好粘了application样以后，我们要等我们的ORDER80重启一下，那么这个时候。

等他一会儿到这会儿差不多了，那么我们再来试试我们现在我们的分time out，这个还能会不会读报错，还是能够正确的读到，好同学们大家请看转圈了吧。大家请看，不像刚才那样的一秒钟拿不到结果，直接给你报错，那么现在我们再点一次啊，大家呢，也可以看到完完整整的装完圈以后，老老实实的通过8001拿到了我们的结果，所以说这个就是我们对open费超时控制那部分业默认是一秒钟，部分业务时间长了，那么同学们可以通过这个方法来进行一下设置。