当前位置：首页 > news >正文

性能压榨指南：Spring Boot 中结合 OkHttp 异步请求与 SSE 实现高性能流式推送

news 2026/3/27 2:33:34

前言

一、场景回放：我们需要解决什么问题？

二、核心技术：OkHttp 的 enqueue 异步入队

三、代码运行机制全流程图解

四、避坑指南与最佳实践

总结

性能压榨指南：Spring Boot 中结合 OkHttp 异步请求与 SSE 实现高性能流式推送

前言

在“ChatGPT 时代”，流式传输（Streaming）已经成为后端服务的标配需求。用户不再愿意等待几十秒直到整个 AI 模型生成完毕才看到结果，他们需要“一个字一个字”地看到动态生成过程。

在 Spring Boot 中，我们通常使用SseEmitter来实现这种服务端推送。然而，很多开发者在调用外部模型 API 时，却不小心踩到了同步阻塞请求的坑，导致服务在高并发下瞬间瘫痪。

今天，我们将通过分析一段实战代码，解密如何利用 OkHttp 的enqueue（异步请求）技术，完美结合 Spring SSE，打造一个高性能、高并发的 AI 智能体代理服务。

一、场景回放：我们需要解决什么问题？

想象一下你正在做一个 Multi-Agent（多智能体）系统。前端发送一个请求，后端需要调用一个外部的长模型 API。这个 API 并不会立刻返回结果，而是通过一个 HTTP 长连接，每秒钟推送一小段生成的 JSON 数据，直到最终生成完毕。

如果你的后端代码是这样写的：

Java

// 错误示范：千万别这么写！ public void handleRequest(SseEmitter sseEmitter) { // 1. 发起外部模型同步调用（当前 Tomcat 线程被卡死，等待外部服务器） Response response = okHttpClient.newCall(request).execute(); // 2. 只有上面这一行完全执行完，才能开始处理数据 // ... 处理流式数据并 send(sseEmitter) ... }

在模型计算的 30 秒内，处理这个用户请求的专有线程会被完全卡住。根据 Little's Law，如果不幸有 200 个用户同时发起请求，而你的 Tomcat 最大线程数恰好也是 200，那么你的整个后端服务将彻底瘫痪，无法响应任何新请求。

二、核心技术：OkHttp 的`enqueue`异步入队

为了解决这个问题，我们必须把“处理用户 HTTP 连接”的线程与“等待外部 API 响应”的线程彻底分开。

这时候，OkHttp 的enqueue方法就粉墨登场了。我们来看一下实战中的代码：

Java

// 核心逻辑节选 public void handleMultiAgentRequest(AgentRequest autoReq, SseEmitter sseEmitter) { // ... 构建 request 和 client ... // 关键点：使用异步 enqueue，而不是同步 execute client.newCall(request).enqueue(new Callback() { // 当外部网络请求彻底失败（超时、网络断开）时回调 @Override public void onFailure(Call call, IOException e) { log.error("onFailure {}", e.getMessage(), e); // 务必通知前端连接结束或失败 sseEmitter.completeWithError(e); } // 当外部服务器开始返回 HTTP 响应头时回调 // 注意：此时 Tomcat 处理线程早已被释放，此方法由 OkHttp 的后台线程执行 @Override public void onResponse(Call call, Response response) { // ... 准备读取流式 Body ... ResponseBody responseBody = response.body(); try { // ... 校验 response.isSuccessful() ... BufferedReader reader = new BufferedReader( new InputStreamReader(responseBody.byteStream()) ); String line; // 在 OkHttp 的后台线程中，死循环读取流式数据的每一行 while ((line = reader.readLine()) != null) { // ... 解析数据，处理心跳 [heartbeat] 或 [DONE] 标记 ... // 将解析后的模型结果实时 send 给前端的 SseEmitter // 这个数据推送过程是全异步的 AgentResponse agentResponse = JSON.parseObject(data, AgentResponse.class); // ... 各种 handler 处理 ... GptProcessResult result = handler.handle(autoReq, agentResponse, agentRespList, eventResult); // 关键调用：推送到前端 sseEmitter.send(result); if (result.isFinished()) { // 结束 SSE 连接 sseEmitter.complete(); } } } catch (Exception e) { log.error("处理流式响应失败", e); sseEmitter.completeWithError(e); } } }); // handleMultiAgentRequest 方法到此结束。 // 此时，Tomcat 线程已经被释放回线程池，而异步网络请求和数据处理正在后台进行。 }

三、代码运行机制全流程图解

这段代码的奇妙之处在于，它完美复用了 Spring 的异步 Servlet 特性和 OkHttp 的内部线程调度：

用户请求到达：Spring Boot 的 Tomcat 处理线程收到前端请求，进入handleMultiAgentRequest方法。
异步入队：调用client.newCall(request).enqueue(...)。OkHttp 的Dispatcher接收到任务，立即将其放入内部队列。此时enqueue方法立刻返回。
释放处理线程：handleMultiAgentRequest方法执行完毕。由于它返回了void（或者如果它是 Controller 方法，返回了SseEmitter），Spring 知道这是一个长连接请求，它会把最初的 Tomcat 处理线程释放回 Tomcat 线程池。
后台执行与等待：OkHttp 的内部专用线程池分出一个工作线程，开始执行真正的网络 I/O，等待外部 API 的响应头和后续的流式 Body。
数据陆续到达：外部 API 返回数据行（如data: {"text": "Hello"}）。OkHttp 的后台工作线程进入onResponse回调，并通过sseEmitter.send()将其陆续推送给最终用户。
清理连接：当外部 API 返回[DONE]标记或连接断开，后台线程调用sseEmitter.complete()，彻底结束这个长连接。

四、避坑指南与最佳实践

在享受异步请求带来的高性能的同时，有几个细节务必注意：

超时时间配置：AI 模型的响应通常很慢。代码中使用了genieConfig.getSseClientReadTimeout()来动态设置readTimeout，这非常实用。对于 Stream 响应，此超时时间应设置得足够长（如 60-120 秒）。
onFailure和异常处理：在异步回调中，你必须显式地调用sseEmitter.completeWithError(e)或sseEmitter.complete()来清理资源。如果不调用，前端的连接可能会一直挂着直到超时，导致服务器资源泄漏。
心跳机制：代码中有一个特殊的heartbeat处理。这在长连接中非常重要。模型生成可能需要很长时间，在生成间隙，后端必须定期向前端发送心跳包（哪怕只是一个空行或注释），防止某些代理服务器（如老旧的 Nginx 默认配置）因为连接长时间无数据交互而强行断开连接。