springcloud五大核心部件

springcloud五大核心部件

一、springcloud介绍

springcloud是微服务的集大成者，将一系列的组件进行了整合。基于springboot构建

，可以快速配置常用模块并构建庞大的分布式系统。

二、具体业务分析

我们举一个例子来进行业务场景分析

假设现在开发一个电商网站,要实现支付订单功能:流程如下：

1.创建一个订单后,如果用户立刻支付了这个订单,我们需要将这个订单状态更新为(已经支付)
2.扣减相对应的商品库存
3.通知仓储中心,进行发货
4.给用户这次购物怎加相对应的积分

整个流程的大体思路如下：
1.用户针对一个订单完成支付后,就回去找订单服务,跟新订单状态
2.订单服务调用库存服务,完成相应的功能
3.订单服务调用仓储服务,完成相应的功能
4.订单服务调用积分服务,完成相应的功能

1、springCloud核心组件：Eureka（nacos也是类似的）

首先考虑第一个问题,订单服务要调用库存服务,仓储服务,或积分服务,怎么调用?

订单服务根本不知道库存服务在哪台机器上,就算想起来,都不知道发送给谁?所以springCloud就有一个springCloud的Eureka,Eureka是服务架构的注册中心 , 专门负责服务的注册和发现;

看下面这图：

如上图所示：库存服务，仓储服务，积分服务，都有一个Eureka Client组件注册中心，这个组件专门将服务的信息注册到Eureka Server中，说白了就是告诉Eureka Server，自己在哪台机器上，监听哪个接口，而Eureka是一个注册中心，里面有一个注册表，保存了各个服务器的机器和端口，

订单服务里面有一个Eureka Client组件组件,Eureka Client组件会问一下:库存在那台服务器上,监听的端口号是哪个,仓储服务呢？积分服务呢？然后就可以把这些相关信息从Eureka Server的注册表中拉取到自己本地缓存起来。

这时候如果订单服务想要调用库存服务,不就可以找自己本地Eureka Client问题下库存服务在那台机器上,监听哪个端口吗？收到响应后，紧接着就可以发送一个请求过去，调用库存服务扣减库存的那个接口！同理，如果订单服务要调用仓储服务、积分服务，也是如法炮制。

所以总结下来就是：

Eureka Server:注册中心，里面有一个注册表，保存各个服务器的机器和端口号。

Eureka Client：负责将这个服务的信息注册到Eureka Server中。

2、springCloud核心组件：Feign（服务调用）

Feign服务调用的一个机制就是实现了动态代理。

首先，如果对某个接口定义了@FeignClient注解，Feign就会针对这个接口创建一个动态代理，如果你要是调用那个接口，FeignClient在底层根据你的注解，根据你在接口上的@RequestMapping等注解，来动态构建出你要请求的服务的地址，然后根据这个地址，发起请求，解析响应。

3、springCloud核心部件：Ribbon

如果库存服务上面部署了多台服务器，92.168.169:9000
192.168.170:9000
192.168.171:9000
192.168.172:9000
192.168.173:9000

那么Feign怎么知道去请求那一台服务器呢，这时候SpringCloud的Ribbon服务就派上用场了，他的作用是负载均衡，会帮你在每一次请求时候选择哪一台机器，均匀的把请求发送到各个服务器上，Ribbon的负载均衡默认使用的是轮询算法，

然后Ribbon就可以使用默认的Round Robin算法,从中选择一台机器

（1）轮询算法：

如果订单服务对库存发起十次请求,那就先让你请求第一台机器,然后是第二台机器,第三台机器,…接着循环到第十台机器

springcloud-nacos-provider: # nacos中的服务id
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule #设置负载均衡

其他负载均衡机制：

（2）随机；

随机策略：RandomRule，从服务提供者的列表中随机选择一个服务实例。此策略的配置设置如下：

springcloud-nacos-provider: # nacos中的服务id
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule #设置负载均衡

（3）权重（常用）；

WeightedResponseTimeRule，根据每个服务提供者的响应时间分配一个权重，响应时间越长，权重越小，被选中的可能性也就越低。它的实现原理是，刚开始使用轮询策略并开启一个计时器，每一段时间收集一次所有服务提供者的平均响应时间，然后再给每个服务提供者附上一个权重，权重越高被选中的概率也越大。此策略的配置设置如下：

springcloud-nacos-provider: # nacos中的服务id
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.WeightedResponseTimeRule

（4）最小连接数策略；

最小连接数策略：BestAvailableRule，也叫最小并发数策略，它是遍历服务提供者列表，选取连接数最小的⼀个服务实例。如果有相同的最小连接数，那么会调用轮询策略进行选取。此策略的配置设置如下：

springcloud-nacos-provider: # nacos中的服务id
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.BestAvailableRule #设置负载均衡

（5）重试策略；

重试策略：RetryRule，按照轮询策略来获取服务，如果获取的服务实例为 null 或已经失效，则在指定的时间之内不断地进行重试来获取服务，如果超过指定时间依然没获取到服务实例则返回 null。此策略的配置设置如下：

