52_订单微服务调用支付服务出现卡顿

好，同学们，我们继续，那么上面呢，我们给大家演示我姐密一点这个压测。2万个线程打进去，每个线程相当于说在我们这个time奥，这是不是都要等上三秒钟才能拿到结果，那么这样2万个过来，马上就把我们他们K特池子里面的线程抽干用进去了，那么他要去响应这个最难的这个请求，那么就会导致我们访问本微服务的其他接口地址，即便是OK的，我们刚才也看过是不是在这儿会转圈圈啊，那么我们是不是就系统就卡顿变慢了，那么这是2万个线程。这是一个线程组，你再整它几个线程组，每组2万个，每一组里面又2万个，里面再包含2万个，那么同学们你想想，你可以不停的添个零，可能系统就死了，明白了吗？那么我们为了避免这种可怕的情况，我们当然要进行一定的降级处理好，所以说通过上面解密的我们的压测结论就是。

8001自测都通不过，那么我们呢？掀起战火来看热闹不嫌事大，八零新建加入，那么现在。我们是自测微服务的提供者，8001就会发现你这个根本干不住2万的并发量，对吧？必须要配着服务降级，那么不好意思啊，屋漏偏逢连雨天，那假设现在八零我们客户端来调用你了，你这个系统本身就是有点不健康，而且别人也来反问你，假设八零也是一些大规模的高并发访问，那么你想想会不会把你自己干死？所以说兄弟们，我们呢，再把这个情况继续恶化，然后我们用S来进行。降级限流的拯救好，那么下面老规矩。新建一个八零消费者啊，Fan hiss，注意不是杨哥吃饱了撑着没事干，把这个名字起那么长，这个意思就是说我们的八零现在调我们的8001用的是FA，然后自身我也加了history strict，那说明什么？He stricts当然一般哈，History stricts呢，是用在客户特做降级，但是现在杨哥整个案例。

坐下来想给大家整明白，就是hes。消费侧、服务侧都可以添加，OK，当然一般我们把它用在八零消费端，好，那么下面不多说了，老规矩。新建工程，那么我们又来了一个兄弟，来这个工程呢，也就越来越多啊，同学们一定要注意这个环境的。正确。和干净的整理好。那么现在是我们的。S80键mod改泡沫，那么泡沫那么也就是我们的。这一块。兄弟们。

跟以前一样，不多说，然后我们的八零要么八零端口。注册到哪注册进我们的有瑞卡，好，假设有必要和需要的话，那么带着这个的时候，我们老规矩还是跟以前的一样。Application要么一张欧了，那么我们呢，主启动类这个呢，直接。写过了。那么come.at硅谷点spring cloud。OK吧，那么这些同学们写过很多遍了，由于我们是要用在，那么本次我们是不是要把这个在主启动类上面先激活我们的。这个特性OK吧，那么接下来我们呢，是不是就要写写我们的什么业务类，那么自然而然是我们的service和我们的controller，那么最重要的我们先写我们的service。

报名。这波OK吧，那么注意我们这个service现在不是个类，它是一个接口份接口，还记得我们前面说过的吗？基本上是不是就是微服的接口加分client接口加注解的模式，我们复习一下，那么首先那么同学们，那么这个是吧，那么来分client，那么。名字不废话，我们现在是不是八零要去调我们的8001，那么有瑞卡上面这个名字啊，不要写，一般这种东西为了避免出错，一律给我粘贴拷贝，那么好，你这个微负接口找这个名字啊去调用，那么人家能提供哪一些呢？第一个是不是OK，这个第二个是不是超时，这个没问题吧，那么基本上。直接拷贝过来，这是第一个，基本上再直接拷贝过来，这是我们的第二个，你们检查一下。

相当于是调这个微服务，就是我们88001上面这个pay这SOK的一个兄弟们没问题吧，然后再调我们一个是什么timeout超时的一个兄弟们没问题吧，好，那么在这块定义了我们的一个方法头OK，我们的payment service写完，那么这个service写完以后，那么下面是不是要写我们的CTRL了。那么来兄弟们这个时候的话呢，我们订单调我们的payment的这样的一个微服务，那么。Controltr了，OK，那么下面我们来来看一眼，那接下来是不是要实现我们的rest？又是这些CTR了，兄弟们。没问题吧，嗯，我们的八零订单主启动类调，我们的支付接口跟我们的那边8001保持一致，但是这儿的话呢，呃，干脆这样吧，在这块呢，虽然说订单我呢，从业务逻辑上啊，我还是给他写的更精确一些，我这儿给他做一下改名吧，这一块还是我们的订单，因为是订单调我们的service嘛，我这儿改一个我们的什么。

