微服务

踩坑总结

Mybatis-PLUS

分页不生效，因为mybatis-plus自3.5.9起，默认不包含分页插件，需要自己引入。

<dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>com.baomidou</groupId>
                <artifactId>mybatis-plus-bom</artifactId>
                <version>3.5.9</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
       </dependencies>
</dependencyManagement>

<!-- MyBatis Plus 分页插件 -->
<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-jsqlparser-4.9</artifactId>
</dependency>

config包下新建：

@Configuration
@MapperScan("edu.whut.smilepicturebackend.mapper")
public class MybatisPlusConfig {

    /**
     * 拦截器配置
     *
     * @return {@link MybatisPlusInterceptor}
     */
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        // 分页插件
        interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));
        return interceptor;
    }
}

雪花算法表示精度问题

“雪花算法”（Snowflake）生成的 ID 本质上是一个 64 位的整数（Java等后端里通常对应 long ），而浏览器端的 JavaScript Number 类型只能安全地表示到 2^53−1 以内的整数，超出这个范围就会出现 “精度丢失”──即低位那几位数字可能会被四舍五入掉，导致 ID 读取或比对出错。因此，最佳实践是：

1. 后端依然用 long（或等价的 64 位整数）存储和处理雪花 ID。
2. 对外接口（REST/graphQL 等）返回时，将这类超出 JS 安全范围的整数序列化为字符串，比如：

@Configuration
public class JacksonConfig {

    private static final String DATE_FORMAT     = "yyyy-MM-dd";
    private static final String DATETIME_FORMAT = "yyyy-MM-dd HH:mm:ss";
    private static final String TIME_FORMAT     = "HH:mm:ss";

    @Bean
    public Jackson2ObjectMapperBuilderCustomizer jacksonCustomizer() {
        return builder -> {
            // 将所有 long / Long 类型序列化成 String
            SimpleModule longToString = new SimpleModule();
            longToString.addSerializer(Long.class,   ToStringSerializer.instance);
            longToString.addSerializer(Long.TYPE,    ToStringSerializer.instance);
            builder.modules(longToString);
        };
    }
}

包扫描问题（非常容易出错！）

以 Spring Boot 为例，框架默认会扫描启动类所在包及其子包中的组件（@Component/@Service/@Repository/@Configuration 等），将它们注册到 Spring 容器中。

问题：当你把某些业务组件、配置类或第三方模块放在了启动类的同级或平级包下（而非子包），却没有手动指定扫描路径，就会出现 “无法注入 Bean” 的情况。

// 启动类
@SpringBootApplication
public class OrderServiceApplication { … }

// 业务类位于 com.example.common 包
@Service
public class PaymentClient { … }

如果项目结构是：

com.example.orderservice   ← 启动类
com.example.common         ← 依赖组件

默认情况下 com.example.common 不会被扫描到，导致注入 PaymentClient 时抛出 NoSuchBeanDefinitionException。

解决方案：

1）显式指定扫描路径**：

@SpringBootApplication
@ComponentScan(basePackages = {
  "com.example.orderservice",
  "com.example.common"
})
public class OrderServiceApplication { … }

2）使用 @Import 或者 Spring Cloud 的自动配置机制（如编写 spring.factories，让依赖模块自动装配）。

数据库连接池

为什么需要？

每次通过 JDBC 调用 DriverManager.getConnection(...)，都要完成网络握手、权限验证、初始化会话等大量开销，通常耗时在几十到几百毫秒不等。连接池通过提前建立好 N 条物理连接并在应用各处循环复用，避免了反复的开销。

流程

数据库连接池在应用启动时预先创建一定数量的物理连接，并将它们保存在空闲队列中；当业务需要访问数据库时，直接从池中“借用”一个连接（无需新建），用完后调用 close() 即把它归还池中；池会根据空闲超时或最大寿命策略自动回收旧连接，并在借出或定期扫描时执行简单心跳（如 SELECT 1）来剔除失效连接，确保始终有可用、健康的连接供高并发场景下快速复用。

┌─────────────────────────────────────────┐
│         应用线程 A 调用 getConnection()          │
│ ┌──────────┐            ┌─────────────┐   │
│ │  空闲连接队列  │──取出──▶│  物理连接  │───┐│
│ └──────────┘            └─────────────┘   ││
│                （代理包装）                   ││
│           返回代理连接给业务代码               ││
└─────────────────────────────────────────┘ │
                                           │
┌─────────────────────────────────────────┐ │
│         业务执行 SQL，最后调用 close()           │
│ ┌───────────────┐        ┌────────────┐       │
│ │  代理 Connection  │──归还──▶│ 空闲连接队列  │◀─────┘
│ └───────────────┘        └────────────┘
└─────────────────────────────────────────┘

当你从连接池里拿到一个底层已被远程关闭的连接时，HikariCP（以及大多数成熟连接池）会在“借出”前先做一次简易校验（默认为 Connection.isValid()，或你配置的 connection-test-query）。如果校验失败，连接池会自动将这条“死”连接销毁，并尝试从池里或新建一个新的物理连接来替换，再把新的健康连接返给业务；只有当新的连接也创建或校验失败到达池的最大重试次数时，才会抛出拿不到连接的超时异常。

遇到的问题

如果本地启动了 Java 应用和前端 Nginx，而 MySQL 部署在远程服务器上，Java 应用通过连接池与远程数据库建立的 TCP 连接在 5 分钟内若无任何 SQL 操作，就会因中间网络设备（如 NAT、负载均衡器、防火墙）超时断开，且应用层不会主动感知，导致后续 SQL 请求失败。

