springCloud五大核心组件介绍

约定不等于承诺〃 2023-07-17 02:50 21阅读 0赞

一:首先看一张springCloud的图片:

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

三:为了方便理解假设一个业务场景(场景来源于石杉的架构笔记（id:shishan100）)

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

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

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvcmV5WHV1_size_16_color_FFFFFF_t_70 1][]

四:SpringCloud核心组件:Eureka

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

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

看下这个图:

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvcmV5WHV1_size_16_color_FFFFFF_t_70 2][]

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

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

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

所以总结下:

Eureka service:注册中心,里面有一个注册表,保存了各个服务所在的机器和端口号

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

五springCloud核心组件;Feign

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

比如这样:

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvcmV5WHV1_size_16_color_FFFFFF_t_70 3][]

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvcmV5WHV1_size_16_color_FFFFFF_t_70 4][]

没有底层的建立连接、构造请求、解析响应的代码，直接就是用注解定义一个 FeignClient接口，然后调用那个接口就可以了。人家Feign Client会在底层根据你的注解，跟你指定的服务建立连接、构造请求、发起靕求、获取响应、解析响应，等等。这一系列脏活累活，人家Feign全给你干了。

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

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvcmV5WHV1_size_16_color_FFFFFF_t_70 5][]  
六:springCloud核心组件:Ribbon

说完了,那么问题来了,如果库存服务上面部署了台机器,

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

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

首先Ribbon会从 Eureka Client里面获取到对应的服务注册表,也就知道了所有的服务都部署在了那台机器上,在监听哪些端口,

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

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvcmV5WHV1_size_16_color_FFFFFF_t_70 6][]

七:SpringCloud的核心组件:Hystrix

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

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvcmV5WHV1_size_16_color_FFFFFF_t_70 7][]

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

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

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

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

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

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

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvcmV5WHV1_size_16_color_FFFFFF_t_70 8][]

七: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个核心组件通过一张图串联起来

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvcmV5WHV1_size_16_color_FFFFFF_t_70 9][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvcmV5WHV1_size_16_color_FFFFFF_t_70]: /images/20230528/586acb77c74842b883c6b44bedfb2e6b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvcmV5WHV1_size_16_color_FFFFFF_t_70 1]: /images/20230528/359a80213e2d4aa19d39a4df62351687.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvcmV5WHV1_size_16_color_FFFFFF_t_70 2]: /images/20230528/e1b6cfa14dcf4ce4a8e61914eae45df8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvcmV5WHV1_size_16_color_FFFFFF_t_70 3]: /images/20230528/b987082c6c7d4c7e8854d282db057fc3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvcmV5WHV1_size_16_color_FFFFFF_t_70 4]: /images/20230528/c7c254d6471f483d833b5affba69c2ba.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvcmV5WHV1_size_16_color_FFFFFF_t_70 5]: /images/20230528/b9eb4ec57ff34967a17989806cbe3b00.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvcmV5WHV1_size_16_color_FFFFFF_t_70 6]: /images/20230528/99108361dc0a48a4a8af799ebdf45767.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvcmV5WHV1_size_16_color_FFFFFF_t_70 7]: /images/20230528/1bb5395a86174a7aa9d8c684404fa0f8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvcmV5WHV1_size_16_color_FFFFFF_t_70 8]: /images/20230528/2cee19325bfc4e77a001d7c516e673d4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NvcmV5WHV1_size_16_color_FFFFFF_t_70 9]: /images/20230528/8c0c2474274a4de2bc105345b4e97957.png