SpringCloud核心组件

最新推荐文章于 2024-04-07 17:22:09 发布

置顶 Dhjie_king

最新推荐文章于 2024-04-07 17:22:09 发布

阅读量413

点赞数

分类专栏： SpringCloud 文章标签： SpringCloud核心组件 SpringCloud组件 SpringCloud五大核心组件

本文链接：https://blog.csdn.net/Dhjie_king/article/details/98846942

版权

SpringCloud 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

一首先看一张springCloud图片：

在这里插入图片描述
二简单介绍下什么是SpringCloud？

Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线）。分布式系统的协调导致了样板模式, 使用Spring Cloud开发人员可以快速地支持实现这些模式的服务和应用程序。他们将在任何分布式环境中运行良好，包括开发人员自己的笔记本电脑，裸机数据中心，以及Cloud Foundry等托管平台。" -----来自官网

三为了方便在这里假设一个业务场景

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

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

整个过程可以如下午所示:

在这里插入图片描述
四SpringCloud核心组将：Eureka

1、首先考虑订单服务要怎么去调用库存服务，仓储服务，积分服务？
   这就用到了SpringCloud中的Eureka组件，Eureka是服务架构的注册中心专门服务服务的注册和发现。

看如下图
在这里插入图片描述
如上图所示:库存服务,仓储服务,积分服务,都有一个Eureka Client组件组件,这个专门这个服务的信息注册到Eureka Server中,说白了就是告诉Eureka Server,自己在哪台机器上,监听那个端口,而Eureka 是一个注册中心,里面有一个注册表,保存了各个服务器的机器和端口,
订单服务里面有一个Eureka Client组件组件,Eureka Client组件会问一下:库存在那台服务器上,监听的端口号是哪个,仓储服务呢？积分服务呢？然后就可以把这些相关信息从Eureka Server的注册表中拉取到自己本地缓存起来。
这时候如果订单服务想要调用库存服务,不就可以找自己本地Eureka Client问题下库存服务在那台机器上,监听哪个端口吗？收到响应后，紧接着就可以发送一个请求过去，调用库存服务扣减库存的那个接口！同理，如果订单服务要调用仓储服务、积分服务，也是如法炮制。

所以总结下:

Eureka包含两个组件：Eureka Server和Eureka Client
Eureka Server提供服务注册服务
各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到

EurekaClient是一个Java客户端，用于简化Eureka Server的交互，客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除（默认90秒）

Eureka自我保护机制

什么是自我保护模式？

默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒）。但是当网络分区故障发生时，微服务与EurekaServer之间无法正常通信，以上行为可能变得非常危险了——因为微服务本身其实是健康的，此时本不应该注销这个微服务。Eureka通过“自我保护模式”来解决这个问题——当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这个节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）。当网络故障恢复后，该Eureka Server节点会自动退出自我保护模式。

在自我保护模式中，Eureka Server会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该Eureka Server节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。一句话讲解：好死不如赖活着

综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留），也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮、稳定。

在Spring Cloud中，可以使用eureka.server.enable-self-preservation = false 禁用自我保护模式。

Eureka服务SpringCloud依赖

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
        </dependency>

客户端服务SpringCloud依赖

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>

把客户端服务注册到Eureka中所需要的依赖

在Eureka服务中需要配置的

在启动类中add @EnableEurekaServer 开启EurekaServer
在这里插入图片描述

yml文件中的配置
在这里插入图片描述
在客户端需要的配置

yml文件中需要配置的Eureka信息
在这里插入图片描述

五SpringCloud核心组件：Fegin

现在订单服务确实知道库存服务,积分服务,仓储服务在哪里了,同事有监听着这些端口号,
但是新问题又来了,难道订单服务要写一大堆代码,跟其他服务建立网络连接,然后构造一个复杂的
请求,接着发送请求过去,结果写一大堆代码来相应处理

如果每次手写代码,代码量会比较多,所以SpringCloud提供了一个优雅的解决方案,看看Feign的话订单服务调用库存的代码会变成啥样?

service-shares-order 是订单服务的名称如下图
在这里插入图片描述

在这里插入图片描述
需要在聚合服务启动类 add @EnableFeignClients （{扫描的Fegin Url}）

需要在聚合服务中引用

        <dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-openfeign</artifactId>
		</dependency>

这样就是可以利用Feign调用底层的服务接口了

问题来了,Feign是如何做到的呢?其实Feign的一个机制就是使用了动态代理,

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

在这里插入图片描述

六SpringCloud核心组件：Ribbon

如果库存服务上面部署了多台服务器‘

