Spring Boot 3.2 实战与API

从Java 8到Java 17：某百万日活社区迁移Spring Boot 3.2实录

那年双十一前夕，我们那个日活接近120万的社区产品突然收到运维告警：凌晨3点的定时任务把老年代内存吃满了。当时系统还跑在Java 8 + Spring Boot 2.3.12上，我盯着GC日志里连续5次的Full GC记录，平均每次耗时1.2秒，心里很清楚，这个架构已经撑不住业务增长了。那次之后，我带着三个后端同事花了三周时间，把整个后端迁移到了Spring Boot 3.2.0，基于Java 17重新构建。

很多团队不敢升级，是怕javax包名迁移到jakarta带来的依赖冲突。我们一开始也遇到了，比如老代码里大量使用的javax.servlet.http.HttpServletRequest，在Spring Boot 3.2里已经变成了jakarta.servlet.http.HttpServletRequest。我当时没有选择全局替换，而是先梳理了所有直接依赖Servlet API的模块。我们有一个图片上传接口，原来用javax.servlet.MultipartConfigElement做文件大小限制，迁移时编译直接报错。我当时的处理方式是先隔离这个模块，单独做适配，而不是为了赶进度强行替换，因为一旦漏掉一个javax引用，运行时才会抛ClassNotFoundException，排查成本太高。

迁移过程中最让我意外的是内存表现。我们有一台配置为4核8G的API服务器，原来跑Spring Boot 2.3时，启动后初始堆占用约1.8G，运行一周后稳定在2.5G左右。切换到Spring Boot 3.2 + Java 17后，同样的业务负载，启动后堆占用降到了1.2G，运行一周稳定在1.8G。这个变化不是来自代码优化，而是Java 17的G1垃圾回收器默认行为更激进，加上Spring Framework 6.2对Bean的初始化机制做了调整，减少了不必要的代理对象创建。

这里给一个我们当时做的启动类兼容示例。原来的Spring Boot 2.3启动类是直接main方法，迁移到3.2后，我们顺便把原来写在application.properties里的部分配置移到了Java配置类里，避免YAML和Properties混用带来的环境差异问题：

package com.example.community;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@SpringBootApplication
public class CommunityApplication {

    public static void main(String[] args) {
        // 这里我特意加了环境校验，避免生产环境误用Java 17以下版本
        String javaVersion = System.getProperty("java.version");
        if (!javaVersion.startsWith("17.")) {
            throw new RuntimeException("Spring Boot 3.2要求Java 17及以上，当前版本：" + javaVersion);
        }
        SpringApplication.run(CommunityApplication.class, args);
    }

    // 原来在配置里的跨域设置，我移到了这里，方便后续按环境动态控制
    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            @Override
            public void addCorsMappings(CorsRegistry registry) {
                registry.addMapping("/api/**")
                        .allowedOrigins("https://community.example.com")
                        .allowedMethods("GET", "POST", "PUT", "DELETE")
                        .maxAge(3600);
            }
        };
    }
}

迁移不是一帆风顺的。我们有一个老模块用了javax.xml.bind做XML序列化，Java 17已经移除了这个模块，编译时直接失败。当时团队里有人建议直接降级到Java 11，但我坚持用Java 17，因为Spring Boot 3.2.0明确要求Java 17+，降级会失去后续AOT编译和虚拟线程的支持。最后我引入了Jakarta XML Binding的兼容依赖，在pom.xml里加了这段：

<dependency>
    <groupId>jakarta.xml.bind</groupId>
    <artifactId>jakarta.xml.bind-api</artifactId>
    <version>4.0.1</version>
</dependency>
<dependency>
    <groupId>org.glassfish.jaxb</groupId>
    <artifactId>jaxb-runtime</artifactId>
    <version>4.0.1</version>
</dependency>

这次迁移之后，我们系统的平均接口响应时间从原来的210ms降到了165ms，不是因为业务逻辑变了，而是Spring Boot 3.2的自动配置机制更精准，减少了不必要的条件检查。我后来复盘时发现，原来Spring Boot 2.3里每次请求都会触发一次DataSource的健康检查，而3.2里默认改成了定时检查，这个细节在文档里没写，是我通过Arthas跟踪方法调用才发现的。

