SpringCloud

675445

于 2024-11-14 11:46:32 发布

阅读量571

点赞数 14

本文链接：https://blog.youkuaiyun.com/weixin_43489165/article/details/142875181

版权

一、SpringCloud 简介

SpringCloud 是基于 SpringBoot 开发的一套微服务架构解决方案，旨在帮助开发者快速构建分布式系统中的各个组件。它整合了 SpringBoot、SpringCloud Netflix、SpringCloud Config 等多个子项目，为开发者提供了丰富的功能模块。

springCloud Netflix和SpringCloud Alibaba

一、SpringCloud Netflix：经典微服务架构

SpringCloud Netflix是基于Netflix开源组件的微服务框架，它提供了一系列的子项目，包括Eureka、Hystrix、Zuul等，用于构建分布式系统的各个组件。

核心组件

服务注册与发现（Eureka）

Eureka 作为 Spring Cloud 的核心组件之一，主要负责服务的注册与发现。它通过维护一个服务注册表，让各个微服务实例能够互相发现并通信。
Eureka工作原理详述

服务注册
当一个微服务启动时，它会向Eureka Server发送一个注册请求，将自己的元数据（如IP地址、端口号、服务名称等）信息注册到Eureka Server上。Eureka Server将这些信息保存在内存中的注册表中，使得其他服务能够发现并调用它。
心跳机制
为了确保服务实例的可用性，Eureka Client会定期向Eureka Server发送心跳。如果Eureka Server在规定时间内没有收到某个服务实例的心跳，它会将该服务实例标记为不可用。
服务发现
当服务消费者需要调用某个服务时，它可以从Eureka Server获取到该服务的注册信息，从而实现服务之间的通信与定位。
自我保护机制
在网络分区或服务实例大量失效的情况下，Eureka Server会启动自我保护机制，防止注册表中服务实例的批量删除，保证服务的持续可用性。
服务剔除
Eureka Server会定期执行服务剔除任务，将长时间未发送心跳的服务实例从注册表中删除，确保注册表中的数据准确性和实效性。

服务熔断与限流（Hystrix）

Hystrix 是一个服务熔断器，能够在服务出现异常时自动进行熔断，防止系统雪崩。同时，它也支持服务限流，保证系统在高并发环境下的稳定性。
一、Hystrix的核心设计理念

Hystrix的设计理念基于以下几个核心目标：

防护与控制：对来自依赖的延迟和故障进行有效防护，避免故障的连锁反应。
快速失败与恢复：在检测到异常情况时，快速失败并迅速尝试恢复。
优雅降级：当系统负载过高或服务不可用时，提供降级服务，保证用户体验。
实时监控与告警：提供近实时的监控与告警功能，确保问题可以被及时发现并处理。

二、Hystrix的关键实现机制

Hystrix通过以下几种机制来实现其设计目标：

资源隔离：通过使用线程池或信号量来隔离不同的服务调用，确保单个服务的故障不会影响到其他服务的正常执行。
- 线程池隔离：为每个依赖服务分配独立的线程池，当线程池耗尽时，新的请求会被拒绝，从而避免排队等待导致的资源耗尽。
- 信号量隔离：通过计数信号量来限制对某个服务的并发调用数量，当达到最大限制时，后续请求会被拒绝并执行降级操作。
熔断机制：当服务调用失败率达到一定阈值时，熔断器会自动打开，一段时间内所有的请求都会被快速拒绝，从而防止故障的连锁反应。
- 熔断器状态包括关闭、开启和半开，其中半开状态是熔断器尝试恢复服务的一个中间状态。
降级机制：在服务不可用或响应超时时，Hystrix会触发降级机制，执行预先定义的降级操作，如返回默认数据或缓存结果。
请求缓存：对于某些具有重复性的服务请求，Hystrix可以通过缓存机制来减少对后端服务的调用，提高系统效率。

负载均衡（Ribbon）

Ribbon 是一个客户端负载均衡器，它能够根据多种策略（如轮询、随机等）对服务实例进行选择，提高系统的可用性和性能。

二、Ribbon的工作原理

Ribbon通过以下步骤实现负载均衡：

1 服务发现与注册：Ribbon首先从服务注册中心（如Eureka或Nacos）获取所有可用的服务实例信息。

负载均衡策略：Ribbon内置了多种负载均衡策略，如轮询（RoundRobinRule）、随机（RandomRule）、响应时间权衡（ResponseTimeWeightedRule）等。开发者可以根据实际情况选择合适的策略。
请求拦截与转发：Ribbon通过拦截RestTemplate的请求，自动选择一个服务实例，并将请求转发到该实例上。
健康检查：Ribbon还提供了IPing接口，用于定期检查服务实例的健康状态，从而确保请求只会被转发到健康的实例。

三、Ribbon的核心组件

IRule：定义了负载均衡策略的接口，不同的实现提供了不同的负载均衡算法。
IPing：用于检查服务实例的健康状态，确保负载均衡器仅向健康的实例发送请求。
ServerList：管理服务实例的列表，可以从服务注册中心获取或通过配置文件指定。
ILoadBalancer：负载均衡器接口，负责根据负载均衡策略选择服务实例。