13:20:01:383  WARN 43640 --- [nio-8084-exec-4] com.zaxxer.hikari.pool.PoolBase          : HikariPool-1 - Failed to validate connection com.mysql.cj.jdbc.ConnectionImpl@36e971ae (No operations allowed after connection closed.). Possibly consider using a shorter maxLifetime value.
13:20:01:384 ERROR 43640 --- [nio-8084-exec-4] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is org.mybatis.spring.MyBatisSystemException: nested exception is org.apache.ibatis.exceptions.PersistenceException: 
### Error querying database.  Cause: org.springframework.jdbc.CannotGetJdbcConnectionException: Failed to obtain JDBC Connection; nested exception is java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30048ms.

为了解决这个问题，

1.只需在 Spring Boot 配置中为 HikariCP 添加定期心跳，让连接池在真正断连前保持流量：

spring:
  datasource:
    hikari:
      keepalive-time: 180000      # 3 分钟发送一次心跳（维持 TCP 活跃）

这样，HikariCP 会每隔 3 分钟自动对空闲连接执行轻量级的验证操作（如 Connection.isValid()），确保中间网络链路不会因长时间静默而被强制关闭。

2.如果JAVA应用和Mysql在同一服务器上（可互通），就不会有上述问题！

Sentinel无数据

sentinel 控制台可以发现哪些微服务连接了，但是Dashboard 在尝试去拿各个微服务上报的规则（端点 /getRules）和指标（端点 /metric）时，一直连不上它们，因为JAVA微服务是在本地私网内部署的，Dashboard无法连接上。

Failed to fetch metric from http://192.168.0.107:8725/metric?…
Failed to fetch metric from http://192.168.0.107:8721/metric?…
HTTP request failed: http://192.168.0.107:8721/getRules?type=flow
java.net.ConnectException: Operation timed out

解决办法：

1.将JAVA应用部署到服务器，但我的服务器内存不够

2.将Dashboard部署到本机docker中，和JAVA应用可互通。

Nacos迁移后的 No DataSource set

原本Nacos和Mysql都是部署到公网服务器，mysql容器对外暴露3307，因此Nacos的env文件中可以是：

MYSQL_SERVICE_DB_NAME=124.xxx.xxx.xxx
MYSQL_SERVICE_PORT=3307

填的mysql的公网ip，以及它暴露的端口3307，这是OK的

但是如果将它们部署在docker同一网络中，应该这样写：

MYSQL_SERVICE_DB_NAME=mysql
MYSQL_SERVICE_PORT=3306

mysql是服务名，不能写localhost（或 127.0.0.1），它永远只会指向「当前容器自己」！！！

注意，Nacos中的配置文件也要迁移过来，导入nacos配置列表中，并且修改JAVA项目中nacos的地址

Docker Compose问题

1）如果你把某个服务从 docker-compose.yml 里删掉，然后再执行：

docker compose down

默认情况下 并不会 停止或删除那个已经“离开”了 Compose 配置的容器。

只能：

docker compose down --remove-orphans  #清理这些“孤儿”容器

或者手动清理：

docker ps   #列出容器
docker stop <container_id_or_name>   
docker rm   <container_id_or_name>

2）端口占用问题

Error response from daemon: Ports are not available: exposing port TCP 0.0.0.0:5672 -> 0.0.0.0:0: listen tcp 0.0.0.0:5672: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

先查看是否端口被占用：

netstat -aon | findstr 5672

如果没有被占用，那么就是windows的bug，在CMD使用管理员权限重启NAT网络服务即可

net stop winnat
net start winnat

3）ip地址问题

seata-server:
    image: seataio/seata-server:1.5.2
    container_name: seata-server
    restart: unless-stopped
    depends_on:
      - mysql
      - nacos
    environment:
      # 指定 Seata 注册中心和配置中心地址
      - SEATA_IP=192.168.10.218       # IDEA 可以访问到的宿主机 IP
      - SEATA_SERVICE_PORT=17099
      - SEATA_CONFIG_TYPE=file
      # 可视情况再加：SEATA_NACOS_SERVER_ADDR=nacos:8848
    networks:
      - hmall-net
    ports:
      - "17099:7099"   # TC 服务端口
      - "8099:8099"   # 服务管理端口（Console）
    volumes:
      - ./seata:/seata-server/resources

SEATA_IP配置的是宿主机IP，你的电脑换了IP，如从教室到寝室，那这里的IP也要跟着变：ipconfig查看宿主机ip

认识微服务

微服务架构，首先是服务化，就是将单体架构中的功能模块从单体应用中拆分出来，独立部署为多个服务。

SpringCloud

使用Spring Cloud 2021.0.x以及Spring Boot 2.7.x版本（需要对应）。

在父pom中的<dependencyManagement>锁定版本，使得后续你在子模块里引用 Spring Cloud 或 Spring Cloud Alibaba 的各个组件时，不需要再写 <version>，Maven 会统一采用你在父 POM 中指定的版本。

微服务拆分

微服务拆分时：

• 高内聚：每个微服务的职责要尽量单一，包含的业务相互关联度高、完整度高。
• 低耦合：每个微服务的功能要相对独立，尽量减少对其它微服务的依赖，或者依赖接口的稳定性要强。

一般微服务项目有两种不同的工程结构：

• 完全解耦：每一个微服务都创建为一个独立的工程，甚至可以使用不同的开发语言来开发，项目完全解耦。
  • 优点：服务之间耦合度低
  • 缺点：每个项目都有自己的独立仓库，管理起来比较麻烦