ribbon:
  ConnectTimeout: 2000 # 请求连接的超时时间
  ReadTimeout: 5000 # 请求处理的超时时间
springcloud-nacos-provider: # nacos 中的服务 id
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule #设置负载均衡

（6）可用性敏感策略

可用敏感性策略：AvailabilityFilteringRule，先过滤掉非健康的服务实例，然后再选择连接数较小的服务实例。此策略的配置设置如下：

springcloud-nacos-provider: # nacos中的服务id
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.AvailabilityFilteringRule

（7）区域敏感策略

区域敏感策略：ZoneAvoidanceRule，根据服务所在区域（zone）的性能和服务的可用性来选择服务实例，在没有区域的环境下，该策略和轮询策略类似。此策略的配置设置如下：

springcloud-nacos-provider: # nacos中的服务id
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.ZoneAvoidanceRule

4、SpringClound的核心部件：Hystrix

在微服务架构里,一个系统会有多个服务, 以本文的业务场景为例：订单服务在一个业务流程里需要调用三个服务,现在假设订单服务自己最多只有100个线程可以处理请求然后呢，积分服务不幸的挂了，每次订单服务调用积分服务的时候，都会卡住几秒钟，然后抛出—个超时异常。

分析下这样会导致什么问题:如果系统在高并发的情况下,大量请求涌过来的时候,订单服务的100个线程会卡在积分服务这块,导致订单服务没有一个线程可以处理请求,然后会导致别的请求订单服务的时候,发现订单服务挂掉,不响应任何请求了,这种问题就是微服务架构中恐怖的服务器雪崩问题:如下图,这么多的服务互相调用要是不做任何保护的话,某一个服务挂掉会引起连锁反应,导致别的服务挂掉,比如积分服务挂了会导致订单服务的线程全部卡在请求积分服务这里没有一个线程可以工作，瞬间导致订单服务也挂了别人请求订单服务全部会卡住，无法响应。

这时就轮到Hystrix闪亮登场了。Hystrix是隔离、熔断以及降级的一个框架。啥意思说白了就是Hystrix会搞很多小线程池,每个小线程池里的线程仅用去请求的服务,

打个比方：现在很不幸，积分服务挂了，会咋样？

当然会导致订单服务里那个用来调用积分服务的线程都卡死不能工作了啊！但由于订单服务调用库存服务、仓储服务的这两个线程池都是正常工作的，所以这两个服务不会受到任何影响。这个时候如果别人请求订单服务,订单服务还是可以正常调用订单服务还是可以正常调用库存服务扣减库存调用仓储服务通知发货。只不过调用积分服务的时候，每次都会报错。但是如果积分服务都挂了，每次调用都要去卡住几秒钟干啥呢？有意义吗？当然没有！所以我们直接对积分服务熔断不就得了，比如在5分钟内请求积分服务直接就返回了，不要去走网络请求卡住几秒钟，这个过程，就是所谓的熔断！

那人家又说，兄弟，积分服务挂了你就熔断，好歹你干点儿什么啊！别啥都不干就直接返回啊？没问题，咱们就来个降级：每次调用积分服务，你就在数据库里记录一条消息，说给某某用户增加了多少积分，因为积分服务挂了，导致没增加成功！这样等积分服务恢复了，你可以根据这些记录手工加一下积分。这个过程，就是所谓的降级。为帮助大家更直观的理解，接下来用一张图，梳理一下Hystrix隔离、熔断和降级的全流程：

面试题：
1、什么是服务雪崩？
服务雪崩就是服务A调用服务B，服务B调用服务C，服务C挂掉了，导致服务B、C超时受影响，导致服务A也超时，对服务造成级联的影响。即下游服务挂掉或者超时，导致上游调用服务大面积受到影响，阻塞、超时，进而导致雪崩效应。

5、SpringCloud核心组件：Zuul

Zuul:微服务网关，对微服务的访问进行控制，它可以进行路由、过滤、鉴权、代理请求，

面试题：

1、Zuul和gateway的区别？

• Zuul1.0是阻塞式的api，不支持长连接，而gateway支持异步。

• Zuul没有提供限流、负载均衡等支持，而gateway支持。

• 它们都是web网关，处理http请求，底层都是servlet。

总结一下SpringCloud结果核心组件:

Eureka:个服务启动时,Eureka会将服务注册到EurekaService,并且EurakeClient还可以返回过来从EurekaService拉去注册表,从而知道服务在哪里

Ribbon:服务间发起请求的时候,基于Ribbon服务做到负载均衡,从一个服务的对台机器中选择一台

Feign:基于fegin的动态代理机制,根据注解和选择机器,拼接Url地址,发起请求

Hystrix:发起的请求是通过Hystrix的线程池来走,不同的服走不同的线程池,实现了不同的服务调度隔离,避免服务雪崩的问题

Zuul:如果前端后端移动端调用后台系统,统一走zull网关进入,有zull网关转发请求给对应的服务