Spring Cloud Alibaba核心组件综合学习记录

一、Spring Cloud Alibaba 核心组件

        微服务（或微服务架构）是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。

        而 Spring Cloud 与 Spring Cloud Alibaba 都是一站式的微服务解决方案：

        微服务与Spring Cloud Alibaba简介_springcloud alibaba微服务架构-优快云博客

1.Spring Cloud 与 Spring Cloud Alibaba 

        什么是Spring Cloud？

        Spring Cloud 是基于 Spring Boot 的一套微服务治理框架，提供了一系列工具（如服务发现、配置中心、负载均衡、熔断器等），简化分布式系统的开发。

        什么是Spring Cloud Alibaba？

        Spring Cloud Alibaba 是阿里巴巴开源的微服务解决方案，基于 Spring Cloud 标准生态构建，提供了一系列适用于云原生和分布式架构的组件。它整合了阿里巴巴在双11等高并发场景下的实践经验，为微服务开发提供更强大、更稳定的支持。

        Spring Cloud 和 Spring Cloud Alibaba 提供了一系列工具来简化微服务的开发、治理和运维，使开发者能更专注于业务逻辑。

2.Spring Cloud Alibaba 核心组件及功能

        Spring Cloud Alibaba 核心组件覆盖了微服务架构中的服务注册发现、配置中心、熔断限流、网关等关键场景。

1. 服务注册与发现：Nacos
   集服务注册中心和配置中心于一体，支持动态服务注册、发现和配置管理，可在 AP（高可用）和 CP（一致性）模式间切换，满足不同场景需求。

2. 负载均衡：Spring Cloud LoadBalancer 
   服务消费者从 Nacos 获取服务列表后，Ribbon/Spring Cloud LoadBalancer  会根据预设策略（如轮询、随机、权重等）选择一个服务实例进行调用，避免单一实例过载。

3. 熔断与限流：Sentinel
   针对服务稳定性的流量治理组件，支持流量控制、熔断降级、系统负载保护等功能，通过控制台可实时监控和动态配置规则，轻量且性能优异。

4. 服务调用：OpenFeign 与 Dubbo

   • OpenFeign：声明式 HTTP 客户端，简化服务间 RESTful 调用，集成负载均衡功能。
   • Dubbo：高性能 RPC 框架，基于二进制协议，适合高并发场景，与 Nacos 结合实现服务注册发现。

5. 网关：Spring Cloud Gateway
   基于 Netty 的异步非阻塞网关，负责请求路由、负载均衡、过滤（鉴权、日志等），性能优于传统的 Zuul 网关。

6. 分布式事务：Seata
   解决跨服务事务一致性问题，支持 AT（自动补偿，低侵入）、TCC（手动编码，高并发）等模式，通过事务协调器（TC）协调分支事务的提交或回滚。

7. 配置中心：Nacos Config
   与 Nacos 服务注册发现功能集成，支持集中管理多环境、多服务配置，实现配置动态刷新，无需重启服务。

二、服务注册和发现 Nacos

        在微服务架构中，一个系统被拆分为多个独立的服务（如用户服务、订单服务），这些服务可能部署在不同的服务器上，且数量会动态变化（新增 / 下线实例）。

• 服务注册：服务启动时，将自己的信息（服务名、IP 地址、端口等）主动上报给一个统一的 "注册中心"，相当于服务在注册中心 "登记" 自己的位置。
• 服务发现：服务消费者需要调用其他服务时，无需硬编码目标服务的地址，而是从注册中心查询目标服务的可用实例列表，再通过负载均衡选择一个实例进行调用。

这一机制解决了微服务集群中服务地址动态变化的问题，实现了服务间的动态通信。

1.基于 Spring Cloud Alibaba Nacos 的服务注册和发现

        Nacos服务发现和配置管理_nacos 服务发现-优快云博客

        Nacos 是一个易于构建云原生应用的动态服务发现、配置管理和服务管理平台。它是 Spring Cloud Alibaba 的组件，主要负责服务注册、发现和配置。

        Nacos（Dynamic Naming and Configuration Service）是 Spring Cloud Alibaba 的核心组件，提供两大核心能力：

• 服务发现与健康管理：微服务的注册、发现和健康监测。
• 动态配置管理：集中化管理所有微服务的配置，支持动态刷新。

1.1 Nacos的工作流程

Nacos 的工作流程可分为服务注册、服务发现与监听、服务调用 三个核心阶段：

服务注册阶段（服务提供者 → Nacos 注册中心）：

服务提供者启动后，会向 Nacos 注册中心上报自身信息（如服务名、IP、端口、实例类型等）：

