今天分享 Spring Boot 4.1。它的主线可以概括为：服务间通信开始官方拥抱 gRPC，开放式 HTTP 出站开始有更明确的 SSRF 防护入口，可观测性继续补生产细节。对 Spring Cloud 和 Agent 应用来说，这些变化都指向同一件事：边界治理正在变得比单点功能更重要。

分享日期：2026-06-12
主题：Java / Spring Boot 4.1 / Spring Cloud / gRPC / SSRF 防护 / Observability / Agent 出站治理

1. 为什么今天值得关注

Spring Boot 4.1.0 已在 2026-06-10 GA，并发布到 Maven Central。官方公告把这次发布的重点列为：Spring gRPC 支持、Jackson 配置增强、HTTP Client SSRF 防护、可观测性和 OpenTelemetry 更新、Log4j 文件轮转等。

这不是一次“又升了几个依赖版本”的小修小补。对 Java 后端团队来说，Spring Boot 4.1 的信号很清楚：Boot 正在把三类原本需要团队各自拼装的能力，收进统一工程模型里：

• 服务间通信：gRPC 从外围项目能力进入 Boot 官方自动配置和 starter 体系。
• 出站访问安全：HTTP 客户端可以用 InetAddressFilter 做 SSRF 防护，尤其适合开放 URL 输入、Webhook、Agent 工具调用等场景。
• 生产可观测性：@Async 上下文传播、OpenTelemetry 采样、Span/Log limits、OTLP SSL bundle 等能力继续补齐。

一句话：Spring Boot 4.1 的价值，不只是“能写 gRPC 服务”，而是让微服务通信、安全边界和观测链路更像一套可以落地治理的默认工程能力。

2. 版本背景：Boot 4.1 和 Cloud Oakwood 的关系

Spring Boot 4.x 对应的是 Spring Framework 7、Jakarta EE 新基线、Jackson 3、JSpecify 空安全等一整套生态变化。Spring Cloud 这边，2025.1.x aka Oakwood 是面向 Spring Boot 4 代际的 release train；Spring Cloud 官方项目页当前把 Oakwood 标为 2025.1.x，并提供 spring-cloud-dependencies BOM 用于统一依赖管理。

所以团队评估 Boot 4.1 时，不应该只看单个应用能不能启动，还要一起看：

• Spring Cloud Gateway / Config / OpenFeign / Stream / CircuitBreaker 是否进入对应的 2025.1.x 线。
• 现有 Spring Cloud 组件是否已经完成 Boot 4 / Framework 7 / Jackson 3 的兼容验证。
• 网关、服务发现、配置中心、消息 binder、声明式 HTTP 客户端是否有废弃 API 或 artifact 迁移。
• CI 基础镜像、构建插件、OpenRewrite/Moderne 迁移脚本是否和目标版本一致。

Boot 4.1 可以先从非核心服务试点，但 Cloud 体系不能“跟着传递依赖自动漂过去”。微服务系统升级，最怕单个服务看似成功，运行时网关、配置、序列化、安全过滤器和链路追踪却各走各的版本线。

3. gRPC：从“自己整合”变成 Boot 官方路径

Spring Boot 4.1 新增了 gRPC 开发和测试支持。官方文档说明，Boot 支持开发 gRPC server 和 client，服务端可以是 Netty 独立服务器，也可以通过 Servlet 集成把 gRPC 暴露在 HTTP/2 上。

服务端最小依赖路径是：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-grpc-server</artifactId>
</dependency>

典型服务实现：

import io.grpc.stub.StreamObserver;
import org.springframework.grpc.server.service.GrpcService;

@GrpcService
public class AccountGrpcService extends AccountServiceGrpc.AccountServiceImplBase {

    @Override
    public void getAccount(AccountRequest request, StreamObserver<AccountReply> responseObserver) {
        AccountReply reply = AccountReply.newBuilder()
                .setId(request.getId())
                .setStatus("ACTIVE")
                .build();

        responseObserver.onNext(reply);
        responseObserver.onCompleted();
    }
}

如果使用 spring-boot-starter-grpc-server，默认 Netty 服务端监听 9090。如果团队更想复用现有 Servlet 容器，比如 Tomcat，则可以排除 grpc-netty，引入 grpc-servlet-jakarta，并开启 HTTP/2。

客户端也进入了 Boot 的 bean 管理模型：

import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.grpc.client.ImportGrpcClients;

@SpringBootApplication
@ImportGrpcClients(
        target = "account",
        types = AccountServiceGrpc.AccountServiceBlockingStub.class
)
public class BillingApplication {
}

通道配置可以放在配置文件里：

spring:
  grpc:
    client:
      channel:
        account:
          target: static://account.internal:9090
          inbound:
            keepalive:
              timeout: 40s
            message:
              max-size: 8MB