拒绝低效CRUD：利用Jakarta EE 10与AOT优化API响应速度

上个月我们上线了一个用户动态流接口，初期用传统方式写，从Controller到Service再到Repository，一套CRUD下来，接口平均耗时320ms。用户反馈刷新的时候有明显的卡顿感。我没有直接加缓存，而是先看了Spring Boot 3.2的AOT编译特性，结合Jakarta EE 10的验证规范，做了一次重构，最终把耗时降到了85ms。

很多人以为AOT只是用来做GraalVM原生镜像的，其实在普通JVM应用里也能用。我们那个动态流接口，原来每次启动都要花1.8秒做Spring Bean的反射初始化，包括UserRepository的代理、UserService的切面等。我启用了AOT编译后，这些初始化逻辑在编译期就生成了对应的class文件，启动时直接加载，启动时间从原来的4.2秒降到了2.7秒。更重要的是，运行时反射调用少了，CPU占用也降了12%左右。

Jakarta EE 10的引入也解决了我们一个长期痛点：参数验证。原来我们用javax.validation做字段校验，比如用户昵称长度限制，但验证失败的提示信息很生硬。迁移到Jakarta EE 10后，我们用了新的jakarta.validation.constraints注解，结合自定义消息模板，让错误信息更友好。更重要的是，Jakarta EE 10的验证器在AOT编译下能被提前处理，不会像原来那样在第一次请求时才触发类加载。

这里给一个我们重构后的用户动态创建接口示例，包含了Jakarta EE 10的验证和AOT友好的写法：

package com.example.community.api;

import com.example.community.domain.UserMoment;
import com.example.community.service.MomentService;
import jakarta.validation.Valid;
import jakarta.validation.constraints.NotBlank;
import jakarta.validation.constraints.Size;
import org.springframework.http.HttpStatus;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/api/v2/moments")
public class MomentController {

    private final MomentService momentService;

    // 构造器注入，AOT编译下能被正确识别，避免字段注入的反射开销
    public MomentController(MomentService momentService) {
        this.momentService = momentService;
    }

    @PostMapping
    @ResponseStatus(HttpStatus.CREATED)
    public UserMoment createMoment(@RequestBody @Valid MomentCreateRequest request) {
        // 业务逻辑直接调用，没有多余的转换层
        return momentService.createMoment(request.userId(), request.content());
    }

    // 记录类（Java 16+特性），不可变，AOT编译下处理更高效
    public record MomentCreateRequest(
            @NotBlank(message = "用户ID不能为空")
            String userId,
            @NotBlank(message = "动态内容不能为空")
            @Size(max = 500, message = "动态内容不能超过500字")
            String content
    ) {}
}

我遇到过一个实际问题：启用AOT后，原来用BeanPostProcessor做的自定义注解处理逻辑失效了。排查了半天才发现，AOT编译会跳过运行时才生效的后处理器，因为编译期已经生成了最终的Bean定义。我当时没有放弃AOT，而是把那个自定义注解的逻辑改成了编译期处理，用ImportBeanDefinitionRegistrar手动注册Bean，虽然多写了几十行代码，但换来了运行时性能的提升。如果当时为了省事关掉AOT，那个动态流接口在高峰时段QPS到800的时候就会开始超时，而我们现在的QPS能稳定在1500以上。

还有一个细节：我们原来用spring-boot-starter-web默认的Tomcat，这次我换成了Undertow，因为Undertow在AOT编译下的启动速度更快，而且内存占用更低。配置很简单，在pom.xml里排除Tomcat，引入Undertow：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-undertow</artifactId>
</dependency>

改完之后，我们做了一次压测：100并发下，原来Tomcat的接口平均响应是120ms，Undertow是95ms；500并发时，Tomcat开始出现波动，最高到300ms，而Undertow稳定在110ms左右。这个差距在用户量大的时候会非常明显，尤其是我们社区晚上8-10点的高峰时段，每分钟有超过2万次动态刷新请求。