• 临时实例：默认类型，通过心跳机制维持注册状态（服务提供者定时发心跳包，Nacos 若超时未收到则标记实例为不健康，极端情况会剔除）。
• 非临时实例：需显式配置（ephemeral=false ），Nacos 会主动询问状态（而非依赖心跳），更可靠但性能稍低。

注册完成后，Nacos 注册中心就保存了完整的服务实例列表。

---

服务发现与监听阶段（Nacos 注册中心 ↔ 服务消费者）：

服务消费者需要调用其他服务时，会从 Nacos 获取目标服务的实例列表，核心逻辑分两步：

1. 初始拉取（Pull）：
   服务消费者启动时，主动从 Nacos 拉取目标服务的实例列表（如 user-service 的 localhost:8081 等实例），并缓存到本地。

2. 动态监听（Push + 定时 Pull 兜底）：

   • 主动推送（Push）：Nacos 注册中心会监听服务实例的变化（新增、下线、状态变更），一旦有变动，主动推送给服务消费者，保证消费者本地缓存及时更新。
   • 定时拉取（Pull 兜底）：为防止推送失败，服务消费者会定时（默认 30 秒）主动拉取最新实例列表，与本地缓存对比更新，确保最终一致性。

---

服务调用阶段（服务消费者 → 服务提供者）：

服务消费者拿到最新的服务实例列表后，结合负载均衡策略（如 Spring Cloud LoadBalancer/Ribbon），从实例列表中选一个实例，发起远程调用。

调用时的负载均衡逻辑（选实例的规则）可灵活配置（轮询、权重、最少连接等 ），保证流量合理分配，避免单实例过载。

完整流程总结：

1. 服务提供者注册：启动后上报信息到 Nacos，通过心跳（临时实例）或主动探测（非临时实例）维持状态。
2. 服务消费者发现：先拉取实例列表缓存本地，再通过 Nacos 推送 + 定时拉取保证缓存实时性。
3. 服务调用：消费者用负载均衡选实例，发起远程调用，完成业务逻辑。

三、服务调用 OpenFeign 与 Dubbo

        OpenFeign 和 Dubbo 都是微服务架构中用于服务间通信的框架：

        OpenFeign服务接口调用_feign接口-优快云博客

1.OpenFeign：基于 HTTP 的声明式 REST 客户端

        OpenFeign 是 Spring Cloud 生态的一部分，本质是声明式 HTTP 客户端，基于 RESTful 风格的 HTTP 协议实现服务间通信，简化了服务调用的代码编写（通过接口 + 注解定义调用规则）。

1.1 OpenFeign 的使用方式

引入依赖（Maven）：

<!-- OpenFeign 核心依赖 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>
<!-- Nacos -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

定义 Feign 客户端接口：
        通过 @FeignClient 注解指定目标服务名，接口方法映射目标服务的 HTTP 接口（类似 Controller 层的映射）：

// 目标服务名：user-service（需在 Nacos 注册）
@FeignClient(name = "user-service") 
public interface UserFeignClient {
    // 映射 user-service 的 /users/{id} 接口（GET 方法）
    @GetMapping("/users/{id}")
    User getUserById(@PathVariable("id") Long id);
    
    // 映射 user-service 的 /users 接口（POST 方法）
    @PostMapping("/users")
    User createUser(@RequestBody User user);
}

启用 Feign 客户端：
在启动类添加 @EnableFeignClients 注解：

@SpringBootApplication
@EnableFeignClients  // 开启 Feign 功能
@EnableDiscoveryClient  // 启用服务发现（可选，部分版本自动生效）
public class OrderServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderServiceApplication.class, args);
    }
}

调用服务：
直接注入 Feign 接口并调用方法，底层会自动通过 HTTP 协议调用目标服务：

@Service
public class OrderService {
    @Autowired
    private UserFeignClient userFeignClient;
    
    public Order createOrder(Long userId) {
        // 调用 user-service 获取用户信息
        User user = userFeignClient.getUserById(userId);
        // 业务逻辑...
        return new Order(1L, userId, user.getName());
    }
}

2.Dubbo：高性能 RPC 框架

        Dubbo 是阿里巴巴开源的高性能 RPC（远程过程调用）框架，基于二进制协议（默认 Dubbo 协议）实现服务间通信，更注重服务治理（如负载均衡、容错、监控等），适合高并发场景。

2.1 Dubbo 的使用方式:

引入依赖（Maven）：

<!-- Dubbo 核心依赖 -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-dubbo</artifactId>
</dependency>
<!-- Nacos 注册中心 -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

