🏆今日学习目标：
🍀SpringCloud五大核心组件
✅创作者：林在闪闪发光
⏰预计时间：30分钟
🎉个人主页：林在闪闪发光的个人主页
🍁林在闪闪发光的个人社区，欢迎你的加入: 林在闪闪发光的社区
springCloud五大组件：
注册中心组件（服务治理）：Netflix Eureka；
负载均衡组件：Netflix Ribbon，各个微服务进行分摊，提高性能；
熔断器组件（断路器）：Netflix Hystrix，Resilience4j ；保护系统，控制故障范围；
网关服务组件：Zuul，spring cloud Gateway；api网关，路由，负载均衡等多种作用；
配置中心：Spring Cloud Config，将配置文件组合起来，放在远程仓库，便于管理；
SpringCloud五大组件：
1、Netflix Eureka（注册中心组件）
- 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模版请求自动转换成客户端负载均衡的服务调用。
负载均衡策略:
- 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 实现了断路器、线程隔离等一系列保护功能，用于隔离访问远程系统、服务或者第三方库，防止联级失败，从而提升系统的可用性与容错性；
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，状态的存储更新必须是线程安全的，即只有一个线程能够在某个时间点更新状态；
- 关闭 ----> 打开：当故障率等于或大于可配置的阈值时，CircuitBreaker 的状态将从“关闭”更改为“打开”。
- 打开 ----> 半开：当 CircuitBreaker 打开时，它会拒绝带有 CallNotPermittedException 的调用，经过一段等待时间后，CircuitBreaker 状态从 OPEN 变为 HALF_OPEN，并允许可配置数量的服务调用是否仍然不可用或再次变为可用，用 CallNotPermittedException 拒绝其他调用，直到所有允许的调用完成，如果故障率或慢呼叫率等于或大于配置的阈值，则状态会变回 OPEN；
- 半开 ----> 关闭：如果故障率和慢呼叫率低于阈值，则状态将变回“已关闭”；
- DISABLED：始终拒绝调用；
- FORCED_OPEN：始终允许调用；
- 在系统设计中，需要预期故障的发生，将应用程序拆分成多个组件，通过资源隔离确保一个组件的故障不会影响其他的组件，就像轮船用隔板（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 集群专门对外提供接口，这样的实现是否合理？是否有更好的方法？
这种架构破坏了服务无状态特点：为了保证对外服务的安全性，我们需要实现对服务访问的权限控制，而 Open Service 的访问权限机制会贯穿并污染整个开放服务的业务逻辑，破坏了集群中 Rest Api 无状态的特点，从具体的开发来说，工作中除了要考虑实际业务逻辑之外，还要额外持续对接口的访问做权限处理；
- 无法直接复用接口：当我们需要一个已有的集群内部接口，我们不得不在原有的接口上做校验逻辑，或者增加一个代理来做权限控制，无法直接复用原有的接口；
网关服务
将权限控制、日志收集从服务单元中抽离出去，最适合的地方是服务集群的最外端，我们需要一个功能更强大的负载均衡器，网关服务；
网关服务是微服务架构中不可或缺的一部分，它具备统一向外提供 Rest Api、服务路由、负载均衡、权限控制等功能，为微服务架构提供了门前保护，除了安全之外，还能让服务集群具备高可用性和测试性；
Zuul 是 NetFlix 开源的微服务网关，可以和 Eureka、Ribbon、Hystrix 等组件配合使用，其核心是一系列的过滤器；
- 身份认证和安全：识别每个资源的验证要求，拒绝不符合要求的请求；
- 审查与监控：在边缘位置追踪有意义的数据和统计结果，从而带来精确的生产视图；
- 动态路由：动态地将请求路由到不同的后端服务集群；
- 压力测试：逐渐增加指向集群的流量；
- 负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求；
- 静态响应处理：在边缘位置直接建立部分响应，从而避免其转发到集群内部；
- 多区域弹性：跨越 AWS Region 进行请求路由，实现 ELB（AWS Elastic Load Balancing ---- 负载均衡服务）使用的多样化，以及让系统的边缘更贴近系统的使用者；
- 客户端请求微服务时，先经过 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 获取配置文件的内容，请求到后再启动容器；
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
来源地址：https://blog.csdn.net/weixin_68829137/article/details/129132634
0