Spring Cloud Gateway中AdaptCachedBodyGlobalFilter缓存请求体的正确使用方式

背景介绍

Spring Cloud Gateway作为微服务架构中的API网关，提供了强大的路由转发和过滤器功能。其中，AdaptCachedBodyGlobalFilter是一个用于缓存请求体的全局过滤器，在处理POST请求时特别有用。然而，许多开发者在实际使用过程中会遇到缓存不生效的问题。

问题现象

开发者在配置AdaptCachedBodyGlobalFilter时，按照常规思路通过发布EnableBodyCachingEvent事件来启用特定路由的请求体缓存功能，但发现过滤器并未按预期工作。经过调试发现，只有当在路由ID前添加"ReactiveCompositeDiscoveryClient_"前缀时，缓存功能才能正常生效。

原因分析

深入分析AdaptCachedBodyGlobalFilter的源码实现，我们可以发现关键点：

1. 过滤器会从exchange中获取GATEWAY_ROUTE_ATTR属性，这个属性的ID格式为"ReactiveCompositeDiscoveryClient_"+原始路由ID
2. 过滤器内部维护了一个routesToCache的Map结构，用于存储需要缓存请求体的路由配置
3. 当检查路由是否需要缓存时，使用的是经过处理后的完整路由ID

这种设计是因为Spring Cloud Gateway在内部处理服务发现时，会自动为路由ID添加前缀以区分不同的路由来源。对于通过服务发现机制(lb://)配置的路由，网关会自动添加"ReactiveCompositeDiscoveryClient_"前缀。

解决方案

基于上述分析，正确的使用方式有以下几种：

方案一：手动添加前缀

在发布EnableBodyCachingEvent事件时，手动为路由ID添加前缀：

@PostConstruct
public void init() {
    gatewayProperties.getRoutes().forEach(routeDefinition -> {
        String routeId = "ReactiveCompositeDiscoveryClient_" + routeDefinition.getId();
        EnableBodyCachingEvent event = new EnableBodyCachingEvent(this, routeId);
        publisher.publishEvent(event);
    });
}

方案二：使用RouteLocator获取完整路由ID

通过RouteLocator获取实际生效的路由信息，确保使用正确的路由ID：

@Autowired
private RouteLocator routeLocator;

@PostConstruct
public void init() {
    routeLocator.getRoutes()
        .subscribe(route -> {
            EnableBodyCachingEvent event = new EnableBodyCachingEvent(this, route.getId());
            publisher.publishEvent(event);
        });
}

方案三：配置全局缓存

如果需要为所有路由启用请求体缓存，可以直接配置：

@Bean
public AdaptCachedBodyGlobalFilter adaptCachedBodyGlobalFilter() {
    return new AdaptCachedBodyGlobalFilter(true);
}

最佳实践建议

1. 对于服务发现类型的路由(lb://)，建议使用方案二获取完整路由ID
2. 如果确定所有路由都需要缓存请求体，使用方案三最为简单直接
3. 在调试时，可以通过打印exchange中的GATEWAY_ROUTE_ATTR属性来确认实际路由ID格式
4. 注意缓存请求体会增加内存消耗，应根据实际业务需求合理配置

总结

Spring Cloud Gateway的AdaptCachedBodyGlobalFilter是一个强大的请求体缓存工具，但使用时需要注意内部路由ID的处理机制。理解网关内部的路由处理流程，可以帮助开发者更准确地配置和使用各种过滤器功能。通过本文的分析和解决方案，开发者可以避免常见的配置陷阱，充分发挥网关的性能优势。