定义服务接口（单独抽成 API 模块，供提供者和消费者依赖）：

// 服务接口（需双方共享）
public interface UserService {
    User getUserById(Long id);
    User createUser(User user);
}

实现服务提供者：

实现接口，并通过 @DubboService 注解暴露服务：

@DubboService  // 暴露服务（注册到 Nacos）
public class UserServiceImpl implements UserService {
    @Override
    public User getUserById(Long id) {
        // 业务逻辑：从数据库查询用户
        return new User(id, "张三");
    }
    
    @Override
    public User createUser(User user) {
        // 业务逻辑：创建用户
        return user;
    }
}

配置提供者（application.yml）：

spring:
  application:
    name: user-service  # 服务名
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848  # Nacos 地址

dubbo:
  protocol:
    name: dubbo  # 协议名称（默认 dubbo）
    port: -1     # 端口（-1 表示随机）
  registry:
    address: spring-cloud://localhost  # 集成 Spring Cloud 注册中心（Nacos）
  scan:
    base-packages: com.example.user.service  # 扫描 @DubboService 注解的包

服务消费者调用：

通过 @DubboReference 注解引用服务接口：

@Service
public class OrderService {
    // 引用 user-service 的 UserService 接口
    @DubboReference
    private UserService userService;
    
    public Order createOrder(Long userId) {
        // 调用 Dubbo 服务
        User user = userService.getUserById(userId);
        // 业务逻辑...
        return new Order(1L, userId, user.getName());
    }
}

配置消费者（application.yml）：

spring:
  application:
    name: order-service
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848

dubbo:
  registry:
    address: spring-cloud://localhost  # 注册中心地址
  consumer:
    timeout: 3000  # 调用超时时间 3 秒

 3.OpenFeign 与 Dubbo 的核心区别

对比维度	OpenFeign	Dubbo
通信协议	基于 HTTP/HTTPS（文本协议）	基于 Dubbo 协议（二进制协议，默认），也支持 HTTP、gRPC 等
性能	较低（文本协议解析开销大，序列化效率低）	较高（二进制协议紧凑，序列化效率高，适合高并发）
服务治理	依赖 Spring Cloud 生态（如 Sentinel 限流、LoadBalancer 负载均衡）	内置完善的服务治理（负载均衡、容错、监控、配置中心等）
接口定义	基于 HTTP 方法（GET/POST 等），需显式定义 URL 映射	基于 Java 接口，无需关心 URL，更接近本地方法调用
跨语言支持	好（HTTP 是通用协议，支持多语言）	一般（默认 Dubbo 协议主要支持 Java，其他语言需适配）
生态集成	与 Spring Cloud 无缝集成（如 Gateway、Config）	可与 Spring Cloud Alibaba 集成，也可独立使用
适用场景	服务间通信简单、跨语言需求高、对性能要求不极致的场景	高并发、高性能要求的内部服务通信，服务治理需求复杂的场景

总结:

• OpenFeign 适合简单的微服务架构，尤其是需要跨语言通信、与 Spring Cloud 生态深度绑定的场景，优势在于易用性和 HTTP 协议的通用性。
• Dubbo 适合对性能要求高、服务治理复杂的内部微服务场景（如电商核心系统），优势在于高性能和完善的服务治理能力。

四、网关 Spring Cloud Gateway

        Spring Cloud Gateway 服务网关-优快云博客

        Spring Cloud Gateway 是 Spring Cloud 官方推出的异步非阻塞网关，基于 Netty、Spring WebFlux 开发，用于替代 Zuul。主要功能包括路由转发、请求过滤、负载均衡、限流熔断等，是微服务的统一入口。

1.Gateway核心组件

① 路由（Route）：路由是网关的基本组件，Gateway包含多个路由，每个路由包含唯一的ID（路由编号）、目标URI（即请求最终被转发到的目的地URI）、路由断言集合和过滤器集合。

② 断言（Predicate）：实际上就是Java 8 Function Predicate的断言功能，即匹配条件，只有满足条件的请求才会被路由到目标URI。输入类型是 Spring Framework ServerWebExchange。其允许开发人员自行匹配来自HTTP请求的任何内容，例如HTTP头或参数。

③ 过滤器（Filter）：作用类似于拦截加工，对于经过过滤器的请求和响应，都可以进行修改，例如Spring Framework GatewayFilter实例，可以在发送下游请求之前或之后修改请求和响应。