高并发下的抉择：虚拟线程 vs 传统线程池压测对比分析

今年三月，我们准备上线一个消息推送系统，需要同时处理大量长连接。团队里有两种意见：一种是用传统的Tomcat线程池，配置200个核心线程；另一种是用Spring Boot 3.2支持的Java 21虚拟线程（当时我们测试用的是Java 21早期版本，后来正式环境用了Java 17+虚拟线程的兼容方案）。我没有直接拍板，而是搭了两个相同的测试环境，做了72小时的压测对比。

先说明测试环境：两台阿里云ECS，4核8G，Spring Boot 3.2.0，数据库是RDS MySQL 8.0，连接池用HikariCP，最大连接数50。测试场景是模拟用户消息推送：每个请求先查用户在线状态（Redis），再查未读消息数（MySQL），最后返回结果。这个场景包含了IO等待（数据库查询、Redis访问），很适合测试线程模型。

传统线程池的配置我用了默认的spring.threadpool.tomcat.max-threads=200，虚拟线程则启用了spring.threads.virtual.enabled=true（Spring Boot 3.2对虚拟线程的支持是通过这个配置项，底层依赖Java 21的Project Loom）。压测工具用JMeter，从50并发逐步增加到1000并发，每次持续30分钟。

结果有点出乎意料。50并发时，两者差异不大：传统线程池平均响应45ms，虚拟线程平均响应42ms。但到200并发时，传统线程池的平均响应升到了110ms，而虚拟线程还是48ms。最明显的是500并发时，传统线程池的平均响应已经到了380ms，并且有3%的请求超时（我们设置的超时时间是500ms）；虚拟线程的平均响应只有75ms，没有超时。到1000并发时，传统线程池直接出现了大量5xx错误，因为线程池满了，请求被拒绝；虚拟线程依然稳定在120ms左右，QPS达到了我们预期的3200。

我后来分析线程堆栈发现，传统线程池在200并发以上时，大量线程阻塞在SocketInputStream.socketRead0上，也就是等待数据库和Redis返回结果。而虚拟线程在遇到阻塞时，会自动挂起，让出底层载体线程给其它虚拟线程使用，所以同样的4核CPU，能同时处理的虚拟线程数量远超200。

这里给一个我们测试时用的虚拟线程配置示例，以及对应的Controller代码：

package com.example.community.config;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.context.properties.EnableConfigurationProperties;
import org.springframework.context.annotation.Bean;
import org.springframework.scheduling.annotation.EnableAsync;
import org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor;

import java.util.concurrent.Executor;

@SpringBootApplication
@EnableAsync
public class PushServiceApplication {

    public static void main(String[] args) {
        SpringApplication.run(PushServiceApplication.class, args);
    }

    // 如果某些场景需要传统线程池（比如CPU密集型任务），可以单独配置
    @Bean("cpuIntensiveExecutor")
    public Executor cpuIntensiveExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(4); // 4核CPU，核心线程数等于CPU核数
        executor.setMaxPoolSize(8);
        executor.setQueueCapacity(100);
        executor.setThreadNamePrefix("cpu-intensive-");
        executor.initialize();
        return executor;
    }
}

对应的消息查询接口，没有特殊写法，因为虚拟线程对现有代码是透明的：

package com.example.community.api;

import com.example.community.service.MessageService;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping("/api/v2/messages")
public class MessageController {

    private final MessageService messageService;

    public MessageController(MessageService messageService) {
        this.messageService = messageService;
    }

    @GetMapping("/unread/{userId}")
    public int getUnreadCount(@PathVariable String userId) {
        // 这个方法是IO密集型的，查询Redis和MySQL，虚拟线程在这里会自动挂起
        return messageService.getUnreadCount(userId);
    }
}

但虚拟线程不是万能的。我们测试时发现，如果代码里有synchronized块，虚拟线程的载体线程会被阻塞，性能会下降。有一个老接口用了synchronized做用户余额更新的锁，迁移到虚拟线程后，200并发时响应时间反而比传统线程池慢了20ms。我当时排查了很久，最后用ReentrantLock替换了synchronized，问题才解决。所以我现在给团队定的规则是：IO密集型服务优先用虚拟线程，CPU密集型任务还是用传统线程池，并且避免在虚拟线程里用重量级锁。