配置中心（Config）

Spring Cloud Config 提供了一个配置中心，用于集中管理应用的配置文件。它支持配置的动态更新，使得在不停机的情况下也能够修改配置。
一、Spring Cloud Config 简介

Spring Cloud Config 是一个基于 Git 的配置中心，它支持配置文件的版本控制和管理。通过 Spring Cloud Config，开发人员可以将配置信息存储在 Git 仓库中，实现配置的集中管理和动态更新。

二、Spring Cloud Config 原理剖析

配置服务器（Config Server）

Spring Cloud Config 的核心组件是配置服务器，它负责从 Git 仓库中检索配置文件，并提供给客户端。配置服务器的工作流程如下：
- 启动时，配置服务器会连接到 Git 仓库，并加载配置文件。
- 当客户端请求配置信息时，配置服务器会根据客户端的应用名和版本号，从 Git 仓库中找到相应的配置文件，并返回给客户端。
- 配置服务器还支持配置文件的版本控制，确保客户端获取到的配置信息是最新版本。
配置客户端（Config Client）

配置客户端负责从配置服务器获取配置信息，并应用到本地环境中。配置客户端的工作如下：
- 启动时，配置客户端会向配置服务器请求配置信息。
- 配置客户端接收到配置信息后，将其存储在本地环境中。
- 当配置信息发生变更时，配置客户端可以通过监听配置服务器的端点，自动获取最新配置并更新本地环境。
配置信息的加载和更新
- 配置信息的加载：配置服务器和客户端在启动时，都会加载配置信息。配置服务器加载的是 Git 仓库中的配置文件，而配置客户端加载的是从配置服务器获取的配置信息。
- 配置信息的更新：当配置信息发生变化时，配置服务器会通过 Webhook 通知配置客户端。配置客户端接收到通知后，会重新从配置服务器获取配置信息，并更新本地环境。

路由网关（Zuul）

Zuul 是一个路由网关，它负责处理外部请求，并将请求路由到对应的微服务实例。同时，它还可以进行安全验证、服务监控等。

优势
- 成熟稳定：Netflix组件经过多年的实践，稳定性较高。
- 社区支持：拥有庞大的开发者社区，问题解决速度快。
适用场景
- 适用于需要快速构建微服务的场景。
- 适合对稳定性要求较高的企业级应用。

二、Zuul核心原理

过滤器机制

Zuul的核心是其过滤器机制，这一机制类似于Servlet框架的Filter或者AOP（面向切面编程）。过滤器能够在请求路由到用户处理逻辑的过程中，参与各种过滤处理，如身份验证（Authentication）、负载均衡（Load Shedding）等。

动态加载：Zuul支持动态加载、编译和运行过滤器，使得在不重启网关的情况下，即可更新过滤器逻辑。
数据传递：过滤器之间不直接通信，而是通过一个名为RequestContext的静态类来实现数据传递。RequestContext类使用ThreadLocal变量来记录每个请求所需传递的数据。

请求路由与过滤

请求路由：Zuul能够根据配置动态地将外部请求路由到具体的微服务实例上，这是实现外部访问统一入口的基础。
请求过滤：过滤器对请求进行处理，包括请求校验、服务聚合等功能，确保了请求的合法性和安全性。

三、Zuul的应用场景

认证和安全
- Zuul能够识别每个资源的验证要求，并拒绝不符合要求的请求，从而保护系统的安全。
性能监测
- 在服务边界追踪和统计数据，提供精确的生产视图，帮助系统管理员及时发现和解决问题。
动态路由
- 根据需求将请求动态路由到后端集群，实现负载均衡和故障转移。
压力测试和负载卸载
- 通过逐渐增加对集群的流量来测试其性能，同时能够在请求超过预设容量时自动丢弃，保护系统不被过载。
静态资源处理
- 直接在边界返回某些静态资源的响应，减少对后端服务的请求。

二、SpringCloud Alibaba：新锐微服务架构

SpringCloud Alibaba是阿里巴巴开源的一套微服务架构解决方案，整合了包括Nacos、Sentinel、Seata等组件。

核心组件
- Nacos：服务发现和配置中心，提供动态服务发现和服务管理。
  一、Nacos 的一致性协议

Nacos 支持两种一致性协议：Raft（强一致性）和 Distro（最终一致性）。这两种协议分别适用于不同的场景，为服务发现和配置管理提供了灵活的选择。

Raft 协议：通过强制复制日志条目到所有节点，确保所有节点数据的一致性。在服务发现场景中，Raft 协议可以确保服务的注册和注销操作在所有节点上同步，从而避免数据不一致导致的服务调用问题。
Distro 协议：采用最终一致性模型，允许数据在一段时间内存在不一致，但最终会达到一致状态。在配置管理场景中，Distro 协议可以在不牺牲性能的前提下，实现配置信息的快速更新和传播。