• Maven聚合：整个项目为一个Project，然后每个微服务是其中的一个Module
  • 优点：项目代码集中，管理和运维方便
  • 缺点：服务之间耦合，编译时间较长

，每个模块都要有：pom.xml application.yml controller service mapper pojo 启动类

IDEA配置小技巧：

1.自动导包

2.配置service窗口，以显示多个微服务启动类

3.如何在idea中虚拟多服务负载均衡?

More options->Add VM options -> -Dserver.port=xxxx

这边设置不同的端口号！

服务注册和发现

注册中心、服务提供者、服务消费者三者间关系如下：

流程如下：

• 服务启动时就会注册自己的服务信息（服务名、IP、端口）到注册中心
• 调用者可以从注册中心订阅想要的服务，获取服务对应的实例列表（1个服务可能多实例部署）
• 调用者自己对实例列表负载均衡，挑选一个实例
• 调用者向该实例发起远程调用

当服务提供者的实例宕机或者启动新实例时，调用者如何得知呢？

• 服务提供者会定期向注册中心发送请求，报告自己的健康状态（心跳请求）
• 当注册中心长时间收不到提供者的心跳时，会认为该实例宕机，将其从服务的实例列表中剔除
• 当服务有新实例启动时，会发送注册服务请求，其信息会被记录在注册中心的服务实例列表
• 当注册中心服务列表变更时，会主动通知微服务，更新本地服务列表（防止服务调用者继续调用挂逼的服务）

Nacos部署：

1.依赖mysql中的一个数据库 ，可由nacos.sql初始化

2.需要.env文件，配置和数据库的连接信息：

PREFER_HOST_MODE=hostname
MODE=standalone
SPRING_DATASOURCE_PLATFORM=mysql
MYSQL_SERVICE_HOST=124.71.159.***
MYSQL_SERVICE_DB_NAME=nacos
MYSQL_SERVICE_PORT=3307
MYSQL_SERVICE_USER=root
MYSQL_SERVICE_PASSWORD=*******
MYSQL_SERVICE_DB_PARAM=characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Shanghai

3.docker部署：

nacos:
    image: nacos/nacos-server:v2.1.0
    container_name: nacos-server
    restart: unless-stopped
    env_file:
      - ./nacos/custom.env         # 自定义环境变量文件
    ports:
      - "8848:8848"               # Nacos 控制台端口
      - "9848:9848"				# RPC 通信端口 (TCP 长连接/心跳)
      - "9849:9849"    	 		# gRPC 通信端口
    networks:
      - hm-net
    depends_on:
      - mysql
    volumes:
      - ./nacos/init.d:/docker-entrypoint-init.d  # 如果需要额外初始化脚本，可选

启动完成后，访问地址：http://ip:8848/nacos/

初始账号密码都是nacos

服务注册

1.在item-service的pom.xml中添加依赖：

<!--nacos 服务注册发现-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

2.配置Nacos

在item-service的application.yml中添加nacos地址配置：

spring:
  application:
    name: item-service   #服务名
  cloud:
    nacos:
      server-addr: 124.71.159.***:8848 # nacos地址

注意，服务注册默认连9848端口！云服务需要开启该端口！

配置里的item-service就是服务名！

服务发现

前两步同服务注册

3.通过DiscoveryClient发现服务实例列表，然后通过负载均衡算法，选择一个实例去调用

discoveryClient发现服务 + restTemplate远程调用

@Service
public class CartServiceImpl {

    @Autowired
    private DiscoveryClient discoveryClient;    // 注入 DiscoveryClient

    @Autowired
    private RestTemplate restTemplate;          // 用于发 HTTP 请求

    private void handleCartItems(List<CartVO> vos) {
        // 1. 获取商品 id 列表
        Set<Long> itemIds = vos.stream()
                                .map(CartVO::getItemId)
                                .collect(Collectors.toSet());

        // 2.1. 发现 item-service 服务的实例列表
        List<ServiceInstance> instances = discoveryClient.getInstances("item-service");

        // 2.2. 负载均衡：随机挑选一个实例
        ServiceInstance instance = instances.get(
            RandomUtil.randomInt(instances.size())
        );

        // 2.3. 发送请求，查询商品详情
        String url = instance.getUri().toString() + "/items?ids={ids}";
        ResponseEntity<List<ItemDTO>> response = restTemplate.exchange(
            url,
            HttpMethod.GET,
            null,
            new ParameterizedTypeReference<List<ItemDTO>>() {},
            String.join(",", itemIds)
        );

        // 2.4. 处理结果
        if (response.getStatusCode().is2xxSuccessful()) {
            List<ItemDTO> items = response.getBody();
            // … 后续处理 …
        } else {
            throw new RuntimeException("查询商品失败: " + response.getStatusCode());
        }
    }
}

OpenFeign

让远程调用像本地方法调用一样简单

快速入门

1.引入依赖

  <!--openFeign-->
  <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-openfeign</artifactId>
  </dependency>
  <!--负载均衡器-->
  <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-loadbalancer</artifactId>
  </dependency>

2.启用OpenFeign

在服务调用者cart-service的CartApplication启动类上添加注解:

@EnableFeignClients

3.编写OpenFeign客户端

在cart-service中，定义一个新的接口，编写Feign客户端：

@FeignClient("item-service")
public interface ItemClient {