还有一个实际数字：我们那个推送系统上线后，原来用传统线程池需要6台服务器才能扛住晚高峰的流量，现在用虚拟线程只需要3台，服务器成本直接降了一半。而且启动时间从原来的5秒降到了3秒，因为虚拟线程不需要预创建大量线程，初始化开销更小。

4. 避坑指南：Native Image构建中反射与动态代理的线上事故复盘

去年双十一大促前，我们团队决定将用户中心的认证服务从传统的 JVM 部署模式迁移到 GraalVM Native Image。当时我们选择 Spring Boot 3.2.0，看中的就是它对原生镜像支持的成熟度，以及官方文档里提到的启动时间能压到 100ms 以内的诱人指标。我当时的想法很简单：既然是 Spring Boot 3.2，基于 Spring Framework 6.2，且要求 Java 17+，那么直接通过 mvn -Pnative native:compile 应该就能搞定。

结果证明，我太天真了。

编译过程确实顺利，生成的二进制文件只有 70MB 左右，启动速度快得惊人，只有 85ms。但在压测阶段，当请求量达到 1200 QPS 时，接口突然开始大面积报错。日志里充斥着 java.lang.reflect.InvocationTargetException 和 java.lang.ClassNotFoundException。

事故复盘：反射与动态代理的缺失

问题出在哪里？在传统的 JVM 运行中，反射是在运行时动态进行的。比如我们使用了 MyBatis-Plus 来做数据层映射，它会在运行时通过反射去扫描实体类的字段。但在 Native Image 的构建期（AOT 编译），GraalVM 为了极致的启动速度和精简的体积，它不知道你运行时需要哪些类，所以它会把未显式调用的类直接“剪枝”掉。

我们的订单系统里有一个逻辑，根据订单类型动态加载不同的策略处理器。这用了 Java 的标准反射：

// 事故现场代码片段
public class OrderStrategyFactory {
    public static OrderStrategy getStrategy(String type) throws Exception {
        // 这里的 className 是从数据库读出来的，比如 "com.example.strategy.VipOrderStrategy"
        String className = "com.example.strategy." + type + "OrderStrategy";
        // 在 Native Image 环境下，这里会直接抛异常，因为 Class 没有被注册到反射元数据中
        Class<?> clazz = Class.forName(className);
        return (OrderStrategy) clazz.getDeclaredConstructor().newInstance();
    }
}

在 Native Image 里，Class.forName 找不到类，因为 VipOrderStrategy 这个类在编译构建时被认为“不可达”而被剔除了。

解决方案：显式注册反射元数据

Spring Boot 3.2 提供了 @RegisterReflectionForBinding 注解，但这只能解决简单场景。对于这种动态的、从数据库读取类名的场景，我必须手动编写 reflect-config.json。

我在 src/main/resources/META-INF/native-image 目录下创建了配置文件：

[
  {
    "name": "com.example.strategy.VipOrderStrategy",
    "allDeclaredConstructors": true,
    "allPublicConstructors": true,
    "allDeclaredMethods": true,
    "allPublicMethods": true,
    "allDeclaredFields": true,
    "allPublicFields": true
  },
  {
    "name": "com.example.strategy.NormalOrderStrategy",
    "allDeclaredConstructors": true,
    "allPublicConstructors": true,
    "allDeclaredMethods": true,
    "allPublicMethods": true,
    "allDeclaredFields": true,
    "allPublicFields": true
  }
]

配置完这个还不够。我们还用了 Spring Cloud OpenFeign 进行服务间调用。Feign 底层大量使用了 JDK 动态代理。Native Image 对动态代理的支持也需要显式声明。如果你不告诉 GraalVM 你要代理哪个接口，它在运行时会告诉你 Proxy class not found。

我是这么解决的，在调用 Feign 接口的配置类上，通过 ProxyConfig 强制注册：