2. Gateway工作流程

        当Gateway客户端向Gateway服务端发送请求时，请求首先被HttpWebHandlerAdapter提取组装成网关上下文，然后网关上下文会传递到DispatcherHandler中。DispatcherHandler是所有请求的分发处理器，主要负责分发请求对应的处理器，比如将请求分发到对应的RoutePredicateHandlerMapping（路由断言处理映射器）。路由断言处理映射器主要用于路由查找，以及找到路由后返回对应的FilterWebHandler。FilterWebHandler主要负责组装过滤器链并调用过滤器执行一系列过滤处理，然后把请求转到后端对应的代理服务处理，处理完毕之后将反馈信息

总结：

1. 客户端发送请求到 Gateway。
2. 网关解析请求，通过 Predicate 匹配路由（找到第一个符合条件的路由）。
3. 执行该路由的 Filter 链（先执行 pre 类型过滤器，再转发请求到目标服务）。
4. 目标服务返回响应，执行 Filter 链的 post 类型过滤器，最终返回响应给客户端。

五、负载均衡策略 Spring Cloud LoadBalancer 

        负载均衡是微服务架构中实现流量合理分配、避免单点过载的核心机制，其核心思想是：将请求 / 任务分摊到多个服务实例上，通过 "分流" 提升系统整体可用性和吞吐量。

        在 Spring Cloud 生态中，负载均衡的实现主要分为两类：客户端负载均衡和服务端负载均衡。

1.Spring Cloud LoadBalancer 

        Spring Cloud LoadBalancer 属于客户端的负载均衡策略：客户端在发起请求前，先获取目标服务的所有可用实例列表，自主决定调用哪个实例（逻辑在客户端实现）。

        Spring Cloud LoadBalancer 提供了一个轻量级的负载均衡功能，它替代了以前的 Ribbon，并且与Nacos、 Eureka、Consul、Zookeeper 等服务注册发现工具无缝集成。Spring Cloud LoadBalancer 默认支持的负载均衡算法有：轮询、随机、权重等。

1.1 负载均衡策略

轮询策略（Round Robin 默认）：

        按照服务实例列表的顺序，依次循环选择服务实例来处理请求，即每个实例在一轮中会被选择一次， 保证每个实例被调用的机会均等。

随机策略（Random）：

        在每次请求到来时，从可用的服务实例列表中随机选择一个实例来处理请求。

加权策略：

        为每个服务实例分配一个权重值，权重越高，表示该实例被选中处理请求的概率越大。通常，权重是根据服务实例的性能（如 CPU、内存、网络带宽等资源的配置）来设置的，性能更好的实例被赋予更高的权重，从而能处理更多的请求。

自定义策略：

        当内置的负载均衡策略无法满足特定业务需求时，开发者可以根据自身业务逻辑，自定义负载均衡的选择逻辑。例如，根据服务实例的实时负载情况（如 CPU 使用率、内存占用率、请求队列长度等指标）来选择负载最轻的实例；或者根据请求的来源 IP、请求的 URL 路径等信息，将特定类型的请求固定转发到某些特定的实例上。

1.2 策略的选择与配置

Spring Cloud LoadBalancer 支持通过配置指定全局策略或针对特定服务的策略。

1. 全局默认策略

        默认情况下，Spring Cloud LoadBalancer 使用轮询策略。若需将全局默认策略改为随机，可通过配置类定义 ReactorLoadBalancer Bean：

import org.springframework.cloud.client.ServiceInstance;
import org.springframework.cloud.loadbalancer.core.RandomLoadBalancer;
import org.springframework.cloud.loadbalancer.core.ReactorLoadBalancer;
import org.springframework.cloud.loadbalancer.core.ServiceInstanceListSupplier;
import org.springframework.cloud.loadbalancer.support.LoadBalancerClientFactory;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.env.Environment;

@Configuration
public class LoadBalancerConfig {
    // 全局默认使用随机策略
    @Bean
    ReactorLoadBalancer<ServiceInstance> randomLoadBalancer(Environment environment, 
                                                           LoadBalancerClientFactory loadBalancerClientFactory) {
        String name = environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);
        return new RandomLoadBalancer(loadBalancerClientFactory.getLazyProvider(name, ServiceInstanceListSupplier.class), name);
    }
}

2. 针对特定服务的策略

        若需为某个服务单独指定策略（例如对 user-service 使用随机策略，其他服务用轮询），可通过 服务名 + 配置类 的方式实现：

        创建一个针对特定服务的配置类（如 UserServiceLoadBalancerConfig），定义该服务的策略：

