springcloud五大组件

电玩女神 2024-04-07 13:19 14阅读 0赞

##  ##

> springcloud五大组件：
> 
> 1、注册中心组件（服务治理）：Netflix Eureka；
> 
> 2、负载均衡组件：Netflix Ribbon，各个微服务进行分摊，提高性能；
> 
> 3、熔断器组件（断路器）：Netflix Hystrix，Resilience4j ；保护系统，控制故障范围；
> 
> 4、网关服务组件：Zuul，Spring Cloud Gateway；api网关，路由，负载均衡等多种作用；
> 
> 5、配置中心：Spring Cloud Config，将配置文件组合起来，放在远程仓库，便于管理；

![989c74716ab4af5064bf539c9ba68a6f.jpeg][]

## **springcloud五大组件：** ##

### **1、**Netflix Eureka（注册中心组件） ###

![59bab74992c5d2df0154b533fcb8853b.png][]

*  Spring Cloud 提供了多种注册中心的支持，如：Eureka、Consul、ZooKeeper 等，Netflix Eureka 本身是一个基于 REST 的服务，包含两个组件：Eureka Server 和 Eureka Client；

**作用：**

*  Eureka Server 提供服务注册服务，各个节点启动后，会在 Eureka Server 中进行注册，这样 Eureka Server 的服务注册表将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到；
 *  Eureka Server 之间通过复制的方式完成数据的同步，Eureka 还提供了客户端缓存机制，即使所有的 Eureka Server 都挂掉，客户端依然可以利用缓存中的信息消费其他服务的 API；
 *  Eureka Client：生产者或消费者；
 *  在应用启动后，Eureka Client 将会向 Eureka Server 发送心跳，默认周期为 30 秒，如果 Eureka Server 在多个心跳周期内（默认 90 秒）没有接收到某个节点的心跳，Eureka Server 将会进入自我保护机制；

### **2、**Netflix Ribbon（负载均衡组件） ###

*  适用于 Spring Cloud 2020 之前的版本；
 *  Ribbon 是 Netflix 发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将 Netflix 的中间层服务连接在一起，Ribbon 客户端组件提供一系列完善的配置项如连接超时，重试等，
 *  简单的说，就是在配置文件中列出 Load Balancer 后面所有的机器，Ribbon 会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器，我们也很容易使用 Ribbon 实现自定义的负载均衡算法；
 *  作用：Ribbon，主要提供客户侧的软件负载均衡算法。
 *  简介：Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。

![bb0696e834edcc6fe809d6e4b9216f47.png][]

**负载均衡策略:**

*  RoundRobinRule ---- 轮询、默认；
 *  RandomRule ---- 随机；
 *  RetryRule ---- 重试机制；
 *  BestAvailableRule ---- 选择最小并发 server；
 *  AvailabilityFilteringRule ---- 过滤高并发、失败 server；
 *  WeightedResponseTimeRule ---- 根据响应时长比重选择中间值；
 *  ZoneAvoidanceRule ---- 判断 server 性能；
 *  查看 com.netflix.loadbalancer.IRule 接口；

### **3、熔断器组件** ###

#### **1.**Netflix Hystrix ####

**简介：**

*  推荐 Spring Cloud 2020 之前版本使用；
 *  雪崩效应：在微服务架构中，存在多个微服务，若其中一个微服务出现故障，就很容易因为依赖关系而引发故障蔓延，最终导致整个系统瘫痪，列举：电商系统中，存在用户、订单、库存、积分、评论等微服务，用户创建一个订单，请求库存系统出货，库存系统出现问题，导致订单服务挂起或失败，在高并发的情况下，被挂起的线程导致后续请求被阻塞，最终导致订单服务不可用；
 *  服务熔断：当 A 服务去调用 B 服务，如果迟迟没有收到 B 服务的响应，那么就终断当前的请求，而不是一直等待下去，此时还要去监控 B 服务，当 B 服务恢复正常使用时，A 服务再发起请求；
 *  服务降级：A 服务调用 B 服务，没有调用成功发生熔断，那么 A 服务拿一个默认值顶着，避免给我们的用户，响应一些错误的页面；
 *  请求缓存：对接口进行缓存，可以大大降低生产者的压力，适用更新频率低，但是访问又比较频繁的数据；
 *  请求合并：将客户端多个请求合并成一个请求，只发送一个 HTTP 请求，得到响应后再将请求结果分发给不同的请求，这样就可以提供传输效率；
 *  Netflix Hystrix 实现了断路器、线程隔离等一系列保护功能，用于隔离访问远程系统、服务或者第三方库，防止联级失败，从而提升系统的可用性与容错性；

![71800d306a0d497fa40198389a0e2953.jpeg][]

#### 2. Resilience4j ####

