Spring-Cloud核心组件及底层原理( 三 ) _服务

192.168.170:9000
192.168.171:9000
192.168.172:9000
【Spring-Cloud核心组件及底层原理】192.168.173:9000
这下麻烦了!人家 Feign 怎么知道该请求哪台机器呢?这时Cloud就派上用场了。
就是专门解决这个问题的。它的作用是负载均衡，会帮你在每次请求时选择一台机器，均匀的把请求分发到各个机器上。
的负载均衡默认使用的最经典的 Round Robin 轮询算法。这是啥?
简单来说，就是如果订单服务对库存服务发起 10 次请求，那就先让你请求第 1 台机器、然后是第 2 台机器、第 3 台机器、第 4 台机器、第 5 台机器，接着再来—个循环，第 1 台机器、第 2 台机器。。。以此类推。
此外，是和 Feign 以及紧密协作，完成工作的，具体如下：
首先会从里获取到对应的服务注册表，也就知道了所有的服务都部署在了哪些机器上，在监听哪些端口号。
然后就可以使用默认的 Round Robin 算法，从中选择一台机器。
Feign 就会针对这台机器，构造并发起请求。
对上述整个过程，再来一张图，帮助大家更深刻的理解：
Cloud核心组件之四：
在微服务架构里，一个系统会有很多的服务。以本文的业务场景为例：订单服务在一个业务流程里需要调用三个服务。

文章插图
现在假设订单服务自己最多只有 100 个线程可以处理请求，然后呢，积分服务不幸的挂了，每次订单服务调用积分服务的时候，都会卡住几秒钟，然后抛出—个超时异常。
咱们一起来分析一下，这样会导致什么问题?如果系统处于高并发的场景下，大量请求涌过来的时候，订单服务的 100 个线程都会卡在请求积分服务这块，导致订单服务没有一个线程可以处理请求。
然后就会导致别人请求订单服务的时候，发现订单服务也挂了，不响应任何请求了。
上面这个，就是微服务架构中恐怖的服务雪崩问题，如下图所示：
如上图，这么多服务互相调用，要是不做任何保护的话，某一个服务挂了，就会引起连锁反应，导致别的服务也挂。
比如积分服务挂了，会导致订单服务的线程全部卡在请求积分服务这里，没有一个线程可以工作，瞬间导致订单服务也挂了，别人请求订单服务全部会卡住，无法响应。
但是我们思考一下，就算积分服务挂了，订单服务也可以不用挂啊!为什么?
我们结合业务来看：支付订单的时候，只要把库存扣减了，然后通知仓库发货就 OK 了。
如果积分服务挂了，大不了等它恢复之后，慢慢人肉手工恢复数据!为啥一定要因为一个积分服务挂了，就直接导致订单服务也挂了呢?不可以接受!
现在问题分析完了，如何解决?这时就轮到闪亮登场了。是隔离、熔断以及降级的一个框架。啥意思呢?
说白了，会搞很多个小小的线程池，比如订单服务请求库存服务是一个线程池，请求仓储服务是一个线程池，请求积分服务是一个线程池。每个线程池里的线程就仅仅用于请求那个服务。
打个比方：现在很不幸，积分服务挂了，会咋样?当然会导致订单服务里那个用来调用积分服务的线程都卡死不能工作了啊!
但由于订单服务调用库存服务、仓储服务的这两个线程池都是正常工作的，所以这两个服务不会受到任何影响。
这个时候如果别人请求订单服务，订单服务还是可以正常调用库存服务扣减库存，调用仓储服务通知发货。
只不过调用积分服务的时候，每次都会报错。但是如果积分服务都挂了，每次调用都要去卡住几秒钟干啥呢?有意义吗?当然没有!