import org.springframework.cloud.client.ServiceInstance;
import org.springframework.cloud.loadbalancer.core.RandomLoadBalancer;
import org.springframework.cloud.loadbalancer.core.ReactorLoadBalancer;
import org.springframework.cloud.loadbalancer.core.ServiceInstanceListSupplier;
import org.springframework.cloud.loadbalancer.support.LoadBalancerClientFactory;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.env.Environment;

@Configuration
public class UserServiceLoadBalancerConfig {
    // 仅对"user-service"生效的随机策略
    @Bean
    ReactorLoadBalancer<ServiceInstance> userServiceRandomLoadBalancer(Environment environment,
                                                                       LoadBalancerClientFactory loadBalancerClientFactory) {
        String name = environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);
        return new RandomLoadBalancer(loadBalancerClientFactory.getLazyProvider(name, ServiceInstanceListSupplier.class), name);
    }
}

        在主配置类中通过 @LoadBalancerClients 注解指定服务与配置类的映射：

import org.springframework.cloud.loadbalancer.annotation.LoadBalancerClients;
import org.springframework.context.annotation.Configuration;

@Configuration
// 为"user-service"指定专用配置，其他服务使用默认策略
@LoadBalancerClients(value = {
    @LoadBalancerClient(name = "user-service", configuration = UserServiceLoadBalancerConfig.class)
})
public class GlobalLoadBalancerConfig {
}

1.3 自定义负载均衡策略

        若内置策略无法满足需求（例如根据实例负载、响应时间等动态选择实例），可通过实现自定义策略扩展。

实现负载均衡器接口：

自定义类继承 ReactorLoadBalancer<ServiceInstance> 接口，重写 choose 方法实现选择逻辑。

import org.springframework.cloud.client.ServiceInstance;
import org.springframework.cloud.loadbalancer.core.ReactorLoadBalancer;
import org.springframework.cloud.loadbalancer.core.ServiceInstanceListSupplier;
import org.springframework.cloud.loadbalancer.support.LoadBalancerClientFactory;
import org.springframework.core.env.Environment;
import reactor.core.publisher.Mono;
import java.util.List;
import java.util.Random;

// 示例：基于权重的自定义策略（假设服务实例元数据中包含"weight"字段）
public class WeightedLoadBalancer implements ReactorLoadBalancer<ServiceInstance> {
    private final String serviceId;
    private final ServiceInstanceListSupplier supplier;
    private final Random random = new Random();

    public WeightedLoadBalancer(ServiceInstanceListSupplier supplier, String serviceId) {
        this.supplier = supplier;
        this.serviceId = serviceId;
    }

    @Override
    public Mono<Response<ServiceInstance>> choose(Request request) {
        return supplier.get().next().map(this::getInstanceByWeight);
    }

    // 根据权重选择实例
    private Response<ServiceInstance> getInstanceByWeight(List<ServiceInstance> instances) {
        if (instances.isEmpty()) {
            return new EmptyResponse();
        }
        // 计算总权重
        int totalWeight = instances.stream()
                .mapToInt(instance -> {
                    String weightStr = instance.getMetadata().get("weight");
                    return weightStr != null ? Integer.parseInt(weightStr) : 1; // 默认权重为1
                })
                .sum();
        // 生成随机数，根据权重区间选择实例
        int randomWeight = random.nextInt(totalWeight) + 1;
        int currentWeight = 0;
        for (ServiceInstance instance : instances) {
            currentWeight += Integer.parseInt(instance.getMetadata().getOrDefault("weight", "1"));
            if (currentWeight >= randomWeight) {
                return new DefaultResponse(instance);
            }
        }
        return new DefaultResponse(instances.get(0)); // 兜底方案
    }
}

配置自定义策略：
在配置类中定义自定义策略的 Bean，指定其生效范围（全局或特定服务）：

@Configuration
public class CustomLoadBalancerConfig {
    // 全局使用权重策略
    @Bean
    ReactorLoadBalancer<ServiceInstance> weightedLoadBalancer(Environment environment,
                                                             LoadBalancerClientFactory loadBalancerClientFactory) {
        String serviceId = environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);
        return new WeightedLoadBalancer(
            loadBalancerClientFactory.getLazyProvider(serviceId, ServiceInstanceListSupplier.class),
            serviceId
        );
    }
}

2.结合 OpenFeign 使用

        Spring Cloud LoadBalancer 与 OpenFeign 结合使用时，通过简单配置就能实现负载均衡功能，借助 @LoadBalanced 注解开启负载均衡。

1. 引入依赖

在项目的 pom.xml 文件中，引入相关依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-loadbalancer</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