那Feign怎么知道请求那台服务器呢,这时Ribbon 就派上用场了,Ribbon 就是解决这个问题的,他的作用是负载均衡,会帮你在每一次请求的时候选择一台机器,均匀的把请求发送到各个机器上 ,Ribbon的负载均衡默认的使用RoundRobin轮询算法,什么是轮询算法?如果订单服务对库存发起十次请求,那就先让你请求第一台机器,然后是第二台机器,第三台机器,…接着循环到第十台机器

此外，Ribbon是和Feign以及Eureka紧密协作，完成工作的，具体如下：

首先Ribbon会从 Eureka Client里面获取到对应的服务注册表,也就知道了所有的服务都部署在了那台机器上,在监听哪些端口,
然后Ribbon就可以使用默认的Round Robin算法,从中选择一台机器,

Feigin就会针对这些机器构造并发送请求.可以参考如下这图:

在这里插入图片描述
七SpringCloud的核心组件：Hystrix

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

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

但是我们思考一下，就算积分服务挂了，订单服务也可以不用挂啊！为什么？

我们结合业务来看：支付订单的时候，只要把库存扣减了，然后通知仓库发货就OK了
如果积分服务挂了，大不了等他恢复之后，慢慢人肉手工恢复数据！为啥一定要因为一个积分服务挂了，就直接导致订单服务也挂了呢？不可以接受！

现在问题分析完了，如何解决？

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

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

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

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

在这里插入图片描述

对于熔断技术的实现需要考虑以下几种情况：

· 出现错误之后可以 fallback 错误的处理信息；
· 如果要结合 Feign 一起使用的时候还需要在 Feign（客户端）进行熔断的配置。

使用熔断器实列和Fign结合使用
OpenFeign是自带断路器的，不用在pom.xml和入口类添加新增引用，但hytrix默认是关闭的，需要设置 feign.hystrix.enabled=true。

feign:
  hystrix:
    enabled: true

@RestController
public class DeptRest {
    @Resource
    private IDeptService deptService;
    @RequestMapping(value = "/dept/get/{id}", method = RequestMethod.GET)
    @HystrixCommand(fallbackMethod="getFallback")    // 如果当前调用的get()方法出现了错误，则执行fallback
    public Object get(@PathVariable("id") long id) {
        Dept vo = this.deptService.get(id) ;    // 接收数据库的查询结果
        if (vo == null) {    // 数据不存在，假设让它抛出个错误
            throw new RuntimeException("部门信息不存在！") ;
        }
        return vo ;
    }
    public Object getFallback(@PathVariable("id") long id) {    // 此时方法的参数 与get()一致
        Dept vo = new Dept() ;
        vo.setDeptno(999999L);
        vo.setDname("【ERROR】Microcloud-Dept-Hystrix");    // 错误的提示
        vo.setLoc("DEPT-Provider");
        return vo ;
    }  
}

一旦 get()方法上抛出了错误的信息，那么就认为该服务有问题，会默认使用“@HystrixCommand”注解之中配置好的 fallbackMethod 调用类中的指定方法，返回相应数据。

七:SpringCloud核心组件:zull

Zuul:微服务网关,这个组件是负责网络路由的!

什么事网络路由?

假设你后台部署了几百个服务，现在有个前端兄弟，人家请求是直接从浏览器那儿发过来的。打个比方：人家要请求一下库存服务，你难道还让人家记着这服务的名字叫做inventory-service？部署在5台机器上？就算人家肯记住这一个，你后台可有几百个服务的名称和地址呢？难不成人家请求一个，就得记住一个？你要这样玩儿，那就是中美合拍,文体开花了!

上面这种情况，压根儿是不现实的。所以一般微服务架构中都必然会设计一个网关在里面，像android、ios、pc前端、微信小程序、H5等等，不用去关心后端有几百个服务，就知道有一个网关，所有请求都往网关走，网关会根据请求中的一些特征，将请求转发给后端的各个服务。

而且有一个网关之后，还有很多好处，比如可以做统一的降级、限流、认证授权、安全，等等。

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

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

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

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

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

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

Spring Cloud的5个核心组件通过一张图串联起来

在这里插入图片描述

好了，本次记录就到这儿了，突然不知不觉发现写了好多，感谢耐心听我叨逼完。我想这篇博客如果你认真的看完，肯定会有收获的！最后，因为内容较多，知识点较多，如果文中有任何错误或欠妥的地方，还望指正。欢迎留言交流！

Dhjie_king

关注

0
点赞
踩
14

收藏

觉得还不错? 一键收藏
0
评论
SpringCloud核心组件

一首先看一张springCloud图片：二简单介绍下什么是SpringCloud？Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线）。分布式系统的协调导致了样板模式, 使用Spring Cloud开发人员可以快速地支持实现这些模式的服务和应用程序。他们将在任何分布式环境中运行良好，包括开发人员自己的笔记...
复制链接

扫一扫