    @GetMapping("/items")
    List<ItemDTO> queryItemByIds(@RequestParam("ids") Collection<Long> ids);
}

queryItemByIds这个方法名可以随便取，但@GetMapping("/items") 和 @RequestParam("ids") 要跟 item-service 服务中实际暴露的接口路径和参数名保持一致（直接参考服务提供者的Controller层对应方法对应即可）；

一个客户端对应一个服务，可以在ItemClient里面写多个方法。

4.使用

List<ItemDTO> items = itemClient.queryItemByIds(Arrays.asList(1L, 2L, 3L));

Feign 会帮你把 ids=[1,2,3] 序列化成一个 HTTP GET 请求，URL 形如：

GET http://item-service/items?ids=1&ids=2&ids=3

连接池

Feign底层发起http请求，依赖于其它的框架。其底层支持的http客户端实现包括：

• HttpURLConnection：默认实现，不支持连接池
• Apache HttpClient ：支持连接池
• OKHttp：支持连接池

这里用带有连接池的HttpClient 替换默认的

1.引入依赖

<dependency>
  <groupId>io.github.openfeign</groupId>
  <artifactId>feign-httpclient</artifactId>
</dependency>

2.开启连接池

feign:
  httpclient:
    enabled: true   # 使用 Apache HttpClient（默认关闭）

重启服务，连接池就生效了。

最佳实践

如果拆分了交易微服务（trade-service），它也需要远程调用item-service中的根据id批量查询商品功能。这个需求与cart-service中是一样的。那么会再次定义ItemClient接口导致重复编程。

• 思路1：抽取到微服务之外的公共module，需要调用client就引用该module的坐标。

• 思路2：每个微服务自己抽取一个module，比如item-service，将需要共享的domain实体放在item-dto模块，需要供其他微服务调用的cilent放在item-api模块，自己维护自己的，然后其他微服务引入maven坐标直接使用。

大型项目思路2更清晰、更合理。但这里选择思路1，方便起见。

拆分之后重启报错：Parameter 0 of constructor in com.hmall.cart.service.impl.CartServiceImpl required a bean of type 'com.hmall.api.client.ItemClient' that could not be found.

是因为：Feign Client 没被扫描到，Spring Boot 默认只会在主应用类所在包及其子包里扫描 @FeignClient。

需要额外设置basePackages

package com.hmall.cart;
@MapperScan("com.hmall.cart.mapper")
@EnableFeignClients(basePackages= "com.hmall.api.client")
@SpringBootApplication
public class CartApplication {
    public static void main(String[] args) {
        SpringApplication.run(CartApplication.class, args);
    }
}

网关

在微服务拆分后的联调过程中，经常会遇到以下问题：

• 不同业务数据分布在各自微服务，需要维护多套地址和端口，调用繁琐且易错；
• 前端无法直接访问注册中心（如 Nacos），无法实时获取服务列表，导致接口切换不灵活。

此外，单体架构下只需完成一次登录与身份校验，所有业务模块即可共享用户信息；但在微服务架构中：

• 每个微服务是否都要重复实现登录校验和用户信息获取？
• 服务间调用时，如何安全、可靠地传递用户身份？

通过引入 API 网关，我们可以在统一入口处解决以上问题：它提供动态路由与负载均衡，前端只需调用一个地址；它与注册中心集成，实时路由调整；它还在网关层集中完成登录鉴权和用户信息透传，下游服务无需重复实现安全逻辑。

快速入门

网关本身也是一个独立的微服务，因此也需要创建一个模块开发功能。大概步骤如下：

• 创建网关微服务
• 引入SpringCloudGateway、NacosDiscovery依赖
• 编写启动类
• 配置网关路由

1.依赖引入：

<!-- 网关 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>

<!-- Nacos Discovery -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

<!-- 负载均衡 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-loadbalancer</artifactId>
</dependency>

2.配置网关路由

id：给这条路由起个唯一的标识，方便你在日志、监控里看是哪个规则。(最好和服务名一致)

uri: lb://xxx：xxx 必须和服务注册时的名字一模一样（比如 Item-service 或全大写 ITEM-SERVICE，取决于你在微服务启动时 spring.application.name 配置）

server:
  port: 8080