2. 开启 OpenFeign 负载均衡

在启动类上添加 @EnableFeignClients 注解开启 Feign 客户端功能：

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.openfeign.EnableFeignClients;

@SpringBootApplication
@EnableFeignClients
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

        在定义的 Feign 客户端接口中，通过指定服务名来调用服务，Spring Cloud LoadBalancer 会自动从注册中心获取服务实例并进行负载均衡：

import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;

@FeignClient(name = "target-service") // target-service是目标服务在注册中心的名称
public interface TargetServiceFeignClient {

    @GetMapping("/api/{id}")
    String getServiceData(@PathVariable("id") Long id);
}

        上述代码中，@FeignClient 注解的 name 属性指定了要调用的服务名称，Spring Cloud LoadBalancer 会根据这个名称从注册中心获取该服务的实例列表，并按照默认的轮询策略或者自定义的负载均衡策略选择一个实例进行调用。

六、熔断与限流 Sentinel

1.服务雪崩

服务雪崩是指一个服务的失败导致整个链路的服务相继失败。

        解决服务雪崩的核心思路是熔断、降级、限流，通过隔离故障、控制流量防止故障扩散，同时保障核心业务可用。Spring Cloud Alibaba 中主要通过 Sentinel 或 Resilience4j 实现。

2.sentinel整合

引入sentinel依赖：

<!--sentinel-->
<dependency>
    <groupId>com.alibaba.cloud</groupId> 
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

配置控制台：

修改application.yaml文件，添加下面内容：

spring:
  cloud:
    sentinel:
      transport:
        dashboard: localhost:8090
      http-method-specify: true # 开启请求方式前缀

2.1 服务熔断

        当被调用的服务连续失败次数达到阈值时，主动切断调用链路，避免无效等待消耗资源，同时快速返回降级响应。待被调用服务恢复后，再逐步恢复调用。

工作原理：类似电路保险丝，有三种状态：

• 闭合（Closed）：正常调用，记录失败次数，失败率超阈值则切换到 “打开” 状态。
• 打开（Open）：拒绝所有调用，直接返回降级结果，经过一段 “休眠时间” 后进入 “半打开” 状态。
• 半打开（Half-Open）：允许少量请求尝试调用，若成功则切换到 “闭合” 状态，否则回到 “打开” 状态。

Sentinel 实现：通过配置熔断规则（如异常比例、慢调用比例）自动触发熔断。

2.2 服务降级

        当服务压力过大或依赖服务故障时，牺牲非核心功能，保障核心功能可用（如返回缓存数据、默认值或简化逻辑）。降级是熔断的补充，更侧重于主动放弃部分功能以保整体稳定。

常见场景：

• 秒杀活动中，非核心接口（如商品详情评论）降级为返回缓存数据，保障下单接口可用。
• 依赖服务超时，直接返回本地默认数据（如 “推荐商品暂时无法加载”）。

Sentinel 实现：使用FallbackFactory给FeignClient编写失败后的降级逻辑。

实现FallbackFactory 接口，定义降级处理类：

@Slf4j
public class ItemClientFallback implements FallbackFactory<ItemClient> {
    @Override
    public ItemClient create(Throwable cause) {
        return new ItemClient() {
            @Override
            public List<ItemDTO> queryItemByIds(Collection<Long> ids) {
                log.error("远程调用ItemClient#queryItemByIds方法出现异常，参数：{}", ids, cause);
                // 查询购物车允许失败，查询失败，返回空集合
                return CollUtils.emptyList();
            }

            @Override
            public void deductStock(List<OrderDetailDTO> items) {
                // 库存扣减业务需要触发事务回滚，查询失败，抛出异常
                throw new BizIllegalException(cause);
            }
        };
    }
}

注册Bean：

@Configuration
public class DefaultFeignConfig {

    @Bean
    public ItemClientFallBack itemClientFallBack(){
        return new ItemClientFallBack();
    }
}

使用ItemClientFallbackFactory：

@FeignClient(value = "item-service",fallbackFactory = ItemClientFallBack.class)
public interface ItemClient {
    // openfeign会自动向item-service/items接口发起请求
    @GetMapping("/items")
    public List<ItemDTO> queryItemByIds(@RequestParam("ids") Collection<Long> ids);

    @PutMapping("/items/stock/deduct")
    public void deductStock(@RequestBody List<OrderDetailDTO> items);
}

2.3 服务限流

        限制单位时间内的请求数量，防止流量突增压垮服务（从源头控制负载，避免服务进入过载状态）。

常见策略：

