簡介在大模型應用快速落地的今天企業(yè)普遍面臨多廠商API協(xié)議不統(tǒng)一、密鑰分散、計費不透明等痛點。API網(wǎng)關作為微服務架構中的核心組件能夠在接入層統(tǒng)一處理鑒權、限流、路由與監(jiān)控這一原理同樣適用于大模型調(diào)用場景。通過協(xié)議適配機制將OpenAI、Claude、DeepSeek、通義千問等異構供應商接口轉(zhuǎn)換為標準格式結合Redis令牌桶限流、熔斷降級、AES-GCM密鑰加密存儲和用量計量計費可以構建一套輕量級LLM API統(tǒng)一管理系統(tǒng)。文章完整展示了基于Java 17、Spring Boot 3、Redis和MySQL的實現(xiàn)細節(jié)涵蓋從系統(tǒng)架構設計、核心模塊編碼到Docker Compose部署上線的全流程并給出了流式響應轉(zhuǎn)發(fā)、連接池調(diào)優(yōu)等真實踩坑經(jīng)驗適合企業(yè)統(tǒng)一模型接入和畢業(yè)設計參考。 最近在做一個統(tǒng)一管理大模型 API 的項目調(diào)研了一圈市面上的方案要么太重、要么只適配單一廠商最后決定自己動手實現(xiàn)一套 LLM API 統(tǒng)一管理系統(tǒng)。從項目立項、系統(tǒng)設計、源碼編寫到部署上線整個過程踩了不少坑今天把我的完整思路和核心代碼實現(xiàn)整理出來分享給大家。這個項目不只是一個簡單的 API 轉(zhuǎn)發(fā)代理而是一套完整的管理體系統(tǒng)一協(xié)議轉(zhuǎn)換、多廠商適配、密鑰安全管控、限流熔斷、計量計費、可視化監(jiān)控、審計日志全部都有。源碼和論文我都整理好了項目中使用到的設計模式、技術方案、關鍵配置本文都會給出具體實現(xiàn)細節(jié)。我寫代碼的工具這邊用的是 Java 17 Spring Boot 3 Redis MySQL Vue3這些技術棧比較主流方便有基礎的同學直接上手改造。如果你是剛開始接觸大模型應用開發(fā)或者正在做畢設、公司內(nèi)部想搭一套統(tǒng)一的模型網(wǎng)關這篇文章應該能幫到你。1. 為什么需要一套“統(tǒng)一管理”大模型 API1.1 大模型 API 擴散帶來的真實痛點先說一個我實際工作中遇到的情況。公司內(nèi)部有好幾個業(yè)務團隊算法團隊接了 OpenAI 和 Claude后端團隊接了 DeepSeek 和通義千問前端團隊還自己注冊了智譜的 key。發(fā)展到后來每一個團隊的代碼里都藏著半打 API key調(diào)用的協(xié)議五花八門OpenAI 用/v1/chat/completionsClaude 用/v1/messagesDeepSeek 兼容 OpenAI 但參數(shù)細節(jié)不完全相同通義千問又有一套自己的風格。最頭疼的是下面幾個問題密鑰失控每個團隊自己管 key什么時候過期了、有沒有超預算、被誰拿去調(diào)用了完全不可控。項目代碼倉庫的.env文件里就躺著好幾個生產(chǎn)環(huán)境 key。計費不透明月底財務拿過來一堆大模型賬單根本分不清哪個業(yè)務線花得多、哪個頁面調(diào)得太頻繁甚至分不清哪部分是測試環(huán)境調(diào)的、哪部分是生產(chǎn)環(huán)境調(diào)的。切換廠商成本高今天 DeepSeek 的 API 不穩(wěn)定想臨時切到通義千問但因為各家協(xié)議不同代碼要改好幾處才能切過去改完還得回歸測試。重復代碼嚴重每個團隊都自己封裝了一套“對接大模型的 SDK”只是參數(shù)略有不同。后來我統(tǒng)計了一下全公司至少有 7 套類似的封裝。1.2 這套系統(tǒng)要解決的核心問題所以我要做的這套 LLM API 統(tǒng)一管理系統(tǒng)核心目標很明確所有業(yè)務方不直接對接任何一家大模型廠商而是統(tǒng)一走我們自己的網(wǎng)關。業(yè)務方的代碼里只出現(xiàn)一個 baseURL用標準協(xié)議發(fā)請求由網(wǎng)關做協(xié)議適配、流量調(diào)度、密鑰管理和計量統(tǒng)計。這個思路跟微服務架構里的 API 網(wǎng)關是一樣的把“鑒權、限流、路由、監(jiān)控”這些橫切關注點從業(yè)務代碼里剝出來下沉到網(wǎng)關層統(tǒng)一處理。這樣設計有幾個明顯的好處業(yè)務方接入成本極低統(tǒng)一協(xié)議后端只需要維護一套對接代碼廠商切換只發(fā)生在網(wǎng)關層業(yè)務代碼零改動所有密鑰集中在網(wǎng)關側(cè)加密存儲從源頭上消滅密鑰散落的問題每一次調(diào)用都有日志、有計量、有審計成本歸屬一目了然2. 系統(tǒng)架構與核心模塊設計2.1 整體分層思路整個系統(tǒng)的架構并不復雜但設計的時候我特意按照“控制面”和“數(shù)據(jù)面”分離的思路來組織。所謂控制面就是管理后臺、配置中心、審計報表這些不直接參與請求轉(zhuǎn)發(fā)的部分數(shù)據(jù)面則是真正處理 API 請求的網(wǎng)關核心鏈路。下面是系統(tǒng)分層的邏輯接入層面向業(yè)務方提供一個統(tǒng)一的 HTTP 入口兼容 OpenAI 風格的請求格式這樣業(yè)務方幾乎不需要修改代碼就能接入。核心網(wǎng)關層包含路由分發(fā)、協(xié)議適配、鑒權認證、限流熔斷、計量計費、審計日志等六大部分。這里就是整個系統(tǒng)的“大腦”和“調(diào)度中心”。存儲層MySQL 存放用戶、API Key、模型配置、調(diào)用日志等結構化數(shù)據(jù)Redis 存放限流計數(shù)器、令牌桶、分布式鎖等實時性要求高的數(shù)據(jù)。控制臺層Vue3 管理頁面用于配置模型供應商、管理 API Key、查看調(diào)用監(jiān)控、導出賬單報表。這個分層借鑒了 API 網(wǎng)關的經(jīng)典架構但又針對大模型場景做了專門的優(yōu)化協(xié)議適配層是核心因為大模型廠商的協(xié)議實在太不統(tǒng)一了。2.2 核心模塊劃分與職責我畫模塊圖的時候把整個系統(tǒng)拆成了下面這些模塊每個模塊的職責邊界都比較清晰模塊核心職責關鍵技術點路由分發(fā)根據(jù)請求參數(shù)決定轉(zhuǎn)發(fā)到哪家廠商模型名到供應商映射、加權輪詢協(xié)議適配各家廠商請求/響應格式統(tǒng)一轉(zhuǎn)換適配器模式、SSE 流解析密鑰管理存儲和注入上游廠商 API KeyAES 加密 每次請求動態(tài)注入鑒權認證識別調(diào)用方身份、校驗權限API Key 前綴模式 哈希校驗限流熔斷保護上游資源和下游穩(wěn)定性Redis 令牌桶、滑動窗口熔斷計量計費記錄 token 用量、費用分攤token 校驗與用量解析審計日志全鏈路調(diào)用留痕異步落庫、日志采樣系統(tǒng)管理用戶管理、供應商管理、模型配置RBAC 權限模型2.3 技術選型的取舍我選型的時候有兩個核心考量一是生態(tài)成熟度二是團隊后續(xù)維護成本。后端選了 Java Spring Boot 3因為我的生產(chǎn)環(huán)境里已經(jīng)有很多 Spring 基礎設施運維工具鏈都是現(xiàn)成的。網(wǎng)關核心沒有引入 Spring Cloud Gateway而是自己封裝了一層基于 Servlet 的轉(zhuǎn)發(fā)邏輯原因是我們的場景沒有那么龐大的服務發(fā)現(xiàn)需求大模型 API 的轉(zhuǎn)發(fā)本質(zhì)上是 HTTP 調(diào)用不需要走 Service Mesh 那套。存儲方面MySQL 存元數(shù)據(jù)和調(diào)用流水Redis 做實時計數(shù)和分布式限流。因為要對上游 key 做細粒度的緩存和防抖Redis 是剛需。前端控制臺選了 Vue3 Element Plus這是目前國內(nèi)使用率最高的中后臺技術組合接手門檻低。3. 核心實現(xiàn)協(xié)議適配層如何做到“一次接入隨處調(diào)用”協(xié)議適配是整個系統(tǒng)里技術含量最高的部分。不同大模型廠商的 API 差異很大我一開始接到一個需求“是不是只要把請求轉(zhuǎn)發(fā)出去就行了”實際做起來才發(fā)現(xiàn)完全不是這么回事。3.1 統(tǒng)一 API 協(xié)議設計我定義了一套內(nèi)部的“標準協(xié)議”所有請求進入網(wǎng)關后先轉(zhuǎn)換成這個標準格式再交給適配器去轉(zhuǎn)換成各家廠商的格式。核心請求模型長這樣public class UnifiedChatRequest { private String requestId; // 全局唯一請求ID private String provider; // 指定供應商可選 private String model; // 模型名如 gpt-4o-mini / deepseek-chat private ListChatMessage messages; // 對話消息列表 private Double temperature; // 采樣溫度 private Integer maxTokens; // 最大輸出 token 數(shù) private Boolean stream; // 是否流式返回 private MapString, Object extraParams; // 各家特有參數(shù)透傳 } public class ChatMessage { private String role; // system / user / assistant private String content; private String name; // 可選多輪對話時使用 }選擇這個模型有兩個關鍵考量第一它完全兼容 OpenAI 的請求格式這樣從 OpenAI 切換過來的業(yè)務方基本零成本第二message 結構上留了name字段和extraParams可以承接各家特有參數(shù)。3.2 適配器模式的具體實現(xiàn)我用適配器模式把“標準協(xié)議”轉(zhuǎn)換成各家協(xié)議。核心是一個接口public interface LLMProviderAdapter { String getProviderName(); UnifiedChatResponse chat(UnifiedChatRequest request); void chatStream(UnifiedChatRequest request, StreamCallbackUnifiedChatResponse callback); }每個廠商實現(xiàn)一個 Adapter 類例如OpenAIAdapter、DeepSeekAdapter、QwenAdapter、ClaudeAdapter。路由分發(fā)的時候根據(jù)請求里的模型名或指定的 provider從 Spring 容器里取出對應的 Bean 執(zhí)行。這里最關鍵的一個設計細節(jié)是模型名到適配器的映射關系是數(shù)據(jù)驅(qū)動的存在 MySQL 表里而不是寫死在代碼里。這樣運營人員可以在控制臺上配置一個新的模型名deepseek-chat映射到 DeepSeek 供應商不需要改一行代碼。數(shù)據(jù)庫表設計如下CREATE TABLE llm_model_registry ( id bigint(20) NOT NULL AUTO_INCREMENT, model_name varchar(128) NOT NULL COMMENT 業(yè)務可見的模型名, provider_code varchar(64) NOT NULL COMMENT 供應商編碼, upstream_model_name varchar(128) NOT NULL COMMENT 上游真實模型名, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 0-停用 1-啟用, remark varchar(512) DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_model_name (model_name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;這樣設計的好處是當上游廠商把gpt-4o換成了gpt-4o-mini只需要在配置中心后臺把upstream_model_name改掉業(yè)務方完全無感知。3.3 流式響應的處理細節(jié)流式接口是整個協(xié)議適配里最容易出 bug 的地方。OpenAI 的 SSE 流返回格式跟 Claude 的流返回格式完全不一樣而且還有一個大坑業(yè)務方連接斷開時網(wǎng)關必須能感知到并立即終止上游請求否則 token 費用會一直累計下去。我的實現(xiàn)方案是在轉(zhuǎn)發(fā)層使用 OkHttp 的異步流式調(diào)用把上游的 SSE 字節(jié)流實時轉(zhuǎn)發(fā)給下游。核心是一個 ResponseBodyCallbackprivate void forwardStream(okhttp3.Response upstreamResponse, HttpServletResponse downstreamResponse) throws IOException { downstreamResponse.setContentType(text/event-stream); downstreamResponse.setCharacterEncoding(UTF-8); downstreamResponse.setHeader(Cache-Control, no-cache); try (BufferedReader reader new BufferedReader( new InputStreamReader(upstreamResponse.body().byteStream(), StandardCharsets.UTF_8))) { String line; while ((line reader.readLine()) ! null) { if (downstreamResponse.getWriter().checkError()) { // 下游連接已斷開立即終止 upstreamResponse.close(); break; } downstreamResponse.getWriter().write(line \n); downstreamResponse.getWriter().flush(); } } }這里有一個細節(jié)每一次 write 之后必須 flush否則下游客戶端會一直等不到數(shù)據(jù)。而且用checkError()判斷下游是否已經(jīng)斷開是一個性價比很高的做法比監(jiān)聽回調(diào)里的異常要可靠得多。4. 核心實現(xiàn)密鑰管理、限流熔斷與計量計費4.1 密鑰安全存儲與隔離密鑰管理是整個系統(tǒng)的安全基石。上游廠商的 Key 如果明文存在數(shù)據(jù)庫里一旦數(shù)據(jù)庫泄露就是重大事故。我的方案是AES-GCM 加密后存儲密鑰從環(huán)境變量注入且應用配置文件里絕不出現(xiàn)明文 Key。Component public class SecretCipher { private static final String TRANSFORMATION AES/GCM/NoPadding; private final SecretKey secretKey; public SecretCipher(Value(${cipher.secret-key}) String base64Key) { byte[] keyBytes Base64.getDecoder().decode(base64Key); this.secretKey new SecretKeySpec(keyBytes, AES); } public String encrypt(String plainText) { try { Cipher cipher Cipher.getInstance(TRANSFORMATION); byte[] iv new byte[12]; SecureRandom random new SecureRandom(); random.nextBytes(iv); cipher.init(Cipher.ENCRYPT_MODE, secretKey, new GCMParameterSpec(128, iv)); byte[] encrypted cipher.doFinal(plainText.getBytes(StandardCharsets.UTF_8)); // 把 iv 和密文拼接存儲 ByteBuffer buffer ByteBuffer.allocate(iv.length encrypted.length); buffer.put(iv); buffer.put(encrypted); return Base64.getEncoder().encodeToString(buffer.array()); } catch (Exception e) { throw new RuntimeException(密鑰加密失敗, e); } } }網(wǎng)關發(fā)起上游調(diào)用時從數(shù)據(jù)庫取出密文解密后再放入請求頭。這里有一個性能優(yōu)化點對解密結果做 10 分鐘的本地緩存避免每一個請求都走一次 AES 解密因為解密本身還是有 CPU 開銷的。密鑰隔離也有講究。我給每個上游供應商單獨建一張密鑰表每個供應商可以配置多個 Key網(wǎng)關發(fā)起請求時可以輪詢使用。當一個 Key 因為余額不足或限流返回 401/429 時自動標記異常并切換到下一個 Key。4.2 限流策略與實現(xiàn)大模型 API 比普通 HTTP API 更需要限流因為一旦某個業(yè)務方代碼出現(xiàn)死循環(huán)每分鐘可能消耗上千元 token 費用。我的限流方案是雙層限流第一層按 API Key 維度每個調(diào)用方每分鐘最多 N 次請求第二層按模型維度每個上游模型全局每分鐘最多 M 次請求實現(xiàn)用的 Redis 令牌桶。之所以用令牌桶而不是固定窗口是因為它可以允許一定程度的突發(fā)流量更貼近實際業(yè)務場景。Component public class RedisRateLimiter { Autowired private StringRedisTemplate redisTemplate; private static final String TOKEN_KEY_PREFIX rate:token:; private static final String TIME_KEY_PREFIX rate:time:; public boolean tryAcquire(String key, int capacity, int refillRate) { long now System.currentTimeMillis(); String tokenKey TOKEN_KEY_PREFIX key; String timeKey TIME_KEY_PREFIX key; // Lua 腳本保證原子性 String luaScript local token_key KEYS[1] local time_key KEYS[2] local now tonumber(ARGV[1]) local capacity tonumber(ARGV[2]) local refill_rate tonumber(ARGV[3]) local refill_interval tonumber(ARGV[4]) local current_tokens tonumber(redis.call(get, token_key) or capacity) local last_refill tonumber(redis.call(get, time_key) or now) local elapsed now - last_refill local refill_count math.floor(elapsed / refill_interval) if refill_count 0 then current_tokens math.min(capacity, current_tokens refill_count * refill_rate) redis.call(set, time_key, now) end if current_tokens 0 then redis.call(set, token_key, current_tokens - 1) return 1 else return 0 end ; Long result redisTemplate.execute( new DefaultRedisScript(luaScript, Long.class), Arrays.asList(tokenKey, timeKey), String.valueOf(now), String.valueOf(capacity), String.valueOf(refillRate), String.valueOf(1000) // 每秒補充一次 ); return Long.valueOf(1).equals(result); } }這個 Lua 腳本的妙處在于令牌補充邏輯和扣減邏輯在 Redis 端原子執(zhí)行不會出現(xiàn)并發(fā)情況下多扣或少補的問題。4.3 熔斷與重試策略上游大模型 API 有時候會突然不穩(wěn)定返回 5xx 或響應超時。如果網(wǎng)關不做熔斷保護所有請求都堆積在慢調(diào)用上很快整個系統(tǒng)都會被拖死。我的熔斷器實現(xiàn)借鑒了 Hystrix 的三態(tài)模型關閉、打開、半開。public enum CircuitState { CLOSED, // 正常狀態(tài)放行所有請求 OPEN, // 熔斷狀態(tài)直接拒絕請求 HALF_OPEN // 半開狀態(tài)放行少量探測請求 }狀態(tài)轉(zhuǎn)換規(guī)則默認 CLOSED狀態(tài)滑動窗口統(tǒng)計最近 60 秒內(nèi)的失敗率失敗率超過閾值比如 50%且請求量超過最小請求數(shù)比如 20 次狀態(tài)切換為 OPENOPEN 狀態(tài)持續(xù) 30 秒期間所有請求快速失敗直接返回 50330 秒后進入 HALF_OPEN放行 5 個探測請求全部成功則恢復 CLOSED否則回到 OPEN熔斷器是每個上游供應商維度的代碼里用ConcurrentHashMapString, CircuitBreaker保存避免一個模型故障拖累所有模型。重試策略我也做了很嚴格的約束只能對冪等請求重試且最多重試 1 次。對于流式請求如果已經(jīng)向下游客戶端輸出了部分數(shù)據(jù)絕不能重試否則會產(chǎn)生內(nèi)容錯亂。4.4 計量計費的設計與實現(xiàn)計量計費開始時我本來想放在一個獨立的日志消費模塊里后來為了簡化部署直接用了異步寫庫 定時匯總的方案。上游的響應里都會帶 usage 字段里面包含prompt_tokens、completion_tokens、total_tokens三個值。網(wǎng)關把這個原始 JSON 透傳給業(yè)務方的同時也同步解析并記錄到數(shù)據(jù)庫public class UsageRecord { private Long id; private String requestId; private String apiKeyId; // 哪個調(diào)用方 private String providerCode; // 哪個供應商 private String modelName; // 哪個模型 private Long promptTokens; private Long completionTokens; private Long totalTokens; private BigDecimal cost; // 計算出的費用 private LocalDateTime createTime; }費用計算是基于供應商配置的單價表。我建了一張provider_price表字段包括input_price_per_million、output_price_per_million單位為元/百萬 token。計費時BigDecimal cost inputPrice.multiply(BigDecimal.valueOf(promptTokens)) .divide(BigDecimal.valueOf(1_000_000), 6, RoundingMode.HALF_UP) .add(outputPrice.multiply(BigDecimal.valueOf(completionTokens)) .divide(BigDecimal.valueOf(1_000_000), 6, RoundingMode.HALF_UP));這個方法雖然沒有官方計價那么精確各家有時按緩存命中與否區(qū)分價格但對于按業(yè)務線做成本分攤完全夠用。5. 控制臺與可視化讓 API 調(diào)用狀態(tài)可觀測一個管理系統(tǒng)的價值很大程度上取決于控制臺做得是否好用。我沒有把精力花在花哨的圖表上而是優(yōu)先保證“調(diào)用方能快速定位問題”。5.1 管理臺功能設計控制臺的核心頁面有五個每個頁面解決一類問題儀表盤展示今日總調(diào)用量、總 token 消耗、預估費用、成功率、P95 響應延遲。這些數(shù)據(jù)每 5 秒刷新一次方便運維盯大屏。調(diào)用日志按時間、調(diào)用方、模型、狀態(tài)碼篩選點開詳情能看到完整的請求參數(shù)和響應內(nèi)容支持一鍵復制 curl 命令復現(xiàn)問題。密鑰管理創(chuàng)建/禁用/輪換業(yè)務方的 API Key支持設置 key 的預算上限和日調(diào)用次數(shù)上限。模型管理維護供應商、模型注冊表、單價表配置模型開關。用量報表按天/按周/按月匯總每個調(diào)用方的費用和 token 消耗支持導出 Excel。5.2 數(shù)據(jù)看板的實現(xiàn)細節(jié)儀表盤的后端接口我用了兩個手段保證性能調(diào)用日志和用量數(shù)據(jù)都做了預聚合每 5 分鐘把明細記錄匯總成一條call_stats_hourly記錄大屏查詢只查聚合表不直接掃明細表。儀表盤的接口都加了 Redis 緩存緩存時間 5 秒。對于大屏場景響應速度比實時性更重要。GetMapping(/api/dashboard/overview) public ResultDashboardOverviewVO overview() { String cacheKey dashboard:overview; DashboardOverviewVO vo redisTemplate.opsForValue().get(cacheKey); if (vo null) { vo buildOverview(); redisTemplate.opsForValue().set(cacheKey, vo, 5, TimeUnit.SECONDS); } return Result.success(vo); }另外一個比較重要的監(jiān)控是上游供應商健康狀態(tài)。我在系統(tǒng)里做了一套定時探測機制每 30 秒向各供應商發(fā)一個最小化的 chat 請求只請求 1 個 token如果連續(xù)失敗 3 次就在控制臺標紅并發(fā)告警通知到群。6. 部署實踐與踩坑記錄系統(tǒng)開發(fā)完成之后部署到測試環(huán)境、壓測、上生產(chǎn)這個過程中又踩了不少坑。我把一些非常有價值的經(jīng)驗整理出來。6.1 Docker Compose 一鍵部署項目的交付物里包含一套完整的docker-compose.yml啟動之后就是一套可用的環(huán)境version: 3.8 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root123456 MYSQL_DATABASE: llm_gateway volumes: - ./sql/init.sql:/docker-entrypoint-initdb.d/init.sql - mysql-data:/var/lib/mysql ports: - 3306:3306 redis: image: redis:7.0-alpine ports: - 6379:6379 volumes: - redis-data:/data backend: build: ./backend environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/llm_gateway?useUnicodetruecharacterEncodingutf8 SPRING_DATA_REDIS_HOST: redis CIPHER_SECRET_KEY: dGhpcy1pcy1hLXNlY3JldC1rZXktZm9yLWRlbW8 depends_on: - mysql - redis ports: - 8080:8080 frontend: build: ./frontend depends_on: - backend ports: - 80:80 volumes: mysql-data: redis-data:注意CIPHER_SECRET_KEY這個環(huán)境變量生產(chǎn)環(huán)境一定要用專門的密鑰管理服務如 Vault來管理不能像 demo 環(huán)境這樣硬編碼。6.2 部署中遇到的經(jīng)典問題問題一SSE 流式響應被 Nginx 緩沖前端調(diào)用流式接口時頁面一直等不到數(shù)據(jù)幾十秒后才一次性吐出全部內(nèi)容。排查后發(fā)現(xiàn)是 Nginx 默認開啟了 proxy_buffering把 SSE 流緩沖了。解決方法是在 Nginx 配置中關閉緩沖location /v1/ { proxy_pass http://backend:8080; proxy_buffering off; proxy_cache off; proxy_set_header Connection ; proxy_http_version 1.1; chunked_transfer_encoding on; proxy_read_timeout 300s; }問題二調(diào)用上游時連接池耗盡壓測時發(fā)現(xiàn) QPS 一高很多請求卡在獲取連接上。原因是我直接用了 RestTemplate 默認連接池最大連接數(shù)只有 200。換成 OkHttp 連接池并調(diào)大配置后問題解決Bean public OkHttpClient okHttpClient() { Dispatcher dispatcher new Dispatcher(); dispatcher.setMaxRequests(500); dispatcher.setMaxRequestsPerHost(200); ConnectionPool pool new ConnectionPool(50, 30, TimeUnit.SECONDS); return new OkHttpClient.Builder() .dispatcher(dispatcher) .connectionPool(pool) .connectTimeout(10, TimeUnit.SECONDS) .readTimeout(120, TimeUnit.SECONDS) .writeTimeout(30, TimeUnit.SECONDS) .build(); }這個 readTimeout 一定要設置得足夠大因為大模型流式響應可能會持續(xù)幾十秒甚至幾分鐘。問題三上游返回connection lost mid-response類錯誤我們調(diào)一些不穩(wěn)定的上游接口時會出現(xiàn)響應已經(jīng)發(fā)了一半突然斷連的情況。這個問題的根因往往是上游的負載均衡超時配置太短或者上游在處理長請求時主動斷開了連接。我在適配器層做了針對性的處理如果響應頭已經(jīng)寫入但還沒有完成捕獲 IOException 后記錄一條特殊的“半包日志”方便追查是哪家供應商在哪一段網(wǎng)絡鏈路出的問題。6.3 壓測數(shù)據(jù)與性能調(diào)優(yōu)我拿了 4C8G 的單機部署做壓測開啟 200 并發(fā)壓了 30 分鐘結果如下指標數(shù)值峰值 QPS2100平均響應時間38msP99 響應時間92ms錯誤率0.02%CPU 平均值45%這個性能對于大部分中小型團隊已經(jīng)完全夠用。性能瓶頸主要在于上游 API 的網(wǎng)絡延遲網(wǎng)關自身轉(zhuǎn)發(fā)的開銷占比很小。7. 從源碼到畢業(yè)論文的整理思路這套系統(tǒng)如果是用來做畢業(yè)設計的源碼和論文的配套整理很關鍵。我建議論文按照“需求分析、系統(tǒng)設計、系統(tǒng)實現(xiàn)、系統(tǒng)測試”這四個大塊組織跟源碼模塊一一對應評審老師讀起來會很順。7.1 論文整體架構建議我整理了論文技術部分的參考結構第一章 緒論寫研究背景、國內(nèi)外 API 網(wǎng)關和大模型應用的現(xiàn)狀點出當前大模型 API 管理缺乏統(tǒng)一方案的痛點第二章 相關技術介紹介紹 LLM 基礎概念、Spring Boot、Redis、Vue.js、適配器模式、令牌桶算法等讓評委確認你技術選型有依據(jù)第三章 系統(tǒng)需求分析把功能性需求協(xié)議轉(zhuǎn)換、密鑰管理、計量計費、監(jiān)控告警和非功能性需求性能、安全性、可用性分開描述第四章 系統(tǒng)設計給出架構圖、功能模塊圖、數(shù)據(jù)庫 ER 圖、關鍵接口設計并用文字說明每個模塊為什么這么設計第五章 系統(tǒng)實現(xiàn)按模塊逐個展示關鍵代碼片段配合截圖展示實際運行效果第六章 系統(tǒng)測試包含功能測試用例設計、性能壓測報告、結果分析7.2 從代碼中提煉論文素材的技巧很多同學寫完代碼寫論文的時候反而沒素材。我的做法是每實現(xiàn)完一個功能模塊就順手寫一篇開發(fā)筆記記錄這個模塊解決了什么問題、核心設計思想是什么、用了什么設計模式、測試數(shù)據(jù)如何。這樣論文里的每一個實現(xiàn)章節(jié)都有真實內(nèi)容和數(shù)據(jù)支撐而不是靠拼湊。比如協(xié)議適配這一章我就寫了“為什么要用適配器模式而不是 if-else 判斷”這個在論文答辯時也是很好的加分亮點。8. 系統(tǒng)測試與穩(wěn)定性驗證測試階段我不僅寫了單元測試還寫了集成測試和端到端聯(lián)調(diào)用例。這里說幾個比較重要的測試方案。單元測試主要是對限流器、熔斷器、加密工具類進行測試。熔斷器狀態(tài)流轉(zhuǎn)的測試用例非常重要因為狀態(tài)機邏輯很容易在邊界情況出錯Test void testCircuitBreakerOpenAndHalfOpen() { CircuitBreaker cb new CircuitBreaker(20, 0.5, 30000); // 模擬 20 個請求中 15 個失敗 for (int i 0; i 20; i) { boolean success i 5; cb.recordResult(success); } assertTrue(cb.isOpen()); // 等待 30 秒進入半開狀態(tài) Thread.sleep(30000); assertTrue(cb.isHalfOpen()); // 連續(xù) 5 個探測請求成功熔斷器關閉 for (int i 0; i 5; i) { cb.recordResult(true); } assertFalse(cb.isOpen()); }集成測試則是用 Testcontainers 起一個真實的 MySQL 和 Redis 容器驗證整個請求鏈路是否通。這種方式比 Mock 更加真實能抓出很多環(huán)境依賴的坑。端到端聯(lián)調(diào)時我在測試環(huán)境配了 3 家真實的大模型供應商把每個供應商的流式和非流式調(diào)用都跑了一遍。這個環(huán)節(jié)讓我發(fā)現(xiàn)了很多只在真實網(wǎng)絡環(huán)境下才會出現(xiàn)的問題比如某些供應商對stream_options參數(shù)的支持差異、不同供應商的 timeout 行為等。這套測試流程完整走下來系統(tǒng)的穩(wěn)定性已經(jīng)比較有保障。9. 改進方向與后續(xù)計劃目前這套系統(tǒng)已經(jīng)在我這邊穩(wěn)定運行了一段時間但離想象中的“完美”還有不少距離。我心里有幾個后續(xù)改進的方向也分享給大家參考。一是引入語義緩存。對于相同或相似的請求可以復用之前的響應這個在典型的多輪客服場景里能省不少 token 費用。難點是緩存鍵的設計和相似度計算需要權衡命中率和內(nèi)存消耗。二是增加A/B 測試和灰度發(fā)布capability。當上游廠商發(fā)布新模型時先讓 5% 的流量走新模型觀察效果后再全量切換。這樣能在網(wǎng)關層實現(xiàn)模型迭代的平滑升級。三是引入動態(tài)路由策略。目前是根據(jù)模型名做靜態(tài)路由未來可以做成基于價格、延遲、可用性的動態(tài)評分路由比如某廠商 API 延遲飆升時自動把流量切到其他廠商。四是完善多租戶配額管理。給每個業(yè)務方設置獨立的預算上限當消費金額超過閾值時自動告警甚至熔斷防止預算超支。這些都還是設計思考階段但方向已經(jīng)比較明確。如果你也在做類似項目歡迎一起交流可以互相參考少走一些彎路。本文還有配套的精品資源點擊獲取