spring:
  application:
    name: gateway
  cloud:
    nacos:
      server-addr: 192.168.150.101:8848
    gateway:
      routes:
        - id: item # 路由规则id，自定义，唯一
          uri: lb://item-service # 路由的目标服务，lb代表负载均衡，会从注册中心拉取服务列表
          predicates: # 路由断言，判断当前请求是否符合当前规则，符合则路由到目标服务
            - Path=/items/**,/search/** # 支持多个路径模式，用逗号隔开
        - id: cart
          uri: lb://cart-service
          predicates:
            - Path=/carts/**
        - id: user
          uri: lb://user-service
          predicates:
            - Path=/users/**,/addresses/**
        - id: trade
          uri: lb://trade-service
          predicates:
            - Path=/orders/**
        - id: pay
          uri: lb://pay-service
          predicates:
            - Path=/pay-orders/**

predicates：路由断言，其实就是匹配条件

如果（predicates）符合这些规则，就把请求送到（uri）这里去。

Ant风格路径

用来灵活地匹配文件或请求路径：

?：匹配单个字符（除了 /）。

• 例如，/user/??/profile 能匹配 /user/ab/profile，但不能匹配 /user/a/profile 或 /user/abc/profile。

*：匹配任意数量的字符（零 个或 多个），但不跨越路径分隔符 /。

• 例如，/images/*.png 能匹配 /images/a.png、/images/logo.png，却不匹配 /images/icons/logo.png。

**：匹配任意层级的路径（可以跨越多个 /）。

• 例如，/static/** 能匹配 /static/、/static/css/style.css、/static/js/lib/foo.js，甚至 /static/a/b/c/d。

AntPathMatcher 是 Spring Framework 提供的一个工具类，用来对“Ant 风格”路径模式做匹配

@Component
@ConfigurationProperties(prefix = "auth")
public class AuthProperties {
    private List<String> excludePaths;
    // getter + setter
}

@Component
public class AuthInterceptor implements HandlerInterceptor {
    private final AntPathMatcher pathMatcher = new AntPathMatcher();
    private final List<String> exclude;

    public AuthInterceptor(AuthProperties props) {
        this.exclude = props.getExcludePaths();
    }

    @Override
    public boolean preHandle(HttpServletRequest req,
                             HttpServletResponse res,
                             Object handler) {
        String path = req.getRequestURI(); // e.g. "/search/books/123"

        // 检查是否匹配任何一个“放行”模式
        for (String pattern : exclude) {
            if (pathMatcher.match(pattern, path)) {
                return true;  // 放行，不做 auth
            }
        }

        // 否则执行认证逻辑
        // ...
        return false;
    }
}

当然

predicates:
   - Path=/users/**,/addresses/**

这里不需要手写JAVA逻辑进行路径匹配，因为Gateway自动实现了。但是后面自定义Gateway过滤器的时候就需要AntPathMatcher了！

登录校验

我们需要实现一个网关过滤器，有两种可选：

• GatewayFilter：路由过滤器，作用范围比较灵活，可以是任意指定的路由Route.
• GlobalFilter：全局过滤器，作用范围是所有路由，不可配置。

网关需要实现两个功能：1.JWT校验 2.将用户信息传递给微服务

网关校验+存用户信息

@Component
@RequiredArgsConstructor
@EnableConfigurationProperties(AuthProperties.class)
public class AuthGlobalFilter implements GlobalFilter, Ordered {

    private final JwtTool jwtTool;

    private final AuthProperties authProperties;

    private final AntPathMatcher antPathMatcher = new AntPathMatcher();

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // 1.获取Request
        ServerHttpRequest request = exchange.getRequest();
        // 2.判断是否不需要拦截
        if(isExclude(request.getPath().toString())){
            // 无需拦截，直接放行
            return chain.filter(exchange);
        }
        // 3.获取请求头中的token
        String token = null;
        List<String> headers = request.getHeaders().get("authorization");
        if (!CollUtils.isEmpty(headers)) {
            token = headers.get(0);
        }
        // 4.校验并解析token
        Long userId = null;
        try {
            userId = jwtTool.parseToken(token);
        } catch (UnauthorizedException e) {
            // 如果无效，拦截
            ServerHttpResponse response = exchange.getResponse();
            response.setRawStatusCode(401);
            return response.setComplete();
        }

        // 5.如果有效，传递用户信息
        String userInfo = userId.toString();
        ServerWebExchange modifiedExchange = exchange.mutate()
                .request(builder -> builder.header("user-info", userInfo))
                .build();
        // 6.放行
        return chain.filter(modifiedExchange);
    }

    private boolean isExclude(String antPath) {
        for (String pathPattern : authProperties.getExcludePaths()) {
            if(antPathMatcher.match(pathPattern, antPath)){
                return true;
            }
        }
        return false;
    }

    @Override
    public int getOrder() {
        return 0;
    }
}

• 实现Ordered接口中的 getOrder 方法，数字越小过滤器执行优先级越高。
• exchange 可以获得上下文信息。

拦截器获取用户

在Common模块中设置：

只负责保存 userinfo 到 UserContext ，不负责拦截，因为拦截在前面的过滤器做了。

public class UserInfoInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 1.获取请求头中的用户信息
        String userInfo = request.getHeader("user-info");
        // 2.判断是否为空
        if (StrUtil.isNotBlank(userInfo)) {
            // 不为空，保存到ThreadLocal
            UserContext.setUser(Long.valueOf(userInfo));
        }
        // 3.放行
        return true;
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        // 移除用户
        UserContext.removeUser();
    }
}

配置类：

@Configuration
@ConditionalOnClass(DispatcherServlet.class)
public class MvcConfig implements WebMvcConfigurer {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new UserInfoInterceptor());
    }
}

注意：Spring Boot 只会从主启动类所在的包（及其子包）去扫描组件。 common 包跟 item、cart 等微服务模块是平级的，无法被扫描到。解决方法：

1.在每个微服务的启动类上添加包扫描

@SpringBootApplication(
  scanBasePackages = {"com.hmall.item","com.hmall.common"}
)

主包以及common包

2.在主应用的启动类上用 @Import：

@SpringBootApplication
@Import(com.hmall.common.interceptors.MvcConfig.class)
public class Application { … }

3.前两种方法的问题在于每个微服务模块中都需要写common的引入

因此可以把common 模块做成 Spring Boot 自动配置

1）在common/src/main/resources/META-INF/spring.factories 里声明：

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
  com.hmall.common.config.MvcConfig

2）在 common 模块里给 MvcConfig 加上

@Configuration
@ConditionalOnClass(DispatcherServlet.class)  //网关不生效  spring服务生效
public class MvcConfig { … }

3）然后在任何微服务的 pom.xml里只要依赖了这个 common jar，就会自动加载拦截器配置，根本不需要改服务里的 @SpringBootApplication。

OpenFeign传递用户

前端发起的请求都会经过网关再到微服务，微服务可以轻松获取登录用户信息。但是，有些业务是比较复杂的，请求到达微服务后还需要调用其它多个微服务，微服务之间的调用无法传递用户信息，因为不在一个上下文（线程）中！

解决思路：让每一个由OpenFeign发起的请求自动携带登录用户信息。要借助Feign中提供的一个拦截器接口：feign.RequestInterceptor

public class DefaultFeignConfig {
    @Bean
    public RequestInterceptor userInfoRequestInterceptor(){
        return new RequestInterceptor() {
            @Override
            public void apply(RequestTemplate template) {
                // 获取登录用户
                Long userId = UserContext.getUser();
                if(userId == null) {
                    // 如果为空则直接跳过
                    return;
                }
                // 如果不为空则放入请求头中，传递给下游微服务
                template.header("user-info", userId.toString());
            }
        };
    }
}

同时，需要在服务调用者的启动类上添加：

@EnableFeignClients(
  basePackages = "com.hmall.api.client",
  defaultConfiguration = DefaultFeignConfig.class
)
@SpringBootApplication
public class PayApplication {

这样 DefaultFeignConfig.class 会对于所有Client类生效

@FeignClient(value = "item-service",
    configuration = DefaultFeignConfig.class)
public interface ItemClient {
    @GetMapping("/items")
    List<ItemDTO> queryItemByIds(@RequestParam("ids") Collection<Long> ids);
}

这种只对ItemClient生效！

整体流程图

配置管理

微服务共享的配置可以统一交给Nacos保存和管理，在Nacos控制台修改配置后，Nacos会将配置变更推送给相关的微服务，并且无需重启即可生效，实现配置热更新。

配置共享

在nacos控制台的配置管理中添加配置文件

• 数据库ip：通过${hm.db.host:192.168.150.101}配置了默认值为192.168.150.101，同时允许通过${hm.db.host}来覆盖默认值

配置读取流程：

微服务整合Nacos配置管理的步骤如下：

1）引入依赖：

  <!--nacos配置管理-->
  <dependency>
      <groupId>com.alibaba.cloud</groupId>
      <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
  </dependency>
  <!--读取bootstrap文件-->
  <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-bootstrap</artifactId>
  </dependency>

2）新建bootstrap.yaml

在cart-service中的resources目录新建一个bootstrap.yaml文件：

主要给nacos的信息

spring:
  application:
    name: cart-service # 服务名称
  profiles:
    active: dev
  cloud:
    nacos:
      server-addr: 192.168.150.101 # nacos地址
      config:
        file-extension: yaml # 文件后缀名
        shared-configs: # 共享配置
          - dataId: shared-jdbc.yaml # 共享mybatis配置
          - dataId: shared-log.yaml # 共享日志配置
          - dataId: shared-swagger.yaml # 共享日志配置

3）修改application.yaml

server:
  port: 8082
feign:
  okhttp:
    enabled: true # 开启OKHttp连接池支持
hm:
  swagger:
    title: 购物车服务接口文档
    package: com.hmall.cart.controller
  db:
    database: hm-cart

配置热更新

有很多的业务相关参数，将来可能会根据实际情况临时调整，如何不重启服务，直接更改配置文件生效呢？

示例：购物车中的商品上限数量需动态调整。

1）在nacos中添加配置

在nacos中添加一个配置文件，将购物车的上限数量添加到配置中：

文件的dataId格式：

[服务名]-[spring.active.profile].[后缀名]

文件名称由三部分组成：

• 服务名：我们是购物车服务，所以是cart-service
• spring.active.profile：就是spring boot中的spring.active.profile，可以省略，则所有profile共享该配置（不管local还是dev还是prod）
• 后缀名：例如yaml

示例：cart-service.yaml

hm:
  cart:
    maxAmount: 1 # 购物车商品数量上限

2）在微服务中配置

@Data
@Component
@ConfigurationProperties(prefix = "hm.cart")
public class CartProperties {
    private Integer maxAmount;
}

3）下次，只需改nacos中的配置文件 =》发布，即可实现热更新。

动态路由

1.监听Nacos的配置变更

NacosConfigManager可以获取ConfigService 配置信息

String configInfo = nacosConfigManager.getConfigService()

内容是带换行和缩进的 YAML 文本或者 JSON 格式（取决于你的配置文件格式）：

//多条路由
[
  {
    "id": "user-service",
    "uri": "lb://USER-SERVICE",
    "predicates": [
      "Path=/user/**"
    ],
    "filters": [
      "StripPrefix=1"
    ]
  },
  {
    "id": "order-service",
    "uri": "lb://ORDER-SERVICE",
    "predicates": [
      "Path=/order/**"
    ],
    "filters": [
      "StripPrefix=1",
      "AddRequestHeader=X-Order-Source,cloud"
    ]
  }
]

因为YAML格式解析不方便，故配置文件采用 JSON 格式保存、读取、解析！

String getConfigAndSignListener(
    String dataId, // 配置文件id
    String group, // 配置组，走默认
    long timeoutMs, // 读取配置的超时时间
    Listener listener // 监听器
) throws NacosException;

getConfigAndSignListener既可以在第一次读配置文件又可以在后面进行监听

每当 Nacos 上该配置有变更，会触发其内部receiveConfigInfo(...) 方法

2.然后手动把最新的路由更新到路由表中。

RouteDefinitionWriter

public interface RouteDefinitionWriter {
        /**
     * 更新路由到路由表，如果路由id重复，则会覆盖旧的路由
     */
        Mono<Void> save(Mono<RouteDefinition> route);
        /**
     * 根据路由id删除某个路由
     */
        Mono<Void> delete(Mono<String> routeId);

}