• 基于 QPS 限流：每秒最多处理 100 个请求。
• 基于线程数限流：最多同时处理 50 个并发请求。

Sentinel 实现：通过控制台配置限流规则，超出阈值的请求直接被拦截并返回降级响应：

这样就把查询购物车列表这个簇点资源的流量限制在了每秒6个，也就是最大QPS为6。

最终监控结果如下：

2.4 资源隔离

        将不同服务的调用隔离在独立的资源池（如线程池、信号量）中，避免单个服务故障耗尽全局资源。

        限流可以降低服务器压力，尽量减少因并发流量引起的服务故障的概率，但并不能完全避免服务故障。一旦某个服务出现故障，我们必须隔离对这个服务的调用，避免发生雪崩。

        比如，查询购物车的时候需要查询商品，为了避免因商品服务出现故障导致购物车服务级联失败，我们可以把购物车业务中查询商品的部分隔离起来，限制可用的线程资源：

Sentinel 实现：

开启Feign的sentinel功能：

feign:
  sentinel:
    enabled: true # 开启feign对sentinel的支持

配置线程隔离：

        这里勾选的是并发线程数限制，也就是说这个查询功能最多使用5个线程，而不是5QPS。如果查询商品的接口每秒处理2个请求，则5个线程的实际QPS在10左右，而超出的请求自然会被拒绝。

七、分布式事务 Seata

        Seata 是阿里巴巴开源的分布式事务解决方案，专注于微服务架构下的分布式事务一致性问题，支持多种事务模式，易用性高且性能优异。

1.Seata架构

• TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。

• TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。

• RM (Resource Manager) - 资源管理器：管理分支事务，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

2.Seata 支持的事务模式

2.1 AT 模式（Auto Transaction）

特点：无侵入式（无需修改业务代码），基于本地事务 + 全局锁实现，适合大多数场景。

工作流程：

• 阶段一（本地事务提交）：

  1. 注册分支事务。
  2. 记录undo_log。
  3. 执行业务SQL并提交。
  4. 汇报执行状态。

• 阶段二（全局事务提交 / 回滚）：

  • 提交：TC 通知所有 RM 删除 undo_log。
  • 回滚：TC 通知 RM 基于 undo_log 执行回滚，恢复数据到修改前状态，再删除 undo_log。

适用场景：非高并发、对代码侵入性要求低的场景（如电商下单、支付流程）。

2.2 XA 模式

特点：基于数据库的 XA 协议（强一致性），支持多数据源，但性能较差。

工作流程：

• 阶段一：

  1. RM注册分支事务到TC。

  2. RM执行分支业务sql但不提交。

  3. RM报告执行状态到TC。

• 阶段二：

  • TC检测各分支事务执行状态。

    1. 如果都成功，通知所有RM提交事务。

    2. 如果有失败，通知所有RM回滚事务。

  • 接收TC指令，提交或回滚事务。

适用场景：对一致性要求极高但可接受性能损耗的场景（如银行核心系统）。

2.3 TCC 模式（Try-Confirm-Cancel）

特点：手动编码实现，性能高但开发成本高，适合高并发场景。

核心步骤：

• Try：资源检查与预留（如冻结库存，避免其他事务占用）。
• Confirm：确认执行业务（如实际扣减库存），仅在所有分支 Try 成功后执行。
• Cancel：取消操作（如解冻库存），当某分支 Try 失败时执行。

工作流程：

1. TM 发起全局事务，调用各服务的 Try 方法。
2. 若所有 Try 成功，TC 通知各服务执行 Confirm；若任一 Try 失败，通知执行 Cancel。

适用场景：高并发、核心业务（如秒杀、金融交易），需开发者手动实现 Try/Confirm/Cancel 逻辑。

2.4 SAGA 模式

特点：长事务解决方案，基于状态机或补偿事务实现，适合业务流程长、异步化的场景。

工作流程：

• 定义事务流程中的每个步骤及对应的补偿操作（如订单创建 → 支付 → 发货，补偿操作则是发货撤销 → 退款 → 订单取消）。
• 若流程正常执行，完成事务；若某步骤失败，按逆序执行补偿操作。

适用场景：跨多个微服务的长流程业务（如供应链管理、物流跟踪）。

3.四种模式对比

八、相关面试问题

1.Spring Cloud Alibaba 核心组件有哪些？

        Spring Cloud Alibaba 核心组件覆盖了微服务框架中的服务注册发现、配置中心、服务调用、负载均衡、熔断限流和网关等关键场景，有以下几种核心组件：

        服务注册和配置中心：Nacos。

        服务调用：openfeign和dubbo。

        负责均衡：Spring Cloud LoadBalancer 。

        熔断与限流：Sentinel。

        API网关：Spring Cloud Gateway。

       分布式事务：Seata。