**简介：**

*  推荐 Spring Cloud 2020 之后版本使用；
 *  Resilience4j 是 Spring Cloud G 版本推荐的容错方案，是一个轻量级的容错库，专为 Java 8 和函数式编程而设计，借鉴了 Hystrix 的设计，提供了断路器（CircuitBreaker）、并发调用隔离（Bulkhead）、限流（RateLimiter）、重试（Retry）、超时（Timeout） 等功能；
 *  断路器 CircuitBreaker
    
     *  断路器一般通过 3 个有限状态机来实现：CLOSED、OPEN、HALF\_OPEN，此外，还有 2 个特殊的状态机：DISABLED 和 FORCED\_OPEN，状态的存储更新必须是线程安全的，即只有一个线程能够在某个时间点更新状态；
 *  ![05d2e91b90314029ba39444db213b64f.jpeg][]
    
     *  关闭 ----> 打开：当故障率等于或大于可配置的阈值时，CircuitBreaker 的状态将从“关闭”更改为“打开”。
     *  打开 ----> 半开：当 CircuitBreaker 打开时，它会拒绝带有 CallNotPermittedException 的调用，经过一段等待时间后，CircuitBreaker 状态从 OPEN 变为 HALF\_OPEN，并允许可配置数量的服务调用是否仍然不可用或再次变为可用，用 CallNotPermittedException 拒绝其他调用，直到所有允许的调用完成，如果故障率或慢呼叫率等于或大于配置的阈值，则状态会变回 OPEN；
     *  半开 ----> 关闭：如果故障率和慢呼叫率低于阈值，则状态将变回“已关闭”；
     *  DISABLED：始终拒绝调用；
     *  FORCED\_OPEN：始终允许调用；
 *  并发调用隔离 Bulkhead
    
     *  在系统设计中，需要预期故障的发生，将应用程序拆分成多个组件，通过资源隔离确保一个组件的故障不会影响其他的组件，就像轮船用隔板（Bulkhead）分成多个小隔间，每个隔间都被隔板密封，这样可以防止进洪水时整艘船沉没；
     *  两个服务 A 和服务 B，A 的某些 API 依赖 B，当服务 B 运行速度非常慢的时候，A 调用 B 的请求变多时，A 的性能会受到影响，服务 A 中那些不依赖于服务 B 的功能也无法处理，因此，需要隔离 A 中依赖 B 的请求，Resilience4j 提供了 SemaphoreBulkhead 和 FixedThreadPoolBulkhead 来实现 Bulkhead；
 *  限流 RateLimiter
    
     *  微服务在给定的时间内设置可以处置的最大请求数，控制吞吐量来帮助保护服务器免于过载；
 *  重试 Retry
    
     *  微服务体系中，多个服务互相依赖，当被依赖的服务出现问题而无法按预期响应时，就会级联到下游服务，导致不良的用户体验，通常我们会为每个微服务部署多个实例，如果其中一个实例有问题，无法响应我们的请求，我们则重试该请求，负载均衡器可以将请求发送到运行状况良好的节点并正确获得响应，通过重试，有更多机会获得正确的响应；
 *  超时 Timeout
    
     *  在微服务体系中，微服务相互依赖，可能因为网络的原因，导致消费者阻塞，在设计时需要设置超时来应对服务缓慢 、不可用性问题；

### **4、**网关服务组件 ###

#### 1.Netflix Zuul ####

**简介：**

*  推荐 Spring Cloud 2020 之前版本使用；
 *  未加网关的微服务架构
    
     *  通过上面的学习，分布式架构基本成型，内部服务集群 Service A 和 Service B，它们都会到注册中心注册和订阅服务，而 Open Service 集群专门对外提供接口，这样的实现是否合理？是否有更好的方法？
 *  ![85a04d6f14c44c5aa75a29097a2a4441.jpeg][]
    
     *  这种架构破坏了服务无状态特点：为了保证对外服务的安全性，我们需要实现对服务访问的权限控制，而 Open Service 的访问权限机制会贯穿并污染整个开放服务的业务逻辑，破坏了集群中 Rest Api 无状态的特点，从具体的开发来说，工作中除了要考虑实际业务逻辑之外，还要额外持续对接口的访问做权限处理；
     *  无法直接复用接口：当我们需要一个已有的集群内部接口，我们不得不在原有的接口上做校验逻辑，或者增加一个代理来做权限控制，无法直接复用原有的接口；
 *  网关服务
    
     *  将权限控制、日志收集从服务单元中抽离出去，最适合的地方是服务集群的最外端，我们需要一个功能更强大的负载均衡器，网关服务；
     *  网关服务是微服务架构中不可或缺的一部分，它具备统一向外提供 Rest Api、服务路由、负载均衡、权限控制等功能，为微服务架构提供了门前保护，除了安全之外，还能让服务集群具备高可用性和测试性；
     *  Zuul 是 NetFlix 开源的微服务网关，可以和 Eureka、Ribbon、Hystrix 等组件配合使用，其核心是一系列的过滤器；
        
         *  身份认证和安全：识别每个资源的验证要求，拒绝不符合要求的请求；
         *  审查与监控：在边缘位置追踪有意义的数据和统计结果，从而带来精确的生产视图；
         *  动态路由：动态地将请求路由到不同的后端服务集群；
         *  压力测试：逐渐增加指向集群的流量；
         *  负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求；
         *  静态响应处理：在边缘位置直接建立部分响应，从而避免其转发到集群内部；
         *  多区域弹性：跨越 AWS Region 进行请求路由，实现 ELB（AWS Elastic Load Balancing ---- 负载均衡服务）使用的多样化，以及让系统的边缘更贴近系统的使用者；
 *  使用 Zuul 后的微服务架构
 *  ![8d22e0e2b47b965b51755014e3f7fa1e.jpeg][]
 *  客户端请求微服务时，先经过 Zuul，再调用微服务集群，这样对于校验、负载均衡等功能移到了 Zuul 中实现，而微服务只需关注自身的业务逻辑则可；