@Slf4j
@Component
@RequiredArgsConstructor
public class DynamicRouteLoader {

    private final RouteDefinitionWriter writer;
    private final NacosConfigManager nacosConfigManager;

    // 路由配置文件的id和分组
    private final String dataId = "gateway-routes.json";
    private final String group = "DEFAULT_GROUP";
    // 保存更新过的路由id
    private final Set<String> routeIds = new HashSet<>();   //order-service ...

    @PostConstruct
    public void initRouteConfigListener() throws NacosException {
        // 1.注册监听器并首次拉取配置
        String configInfo = nacosConfigManager.getConfigService()  
                .getConfigAndSignListener(dataId, group, 5000, new Listener() {
                    @Override
                    public Executor getExecutor() {
                        return null;
                    }

                    @Override
                    public void receiveConfigInfo(String configInfo) {
                        updateConfigInfo(configInfo); 
                    }
                });
        // 2.首次启动时，更新一次配置
        updateConfigInfo(configInfo);
    }

    private void updateConfigInfo(String configInfo) {
        log.debug("监听到路由配置变更，{}", configInfo);
        // 1.反序列化
        List<RouteDefinition> routeDefinitions = JSONUtil.toList(configInfo, RouteDefinition.class);
        // 2.更新前先清空旧路由
        // 2.1.清除旧路由
        for (String routeId : routeIds) {
            writer.delete(Mono.just(routeId)).subscribe();
        }
        routeIds.clear();
        // 2.2.判断是否有新的路由要更新
        if (CollUtils.isEmpty(routeDefinitions)) {
            // 无新路由配置，直接结束
            return;
        }
        // 3.更新路由
        routeDefinitions.forEach(routeDefinition -> {
            // 3.1.更新路由
            writer.save(Mono.just(routeDefinition)).subscribe();
            // 3.2.记录路由id，方便将来删除
            routeIds.add(routeDefinition.getId());
        });
    }
}

