Springcloud相关
Table of Contents
介绍一下Spring框架的IOC容器
- IOC 容器负责管理应用中的对象（Bean）的创建、配置和生命周期。它实现了控制反转的理念，即将对象的创建和依赖关系的管理从应用代码转移到了容器中。
- IOC 容器主要具有以下特点和功能：
- 对象创建：根据配置信息（如 XML 配置文件、注解等）创建对象实例。
- 依赖注入：自动为对象注入其所需的依赖，包括属性注入、构造器注入和方法注入等方式。
- 配置管理：集中管理对象的配置信息，包括对象的属性值、对象之间的关系等。
- 生命周期管理：负责对象的初始化、销毁等生命周期阶段的处理，可以通过实现特定的接口或使用注解来定制对象的生命周期回调方法。
- 解耦：降低了对象之间的直接依赖，提高了系统的灵活性和可维护性。
介绍一下Spring框架的AOP容器
- Spring 框架中的 AOP（面向切面编程）并不是一个单独的容器，而是通过 Spring 的 IOC 容器来实现和管理 AOP 相关的功能。
- AOP 是一种 编程范式 ，主要用于解决横切关注点的问题，将那些与业务逻辑无关但又广泛存在的功能（如日志记录、事务管理、性能监控、权限控制等）从业务逻辑中分离出来。
- 在 Spring 中，通过配置和使用切面（Aspect）、切点（Pointcut）和通知（Advice）来实现 AOP 功能。
- 切面：定义了一个横切关注点的模块化单元，包含了切点和通知。
- 切点：用于定义在哪些连接点（JoinPoint，比如方法执行、方法调用、异常抛出等）应用通知。
- 通知：是在切点处执行的具体操作，包括前置通知（Before Advice）、后置通知（After Advice）、环绕通知（Around Advice）、异常通知（After Throwing Advice）和最终通知（After Returning Advice）。
- 以下是一些 Spring 框架中 AOP 容器的使用案例：
- 日志记录
- 权限控制
- 异常处理
介绍一下SpringBoot、Cloud
Spring Boot
- 自动配置：能根据项目中引入的依赖自动进行配置，大大减少了开发者手动配置的工作量。
- 起步依赖：通过定义起步依赖，能方便地引入一组相关的依赖，无需逐个去管理版本。
- 内嵌服务器：比如 Tomcat、Jetty 等，方便开发和测试。
- 简化配置：提供了默认的配置，同时支持通过 properties 或 yml 文件进行个性化配置。
Spring Cloud
- Spring Cloud 是基于 Spring Boot 的一套微服务架构解决方案。
- 它包含了众多的组件和工具，用于实现微服务架构中的各种功能，比如：
- Eureka：服务注册与发现组件。Nacos代替
- Ribbon：客户端负载均衡。
- Feign：声明式的服务调用。
- Hystrix：服务容错与降级。
- Zuul：服务网关。
Spring事务的传播范围
Spring 事务的传播范围主要有以下几种：
- propagation_required：如果当前没有事务，就新建一个事务；如果已经存在一个事务，就加入到这个事务中。这是最常见的默认传播行为。
- propagation_supports：如果当前存在事务，就加入到这个事务中；如果当前没有事务，就以非事务方式执行。
- propagation_mandatory：必须在一个已有的事务中执行，如果当前没有事务，就抛出异常。
- propagation_requires_new：总是新建一个事务，如果当前存在事务，就把当前事务挂起。
- propagation_not_supported：以非事务方式执行，如果当前存在事务，就把当前事务挂起。
- propagation_never：以非事务方式执行，如果当前存在事务，就抛出异常。
- propagation_nested：如果当前存在事务，则在嵌套事务内执行；如果当前没有事务，则与 propagation_required 的行为相同。
Spring boot异步任务@Async失效问题
- 启动类是否开启异步服务；
- 在定义异步方法的同一个类中，调用带有@Async注解方法，该方法则无法异步执行；
- 注解的方法必须是public方法，不能是static；
- 没有走Spring的代理类。因为@Transactional和@Async注解的实现都是基于Spring的AOP，而AOP的实现是基于动态代理模式实现的。那么注解失效的原因就很明显了，有可能因为调用方法的是对象本身而不是代理对象，因为没有经过Spring容器管理。
SpringCloud常用组件
- Spring Cloud 是基于 Spring Boot 的一套微服务架构解决方案。
- 它包含了众多的组件和工具，用于实现微服务架构中的各种功能，比如：
- Eureka：服务注册与发现组件。（也可以使用
Nacos代替） - Ribbon：客户端负载均衡。
- Feign：声明式的服务调用。
- Hystrix：服务容错与降级。
- Zuul：服务网关。
eureka相关的一些问题
Eureka vs Nacos
- Eureka和Nacos都是流行的服务发现和注册中心，它们在微服务架构中扮演着重要的角色。
Eureka
- Eureka是Netflix开源的服务发现框架，它是Spring Cloud体系中的核心组件之一。
- Eureka基于RESTful API进行服务注册和发现。
- 它提供了以下特性：
- 区域感知 Eureka可以配置区域感知，使得客户端优先访问同一区域的服务实例。
- 服务实例元数据 服务实例可以在注册时提供元数据，如版本号、环境标签等，以支持更智能的路由决策。
- 自我保护机制 在网络分区或其他异常情况下，Eureka会启动自我保护机制，避免因大量服务下线而导致的注册表剧烈变化。
- 然而，Eureka的性能瓶颈主要体现在：
- CPU负载 在服务实例数量较多时，Eureka服务器的CPU负载可能会急剧上升，尤其是在心跳续约和定期全量/增量拉取注册表数据时。
- 实例同步 Eureka服务器之间的实例同步可能会造成延迟，影响服务发现的及时性。
Nacos
- Nacos是阿里巴巴开源的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
- Nacos提供了以下特性：
- 服务发现 支持基于DNS和RPC的服务发现机制。
- 配置管理 提供了集中式的配置管理能力。
- 服务管理 提供了对服务的元数据和健康状态的管理。
Nacos在性能方面的优化包括：
- 通信协议 Nacos 2.0将通信协议从HTTP升级到TCP，提高了吞吐量和降低了延迟。
- 框架升级 从Spring Boot升级到Spring Cloud，提高了扩展性和灵活性。
- 数据模型优化 减少了数据冗余，提高了查询效率。
性能对比：
- 压测结果显示 Nacos在注册、查询和注销实例的性能上表现优异，尤其是在高并发场景下，Nacos能够保持较低的延迟和较高的吞吐量。
- 集群稳定性 Nacos在大规模实例注册时，能够保持稳定的CPU使用率和较少的实例抖动。
结论
- Eureka和Nacos各有优势，但在性能方面，Nacos通过一系列的优化，如通信协议升级、框架升级和数据模型优化，提供了更好的性能表现。
- 对于需要高吞吐量和低延迟的服务发现场景，Nacos可能是更合适的选择。
讲一下服务熔断降级
- 服务熔断降级是微服务架构中的一种保护机制，用于防止系统过载和故障蔓延。
- 当某个服务单元（例如一个微服务）发生故障或者响应时间过长时，熔断机制会“断开”对它的调用，从而避免系统资源的进一步浪费，并防止故障扩散到整个系统。
- 服务降级是另一种保护机制，它允许系统在某些服务不可用时，提供降级的备选方案。
- 例如，如果一个推荐系统的服务不可用，系统可以提供一个默认的推荐列表，而不是等待推荐服务的响应。
服务熔断降级的实现
- 熔断器模式 这是实现熔断机制的常用模式，它包括三个状态：关闭（正常调用）、打开（熔断，拒绝调用）、半打开（尝试恢复调用）。熔断器会在检测到一定数量的失败或超时后切换到打开状态，在一定时间后切换到半打开状态，尝试恢复服务调用。
- 断路器组件 在Spring Cloud微服务框架中，提供了断路器（Hystrix）组件来实现熔断机制。
- 降级逻辑 在服务调用中实现降级逻辑，当检测到服务不可用时，可以调用备用服务或返回默认值。
- 监控和报警 实时监控服务的健康状况和性能指标，当达到熔断阈值时，触发报警并执行熔断逻辑。
- 配置中心 通过配置中心动态调整熔断器的参数，如失败率阈值、超时时间等，以适应不同的业务需求。
负载均衡应该设计在客户端还是网关？
- 网关。
- 所有进入的请求首先到达网关，然后由网关根据配置的负载均衡策略将请求路由到后端的某个服务实例。
- 优势：
- 集中管理：负载均衡策略在网关层面集中管理，简化了客户端的逻辑。
- 安全性：网关可以统一处理安全相关的问题，如认证、授权、限流等。
- 透明性：客户端不需要关心后端服务的负载均衡细节，对客户端透明。
- 劣势：
- 单点故障：如果网关没有设计好，可能会成为系统的单点故障。
- 性能开销：所有的请求都需要经过网关，可能会引入额外的延迟。
- 实现工具：Spring Cloud Gateway、Zuul、Kong、Nginx。