这背后的工程意义是：gRPC 不再只是某个团队自己拼 grpc-java + Netty + proto plugin + health + security 的组合拳，而是可以进入 Boot 的 starter、配置属性、SSL bundle、健康检查、安全配置和测试体系。

4. gRPC 对微服务架构的实际影响

HTTP JSON 仍然会长期存在，尤其适合开放 API、浏览器生态、调试和跨组织集成。gRPC 更适合下面这些场景：

• 内部服务之间高频、低延迟、强 schema 的调用。
• 多语言系统之间需要统一 IDL 和代码生成。
• 大对象流式传输、双向流、长连接场景。
• 对接口演进、字段兼容、契约治理要求更高的核心链路。

但 gRPC 不是“性能开关”。团队落地时要先补齐治理问题：

• .proto 文件要有归属、版本策略和兼容规则。
• 网关、服务发现、负载均衡、熔断、限流要确认是否支持 HTTP/2 和 gRPC 语义。
• 错误码不能随便塞字符串，要建立业务错误和 gRPC status 的映射。
• 日志、trace id、tenant id、auth token 要有 metadata 传播规范。
• 发布前必须压测最大消息体、流式调用、连接复用、超时和取消传播。

Boot 4.1 把“接入成本”降了下来，但不会自动解决分布式系统的契约和治理问题。这一点得说清楚，否则很容易把 gRPC 用成另一种形态的强耦合 RPC。

5. SSRF 防护：Agent 和开放式出站调用都要看

Boot 4.1 的另一个重点是 HTTP Client SSRF mitigation。官方文档新增了 InetAddressFilter：团队可以限制 HTTP 客户端允许访问的远端地址，防止用户输入或模型生成的 URL 把应用引到内网地址、元数据服务或受保护系统。

最典型的风险场景：

• 用户提交一个 URL，让系统去抓取网页、图片、PDF 或 OpenGraph 信息。
• Webhook、回调地址、第三方集成地址由租户配置。
• AI Agent / MCP 工具调用链里，模型可以间接影响请求目标。
• 后台任务根据消息内容访问外部 HTTP 资源。

Boot 4.1 的写法可以很直接：

import org.springframework.boot.http.client.ClientHttpRequestFactoryBuilder;
import org.springframework.boot.http.client.HttpClientSettings;
import org.springframework.boot.http.client.InetAddressFilter;
import org.springframework.http.client.ClientHttpRequestFactory;
import org.springframework.stereotype.Service;
import org.springframework.web.client.RestClient;

@Service
public class PageFetchService {

    private final RestClient restClient;

    public PageFetchService() {
        InetAddressFilter onlyExternalAddresses = InetAddressFilter.externalAddresses();
        HttpClientSettings settings = HttpClientSettings.defaults()
                .withInetAddressFilter(onlyExternalAddresses);
        ClientHttpRequestFactory requestFactory = ClientHttpRequestFactoryBuilder.jdk()
                .build(settings);

        this.restClient = RestClient.builder()
                .requestFactory(requestFactory)
                .build();
    }
}

也可以定义一个全局 bean，让自动配置的 HTTP client builder 都使用同一套规则：

import org.springframework.boot.http.client.InetAddressFilter;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration(proxyBeanMethods = false)
class HttpClientSecurityConfiguration {

    @Bean
    InetAddressFilter httpClientInetAddressFilter() {
        return InetAddressFilter.externalAddresses();
    }
}

这对 Agent 开发尤其关键。Tool Calling、MCP、RAG 检索、URL 抓取看起来是 AI 功能，实际落地时都是后端应用在执行出站调用。模型不能替团队承担安全边界；应用必须在 DNS 解析后、连接建立前、重定向后继续确认目标地址是否允许访问。

6. 可观测性：异步、消息和 OTel 都在补细节

Boot 4.1 在可观测性上不是大改框架，而是补生产里最烦人的边角：

• @Async 方法可以自动传播上下文，减少 trace 在异步线程里断开的概率。
• Kafka / Rabbit / Rabbit Stream 的 observation convention 可以自动应用到对应组件。
• OpenTelemetry 增加 management.opentelemetry.enabled，可以禁用 SDK 但保留 propagators。
• OTel tracing sampler、SpanLimits、LogLimits、BatchLogRecordProcessor 配置项更完整。
• OTLP logging、metrics、trace exporter 支持 SSL bundle。

这对微服务和 Agent 系统都很现实。Agent 一次回答可能包含模型调用、检索、工具调用、HTTP 出站、消息投递、数据库查询、异步任务。如果 trace 在线程切换或消息边界断掉，排查问题时就会变成“每段日志都看起来正常，但整条链路拼不起来”。