可以在项目启动时先更新一次路由，后续随着配置变更通知到监听器，完成路由更新。

服务保护

服务保护方案

1）请求限流

限制或控制接口访问的并发流量，避免服务因流量激增而出现故障。

2）线程隔离

为了避免某个接口故障或压力过大导致整个服务不可用，我们可以限定每个接口可以使用的资源范围，也就是将其“隔离”起来。

3）服务熔断

线程隔离虽然避免了雪崩问题，但故障服务（商品服务）依然会拖慢购物车服务（服务调用方）的接口响应速度。

所以，我们要做两件事情：

• 编写服务降级逻辑：就是服务调用失败后的处理逻辑，根据业务场景，可以抛出异常，也可以返回友好提示或默认数据。
• 异常统计和熔断：统计服务提供方的异常比例，当比例过高表明该接口会影响到其它服务，应该拒绝调用该接口，而是直接走降级逻辑。

无非就是停止无意义的等待，直接返回Fallback方案。

Sentinel

介绍和安装

Sentinel是阿里巴巴开源的一款服务保护框架，quick-start | Sentinel

安装：

1）下载jar包 https://github.com/alibaba/Sentinel/releases

2）将jar包放在任意非中文、不包含特殊字符的目录下，重命名为sentinel-dashboard.jar

然后运行如下命令启动控制台：

java -Dserver.port=8090 -Dcsp.sentinel.dashboard.server=localhost:8090 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard.jar

3）访问http://localhost:8090页面，就可以看到sentinel的控制台了

账号和密码，默认都是：sentinel

微服务整合

1）引入依赖

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

2）配置控制台

修改application.yaml文件（可以用共享配置nacos）,添加如下：

spring:
  cloud: 
    sentinel:
      transport:
        dashboard: localhost:8090

我们的SpringMVC接口是按照Restful风格设计，因此购物车的查询、删除、修改等接口全部都是/carts路径。默认情况下Sentinel会把路径作为簇点资源的名称，无法区分路径相同但请求方式不同的接口。

可以在application.yml中添加下面的配置 然后，重启服务

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

OpenFeign整合Sentinel

默认sentinel只会整合spring mvc中的接口。

修改cart-service模块的application.yml文件，可开启Feign的sentinel功能：

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

调用的别的服务(/item-service)的接口也会显示在这。

限流：

直接在sentinel控制台->簇点链路->流控 里面设置QPS

线程隔离

阈值类型选 并发线程数 ，代表这个接口所能用的线程数。

Fallback

触发限流或熔断后的请求不一定要直接报错，也可以返回一些默认数据或者友好提示，采用FallbackFactory，可以对远程调用的异常做处理。

业务场景：购物车服务需要同时openFeign调用服务B和商品服务，现在对商务服务做了线程隔离，在高并发的时候，会疯狂抛异常，现在做个fallback让它返回默认值。

步骤一：在hm-api模块中给ItemClient定义降级处理类，实现FallbackFactory：

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);
            }
        };
    }
}

步骤二：在hm-api模块中的com.hmall.api.config.DefaultFeignConfig类中将ItemClientFallback注册为一个Bean：

@Bean
public ItemClientFallback itemClientFallback(){
     return new ItemClientFallback();
}

步骤三：在hm-api模块中的ItemClient接口中使用ItemClientFallbackFactory：

