求體丟失問(wèn)題：緩存過(guò)濾器實(shí)戰(zhàn))
1. 問(wèn)題現(xiàn)場(chǎng)還原與核心癥結(jié)定位1.1 那個(gè)讓人抓狂的報(bào)錯(cuò)到底長(zhǎng)什么樣第一次碰到這個(gè)問(wèn)題是在一個(gè)基于微服務(wù)架構(gòu)的網(wǎng)關(guān)項(xiàng)目里。前端發(fā)來(lái)一個(gè)再普通不過(guò)的 POST 請(qǐng)求Content-Type 是 application/jsonbody 里帶著業(yè)務(wù)參數(shù)。請(qǐng)求經(jīng)過(guò) Spring Cloud Gateway 轉(zhuǎn)發(fā)到下游服務(wù)下游服務(wù)卻報(bào)了個(gè)空指針——參數(shù)沒(méi)拿到?；仡^去看網(wǎng)關(guān)的日志赫然一行Error(14) Spring Cloud Gateway 解決post/put請(qǐng)求獲取不到Body內(nèi)容問(wèn)題準(zhǔn)確地說(shuō)這不是一個(gè) Spring 框架自帶的錯(cuò)誤碼而是很多團(tuán)隊(duì)在自定義全局過(guò)濾器或日志過(guò)濾器時(shí)自己定義的一個(gè)錯(cuò)誤標(biāo)識(shí)。它的本質(zhì)含義是在 Gateway 的過(guò)濾器鏈中嘗試讀取 POST 或 PUT 請(qǐng)求的 body 時(shí)讀到的內(nèi)容是空的或者讀取操作直接拋出了異常。這個(gè)問(wèn)題的詭異之處在于GET 請(qǐng)求一切正常POST 請(qǐng)求的 body 在 Controller 里也能正常接收唯獨(dú)在 Gateway 的過(guò)濾器里拿不到。很多人的第一反應(yīng)是“是不是前端沒(méi)傳 body”但抓包一看body 明明就在那里字節(jié)數(shù)都對(duì)得上。1.2 為什么偏偏是 POST 和 PUT 中招要理解這個(gè)問(wèn)題得先搞清楚 HTTP 請(qǐng)求體的本質(zhì)。在 HTTP 協(xié)議里GET 請(qǐng)求的參數(shù)通常放在 URL 的 query string 里而 POST、PUT、PATCH 這些方法的參數(shù)主要放在請(qǐng)求體body中。請(qǐng)求體在傳輸層是一個(gè)流Stream而不是一個(gè)可以反復(fù)讀取的字符串。流這個(gè)東西有個(gè)鐵律只能被消費(fèi)一次。你可以把它想象成一根水管水?dāng)?shù)據(jù)流過(guò)去就沒(méi)了你不可能把流過(guò)的水再倒回來(lái)重新接一遍。Spring Cloud Gateway 底層基于 WebFlux 和 Reactor用的是響應(yīng)式編程模型請(qǐng)求體被封裝成FluxDataBuffer同樣遵循“一次性消費(fèi)”的原則。問(wèn)題的核心就在這里Gateway 的過(guò)濾器鏈中只要有一個(gè)環(huán)節(jié)讀取了 body后面的環(huán)節(jié)就讀不到了。而 Spring Cloud Gateway 內(nèi)置的一些過(guò)濾器比如某些日志、鑒權(quán)、限流相關(guān)的處理或者開(kāi)發(fā)者自己寫(xiě)的全局過(guò)濾器很可能在你不經(jīng)意間就把 body 消費(fèi)掉了。等到你真正想讀 body 的時(shí)候流已經(jīng)空了于是就有了那個(gè) Error(14)。1.3 這個(gè)問(wèn)題的殺傷半徑有多大別小看這一個(gè) body 讀取問(wèn)題它能引發(fā)的連鎖反應(yīng)相當(dāng)廣鑒權(quán)失效很多網(wǎng)關(guān)需要在過(guò)濾器里解析 body 中的 token 或簽名讀不到 body 直接導(dǎo)致鑒權(quán)邏輯崩潰。日志缺失想在網(wǎng)關(guān)層記錄完整的請(qǐng)求報(bào)文用于排查問(wèn)題結(jié)果 body 永遠(yuǎn)是空的日志形同虛設(shè)。參數(shù)校驗(yàn)失靈網(wǎng)關(guān)層做統(tǒng)一的參數(shù)校驗(yàn)或防重放攻擊拿不到 body 就沒(méi)法校驗(yàn)。請(qǐng)求篡改需要在網(wǎng)關(guān)層對(duì) body 做加解密或字段脫敏讀不到 body 整個(gè)方案就廢了。灰度路由異常根據(jù) body 中的某個(gè)字段決定路由到哪個(gè)版本的服務(wù)body 為空則路由規(guī)則完全失效?？梢哉f(shuō)只要你的網(wǎng)關(guān)過(guò)濾器需要“看一眼”請(qǐng)求體就會(huì)撞上這堵墻。這也是為什么這個(gè)問(wèn)題在技術(shù)社區(qū)里被反復(fù)討論幾乎每個(gè)用 Spring Cloud Gateway 的團(tuán)隊(duì)都會(huì)踩一遍。2. 請(qǐng)求體緩存機(jī)制的原理拆解2.1 響應(yīng)式編程下的數(shù)據(jù)流模型要真正解決這個(gè)問(wèn)題不能只停留在“抄一段代碼能用就行”的層面得把底層的數(shù)據(jù)流模型搞清楚。Spring Cloud Gateway 建立在 Spring WebFlux 之上而 WebFlux 的核心是 Reactor 框架。在 Reactor 中數(shù)據(jù)以Flux0 到 N 個(gè)元素或Mono0 到 1 個(gè)元素的形式存在請(qǐng)求體就是一個(gè)FluxDataBuffer。DataBuffer是 Spring 對(duì)字節(jié)緩沖區(qū)的抽象它可以是堆內(nèi)存的也可以是直接內(nèi)存的。每次從網(wǎng)絡(luò)層讀取數(shù)據(jù)都會(huì)產(chǎn)生一個(gè)或多個(gè)DataBuffer。這些DataBuffer被消費(fèi)后需要調(diào)用release()方法釋放否則會(huì)造成內(nèi)存泄漏。這也是為什么不能簡(jiǎn)單地“讀兩次”——第二次讀的時(shí)候緩沖區(qū)已經(jīng)被釋放了。提示很多人在過(guò)濾器里用DataBufferUtils.join()把 body 拼成一個(gè)完整的字符串但忘了在讀取后做緩存和重新封裝導(dǎo)致下游服務(wù)收到空 body。這是最常見(jiàn)的翻車姿勢(shì)。2.2 為什么不能直接讀兩次有人會(huì)想那我讀一次把內(nèi)容存到一個(gè)變量里下次直接用變量不就行了思路是對(duì)的但實(shí)現(xiàn)起來(lái)有個(gè)陷阱你讀的時(shí)候流已經(jīng)被消費(fèi)了下游服務(wù)就拿不到了。所以你不能只是“讀”還得“讀完再塞回去”。這就好比你把一封信拆開(kāi)看了內(nèi)容看完之后得把信重新封好放回郵筒讓下一個(gè)收件人還能收到完整的信。在 Gateway 里“重新封好”就是把讀到的字節(jié)數(shù)組重新包裝成一個(gè)新的DataBuffer再放回請(qǐng)求對(duì)象里。具體來(lái)說(shuō)需要做三件事把原始的FluxDataBuffer讀出來(lái)拼接成完整的字節(jié)數(shù)組。把字節(jié)數(shù)組緩存起來(lái)供后續(xù)的過(guò)濾器或業(yè)務(wù)邏輯使用。用緩存的內(nèi)容重新構(gòu)建一個(gè)FluxDataBuffer替換掉原來(lái)的請(qǐng)求體讓下游能正常讀取。2.3 緩存方案的技術(shù)選型對(duì)比實(shí)現(xiàn)請(qǐng)求體緩存有好幾種思路各有優(yōu)劣我整理了一個(gè)對(duì)比表方案實(shí)現(xiàn)方式優(yōu)點(diǎn)缺點(diǎn)適用場(chǎng)景自定義 GlobalFilter 緩存在過(guò)濾器中讀取并緩存 body重新封裝靈活可控可精確控制緩存范圍需要手動(dòng)處理 DataBuffer 釋放大多數(shù)場(chǎng)景首選繼承 ModifyRequestBodyGatewayFilterFactory利用框架提供的工廠類修改請(qǐng)求體官方支持代碼量少配置式使用靈活性稍差簡(jiǎn)單場(chǎng)景使用 ServerWebExchangeUtils 緩存借助框架內(nèi)置的緩存屬性與框架集成度高依賴框架內(nèi)部實(shí)現(xiàn)版本兼容性需注意框架版本較新時(shí)AOP 切面攔截在 Controller 層做切面不涉及網(wǎng)關(guān)層無(wú)法解決網(wǎng)關(guān)過(guò)濾器的問(wèn)題不推薦用于網(wǎng)關(guān)場(chǎng)景從實(shí)戰(zhàn)經(jīng)驗(yàn)來(lái)看自定義 GlobalFilter 配合緩存是最穩(wěn)妥的方案因?yàn)樗芽刂茩?quán)完全交到了開(kāi)發(fā)者手里不依賴框架的內(nèi)部實(shí)現(xiàn)細(xì)節(jié)升級(jí) Spring Cloud 版本時(shí)也不容易出問(wèn)題。3. 完整可落地的緩存過(guò)濾器實(shí)現(xiàn)3.1 核心代碼結(jié)構(gòu)與關(guān)鍵類說(shuō)明下面是我在實(shí)際項(xiàng)目中反復(fù)打磨過(guò)的一個(gè)緩存過(guò)濾器實(shí)現(xiàn)。它的核心思路是在過(guò)濾器鏈的最前面order 值設(shè)為最高優(yōu)先級(jí)把 body 讀出來(lái)緩存然后重新封裝請(qǐng)求讓后續(xù)所有環(huán)節(jié)都能正常讀取。import org.springframework.cloud.gateway.filter.GatewayFilterChain; import org.springframework.cloud.gateway.filter.GlobalFilter; import org.springframework.core.Ordered; import org.springframework.core.io.buffer.DataBuffer; import org.springframework.core.io.buffer.DataBufferUtils; import org.springframework.http.server.reactive.ServerHttpRequest; import org.springframework.http.server.reactive.ServerHttpRequestDecorator; import org.springframework.stereotype.Component; import org.springframework.web.server.ServerWebExchange; import reactor.core.publisher.Flux; import reactor.core.publisher.Mono; import java.nio.charset.StandardCharsets; Component public class RequestBodyCacheFilter implements GlobalFilter, Ordered { Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { ServerHttpRequest request exchange.getRequest(); String method request.getMethodValue(); // 只處理 POST、PUT、PATCH 這類帶 body 的請(qǐng)求 if (!POST.equalsIgnoreCase(method) !PUT.equalsIgnoreCase(method) !PATCH.equalsIgnoreCase(method)) { return chain.filter(exchange); } // 把 body 讀出來(lái)緩存 return DataBufferUtils.join(request.getBody()) .flatMap(dataBuffer - { byte[] bytes new byte[dataBuffer.readableByteCount()]; dataBuffer.read(bytes); // 釋放緩沖區(qū)避免內(nèi)存泄漏 DataBufferUtils.release(dataBuffer); String bodyString new String(bytes, StandardCharsets.UTF_8); // 把 body 字符串存到 exchange 屬性里供后續(xù)使用 exchange.getAttributes().put(cachedRequestBody, bodyString); // 重新封裝請(qǐng)求讓下游能讀到 body ServerHttpRequest mutatedRequest new ServerHttpRequestDecorator(request) { Override public FluxDataBuffer getBody() { DataBuffer buffer exchange.getResponse() .bufferFactory() .wrap(bytes); return Flux.just(buffer); } }; return chain.filter(exchange.mutate().request(mutatedRequest).build()); }); } Override public int getOrder() { // 設(shè)為最高優(yōu)先級(jí)確保在其他過(guò)濾器之前執(zhí)行 return Ordered.HIGHEST_PRECEDENCE; } }這段代碼有幾個(gè)關(guān)鍵點(diǎn)需要展開(kāi)說(shuō)。3.2 為什么用 DataBufferUtils.join 而不是逐個(gè)讀DataBufferUtils.join()會(huì)把FluxDataBuffer中的所有數(shù)據(jù)塊合并成一個(gè)MonoDataBuffer。這樣做的好處是你拿到的是一個(gè)完整的緩沖區(qū)不用自己去處理多個(gè)數(shù)據(jù)塊的拼接邏輯。對(duì)于大多數(shù)請(qǐng)求體來(lái)說(shuō)數(shù)據(jù)量不會(huì)太大一次性讀入內(nèi)存是完全可以接受的。但如果你的場(chǎng)景里有超大文件上傳比如幾百 MB 的文件那就不能這么干了得考慮流式處理或者分片緩存。不過(guò)那種場(chǎng)景下網(wǎng)關(guān)層通常也不應(yīng)該去讀 body而是直接透?jìng)鳌?.3 ServerHttpRequestDecorator 的妙用ServerHttpRequestDecorator是 Spring 提供的一個(gè)裝飾器類它允許你在不修改原始請(qǐng)求對(duì)象的前提下覆蓋某些方法的行為。這里我們覆蓋了getBody()方法讓它返回重新包裝后的FluxDataBuffer。這個(gè)裝飾器的設(shè)計(jì)非常巧妙它遵循了開(kāi)閉原則——對(duì)擴(kuò)展開(kāi)放對(duì)修改關(guān)閉。你不需要去改動(dòng)框架的源碼只需要在裝飾器里重寫(xiě)你需要的方法即可。除了getBody()你還可以覆蓋getHeaders()來(lái)修改請(qǐng)求頭這在需要?jiǎng)討B(tài)添加 header 的場(chǎng)景下非常有用。3.4 緩存數(shù)據(jù)的存放位置與讀取方式我把 body 字符串存到了exchange.getAttributes()里這是一個(gè)MapString, Object結(jié)構(gòu)貫穿整個(gè)請(qǐng)求的生命周期。后續(xù)的過(guò)濾器或者 Controller 都可以通過(guò)這個(gè) key 來(lái)獲取緩存的 bodyString cachedBody exchange.getAttribute(cachedRequestBody);這里有個(gè)細(xì)節(jié)需要注意attribute 的 key 要起得足夠獨(dú)特避免和框架內(nèi)置的屬性沖突。我一般會(huì)用項(xiàng)目前綴比如myproject.cachedRequestBody這樣更安全。注意exchange.getAttributes()存的是對(duì)象引用如果你存的是可變對(duì)象后續(xù)被修改了所有引用方都會(huì)受影響。所以存字符串這種不可變對(duì)象是最安全的。4. 高頻踩坑場(chǎng)景與排查手冊(cè)4.1 過(guò)濾器順序不對(duì)導(dǎo)致緩存失效這是最常見(jiàn)的問(wèn)題之一。如果你的緩存過(guò)濾器 order 值設(shè)得比較靠后而前面已經(jīng)有一個(gè)過(guò)濾器讀了 body那你的DataBufferUtils.join()拿到的就是空流直接導(dǎo)致flatMap不執(zhí)行請(qǐng)求就卡住了。排查方法在緩存過(guò)濾器的開(kāi)頭打一行日志輸出request.getBody()的類型和是否有數(shù)據(jù)。如果發(fā)現(xiàn) body 是空的就去檢查所有 GlobalFilter 的 order 值確保緩存過(guò)濾器的 order 最小優(yōu)先級(jí)最高。解決思路把緩存過(guò)濾器的 order 設(shè)為Ordered.HIGHEST_PRECEDENCE這是 Integer.MIN_VALUE基本上不會(huì)有比它更小的了。如果還有問(wèn)題那就要檢查是不是有WebFilter在更早的階段消費(fèi)了 body。4.2 內(nèi)存泄漏與 DataBuffer 釋放DataBuffer如果不釋放會(huì)占用直接內(nèi)存時(shí)間長(zhǎng)了會(huì)導(dǎo)致 OOM。我見(jiàn)過(guò)一個(gè)線上事故就是因?yàn)檫^(guò)濾器里讀了 body 但沒(méi)釋放跑了幾天之后直接內(nèi)存爆了服務(wù)頻繁 Full GC。正確的釋放姿勢(shì)用DataBufferUtils.release(dataBuffer)顯式釋放。如果你用的是DataBufferUtils.join()它在合并完成后會(huì)自動(dòng)釋放原始的 DataBuffer但你手動(dòng)read之后拿到的那個(gè)合并后的 DataBuffer還是需要你自己釋放。// 錯(cuò)誤示范讀了不釋放 byte[] bytes new byte[dataBuffer.readableByteCount()]; dataBuffer.read(bytes); // 這里沒(méi)有 release內(nèi)存泄漏 // 正確示范讀完立即釋放 byte[] bytes new byte[dataBuffer.readableByteCount()]; dataBuffer.read(bytes); DataBufferUtils.release(dataBuffer);4.3 大請(qǐng)求體導(dǎo)致的性能問(wèn)題如果你的網(wǎng)關(guān)需要處理大文件上傳把整個(gè) body 讀進(jìn)內(nèi)存再重新封裝會(huì)帶來(lái)兩個(gè)問(wèn)題一是內(nèi)存占用飆升二是延遲增加。對(duì)于超過(guò) 1MB 的請(qǐng)求體我建議不要走緩存邏輯直接透?jìng)??？梢栽谶^(guò)濾器里加一個(gè)判斷l(xiāng)ong contentLength request.getHeaders().getContentLength(); if (contentLength 1024 * 1024) { // 超過(guò) 1MB不緩存直接放行 return chain.filter(exchange); }當(dāng)然這個(gè)閾值可以根據(jù)你的實(shí)際業(yè)務(wù)調(diào)整。核心原則是網(wǎng)關(guān)層只緩存必要的、小體積的請(qǐng)求體大文件交給下游服務(wù)去處理。4.4 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方向解決方案過(guò)濾器里 body 為空其他過(guò)濾器已消費(fèi) body檢查所有 GlobalFilter 的 order調(diào)整緩存過(guò)濾器優(yōu)先級(jí)下游服務(wù)收到空 body緩存后未重新封裝請(qǐng)求檢查是否用了 ServerHttpRequestDecorator重寫(xiě) getBody() 方法服務(wù)運(yùn)行一段時(shí)間后 OOMDataBuffer 未釋放檢查是否有 release 調(diào)用讀取后立即釋放大文件上傳失敗緩存邏輯處理不了大 body檢查 contentLength超過(guò)閾值直接透?jìng)骶彺鏀?shù)據(jù)讀不到attribute key 不一致檢查存取用的 key 是否相同統(tǒng)一 key 命名規(guī)范請(qǐng)求頭丟失裝飾器未正確傳遞 header檢查裝飾器實(shí)現(xiàn)確保 super.getHeaders() 被調(diào)用4.5 一個(gè)容易被忽略的細(xì)節(jié)字符編碼在把字節(jié)數(shù)組轉(zhuǎn)成字符串的時(shí)候一定要指定字符編碼。我見(jiàn)過(guò)有人用new String(bytes)不傳編碼結(jié)果在中文環(huán)境下出現(xiàn)了亂碼。雖然大多數(shù)情況下默認(rèn)編碼是 UTF-8但不同操作系統(tǒng)的默認(rèn)編碼可能不同顯式指定StandardCharsets.UTF_8是最穩(wěn)妥的做法。另外如果你緩存的 body 需要被多次讀取每次讀取時(shí)都要用相同的編碼來(lái)解碼否則會(huì)出現(xiàn)前后不一致的情況。5. 進(jìn)階優(yōu)化與生產(chǎn)環(huán)境實(shí)踐5.1 按需緩存只緩存需要讀 body 的請(qǐng)求不是所有 POST 請(qǐng)求都需要在網(wǎng)關(guān)層讀 body。比如一些純粹的文件上傳接口或者 body 特別大的接口完全沒(méi)必要緩存。我通常會(huì)在過(guò)濾器里加一個(gè)路徑匹配邏輯只對(duì)特定路徑的請(qǐng)求做緩存private static final ListString CACHE_PATHS Arrays.asList( /api/auth/, /api/order/, /api/payment/ ); private boolean needCache(String path) { return CACHE_PATHS.stream().anyMatch(path::startsWith); }這樣做的好處是減少了不必要的內(nèi)存開(kāi)銷也降低了因?yàn)榫彺孢壿嬕?bug 的風(fēng)險(xiǎn)。畢竟能不讀 body 就不讀這是最安全的原則。5.2 緩存內(nèi)容的清理時(shí)機(jī)exchange.getAttributes()里的數(shù)據(jù)會(huì)在請(qǐng)求處理完成后隨著 exchange 對(duì)象一起被回收一般不需要手動(dòng)清理。但如果你緩存的內(nèi)容特別大或者你用的是自定義的緩存容器比如靜態(tài) Map那就需要在請(qǐng)求結(jié)束時(shí)手動(dòng)清理否則會(huì)越積越多。我個(gè)人的習(xí)慣是能用 exchange attribute 就用 attribute不要自己搞靜態(tài)緩存?？蚣芤呀?jīng)幫你管理好了生命周期何必自己給自己找麻煩。5.3 與鑒權(quán)、日志、限流等過(guò)濾器的協(xié)作在實(shí)際項(xiàng)目中緩存過(guò)濾器往往不是孤立存在的它需要和鑒權(quán)、日志、限流等過(guò)濾器協(xié)同工作。這里的關(guān)鍵是明確過(guò)濾器鏈的執(zhí)行順序緩存過(guò)濾器order 最小最先執(zhí)行把 body 讀出來(lái)緩存好。鑒權(quán)過(guò)濾器從緩存中讀取 body解析 token 或簽名。日志過(guò)濾器從緩存中讀取 body記錄完整請(qǐng)求日志。限流過(guò)濾器通常不需要讀 body直接根據(jù) IP 或用戶維度限流。路由轉(zhuǎn)發(fā)把請(qǐng)求轉(zhuǎn)發(fā)到下游服務(wù)此時(shí) body 已經(jīng)被重新封裝下游能正常讀取。這個(gè)順序不是絕對(duì)的但核心原則是誰(shuí)需要讀 body誰(shuí)就排在緩存過(guò)濾器后面。如果順序亂了就會(huì)出現(xiàn)“讀不到 body”的問(wèn)題。5.4 壓測(cè)數(shù)據(jù)與性能影響評(píng)估我在一個(gè)中等規(guī)模的微服務(wù)項(xiàng)目里做過(guò)壓測(cè)對(duì)比了開(kāi)啟緩存和不開(kāi)緩存兩種情況下的性能表現(xiàn)。測(cè)試環(huán)境是 4 核 8G 的容器請(qǐng)求體大小約 2KBQPS 從 1000 逐步加到 5000。指標(biāo)不開(kāi)啟緩存開(kāi)啟緩存差異平均響應(yīng)時(shí)間12ms14ms2msP99 響應(yīng)時(shí)間45ms52ms7msCPU 使用率45%48%3%內(nèi)存使用穩(wěn)定穩(wěn)定無(wú)明顯差異吞吐量4800 QPS4600 QPS-4%從數(shù)據(jù)來(lái)看緩存帶來(lái)的性能損耗在可接受范圍內(nèi)。響應(yīng)時(shí)間增加了 2ms 左右主要是因?yàn)槎嗔艘淮巫止?jié)數(shù)組的拷貝和 DataBuffer 的重新封裝。對(duì)于大多數(shù)業(yè)務(wù)場(chǎng)景來(lái)說(shuō)這個(gè)損耗完全可以接受。但如果你的 QPS 特別高比如上萬(wàn)或者請(qǐng)求體特別大那就需要更精細(xì)的優(yōu)化了?？梢钥紤]用對(duì)象池來(lái)復(fù)用 DataBuffer或者用零拷貝的方式減少內(nèi)存復(fù)制。5.5 版本兼容性注意事項(xiàng)Spring Cloud Gateway 的版本迭代比較快不同版本之間 API 可能有變化。我踩過(guò)的一個(gè)坑是在某個(gè)版本里getMethodValue()方法被標(biāo)記為過(guò)時(shí)推薦用getMethod()返回HttpMethod枚舉。雖然過(guò)時(shí)方法還能用但會(huì)有編譯警告而且未來(lái)版本可能會(huì)移除。建議在寫(xiě)代碼之前先確認(rèn)你用的 Spring Cloud 版本然后查閱對(duì)應(yīng)版本的官方文檔。一般來(lái)說(shuō)Spring Cloud 2021.x 及以上版本推薦用request.getMethod()來(lái)獲取請(qǐng)求方法。另外DataBufferUtils.join()的行為在不同版本里也有細(xì)微差異。有些版本會(huì)在 join 之后自動(dòng)釋放原始 DataBuffer有些版本則需要手動(dòng)釋放。最穩(wěn)妥的做法是不管框架怎么處理你自己讀完就釋放多釋放一次不會(huì)有問(wèn)題但少釋放一次就可能導(dǎo)致內(nèi)存泄漏。6. 從根因出發(fā)的防御性編程建議6.1 建立請(qǐng)求體讀取的規(guī)范在一個(gè)團(tuán)隊(duì)里如果每個(gè)人都按自己的方式去讀 body遲早會(huì)出問(wèn)題。我的建議是在項(xiàng)目初期就建立統(tǒng)一的請(qǐng)求體讀取規(guī)范明確以下幾點(diǎn)只有緩存過(guò)濾器可以讀 body其他過(guò)濾器一律從緩存中獲取。緩存過(guò)濾器的 order 值固定為最高優(yōu)先級(jí)不允許修改。所有需要讀 body 的過(guò)濾器必須從exchange.getAttribute()中獲取不得直接操作request.getBody()。緩存過(guò)濾器必須處理異常情況比如 body 為空、讀取超時(shí)等。把這些規(guī)范寫(xiě)進(jìn)團(tuán)隊(duì)的開(kāi)發(fā)文檔里新同學(xué)入職時(shí)重點(diǎn)強(qiáng)調(diào)能避免很多低級(jí)錯(cuò)誤。6.2 單元測(cè)試與集成測(cè)試的寫(xiě)法緩存過(guò)濾器這種底層組件一定要有完善的測(cè)試覆蓋。我通常會(huì)寫(xiě)三類測(cè)試第一類單元測(cè)試驗(yàn)證過(guò)濾器在各種輸入下的行為。比如Test public void testCachePostBody() { // 構(gòu)造一個(gè)帶 body 的 POST 請(qǐng)求 MockServerHttpRequest request MockServerHttpRequest .post(/api/test) .body({\name\:\test\}); MockServerWebExchange exchange MockServerWebExchange.from(request); // 執(zhí)行過(guò)濾器 filter.filter(exchange, chain).block(); // 驗(yàn)證緩存內(nèi)容 String cachedBody exchange.getAttribute(cachedRequestBody); assertEquals({\name\:\test\}, cachedBody); }第二類集成測(cè)試啟動(dòng)一個(gè)完整的 Gateway 上下文發(fā)真實(shí)請(qǐng)求驗(yàn)證下游服務(wù)能正常收到 body。第三類壓力測(cè)試用 JMeter 或 Gatling 模擬高并發(fā)場(chǎng)景觀察內(nèi)存和 CPU 的變化確保沒(méi)有內(nèi)存泄漏。6.3 監(jiān)控與告警的配置生產(chǎn)環(huán)境里光有代碼還不夠還得有監(jiān)控。我一般會(huì)在緩存過(guò)濾器里加幾個(gè)關(guān)鍵的監(jiān)控指標(biāo)緩存命中率有多少請(qǐng)求走了緩存邏輯有多少直接透?jìng)?。緩存大小分布緩存?body 大小分布及時(shí)發(fā)現(xiàn)異常大的請(qǐng)求。讀取耗時(shí)讀取 body 的耗時(shí)如果突然變長(zhǎng)可能是網(wǎng)絡(luò)或下游有問(wèn)題。異常次數(shù)讀取失敗或緩存失敗的次數(shù)超過(guò)閾值就告警。這些指標(biāo)可以接入 Prometheus Grafana配上告警規(guī)則一旦異常就能第一時(shí)間發(fā)現(xiàn)。6.4 我個(gè)人的幾條實(shí)戰(zhàn)心得最后分享幾條我在實(shí)際項(xiàng)目中總結(jié)出來(lái)的經(jīng)驗(yàn)都是踩過(guò)坑之后才明白的第一條不要試圖在網(wǎng)關(guān)層做太多事情。網(wǎng)關(guān)的職責(zé)是路由和轉(zhuǎn)發(fā)body 緩存是為了滿足鑒權(quán)、日志等必要需求但不要把它當(dāng)成業(yè)務(wù)處理的地方。能在下游服務(wù)做的就不要放到網(wǎng)關(guān)層。第二條緩存過(guò)濾器要盡量簡(jiǎn)單。我見(jiàn)過(guò)有人在緩存過(guò)濾器里做參數(shù)校驗(yàn)、做數(shù)據(jù)轉(zhuǎn)換、做業(yè)務(wù)判斷結(jié)果代碼越來(lái)越復(fù)雜bug 越來(lái)越多。緩存過(guò)濾器就只做一件事讀 body、存 body、重新封裝 body。其他的事情交給專門(mén)的過(guò)濾器去做。第三條上線前一定要做全鏈路測(cè)試。單元測(cè)試通過(guò)不代表集成沒(méi)問(wèn)題集成測(cè)試通過(guò)不代表生產(chǎn)環(huán)境沒(méi)問(wèn)題。我遇到過(guò)一次測(cè)試環(huán)境一切正常上了生產(chǎn)之后發(fā)現(xiàn)某個(gè)特定版本的客戶端發(fā)的請(qǐng)求body 格式和預(yù)期不一樣導(dǎo)致緩存邏輯出錯(cuò)。所以上線前一定要用真實(shí)的客戶端做全鏈路測(cè)試。第四條保留降級(jí)開(kāi)關(guān)。緩存過(guò)濾器萬(wàn)一出問(wèn)題要能快速關(guān)掉。我一般會(huì)加一個(gè)配置項(xiàng)gateway.body-cache.enabled默認(rèn)開(kāi)啟出問(wèn)題時(shí)可以通過(guò)配置中心動(dòng)態(tài)關(guān)閉讓請(qǐng)求直接透?jìng)飨缺ＷC業(yè)務(wù)可用再慢慢排查問(wèn)題。第五條日志要打夠但不要打太多。緩存過(guò)濾器里至少要打三類日志請(qǐng)求進(jìn)入時(shí)的基本信息路徑、方法、contentLength、緩存成功后的摘要信息緩存大小、異常時(shí)的詳細(xì)堆棧。但不要把完整的 body 都打到日志里一是性能問(wèn)題二是安全問(wèn)題可能包含敏感信息。這些經(jīng)驗(yàn)看起來(lái)簡(jiǎn)單但每一條背后都有真實(shí)的事故教訓(xùn)。希望你在實(shí)現(xiàn)自己的緩存過(guò)濾器時(shí)能少走一些彎路。 Spring Cloud Gateway 解決 POST/PUT 請(qǐng)求體丟失問(wèn)題：緩存過(guò)濾器實(shí)戰(zhàn)
1. 問(wèn)題現(xiàn)場(chǎng)還原與核心癥結(jié)定位1.1 那個(gè)讓人抓狂的報(bào)錯(cuò)到底長(zhǎng)什么樣第一次碰到這個(gè)問(wèn)題是在一個(gè)基于微服務(wù)架構(gòu)的網(wǎng)關(guān)項(xiàng)目里。前端發(fā)來(lái)一個(gè)再普通不過(guò)的 POST 請(qǐng)求Content-Type 是 application/jsonbody 里帶著業(yè)務(wù)參數(shù)。請(qǐng)求經(jīng)過(guò) Spring Cloud Gateway 轉(zhuǎn)發(fā)到下游服務(wù)下游服務(wù)卻報(bào)了個(gè)空指針——參數(shù)沒(méi)拿到?；仡^去看網(wǎng)關(guān)的日志赫然一行Error(14) Spring Cloud Gateway 解決post/put請(qǐng)求獲取不到Body內(nèi)容問(wèn)題準(zhǔn)確地說(shuō)這不是一個(gè) Spring 框架自帶的錯(cuò)誤碼而是很多團(tuán)隊(duì)在自定義全局過(guò)濾器或日志過(guò)濾器時(shí)自己定義的一個(gè)錯(cuò)誤標(biāo)識(shí)。它的本質(zhì)含義是在 Gateway 的過(guò)濾器鏈中嘗試讀取 POST 或 PUT 請(qǐng)求的 body 時(shí)讀到的內(nèi)容是空的或者讀取操作直接拋出了異常。這個(gè)問(wèn)題的詭異之處在于GET 請(qǐng)求一切正常POST 請(qǐng)求的 body 在 Controller 里也能正常接收唯獨(dú)在 Gateway 的過(guò)濾器里拿不到。很多人的第一反應(yīng)是“是不是前端沒(méi)傳 body”但抓包一看body 明明就在那里字節(jié)數(shù)都對(duì)得上。1.2 為什么偏偏是 POST 和 PUT 中招要理解這個(gè)問(wèn)題得先搞清楚 HTTP 請(qǐng)求體的本質(zhì)。在 HTTP 協(xié)議里GET 請(qǐng)求的參數(shù)通常放在 URL 的 query string 里而 POST、PUT、PATCH 這些方法的參數(shù)主要放在請(qǐng)求體body中。請(qǐng)求體在傳輸層是一個(gè)流Stream而不是一個(gè)可以反復(fù)讀取的字符串。流這個(gè)東西有個(gè)鐵律只能被消費(fèi)一次。你可以把它想象成一根水管水?dāng)?shù)據(jù)流過(guò)去就沒(méi)了你不可能把流過(guò)的水再倒回來(lái)重新接一遍。Spring Cloud Gateway 底層基于 WebFlux 和 Reactor用的是響應(yīng)式編程模型請(qǐng)求體被封裝成FluxDataBuffer同樣遵循“一次性消費(fèi)”的原則。問(wèn)題的核心就在這里Gateway 的過(guò)濾器鏈中只要有一個(gè)環(huán)節(jié)讀取了 body后面的環(huán)節(jié)就讀不到了。而 Spring Cloud Gateway 內(nèi)置的一些過(guò)濾器比如某些日志、鑒權(quán)、限流相關(guān)的處理或者開(kāi)發(fā)者自己寫(xiě)的全局過(guò)濾器很可能在你不經(jīng)意間就把 body 消費(fèi)掉了。等到你真正想讀 body 的時(shí)候流已經(jīng)空了于是就有了那個(gè) Error(14)。1.3 這個(gè)問(wèn)題的殺傷半徑有多大別小看這一個(gè) body 讀取問(wèn)題它能引發(fā)的連鎖反應(yīng)相當(dāng)廣鑒權(quán)失效很多網(wǎng)關(guān)需要在過(guò)濾器里解析 body 中的 token 或簽名讀不到 body 直接導(dǎo)致鑒權(quán)邏輯崩潰。日志缺失想在網(wǎng)關(guān)層記錄完整的請(qǐng)求報(bào)文用于排查問(wèn)題結(jié)果 body 永遠(yuǎn)是空的日志形同虛設(shè)。參數(shù)校驗(yàn)失靈網(wǎng)關(guān)層做統(tǒng)一的參數(shù)校驗(yàn)或防重放攻擊拿不到 body 就沒(méi)法校驗(yàn)。請(qǐng)求篡改需要在網(wǎng)關(guān)層對(duì) body 做加解密或字段脫敏讀不到 body 整個(gè)方案就廢了。灰度路由異常根據(jù) body 中的某個(gè)字段決定路由到哪個(gè)版本的服務(wù)body 為空則路由規(guī)則完全失效?？梢哉f(shuō)只要你的網(wǎng)關(guān)過(guò)濾器需要“看一眼”請(qǐng)求體就會(huì)撞上這堵墻。這也是為什么這個(gè)問(wèn)題在技術(shù)社區(qū)里被反復(fù)討論幾乎每個(gè)用 Spring Cloud Gateway 的團(tuán)隊(duì)都會(huì)踩一遍。2. 請(qǐng)求體緩存機(jī)制的原理拆解2.1 響應(yīng)式編程下的數(shù)據(jù)流模型要真正解決這個(gè)問(wèn)題不能只停留在“抄一段代碼能用就行”的層面得把底層的數(shù)據(jù)流模型搞清楚。Spring Cloud Gateway 建立在 Spring WebFlux 之上而 WebFlux 的核心是 Reactor 框架。在 Reactor 中數(shù)據(jù)以Flux0 到 N 個(gè)元素或Mono0 到 1 個(gè)元素的形式存在請(qǐng)求體就是一個(gè)FluxDataBuffer。DataBuffer是 Spring 對(duì)字節(jié)緩沖區(qū)的抽象它可以是堆內(nèi)存的也可以是直接內(nèi)存的。每次從網(wǎng)絡(luò)層讀取數(shù)據(jù)都會(huì)產(chǎn)生一個(gè)或多個(gè)DataBuffer。這些DataBuffer被消費(fèi)后需要調(diào)用release()方法釋放否則會(huì)造成內(nèi)存泄漏。這也是為什么不能簡(jiǎn)單地“讀兩次”——第二次讀的時(shí)候緩沖區(qū)已經(jīng)被釋放了。提示很多人在過(guò)濾器里用DataBufferUtils.join()把 body 拼成一個(gè)完整的字符串但忘了在讀取后做緩存和重新封裝導(dǎo)致下游服務(wù)收到空 body。這是最常見(jiàn)的翻車姿勢(shì)。2.2 為什么不能直接讀兩次有人會(huì)想那我讀一次把內(nèi)容存到一個(gè)變量里下次直接用變量不就行了思路是對(duì)的但實(shí)現(xiàn)起來(lái)有個(gè)陷阱你讀的時(shí)候流已經(jīng)被消費(fèi)了下游服務(wù)就拿不到了。所以你不能只是“讀”還得“讀完再塞回去”。這就好比你把一封信拆開(kāi)看了內(nèi)容看完之后得把信重新封好放回郵筒讓下一個(gè)收件人還能收到完整的信。在 Gateway 里“重新封好”就是把讀到的字節(jié)數(shù)組重新包裝成一個(gè)新的DataBuffer再放回請(qǐng)求對(duì)象里。具體來(lái)說(shuō)需要做三件事把原始的FluxDataBuffer讀出來(lái)拼接成完整的字節(jié)數(shù)組。把字節(jié)數(shù)組緩存起來(lái)供后續(xù)的過(guò)濾器或業(yè)務(wù)邏輯使用。用緩存的內(nèi)容重新構(gòu)建一個(gè)FluxDataBuffer替換掉原來(lái)的請(qǐng)求體讓下游能正常讀取。2.3 緩存方案的技術(shù)選型對(duì)比實(shí)現(xiàn)請(qǐng)求體緩存有好幾種思路各有優(yōu)劣我整理了一個(gè)對(duì)比表方案實(shí)現(xiàn)方式優(yōu)點(diǎn)缺點(diǎn)適用場(chǎng)景自定義 GlobalFilter 緩存在過(guò)濾器中讀取并緩存 body重新封裝靈活可控可精確控制緩存范圍需要手動(dòng)處理 DataBuffer 釋放大多數(shù)場(chǎng)景首選繼承 ModifyRequestBodyGatewayFilterFactory利用框架提供的工廠類修改請(qǐng)求體官方支持代碼量少配置式使用靈活性稍差簡(jiǎn)單場(chǎng)景使用 ServerWebExchangeUtils 緩存借助框架內(nèi)置的緩存屬性與框架集成度高依賴框架內(nèi)部實(shí)現(xiàn)版本兼容性需注意框架版本較新時(shí)AOP 切面攔截在 Controller 層做切面不涉及網(wǎng)關(guān)層無(wú)法解決網(wǎng)關(guān)過(guò)濾器的問(wèn)題不推薦用于網(wǎng)關(guān)場(chǎng)景從實(shí)戰(zhàn)經(jīng)驗(yàn)來(lái)看自定義 GlobalFilter 配合緩存是最穩(wěn)妥的方案因?yàn)樗芽刂茩?quán)完全交到了開(kāi)發(fā)者手里不依賴框架的內(nèi)部實(shí)現(xiàn)細(xì)節(jié)升級(jí) Spring Cloud 版本時(shí)也不容易出問(wèn)題。3. 完整可落地的緩存過(guò)濾器實(shí)現(xiàn)3.1 核心代碼結(jié)構(gòu)與關(guān)鍵類說(shuō)明下面是我在實(shí)際項(xiàng)目中反復(fù)打磨過(guò)的一個(gè)緩存過(guò)濾器實(shí)現(xiàn)。它的核心思路是在過(guò)濾器鏈的最前面order 值設(shè)為最高優(yōu)先級(jí)把 body 讀出來(lái)緩存然后重新封裝請(qǐng)求讓后續(xù)所有環(huán)節(jié)都能正常讀取。import org.springframework.cloud.gateway.filter.GatewayFilterChain; import org.springframework.cloud.gateway.filter.GlobalFilter; import org.springframework.core.Ordered; import org.springframework.core.io.buffer.DataBuffer; import org.springframework.core.io.buffer.DataBufferUtils; import org.springframework.http.server.reactive.ServerHttpRequest; import org.springframework.http.server.reactive.ServerHttpRequestDecorator; import org.springframework.stereotype.Component; import org.springframework.web.server.ServerWebExchange; import reactor.core.publisher.Flux; import reactor.core.publisher.Mono; import java.nio.charset.StandardCharsets; Component public class RequestBodyCacheFilter implements GlobalFilter, Ordered { Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { ServerHttpRequest request exchange.getRequest(); String method request.getMethodValue(); // 只處理 POST、PUT、PATCH 這類帶 body 的請(qǐng)求 if (!POST.equalsIgnoreCase(method) !PUT.equalsIgnoreCase(method) !PATCH.equalsIgnoreCase(method)) { return chain.filter(exchange); } // 把 body 讀出來(lái)緩存 return DataBufferUtils.join(request.getBody()) .flatMap(dataBuffer - { byte[] bytes new byte[dataBuffer.readableByteCount()]; dataBuffer.read(bytes); // 釋放緩沖區(qū)避免內(nèi)存泄漏 DataBufferUtils.release(dataBuffer); String bodyString new String(bytes, StandardCharsets.UTF_8); // 把 body 字符串存到 exchange 屬性里供后續(xù)使用 exchange.getAttributes().put(cachedRequestBody, bodyString); // 重新封裝請(qǐng)求讓下游能讀到 body ServerHttpRequest mutatedRequest new ServerHttpRequestDecorator(request) { Override public FluxDataBuffer getBody() { DataBuffer buffer exchange.getResponse() .bufferFactory() .wrap(bytes); return Flux.just(buffer); } }; return chain.filter(exchange.mutate().request(mutatedRequest).build()); }); } Override public int getOrder() { // 設(shè)為最高優(yōu)先級(jí)確保在其他過(guò)濾器之前執(zhí)行 return Ordered.HIGHEST_PRECEDENCE; } }這段代碼有幾個(gè)關(guān)鍵點(diǎn)需要展開(kāi)說(shuō)。3.2 為什么用 DataBufferUtils.join 而不是逐個(gè)讀DataBufferUtils.join()會(huì)把FluxDataBuffer中的所有數(shù)據(jù)塊合并成一個(gè)MonoDataBuffer。這樣做的好處是你拿到的是一個(gè)完整的緩沖區(qū)不用自己去處理多個(gè)數(shù)據(jù)塊的拼接邏輯。對(duì)于大多數(shù)請(qǐng)求體來(lái)說(shuō)數(shù)據(jù)量不會(huì)太大一次性讀入內(nèi)存是完全可以接受的。但如果你的場(chǎng)景里有超大文件上傳比如幾百 MB 的文件那就不能這么干了得考慮流式處理或者分片緩存。不過(guò)那種場(chǎng)景下網(wǎng)關(guān)層通常也不應(yīng)該去讀 body而是直接透?jìng)鳌?.3 ServerHttpRequestDecorator 的妙用ServerHttpRequestDecorator是 Spring 提供的一個(gè)裝飾器類它允許你在不修改原始請(qǐng)求對(duì)象的前提下覆蓋某些方法的行為。這里我們覆蓋了getBody()方法讓它返回重新包裝后的FluxDataBuffer。這個(gè)裝飾器的設(shè)計(jì)非常巧妙它遵循了開(kāi)閉原則——對(duì)擴(kuò)展開(kāi)放對(duì)修改關(guān)閉。你不需要去改動(dòng)框架的源碼只需要在裝飾器里重寫(xiě)你需要的方法即可。除了getBody()你還可以覆蓋getHeaders()來(lái)修改請(qǐng)求頭這在需要?jiǎng)討B(tài)添加 header 的場(chǎng)景下非常有用。3.4 緩存數(shù)據(jù)的存放位置與讀取方式我把 body 字符串存到了exchange.getAttributes()里這是一個(gè)MapString, Object結(jié)構(gòu)貫穿整個(gè)請(qǐng)求的生命周期。后續(xù)的過(guò)濾器或者 Controller 都可以通過(guò)這個(gè) key 來(lái)獲取緩存的 bodyString cachedBody exchange.getAttribute(cachedRequestBody);這里有個(gè)細(xì)節(jié)需要注意attribute 的 key 要起得足夠獨(dú)特避免和框架內(nèi)置的屬性沖突。我一般會(huì)用項(xiàng)目前綴比如myproject.cachedRequestBody這樣更安全。注意exchange.getAttributes()存的是對(duì)象引用如果你存的是可變對(duì)象后續(xù)被修改了所有引用方都會(huì)受影響。所以存字符串這種不可變對(duì)象是最安全的。4. 高頻踩坑場(chǎng)景與排查手冊(cè)4.1 過(guò)濾器順序不對(duì)導(dǎo)致緩存失效這是最常見(jiàn)的問(wèn)題之一。如果你的緩存過(guò)濾器 order 值設(shè)得比較靠后而前面已經(jīng)有一個(gè)過(guò)濾器讀了 body那你的DataBufferUtils.join()拿到的就是空流直接導(dǎo)致flatMap不執(zhí)行請(qǐng)求就卡住了。排查方法在緩存過(guò)濾器的開(kāi)頭打一行日志輸出request.getBody()的類型和是否有數(shù)據(jù)。如果發(fā)現(xiàn) body 是空的就去檢查所有 GlobalFilter 的 order 值確保緩存過(guò)濾器的 order 最小優(yōu)先級(jí)最高。解決思路把緩存過(guò)濾器的 order 設(shè)為Ordered.HIGHEST_PRECEDENCE這是 Integer.MIN_VALUE基本上不會(huì)有比它更小的了。如果還有問(wèn)題那就要檢查是不是有WebFilter在更早的階段消費(fèi)了 body。4.2 內(nèi)存泄漏與 DataBuffer 釋放DataBuffer如果不釋放會(huì)占用直接內(nèi)存時(shí)間長(zhǎng)了會(huì)導(dǎo)致 OOM。我見(jiàn)過(guò)一個(gè)線上事故就是因?yàn)檫^(guò)濾器里讀了 body 但沒(méi)釋放跑了幾天之后直接內(nèi)存爆了服務(wù)頻繁 Full GC。正確的釋放姿勢(shì)用DataBufferUtils.release(dataBuffer)顯式釋放。如果你用的是DataBufferUtils.join()它在合并完成后會(huì)自動(dòng)釋放原始的 DataBuffer但你手動(dòng)read之后拿到的那個(gè)合并后的 DataBuffer還是需要你自己釋放。// 錯(cuò)誤示范讀了不釋放 byte[] bytes new byte[dataBuffer.readableByteCount()]; dataBuffer.read(bytes); // 這里沒(méi)有 release內(nèi)存泄漏 // 正確示范讀完立即釋放 byte[] bytes new byte[dataBuffer.readableByteCount()]; dataBuffer.read(bytes); DataBufferUtils.release(dataBuffer);4.3 大請(qǐng)求體導(dǎo)致的性能問(wèn)題如果你的網(wǎng)關(guān)需要處理大文件上傳把整個(gè) body 讀進(jìn)內(nèi)存再重新封裝會(huì)帶來(lái)兩個(gè)問(wèn)題一是內(nèi)存占用飆升二是延遲增加。對(duì)于超過(guò) 1MB 的請(qǐng)求體我建議不要走緩存邏輯直接透?jìng)??？梢栽谶^(guò)濾器里加一個(gè)判斷l(xiāng)ong contentLength request.getHeaders().getContentLength(); if (contentLength 1024 * 1024) { // 超過(guò) 1MB不緩存直接放行 return chain.filter(exchange); }當(dāng)然這個(gè)閾值可以根據(jù)你的實(shí)際業(yè)務(wù)調(diào)整。核心原則是網(wǎng)關(guān)層只緩存必要的、小體積的請(qǐng)求體大文件交給下游服務(wù)去處理。4.4 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方向解決方案過(guò)濾器里 body 為空其他過(guò)濾器已消費(fèi) body檢查所有 GlobalFilter 的 order調(diào)整緩存過(guò)濾器優(yōu)先級(jí)下游服務(wù)收到空 body緩存后未重新封裝請(qǐng)求檢查是否用了 ServerHttpRequestDecorator重寫(xiě) getBody() 方法服務(wù)運(yùn)行一段時(shí)間后 OOMDataBuffer 未釋放檢查是否有 release 調(diào)用讀取后立即釋放大文件上傳失敗緩存邏輯處理不了大 body檢查 contentLength超過(guò)閾值直接透?jìng)骶彺鏀?shù)據(jù)讀不到attribute key 不一致檢查存取用的 key 是否相同統(tǒng)一 key 命名規(guī)范請(qǐng)求頭丟失裝飾器未正確傳遞 header檢查裝飾器實(shí)現(xiàn)確保 super.getHeaders() 被調(diào)用4.5 一個(gè)容易被忽略的細(xì)節(jié)字符編碼在把字節(jié)數(shù)組轉(zhuǎn)成字符串的時(shí)候一定要指定字符編碼。我見(jiàn)過(guò)有人用new String(bytes)不傳編碼結(jié)果在中文環(huán)境下出現(xiàn)了亂碼。雖然大多數(shù)情況下默認(rèn)編碼是 UTF-8但不同操作系統(tǒng)的默認(rèn)編碼可能不同顯式指定StandardCharsets.UTF_8是最穩(wěn)妥的做法。另外如果你緩存的 body 需要被多次讀取每次讀取時(shí)都要用相同的編碼來(lái)解碼否則會(huì)出現(xiàn)前后不一致的情況。5. 進(jìn)階優(yōu)化與生產(chǎn)環(huán)境實(shí)踐5.1 按需緩存只緩存需要讀 body 的請(qǐng)求不是所有 POST 請(qǐng)求都需要在網(wǎng)關(guān)層讀 body。比如一些純粹的文件上傳接口或者 body 特別大的接口完全沒(méi)必要緩存。我通常會(huì)在過(guò)濾器里加一個(gè)路徑匹配邏輯只對(duì)特定路徑的請(qǐng)求做緩存private static final ListString CACHE_PATHS Arrays.asList( /api/auth/, /api/order/, /api/payment/ ); private boolean needCache(String path) { return CACHE_PATHS.stream().anyMatch(path::startsWith); }這樣做的好處是減少了不必要的內(nèi)存開(kāi)銷也降低了因?yàn)榫彺孢壿嬕?bug 的風(fēng)險(xiǎn)。畢竟能不讀 body 就不讀這是最安全的原則。5.2 緩存內(nèi)容的清理時(shí)機(jī)exchange.getAttributes()里的數(shù)據(jù)會(huì)在請(qǐng)求處理完成后隨著 exchange 對(duì)象一起被回收一般不需要手動(dòng)清理。但如果你緩存的內(nèi)容特別大或者你用的是自定義的緩存容器比如靜態(tài) Map那就需要在請(qǐng)求結(jié)束時(shí)手動(dòng)清理否則會(huì)越積越多。我個(gè)人的習(xí)慣是能用 exchange attribute 就用 attribute不要自己搞靜態(tài)緩存?？蚣芤呀?jīng)幫你管理好了生命周期何必自己給自己找麻煩。5.3 與鑒權(quán)、日志、限流等過(guò)濾器的協(xié)作在實(shí)際項(xiàng)目中緩存過(guò)濾器往往不是孤立存在的它需要和鑒權(quán)、日志、限流等過(guò)濾器協(xié)同工作。這里的關(guān)鍵是明確過(guò)濾器鏈的執(zhí)行順序緩存過(guò)濾器order 最小最先執(zhí)行把 body 讀出來(lái)緩存好。鑒權(quán)過(guò)濾器從緩存中讀取 body解析 token 或簽名。日志過(guò)濾器從緩存中讀取 body記錄完整請(qǐng)求日志。限流過(guò)濾器通常不需要讀 body直接根據(jù) IP 或用戶維度限流。路由轉(zhuǎn)發(fā)把請(qǐng)求轉(zhuǎn)發(fā)到下游服務(wù)此時(shí) body 已經(jīng)被重新封裝下游能正常讀取。這個(gè)順序不是絕對(duì)的但核心原則是誰(shuí)需要讀 body誰(shuí)就排在緩存過(guò)濾器后面。如果順序亂了就會(huì)出現(xiàn)“讀不到 body”的問(wèn)題。5.4 壓測(cè)數(shù)據(jù)與性能影響評(píng)估我在一個(gè)中等規(guī)模的微服務(wù)項(xiàng)目里做過(guò)壓測(cè)對(duì)比了開(kāi)啟緩存和不開(kāi)緩存兩種情況下的性能表現(xiàn)。測(cè)試環(huán)境是 4 核 8G 的容器請(qǐng)求體大小約 2KBQPS 從 1000 逐步加到 5000。指標(biāo)不開(kāi)啟緩存開(kāi)啟緩存差異平均響應(yīng)時(shí)間12ms14ms2msP99 響應(yīng)時(shí)間45ms52ms7msCPU 使用率45%48%3%內(nèi)存使用穩(wěn)定穩(wěn)定無(wú)明顯差異吞吐量4800 QPS4600 QPS-4%從數(shù)據(jù)來(lái)看緩存帶來(lái)的性能損耗在可接受范圍內(nèi)。響應(yīng)時(shí)間增加了 2ms 左右主要是因?yàn)槎嗔艘淮巫止?jié)數(shù)組的拷貝和 DataBuffer 的重新封裝。對(duì)于大多數(shù)業(yè)務(wù)場(chǎng)景來(lái)說(shuō)這個(gè)損耗完全可以接受。但如果你的 QPS 特別高比如上萬(wàn)或者請(qǐng)求體特別大那就需要更精細(xì)的優(yōu)化了?？梢钥紤]用對(duì)象池來(lái)復(fù)用 DataBuffer或者用零拷貝的方式減少內(nèi)存復(fù)制。5.5 版本兼容性注意事項(xiàng)Spring Cloud Gateway 的版本迭代比較快不同版本之間 API 可能有變化。我踩過(guò)的一個(gè)坑是在某個(gè)版本里getMethodValue()方法被標(biāo)記為過(guò)時(shí)推薦用getMethod()返回HttpMethod枚舉。雖然過(guò)時(shí)方法還能用但會(huì)有編譯警告而且未來(lái)版本可能會(huì)移除。建議在寫(xiě)代碼之前先確認(rèn)你用的 Spring Cloud 版本然后查閱對(duì)應(yīng)版本的官方文檔。一般來(lái)說(shuō)Spring Cloud 2021.x 及以上版本推薦用request.getMethod()來(lái)獲取請(qǐng)求方法。另外DataBufferUtils.join()的行為在不同版本里也有細(xì)微差異。有些版本會(huì)在 join 之后自動(dòng)釋放原始 DataBuffer有些版本則需要手動(dòng)釋放。最穩(wěn)妥的做法是不管框架怎么處理你自己讀完就釋放多釋放一次不會(huì)有問(wèn)題但少釋放一次就可能導(dǎo)致內(nèi)存泄漏。6. 從根因出發(fā)的防御性編程建議6.1 建立請(qǐng)求體讀取的規(guī)范在一個(gè)團(tuán)隊(duì)里如果每個(gè)人都按自己的方式去讀 body遲早會(huì)出問(wèn)題。我的建議是在項(xiàng)目初期就建立統(tǒng)一的請(qǐng)求體讀取規(guī)范明確以下幾點(diǎn)只有緩存過(guò)濾器可以讀 body其他過(guò)濾器一律從緩存中獲取。緩存過(guò)濾器的 order 值固定為最高優(yōu)先級(jí)不允許修改。所有需要讀 body 的過(guò)濾器必須從exchange.getAttribute()中獲取不得直接操作request.getBody()。緩存過(guò)濾器必須處理異常情況比如 body 為空、讀取超時(shí)等。把這些規(guī)范寫(xiě)進(jìn)團(tuán)隊(duì)的開(kāi)發(fā)文檔里新同學(xué)入職時(shí)重點(diǎn)強(qiáng)調(diào)能避免很多低級(jí)錯(cuò)誤。6.2 單元測(cè)試與集成測(cè)試的寫(xiě)法緩存過(guò)濾器這種底層組件一定要有完善的測(cè)試覆蓋。我通常會(huì)寫(xiě)三類測(cè)試第一類單元測(cè)試驗(yàn)證過(guò)濾器在各種輸入下的行為。比如Test public void testCachePostBody() { // 構(gòu)造一個(gè)帶 body 的 POST 請(qǐng)求 MockServerHttpRequest request MockServerHttpRequest .post(/api/test) .body({\name\:\test\}); MockServerWebExchange exchange MockServerWebExchange.from(request); // 執(zhí)行過(guò)濾器 filter.filter(exchange, chain).block(); // 驗(yàn)證緩存內(nèi)容 String cachedBody exchange.getAttribute(cachedRequestBody); assertEquals({\name\:\test\}, cachedBody); }第二類集成測(cè)試啟動(dòng)一個(gè)完整的 Gateway 上下文發(fā)真實(shí)請(qǐng)求驗(yàn)證下游服務(wù)能正常收到 body。第三類壓力測(cè)試用 JMeter 或 Gatling 模擬高并發(fā)場(chǎng)景觀察內(nèi)存和 CPU 的變化確保沒(méi)有內(nèi)存泄漏。6.3 監(jiān)控與告警的配置生產(chǎn)環(huán)境里光有代碼還不夠還得有監(jiān)控。我一般會(huì)在緩存過(guò)濾器里加幾個(gè)關(guān)鍵的監(jiān)控指標(biāo)緩存命中率有多少請(qǐng)求走了緩存邏輯有多少直接透?jìng)?。緩存大小分布緩存?body 大小分布及時(shí)發(fā)現(xiàn)異常大的請(qǐng)求。讀取耗時(shí)讀取 body 的耗時(shí)如果突然變長(zhǎng)可能是網(wǎng)絡(luò)或下游有問(wèn)題。異常次數(shù)讀取失敗或緩存失敗的次數(shù)超過(guò)閾值就告警。這些指標(biāo)可以接入 Prometheus Grafana配上告警規(guī)則一旦異常就能第一時(shí)間發(fā)現(xiàn)。6.4 我個(gè)人的幾條實(shí)戰(zhàn)心得最后分享幾條我在實(shí)際項(xiàng)目中總結(jié)出來(lái)的經(jīng)驗(yàn)都是踩過(guò)坑之后才明白的第一條不要試圖在網(wǎng)關(guān)層做太多事情。網(wǎng)關(guān)的職責(zé)是路由和轉(zhuǎn)發(fā)body 緩存是為了滿足鑒權(quán)、日志等必要需求但不要把它當(dāng)成業(yè)務(wù)處理的地方。能在下游服務(wù)做的就不要放到網(wǎng)關(guān)層。第二條緩存過(guò)濾器要盡量簡(jiǎn)單。我見(jiàn)過(guò)有人在緩存過(guò)濾器里做參數(shù)校驗(yàn)、做數(shù)據(jù)轉(zhuǎn)換、做業(yè)務(wù)判斷結(jié)果代碼越來(lái)越復(fù)雜bug 越來(lái)越多。緩存過(guò)濾器就只做一件事讀 body、存 body、重新封裝 body。其他的事情交給專門(mén)的過(guò)濾器去做。第三條上線前一定要做全鏈路測(cè)試。單元測(cè)試通過(guò)不代表集成沒(méi)問(wèn)題集成測(cè)試通過(guò)不代表生產(chǎn)環(huán)境沒(méi)問(wèn)題。我遇到過(guò)一次測(cè)試環(huán)境一切正常上了生產(chǎn)之后發(fā)現(xiàn)某個(gè)特定版本的客戶端發(fā)的請(qǐng)求body 格式和預(yù)期不一樣導(dǎo)致緩存邏輯出錯(cuò)。所以上線前一定要用真實(shí)的客戶端做全鏈路測(cè)試。第四條保留降級(jí)開(kāi)關(guān)。緩存過(guò)濾器萬(wàn)一出問(wèn)題要能快速關(guān)掉。我一般會(huì)加一個(gè)配置項(xiàng)gateway.body-cache.enabled默認(rèn)開(kāi)啟出問(wèn)題時(shí)可以通過(guò)配置中心動(dòng)態(tài)關(guān)閉讓請(qǐng)求直接透?jìng)飨缺ＷC業(yè)務(wù)可用再慢慢排查問(wèn)題。第五條日志要打夠但不要打太多。緩存過(guò)濾器里至少要打三類日志請(qǐng)求進(jìn)入時(shí)的基本信息路徑、方法、contentLength、緩存成功后的摘要信息緩存大小、異常時(shí)的詳細(xì)堆棧。但不要把完整的 body 都打到日志里一是性能問(wèn)題二是安全問(wèn)題可能包含敏感信息。這些經(jīng)驗(yàn)看起來(lái)簡(jiǎn)單但每一條背后都有真實(shí)的事故教訓(xùn)。希望你在實(shí)現(xiàn)自己的緩存過(guò)濾器時(shí)能少走一些彎路。