建议团队把 Boot 4.1 的可观测性升级当成一次链路标准化机会：

• 统一 trace id、user id、tenant id、request id 的传播规则。
• 明确哪些字段可以进 span attribute，哪些只能进日志摘要，哪些不能记录。
• 对 Agent 工具调用建立独立 span 名称和标签规范，例如 tool.name、tool.result、tool.latency、tool.error_type。
• 为 gRPC 建立与 HTTP 一致的延迟、错误率、状态码、消息大小指标。
• 对 OTel 采样率和日志限制做环境区分，避免开发环境看不到、生产环境撑爆存储。

7. 一张图看 Boot 4.1 的工程位置

flowchart LR
    User[用户请求] --> Gateway[Spring Cloud Gateway]
    Gateway --> Api[Spring Boot 4.1 API]
    Api --> Rest[HTTP Client]
    Rest --> Filter[InetAddressFilter]
    Filter --> External[外部 API / 文档 / SaaS]
    Api --> GrpcClient[gRPC Client]
    GrpcClient --> GrpcServer[gRPC Server]
    Api --> Agent[Agent / Tool Calling]
    Agent --> Rest
    Api --> OTel[OpenTelemetry / Micrometer]
    GrpcServer --> OTel
    Gateway --> OTel

这张图的重点不是“所有服务都要改 gRPC”，而是 Boot 4.1 正在把应用层常见出口统一纳入治理：HTTP 出站要有地址过滤，gRPC 通信要有 starter 和健康安全模型，异步和消息链路要能被追踪。

8. 升级和试点建议

第一阶段：先选一个内部读接口做 gRPC PoC。

• 选择调用频繁、schema 稳定、业务影响可控的接口。
• 保留 HTTP JSON 入口作为对照组。
• 压测延迟、吞吐、CPU、连接数、消息大小和错误处理。
• 验证 gRPC health、reflection、mTLS、安全拦截器、trace metadata。

第二阶段：把出站 HTTP 安全前置。

• 搜索所有 RestClient、RestTemplate、WebClient、HTTP interface client、自研 HTTP 工具类。
• 标记哪些调用目标来自用户、租户配置、消息内容或模型输出。
• 对开放式出站调用启用 InetAddressFilter。
• 明确重定向、DNS rebinding、IPv6、本地地址、云元数据地址的处理策略。

第三阶段：做 Boot 4.1 + Cloud Oakwood 兼容矩阵。

• 固定 Spring Boot、Spring Cloud BOM、Spring Security、Spring Data、Spring Kafka、Spring AMQP 版本。
• 对 Gateway、Config、OpenFeign、Stream、CircuitBreaker 做集成测试。
• 检查 Jackson 3、JSpecify、Jakarta API、废弃 artifact 和插件变化。
• 用一组服务跑完整链路，而不是只跑单元测试。

第四阶段：统一可观测性命名。

• 为 HTTP、gRPC、消息、Agent 工具调用制定 span 命名规范。
• 配置 OTel sampler、limits、exporter SSL bundle。
• 在仪表盘里同时看 HTTP 和 gRPC 的错误率、延迟分位数、消息大小和下游目标。

9. 适合分享时强调的判断

Spring Boot 4.1 不会让所有 Java 微服务立刻切到 gRPC，也不会自动解决 Agent 的安全问题。它真正重要的地方在于：把“通信协议、出站访问、安全过滤、异步上下文、可观测性”这些生产必需能力，继续往 Boot 的默认工程体系里收拢。

对团队来说，最务实的动作不是追着新版本全量升级，而是挑三件事试点：

1. 用一个内部接口验证 Boot gRPC server/client 的开发、测试、部署和观测闭环。
2. 给所有开放式 HTTP 出站调用补 InetAddressFilter，尤其是 Agent、Webhook、URL 抓取场景。
3. 把 Boot 4.1 和 Spring Cloud 2025.1.x 放进同一张兼容矩阵，避免单服务升级造成系统级裂缝。

10. 分享金句

Spring Boot 4.1 的重点不是“Java 终于能方便写 gRPC 了”，而是 Spring 生态正在把微服务通信、出站安全和可观测性变成可配置、可测试、可治理的默认能力。真正成熟的升级，不是把版本号推上去，而是把调用边界、协议契约和观测链路一起推清楚。

参考资料

• Spring Boot 4.1.0 available now
• Spring Boot 4.1 Release Notes
• Spring Boot gRPC Reference
• Spring Boot REST Client - InetAddress Filtering and SSRF Protection
• Spring gRPC 1.1.0 available now
• Spring Cloud Project Page
• Spring Cloud 2025.1.0 aka Oakwood has been released