2.服务注册和发现是什么意思？Spring Cloud 如何实现服务注册发现？

        服务注册与发现主要包含三个核心功能：服务注册、服务发现和服务状态监控。

        我最常使用的服务注册中心是Nacos，它的工作流程主要分为三个阶段：

        服务注册阶段：服务提供者将自己的信息注册到nacos中。

        服务发现阶段：服务消费者从nacos中获取服务列表信息，并根据负载均衡算法选择一个服务进行调用。

        服务监听阶段：有两种策略：临时实例和非临时实例。临时实例是指：服务提供者主动向nacos发送心跳以检测健康状态，nacos若超时未收到则认为不健康，会从服务列表中剔除该服务。非临时实例是指nacos会主动检测服务状态而不是依靠心跳。

3.OpenFeign 与 Dubbo 有什么区别？

        OpenFeign 和 Dubbo 都是微服务架构中用于服务间通信的框架：

        首先，openfeign是基于HTTP的声明式REST客户端，而dubbo是基于二进制协议（Dubbo协议）的高性能RPC（远程过程调用）框架。

        其次，openfeign依赖于springcloud生态，而dubbo内置完整的服务治理。

        最后，openfeign适用于简单的微服务架构，尤其是需要跨语言通信、与 Spring Cloud 生态深度绑定的场景。而dubbo适用于对性能要求高、服务治理复杂的内部微服务场景。

4.Gateway核心组件有哪些？

        Gateway的核心组件有：路由、断言、过滤器。

        路由是网关的基本单位，包含全局唯一ID、目标URL、断言集合和过滤器其集合。

        断言即匹配条件，用于将满足条件的请求路由到目标URL上。

        过滤器用于拦截加工请求响应。

5.请你简单说一下Gateway的工作流程？

        Gateway的工作流程如下：

        首先，前端发送请求给Gateway网关，网关上下午接收到请求并传递给请求分发处理器DispatcherHandler.

        其次，DispatcherHandler分发请求处理器到相应的路由断言处理器中。

        然后，路由断言处理器匹配请求是否符合条件，符合则传递请求到过滤器链中。

        最后，请求先经过过滤器链的前置过滤器，到达目标服务，服务处理完成再进过过滤器链的后置过滤器返回响应。

6.Spring Cloud的负载均衡负载均衡策略有哪些？

        在Spring Cloud20x版本之后底层的负载均衡策略主要就是Spring Cloud LoadBalancer。

        主要有四种负载均衡策略：

        轮询策略：这也是默认的策略。

        随机策略：随机选择服务。

        加权策略：为每个服务实例分配一个权重值，权重越高，表示该实例被选中处理请求的概率越大。

        自定义负载均衡策略：需要实现ReactorLoadBalancer接口，重写方法，并在配置类中配置生效范围。

7.什么是服务雪崩，怎么解决这个问题？

        服务雪崩是指一个服务的失败导致整个链路的其他服务相续失败，我们通常使用服务熔断和服务降级来解决：

        服务熔断：当调用请求失败率达到阈值后，触发熔断机制，防止系统过载。

        服务降级：当请求量突增时，降低服务的级别，保证核心服务的使用。

8.Seata 的三大角色及其作用？

        Seata架构三大核心角色分别为：TC、TM和RM。

        TC事物协调者，负责维护全局和分支事物状态，协调全局事物提交或回滚。

        TM事物管理器，定义全局事物范围，开始全局事物，提交或回滚全局事物。

        RM资源管理器，管理分支事物，与TC交谈注册分支事务和报告分支事务的状态，驱动分支事务回滚。

9.Seata 如何保证分布式事务的一致性？

        Seata 保证分布式事务一致性的核心逻辑是通过TC、TM和RM的协同，结合不同事务模式的特定机制，最终实现数据的一致性。

        首先AT模式基于本地事务 + undo_log + 全局锁，所有分支事务要么全部成功，要么全部回滚，实现数据的最终一致性。

        其次XT模式依赖数据库 XA 协议，所有分支要么同时提交，要么同时回滚，实现强一致性。

        然后TCC模式通过预留资源 + 确认 / 取消，确保只有所有分支都能成功时才提交业务，否则全部回滚，实现强一致性（无中间状态）。

        最后SAGA 模式通过 “正向执行 + 反向补偿”，即使中间步骤失败，也能通过补偿回到初始状态，实现最终一致性。