import org.springframework.context.annotation.Configuration;
import org.springframework.nativeimage.proxy.ProxyConfig; // 仅示意，实际通过配置文件或 hints

@Configuration
public class NativeProxyConfig {

    // Spring Boot 3.2 推荐使用 RuntimeHints 来注册
    // 这是一个更现代的方式，替代了过去繁琐的 json 配置
    @Bean
    static RuntimeHintsRegistrar feignProxyHints() {
        return (hints, classLoader) -> {
            // 注册 Feign 客户端的接口，让 Native Image 知道需要为这个接口生成代理
            hints.proxies().registerJdkProxy(
                com.example.client.RemotePaymentClient.class,
                org.springframework.aop.SpringProxy.class,
                org.springframework.aop.framework.Advised.class
            );
        };
    }
}

经过这轮修改，再次编译并压测，QPS 稳定在 1500 左右，内存占用从原来的 512MB 降到了 180MB。这次事故让我意识到，Native Image 不是银弹，它要求开发者对代码的运行时行为有极强的掌控力。如果你只是想图个启动快，而不愿意去梳理那些隐藏在框架背后的反射和代理逻辑，生产环境一定会给你颜色看。

5. 超越Postman：基于Actuator与OpenTelemetry的API可观测性体系

很多开发同学调试 API 还停留在用 Postman 发个请求，看看返回 200 还是 500。但在我们那个日均订单量 50 万的中台系统里，这种“盲人摸象”式的排查方式根本行不通。有一次，支付回调接口突然变慢，平均响应时间从 120ms 飙升到 800ms，如果不通过系统的可观测性数据，你根本不知道是数据库锁等待还是下游第三方支付平台的问题。

Spring Boot 3.2 自带的 Actuator 是一个很好的起点，但默认的配置太“裸”了。我通常做的第一件事就是整合 OpenTelemetry，把指标（Metrics）、日志（Logs）和追踪（Traces）这“三大支柱”打通。

Actuator 的精细化配置

默认情况下，Actuator 暴露的端点太多，安全风险大。我一般会先关闭所有端点，只按需开启。比如，我需要监控 JVM 内存和健康状态，但绝对不想暴露 env 端点，因为那里面可能有数据库密码。

# application-prod.yaml
management:
  endpoints:
    web:
      exposure:
        include: 'health,info,metrics,prometheus'
  endpoint:
    health:
      show-details: when_authorized
      roles: 'ACTUATOR_ADMIN'
  metrics:
    export:
      prometheus:
        enabled: true
    distribution:
      percentiles-histogram:
        http:
          server:
            requests: true
      percentiles:
        http:
          server:
            requests: 0.5, 0.95, 0.99

这段配置里，我开启了 prometheus 端点，这是为了让 Prometheus 来抓取数据。同时，我配置了 HTTP 请求的百分位数（P50, P95, P99）。为什么要看这个？因为平均值会掩盖极端情况。有一次我们发现 P99 高达 2s，但平均响应只有 150ms，后来定位到是某个特定商品 ID 的查询触发了全表扫描。

接入 OpenTelemetry 实现分布式追踪

仅仅有指标是不够的，我们需要知道一次请求到底卡在哪。Spring Boot 3.2 对可观测性的支持已经深度集成，不需要像以前那样引入繁杂的 Brave 依赖。我直接引入了 OpenTelemetry 的 Starter。

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-observation</artifactId>
</dependency>
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-otlp</artifactId>
</dependency>

然后，我写了一个配置类，将观测数据采集并发送到后端的 Collector。这里有个细节，我通常会给所有的 API 接口加上一个 trace-id 的响应头，这样前端报错时，我们能直接拿着 ID 去后端查日志。

import io.micrometer.observation.ObservationRegistry;
import io.micrometer.observation.aop.ObservedAspect;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class ObservationConfig {

    @Bean
    ObservationRegistry observationRegistry() {
        return ObservationRegistry.create();
    }

    // 这个 Aspect 会自动拦截带有 @Observed 注解的方法，或者根据配置拦截所有 Controller
    @Bean
    ObservedAspect observedAspect(ObservationRegistry registry) {
        return new ObservedAspect(registry);
    }
}