二、服务注册与发现机制

Nacos 的服务注册与发现机制是构建在一致性协议之上的。服务提供者在启动时将自己的信息（如服务名、IP、端口）注册到 Nacos 中，而消费者则可以从 Nacos 中获取服务实例列表，实现服务的动态发现。

临时实例与永久实例：Nacos 中有两种服务实例类型，临时实例和永久实例。临时实例仅保存在服务注册表的缓存中，不会持久化到磁盘。当服务实例异常或下线时，Nacos 会将其从注册表中剔除。而永久实例则会被持久化到磁盘文件中，即使服务实例异常或下线，其信息仍然可见，但状态会标记为不健康。
服务保活：Nacos 通过心跳机制确保服务实例的存活状态。服务实例需要定期向 Nacos 发送心跳，如果 Nacos 在规定时间内没有收到心跳，则认为该实例已下线。

三、配置管理机制

Nacos 的配置管理机制使得配置信息的更新和传播变得异常高效。以下是其关键原理：

配置存储与发布：Nacos 将配置信息存储在内部持久化存储中（如 MySQL 数据库）。当配置信息更新时，Nacos 会生成新的版本，并通过长轮询机制通知客户端。
客户端刷新配置：客户端通过 HTTP 长轮询方式定期查询 Nacos 是否有新的配置发布。一旦检测到新配置，客户端会触发回调方法，刷新本地的配置信息。
- Sentinel：流量控制组件，用于处理服务的流量控制和熔断降级。
  一、Sentinel的核心功能
流量控制：Sentinel通过对请求的流量进行监控和控制，防止系统因流量过大而过载，确保系统的高可用性。
熔断降级：当服务出现异常或者负载过高时，Sentinel会自动触发熔断机制，避免故障的进一步扩散。
系统负载保护：Sentinel能够监控系统的负载情况，当系统负载接近或超过阈值时，自动启动保护机制，降低系统的负载。

二、Sentinel的工作原理

资源定义：在Sentinel中，资源是指需要被保护的系统或者服务，如一个API接口或者一个服务方法。资源需要被明确地定义，以便于Sentinel进行监控。
流量控制规则：Sentinel通过定义流量控制规则来限制资源的访问频率。规则包括阈值（如QPS、并发线程数等）和流量控制模式（如快速失败、Warm Up等）。
统计与判断：Sentinel使用LeapArray数据结构进行实时的流量统计。每当资源被访问时，Sentinel会根据统计数据进行判断，决定是否允许访问或者进行熔断。
熔断机制：当资源访问次数超过设定的阈值时，Sentinel会触发熔断机制。熔断器（CircuitBreaker）有两种实现方式：基于异常指标和基于响应时间（rt）指标。
状态转换：熔断器状态包括闭合、断开和半开。闭合状态下，请求可以通过；断开状态下，请求被阻止；半开状态下，允许部分请求通过，用于测试资源是否恢复。

三、Sentinel的高级特性

热点规则：Sentinel支持对热点资源进行更精细的流量控制，如针对接口的特定参数进行限流。
系统规则：Sentinel可以根据系统的整体负载情况进行动态调整，确保系统的稳定性。
授权规则：Sentinel支持对请求进行黑白名单控制，确保只有特定来源的请求能够访问资源。
- Seata：分布式事务处理组件，确保分布式系统中的数据一致性。
优势
- 国内支持：适合国内开发者，文档和社区支持更加友好。
- 新特性：整合了更多新兴技术，如Nacos和Sentinel，提供了更多的灵活性和可定制性。
适用场景
- 适用于需要高并发和大数据处理的业务场景。
- 适合对服务治理和配置管理有较高需求的系统。

二、Seata的核心组件

Seata的架构设计基于三个核心组件：事务管理器(Transaction Manager, TM)、资源管理器(Resource Manager, RM)和事务协调器(Transaction Coordinator, TC)。

事务管理器™：负责开启和关闭全局事务，它会在事务开始时向TC注册事务信息，并在事务结束时通知TC提交或回滚事务。
资源管理器(RM)：负责分支事务的资源管理和数据操作，它会向TC报告分支事务的状态，并根据TC的指令执行分支事务的提交或回滚。
事务协调器(TC)：作为全局事务的协调者，负责协调TM和RM之间的交互，决定全局事务是否可以提交或回滚。

三、Seata的工作流程

Seata的工作流程大致可以分为两个阶段：事务准备阶段和事务提交/回滚阶段。

事务准备阶段：在事务准备阶段，TM发起全局事务，并通知TC进行注册。RM则会锁定资源并向TC报告资源准备状态。
事务提交/回滚阶段：在事务的提交或回滚阶段，TC根据RM的报告决定全局事务的命运。如果所有RM都准备好，TC将指令RM进行事务提交；如果有RM未能准备好，TC将指令RM进行事务回滚。

四、Seata的事务模式

Seata支持多种分布式事务模式，主要包括AT模式和TCC模式。