@FeignClient(value = "item-service",fallbackFactory = ItemClientFallback.class)
public interface ItemClient {
    @GetMapping("/items")
    List<ItemDTO> queryItemByIds(@RequestParam("ids") Collection<Long> ids);
}

重启后，再次测试

熔断器

分布式事务

场景：订单服务依次调用了购物车服务和库存服务，它们各自操作不同的数据库。当清空购物车操作成功、库存扣减失败时，订单服务能捕获到异常，却无法通知已完成操作的购物车服务，导致数据不一致。虽然每个微服务内部都能保证本地事务的 ACID 特性，但跨服务调用缺乏全局协调，无法实现端到端的一致性。

Seeta

要解决这个问题，只需引入一个统一的事务协调者，负责跟每个分支通信，检测状态，并统一决定全局提交或回滚。

在 Seata 中，对应三大角色：

• TC（Transaction Coordinator）事务协调者 维护全局事务和各分支事务的状态，负责发起全局提交或回滚指令。
• TM（Transaction Manager）事务管理器 定义并启动全局事务，最后根据应用调用决定调用提交或回滚。
• RM（Resource Manager）资源管理器 嵌入到各微服务中，负责注册分支事务、上报执行结果，并在接到 TC 指令后执行本地提交或回滚。

其中，TM 和 RM 作为客户端依赖，直接集成到业务服务里；TC 则是一个独立部署的微服务，承担全局协调的职责。这样，无论有多少分支参与，都能保证“要么都成功、要么都回滚”的一致性。

部署TC服务

1）准备数据库表

seata-tc.sql 运行初始化脚本

2）准备配置文件

3）Docker部署

seeta-server:
    image: seataio/seata-server:1.5.2
    container_name: seata-server
    restart: unless-stopped
    depends_on:
      - mysql
      - nacos
    environment:
      # 指定 Seata 注册中心和配置中心地址
      - SEATA_IP=192.168.0.107       # IDEA 可以访问到的宿主机 IP
      - SEATA_SERVICE_PORT=17099
      - SEATA_CONFIG_TYPE=file
      # 可视情况再加：SEATA_NACOS_SERVER_ADDR=nacos:8848
    networks:
      - hmall-net
    ports:
      - "17099:7099"   # TC 服务端口
      - "8099:8099"   # 服务管理端口（Console）
    volumes:
      - ./seata:/seata-server/resources

微服务集成Seata

1）引入依赖

<!--统一配置管理-->
  <dependency>
      <groupId>com.alibaba.cloud</groupId>
      <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
  </dependency>
  <!--读取bootstrap文件-->
  <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-bootstrap</artifactId>
  </dependency>
  <!--seata-->
  <dependency>
      <groupId>com.alibaba.cloud</groupId>
      <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
  </dependency>

2）在nacos上添加一个共享的seata配置，命名为shared-seata.yaml，你在bootstrap中引入该配置即可：

seata:
  registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
    type: nacos # 注册中心类型 nacos
    nacos:
      server-addr: 192.168.0.107:8848 # 替换为自己的nacos地址
      namespace: "" # namespace，默认为空
      group: DEFAULT_GROUP # 分组，默认是DEFAULT_GROUP
      application: seata-server # seata服务名称
      username: nacos
      password: nacos
  tx-service-group: hmall # 事务组名称
  service:
    vgroup-mapping: # 事务组与tc集群的映射关系
      hmall: "default"

这段配置是告诉你的微服务如何去「找到并使用」Seata 的 TC（Transaction Coordinator）服务，以便在本地发起、提交或回滚分布式事务。

XA模式

XA模式的优点是什么？

• 事务的强一致性，满足ACID原则
• 常用数据库都支持，实现简单，并且没有代码侵入

XA模式的缺点是什么？

• 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
• 依赖关系型数据库实现事务

实现方式

1）在Nacos中的共享shared-seata.yaml配置文件中设置：

seata:
  data-source-proxy-mode: XA

2）利用@GlobalTransactional标记分布式事务的入口方法

@GlobalTransactional
public Long createOrder(OrderFormDTO orderFormDTO) {
	...
}	

3）子事务中方法前添加@Transactional ，方便回滚

AT模式

简述AT模式与XA模式最大的区别是什么？

• XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
• XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
• XA模式强一致；AT模式最终一致（存在短暂不一致）

实现方式：

1）为需要的微服务数据库中创建undo_log表

-- for AT mode you must to init this sql for you business database. the seata server not need it.
CREATE TABLE IF NOT EXISTS `undo_log`
(
    `branch_id`     BIGINT       NOT NULL COMMENT 'branch transaction id',
    `xid`           VARCHAR(128) NOT NULL COMMENT 'global transaction id',
    `context`       VARCHAR(128) NOT NULL COMMENT 'undo_log context,such as serialization',
    `rollback_info` LONGBLOB     NOT NULL COMMENT 'rollback info',
    `log_status`    INT(11)      NOT NULL COMMENT '0:normal status,1:defense status',
    `log_created`   DATETIME(6)  NOT NULL COMMENT 'create datetime',
    `log_modified`  DATETIME(6)  NOT NULL COMMENT 'modify datetime',
    UNIQUE KEY `ux_undo_log` (`xid`, `branch_id`)
) ENGINE = InnoDB
  AUTO_INCREMENT = 1
  DEFAULT CHARSET = utf8mb4 COMMENT ='AT transaction mode undo table';

2）微服务的配置中设置（其实不设置，默认也是AT模式）

seata:
  data-source-proxy-mode: AT