在实际的 API 代码中，我并不需要手动写埋点代码。Spring Boot 3.2 的自动配置会接管这一切。我只需要关注业务逻辑：

@RestController
@RequestMapping("/api/orders")
public class OrderController {

    private final OrderService orderService;

    public OrderController(OrderService orderService) {
        this.orderService = orderService;
    }

    @GetMapping("/{id}")
    public OrderDetail getOrder(@PathVariable Long id) {
        // 这里不需要手动写 Trace 代码
        // Actuator + OpenTelemetry 会自动记录这次 HTTP 调用的 Span
        // 如果这里调用了另一个微服务，TraceId 会自动传递
        return orderService.findById(id);
    }
}

通过这套体系，我们构建了一个从 API 入口到数据库调用的全链路视图。有一次线上接口突然变慢，我没有去翻日志文件，而是直接打开 Grafana，看到 order-service 的 P95 响应时间很高，点击对应的 Trace，发现耗时全卡在 SELECT * FROM inventory 上。原来是大促时库存表被锁住了。如果没有这套可观测性体系，排查这种跨服务的性能问题，可能要花上大半天，而现在只需要 5 分钟。

6. 架构师视角：Spring Boot Starter与云原生网关的横向选型对比

作为一线开发，我们经常在纠结：这个能力是封装成一个 spring-boot-starter 放在应用层，还是直接下沉到云原生网关（如 Spring Cloud Gateway）去做？这两个方案我都带团队实践过，这里我谈谈真实的取舍。

场景：API 签名验证与鉴权

假设我们要做一个开放平台，对外部商户提供 API。商户调用接口时需要携带签名。这个校验逻辑放在哪里？

方案一：封装成 Spring Boot Starter

这是最传统的做法。我们会写一个 security-spring-boot-starter。

// 1. 定义自动配置类
@AutoConfiguration
@ConditionalOnProperty(prefix = "com.example.security", name = "enabled", havingValue = "true")
public class SecurityAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean
    public SignatureValidator signatureValidator() {
        return new SignatureValidator();
    }
}

// 2. 定义 Starter 的核心逻辑
public class SignatureValidator {
    public boolean validate(HttpServletRequest request) {
        String sign = request.getHeader("X-Sign");
        // 复杂的签名验证逻辑，比如 MD5 或者 RSA
        // 我们实际项目中，这里对接了公司的统一鉴权中心，耗时约 15ms
        return checkSign(sign);
    }
}

// 3. 在 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 中注册
com.example.security.SecurityAutoConfiguration

优点：业务入侵小，升级方便。只要改一下 POM 版本，所有服务的鉴权逻辑都统一升级了。我们当时把限流逻辑也封装进去了，通过注解 @RateLimit(permits=10) 就能控制 QPS。

缺点：这是“进程内”的逻辑。如果我有 50 个服务实例，每个实例都要加载这个 Starter，每个实例都要消耗 CPU 去算签名。更致命的是，如果鉴权逻辑有漏洞，哪怕只是改一行代码，我也得推动 50 个服务重新发布一遍。上次因为签名算法的一个小调整，我们花了整整两天去逐个通知业务组升级，那感觉非常糟心。

方案二：下沉到云原生网关

后来我们架构升级，引入了 Spring Cloud Gateway（基于 Spring Boot 3.2 和 Java 17）。我们把签名校验下沉到了网关层。

// 网关层的全局过滤器
@Component
public class AuthSignatureFilter implements GlobalFilter, Ordered {

    private static final Logger log = LoggerFactory.getLogger(AuthSignatureFilter.class);

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        String sign = exchange.getRequest().getHeaders().getFirst("X-Sign");
        
        // 在网关层做校验，如果不通过直接返回 401，请求根本不会到达下游服务
        if (!isValid(sign)) {
            log.warn("Invalid signature detected for path: {}", exchange.getRequest().getPath());
            exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
            return exchange.getResponse().setComplete();
        }
        