砍出了内这一波，请同学们注意一下。严谨一点啊，因为虽然说订单干脆都是因为订单，它没有业务，支付微服务，所以说它都是去调，但是我们control错了，还是以订单开头，底层的接口我们调的是payment，好，那么接下来。在这块private，那么是不是我们的payment？刚才我们自己写的这个没问题吧，说穿了我们订单没有什么业务逻辑，只有一个CTRL了，第二是调的是我们的费微服务支付接口，那么过了resource这一波继续好，那接下来这些呢，我们呢就不再多浪费时间了。

我们调用的就是我们这，哎，调用的就是我们的这个。接口我就直接拷贝好，那接下来。我们的服务方法也就是这个，那么找到我们的订单，找到我们的订单以后，跑到这儿，我们给它搁到这儿了以后，那么大家请看啊，这稍微做一下变更，那么payment，按照我们的习惯，这个consumer。代表来自于消费侧，那么payment hes OK，这个没有任何问题，其他的简单了，那么string。那么。这个为负接口，点调的是OK。传进去，那return result这一波同学们没有任何问题吧，那么再来这一波，我们带走跑到这。

给它搁到这儿，然后同学们也一样的，这个是加一个consume直接搞定，因为这些呢，就不再手敲了啊，直接粘就行，重要是演示我们的效果，那跟前面的也是一样，尽量的让代码简单，保证大家看的时候能够轻松，那么这个时候使用time out ID这波兄弟们没问题吧啊出现的。情况，那么就是order去调用的payment用的是fan，那么接下来我们就要启动我们的fans order80，来看看我们的正常调用能不能够成功，好，那么这块找到我们的八零的主启动类，哎。嗯。算盘就在这儿，好，那么同学们我给他启动一下，好，我先暂停一下录屏，同学们我们继续服务，启动成功以后，那么现在我们就是三个服务了啊。

80180，好，首先我们先自测8001，那么OK的啊，同学们请看是最快的，现在是8001呢，听懂先自测。马上就出来了，闪一下就出来了，很快秒杀，听懂，那么这个是正常的要，但是要耗费时间长一点，他们out的要耗费三秒钟，请看大家露眼转圈，自然而然要等三秒钟嘛，这个也没有任何问题，说明我们8001OK吧，那么现在。我们呢，来看看我们的historys order，八零这个东东来访问O不OK，那么一方面测我们的。是否正确，大家请看我现在端口号，只要带着consumer，没写端口号就说明来自于。八零消费者客户端，那大家请看我访问OK的时候，大家请看是不是也很快刷刷刷刷的出来，闪一下是不是就出来了，都挺爽吧，哦了，好到这很自然，像大自然一样自然，没有异常好的，接下来同学们。

高并发压测一下，我们来试试，现在我2万个线程去压8001，那么相当于说微服务的提供者8001，这是不是每次要等三秒钟，现在2万个去干你，那么现在别人又来找你的时候，现在我的八零是不用等的，听到有没有发现这很快，但是如果我又干了这个事儿的话。我们会出现一些什么样的情况呢？找到我们这个请求看下，那么这个时候同学们请看啊，我这一转有没有发现我们的。八零已经开始等待了，那么这样的话是2万个线程，那么我多跑一点，多跑一点，多跑一点，那么再来。8001自己也去干，8001自己在添加看热闹不嫌事大，那么再大家再看是不是我出现了转圈圈了，那么再来转圈圈了，我们所以说什么八零的微服务直接去访问干嘛，极度的变慢，服务的整体性能急剧下降，要么转圈圈等待，要么消费端如果你狂点，偶尔还会点出来这样的是吗？I配超时了，因为八零它实在是调不动了，怎么每次去访问都说，比方说请稍后重试啊，每次重试啊都要让我等好长好长时间，偶尔有一次调通，但是大规模的情况下都会让我等待，那么这个时候将会导致我们的消费端干嘛出问题，听懂，那么这个必须要有限流控制，那么故障现象和导致原因一句话。

8001，同一层次的其他接口服务被困死了，什么意思啊？我们的8001现在是不是2万个线程在。紧着在这儿干，那么其他的就算是很轻松的资源也已经没有了，没有办法给你快速的响应提供服务，因为他们看的线程池里面的工作线程已经被集账完毕。

如果八零此时再去调用8001客户端，访问响应很慢，是不是转圈圈啊，那么这种等待是很恐怖的，你去大厂的时候去做优化程序，我告诉你，可能人家提的需求就是你给我把这个接口优化一下，给我走进一秒钟以内，好了，这周你就完成这个去干吧，干的好在阿里3.5以上，干不好就是3.25。听到，所以说我们在这儿就要解决上述的问题，那么正是因为有了上述的故障或者是不佳的表现，才有我们的降级、容错、限流等技术诞生，那么我们该如何解决呢？下一讲给大家继续介绍。