### **5、配置中心组件** ###

#### Spring Cloud Config ####

**简介：**

*  之前配置文件是否存在的问题？
    
     *  微服务各自拥有自己的配置文件，当配置修改之后，我们需要重启项目，如果数量庞大，维护成本增加，针对这个问题，我们采用 Spring Cloud Config 来做配置；
 *  Spring Cloud Config 为分布式系统外部化配置提供了服务端和客户端的支持，它包含 Config Server 和 Config Client 两个部分，实现了 Spring Environment 和 PropertySource 抽象的映射，非常适合 Spring 应用程序；
 *  Config Server 是一个可横向扩展、集中式的配置服务器，它用于集中管理应用程序各个环境下的配置，支持 Git、SVN、本地文件存储，默认使用 Git；
 *  Config Client 是 Config Server 的客户端，用于操作存储在 Config Server 中的配置内容，微服务在启动时会请求 Config Server 获取配置文件的内容，请求到后再启动容器；

![45ee258d86da4e6c8bc3e74e52a642d7.jpeg][]

#### 1.Config Server ####

*  创建仓库
    
     *  创建 Git 远程仓库，并将微服务所有配置文件上传到仓库中，配置文件命名规则：
        
         *   *  **环境配置：application-\{profile\}.properties；**
             *  **配置中心：\{application\}-\{profile\}.profiles;**
 *  创建工程,选择 Eureka Discovery Client、Config Server 组件；
 *  导入pom,配置文件以及启动类配置
 *  启动测试

#### 2.Config Client ####

*  加入bootstrap支持，pom
 *  创建bootstrap.properties
 *  拆分application.properties，本地 application.properties 中的配置分成两个部分
 *  注册部分，Eureka 相关配置、引入的其余配置文件配置（比如 logback.xml），**移植到 bootstrap.properties 配置文件中，注册微服务**
 *  其余配置项，移植到远程配置仓库中对应的配置文件中；
 *  删除 application.properties 配置（我对之进行重命名备份）；
 *  微服务启动，到注册中心中去注册，才能获取配置中心提供的功能，去读取git仓库中的配置文件
 *  注册中心配置，就需要从application.properties移到bootstrap.properties；

*  配置加载顺序：
    
     *  读本地 bootstrap.properties
     *  到注册中心注册服务
     *  连接 Config Server，加载远程配置 applicationTest-dev.properties
     *  加载本地 application.properties；

[989c74716ab4af5064bf539c9ba68a6f.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/08ddee13df5546f6858ff920b284cce7.jpeg
[59bab74992c5d2df0154b533fcb8853b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/607cb0549dac41fbabb543707a5b4693.png
[bb0696e834edcc6fe809d6e4b9216f47.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/99aa62ff34a046eea94cd5646334ae02.png
[71800d306a0d497fa40198389a0e2953.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/21530369f4134333814eb6ecc6bdb368.jpeg
[05d2e91b90314029ba39444db213b64f.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/3e48eeb1f39141988d2b90a46908a0ad.jpeg
[85a04d6f14c44c5aa75a29097a2a4441.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/f87a2c4e4a84419eafc02fbb6641b3a5.jpeg
[8d22e0e2b47b965b51755014e3f7fa1e.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/f6aa0d1d3c094d3ca5556f8d62192114.jpeg
[45ee258d86da4e6c8bc3e74e52a642d7.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/74baf6b4a5f340b08311f5ef115d22d9.jpeg