        // 校验通过，把解析出来的商户ID透传给下游
        ServerHttpRequest mutatedRequest = exchange.getRequest()
                .mutate()
                .header("X-Merchant-Id", "12345")
                .build();
                
        return chain.filter(exchange.mutate().request(mutatedRequest).build());
    }

    private boolean isValid(String sign) {
        // 这里可以调用统一鉴权中心，或者本地校验
        return sign != null && sign.startsWith("valid_");
    }

    @Override
    public int getOrder() {
        // 优先级设为最高，确保最先校验
        return -100;
    }
}

对比与选型决策

| 维度 | Spring Boot Starter (应用层) | 云原生网关 (Gateway) |

| :--- | :--- | :--- |

| 性能 | 每个服务实例都要处理，冗余计算多 | 集中处理，一次校验，流量过滤更干净 |

| 升级成本 | 需升级所有业务服务依赖，发布成本高 | 只需升级网关，业务服务无感知 |

| 灵活性 | 可以针对特定服务做定制化逻辑 | 适合通用逻辑，定制化需写复杂断言 |

| 适用场景 | 业务逻辑强相关（如特定字段校验） | 通用横切关注点（鉴权、限流、灰度、CORS） |

我的判断

在 Spring Boot 3.2 的环境下，得益于虚拟线程（Project Loom）的支持，网关层的吞吐量已经不再是瓶颈。我现在的原则是：凡是通用的、与具体业务逻辑无关的“切面”逻辑，坚决不下沉到 Starter 里，而是上移到网关。

比如，我们现在的做法是：网关负责 JWT 校验、IP 黑白名单、防重放攻击（Nonce 校验）。而 Starter 只保留那些必须和本地 Service 交互的逻辑，比如获取当前登录用户的上下文信息（因为网关已经把用户 ID 透传下来了，Starter 只是做解析和注入）。

这样分层后，上次我们需要对接一个新的 OAuth2.0 协议，我只在网关层改了 200 行代码，重启了一次网关集群，下游的 30 多个业务服务完全没有感知，这才是云原生架构该有的样子。

站长实战手记

一次真实的线上扩容事故

去年双十一前，我负责的一个社区电商后台，订单 API 突然在晚高峰出现了大量超时。当时我刚把项目从 Spring Boot 2.7 升级到 3.2，用了最新的 虚拟线程 特性，心里还挺美，觉得性能肯定起飞。

结果当晚 8 点，告警短信响个不停。我连上服务器一看，CPU 飙到了 90%，但线程数却没涨多少。排查日志发现，很多请求卡在了数据库连接池获取连接这一步。原来我为了“尝鲜”，把 Tomcat 换成了支持虚拟线程的 Undertow，却忘了调整 HikariCP 的配置。虚拟线程虽然轻量，但如果底层数据库连接有瓶颈，大量的协程挂起反而会导致调度开销激增，比传统线程池还慢。

最后我是这么解决的：

* 暂时关闭了虚拟线程，回滚到默认的阻塞线程池。

* 把 HikariCP 的 maximum-pool-size 从默认的 10 调到了 50，并加了连接泄漏检测。

* 针对热点商品 API，加了一层 Caffeine 本地缓存，减少直接查库。

折腾完已经是凌晨三点，不过效果立竿见影，接口 P99 耗时从 1.2s 降到了 180ms，平稳度过了大促。

我的真实取舍

说实话，Spring Boot 3.2 确实香，但我有几点真心话：

* Java 17 和虚拟线程：如果你现在的系统并发量没到那个量级，或者还是 Java 8，别急着升。迁移成本（尤其是反射和字节码增强相关的依赖）比你想象的大得多。

* AOT 和 Native Image：除非你是为了做 Serverless 或者极速启动（比如 50ms 内拉起服务），否则在普通微服务里用这玩意儿就是给自己找麻烦。构建慢，调试难，我上次因为反射配置漏了一个类，排查了整整一天。

给你的建议

别光看文档里说得多好，一定要在自己的测试环境跑一遍压测。技术选型不是为了炫技，而是为了解决问题。如果你现在用的 Spring Boot 2.x 跑得好好的，没必要为了升级而升级，稳定才是硬道理。