1. 攔截器解決的四個(gè)真實(shí)場(chǎng)景從統(tǒng)一請(qǐng)求頭到防篡改簽名先講一個(gè)很典型的痛點(diǎn)。我之前在給某開放平臺(tái)做聯(lián)調(diào)的時(shí)候要對(duì)接十幾個(gè)第三方接口每個(gè)接口都要求帶clientId、timestamp、sign這些公共參數(shù)而且服務(wù)端驗(yàn)簽特別嚴(yán)格。最開始圖省事我直接在每一個(gè) Feign 方法里手動(dòng)塞請(qǐng)求頭代碼寫成這樣PostMapping(value /order/create, headers {X-Client-Idclient-001, X-Signabc}) Order createOrder(RequestBody OrderCreateRequest request);表面上看沒什么問題但真跑起來就難受了。簽名里往往要帶上時(shí)間戳和請(qǐng)求體內(nèi)容headers注解里寫的是靜態(tài)值根本無法根據(jù)每次請(qǐng)求動(dòng)態(tài)計(jì)算。后來只能改成在方法內(nèi)部用RequestContextHolder拿請(qǐng)求對(duì)象、再塞進(jìn) Feign 的配置里……繞了一大圈最后還是繞回到RequestInterceptor上。我當(dāng)時(shí)的結(jié)論是只要你的 Feign 客戶端需要做“每個(gè)請(qǐng)求都要做一遍”的事情就應(yīng)該考慮攔截器而不是在業(yè)務(wù)代碼里到處復(fù)制粘貼。具體來說有四類場(chǎng)景特別適合用RequestInterceptor統(tǒng)一處理場(chǎng)景典型需求不用攔截器的后果令牌傳遞下游接口要求Authorization: Bearer xxx每個(gè)方法單獨(dú)處理漏一個(gè)就 401鏈路追蹤透?jìng)鱰raceId、spanId等鏈路標(biāo)識(shí)排查問題時(shí)很難串起整條調(diào)用鏈多環(huán)境隔離聯(lián)調(diào)環(huán)境、預(yù)發(fā)環(huán)境路由到不同實(shí)例或帶不同標(biāo)識(shí)改一處要重新編譯部署接口簽名請(qǐng)求頭附帶timestamp、nonce、sign防篡改防重放動(dòng)態(tài)簽名根本沒法用靜態(tài)注解實(shí)現(xiàn)其中簽名這個(gè)場(chǎng)景最復(fù)雜后面我會(huì)專門用一整節(jié)來講。先記住一個(gè)最核心的判斷標(biāo)準(zhǔn)只要這個(gè)動(dòng)作是“所有 Feign 請(qǐng)求都要做”的就落入RequestInterceptor的職責(zé)范圍。2. RequestInterceptor 的執(zhí)行時(shí)機(jī)為什么它在編碼器之前又為什么日志里看不到很多人第一次寫RequestInterceptor時(shí)都會(huì)有一個(gè)疑惑我明明加上了Component程序也能啟動(dòng)但請(qǐng)求日志里看不到我設(shè)置的 header到底執(zhí)行了沒有要回答這個(gè)問題得先搞清楚 Feign 處理一次請(qǐng)求的完整鏈路。2.1 Feign 請(qǐng)求執(zhí)行的順序概括來說一次 Feign 調(diào)用的流程是通過 JDK 動(dòng)態(tài)代理攔截你的接口調(diào)用MethodHandler 將方法參數(shù)解析成RequestTemplate對(duì)象依次執(zhí)行你配置的RequestInterceptor鏈對(duì)RequestTemplate進(jìn)行改寫通過Encoder把方法參數(shù)編碼成請(qǐng)求體交給Client發(fā)起真正的 HTTP 請(qǐng)求通過Decoder解析響應(yīng)。注意第 3 步和第 4 步的順序。RequestInterceptor是在編碼器之前執(zhí)行的也就是說攔截器拿到的是還沒有被編碼的RequestTemplate。此時(shí)如果你設(shè)置了template.body()你會(huì)發(fā)現(xiàn)它拿的是參數(shù)對(duì)象的原始字符串形式通常是 JSON 序列化之前的樣子而不是最終 HTTP 報(bào)文里的字節(jié)流。這個(gè)“先攔截、后編碼”的順序有個(gè)很實(shí)際的影響如果你想在攔截器里讀取請(qǐng)求體做簽名拿到的可能是LinkedHashMap序列化后的字符串而不是你最終發(fā)送的 body。我一開始在這里栽過跟頭后面講簽名時(shí)再重點(diǎn)展開。2.2 攔截器生效的兩種注冊(cè)方式RequestInterceptor有兩條注冊(cè)路徑很多人只知道第一種// 方式一使用默認(rèn)的全局配置 Configuration public class FeignGlobalConfig { Bean public RequestInterceptor globalRequestInterceptor() { return new MyRequestInterceptor(); } }// 方式二細(xì)粒度指定給某個(gè) FeignClient FeignClient(name order-service, configuration OrderFeignConfig.class) public interface OrderClient { // ... }方式一是全局生效所有通過 Feign 發(fā)出的請(qǐng)求都會(huì)走過這個(gè)攔截器方式二是局部生效只對(duì)指定的 client 生效。這里面有一個(gè)很多初學(xué)者容易踩的坑如果OrderFeignConfig類被放在了啟動(dòng)類可以掃描到的包路徑下而且你又在類上加了Configuration那么這個(gè)局部配置其實(shí)會(huì)變成全局配置影響所有 Feign 客戶端。這不是玄學(xué)是 Spring 的組件掃描機(jī)制導(dǎo)致的。2.3 RequestTemplate 的核心操作 API攔截器的入?yún)⑹荝equestTemplate核心操作無非這幾種public class HeaderInterceptor implements RequestInterceptor { Override public void apply(RequestTemplate template) { // 添加請(qǐng)求頭 template.header(X-Api-Key, your-api-key); // 覆蓋請(qǐng)求頭如果不覆蓋重復(fù)調(diào)用會(huì)追加值 template.header(Authorization, Bearer token); // 獲取某個(gè)請(qǐng)求頭 CollectionString values template.headers().get(Content-Type); // 修改請(qǐng)求體注意body 在攔截器階段還是 String沒有經(jīng)過 Encoder 編碼 template.body({\name\:\test\}); // 修改請(qǐng)求路徑 template.uri(/v2 template.path()); // 獲取 query 參數(shù) MapString, CollectionString queries template.queries(); } }這里有個(gè)細(xì)節(jié)值得注意template.header()是追加語義。如果同名的 header 已經(jīng)存在再次調(diào)用會(huì)把新值追加到后面而不是替換。實(shí)際場(chǎng)景里下游服務(wù)如果只取第一個(gè)值可能會(huì)看不到你后來追加的。所以我習(xí)慣在設(shè)置關(guān)鍵 header 之前先template.removeHeader(X-Api-Key)或者確認(rèn)原始請(qǐng)求不會(huì)帶這個(gè) header。還有一個(gè)細(xì)節(jié)RequestTemplate暴露的 header 名稱在查詢時(shí)區(qū)分大小寫但 HTTP 協(xié)議本身不區(qū)分。如果你在排查時(shí)發(fā)現(xiàn)明明設(shè)置了 header 卻拿不到先檢查一下是不是大小寫不一致。3. 手寫統(tǒng)一請(qǐng)求頭攔截器從第一版到可上線的完整代碼這一節(jié)直接提供可抄作業(yè)的代碼。我先把一個(gè)通用的實(shí)現(xiàn)寫出來再逐步加上健壯性處理。3.1 第一版從配置文件讀取請(qǐng)求頭需求是給所有 Feign 請(qǐng)求加上X-Client-Id和X-Api-Key并且這兩個(gè)值在不同環(huán)境本地、聯(lián)調(diào)、預(yù)發(fā)不一樣所以不能寫死在代碼里。Component public class ClientInfoInterceptor implements RequestInterceptor { private static final Logger log LoggerFactory.getLogger(ClientInfoInterceptor.class); private final ClientInfoProperties properties; public ClientInfoInterceptor(ClientInfoProperties properties) { this.properties properties; } Override public void apply(RequestTemplate template) { template.header(X-Client-Id, properties.getClientId()); template.header(X-Api-Key, properties.getApiKey()); // 可選加上環(huán)境標(biāo)識(shí)方便下游區(qū)分布 template.header(X-Env, properties.getEnv()); log.debug(Feign request intercepted, uri: {}, template.url()); } }對(duì)應(yīng)的配置類ConfigurationProperties(prefix openapi.client) public class ClientInfoProperties { private String clientId; private String apiKey; private String env dev; // getter / setter 省略 }然后在application.yml里配置openapi: client: client-id: client-001 api-key: sk-abc123 env: local這一版能解決 80% 的靜態(tài)請(qǐng)求頭需求。但如果你只是需要透?jìng)饔脩羯矸?Token還需要繼續(xù)看下一節(jié)。3.2 第二版從當(dāng)前線程上下文透?jìng)?Token常見的業(yè)務(wù)場(chǎng)景是用戶 A 發(fā)起請(qǐng)求到你的 Spring MVC 接口這個(gè)接口內(nèi)部又通過 Feign 調(diào)用了下游服務(wù)。下游服務(wù)同樣需要校驗(yàn)用戶身份所以要把用戶的Authorizationheader 原樣透?jìng)鬟^去。這時(shí)候攔截器里要讀取當(dāng)前的ServletRequest獲取 header再設(shè)置到RequestTemplate上Component public class TokenPropagationInterceptor implements RequestInterceptor { Override public void apply(RequestTemplate template) { // 1. 從 Spring 的線程上下文中拿當(dāng)前請(qǐng)求 RequestAttributes requestAttributes RequestContextHolder.getRequestAttributes(); if (requestAttributes instanceof ServletRequestAttributes) { HttpServletRequest request ((ServletRequestAttributes) requestAttributes).getRequest(); String authz request.getHeader(Authorization); if (StringUtils.hasText(authz)) { template.header(Authorization, authz); return; } } // 2. 拿不到就使用兜底 Token一般來自服務(wù)間調(diào)用憑證 String fallback environment.getProperty(openapi.client.service-token, ); if (StringUtils.hasText(fallback)) { template.header(Authorization, Bearer fallback); } } }這個(gè)實(shí)現(xiàn)里有個(gè)容易掉進(jìn)去的坑異步線程丟上下文。如果你在業(yè)務(wù)代碼里用了Async或自定義線程池RequestContextHolder里是拿不到當(dāng)前請(qǐng)求的因?yàn)?Spring 默認(rèn)的ThreadLocal不會(huì)跨線程傳遞。遇到這種情況要么在進(jìn)入異步之前手動(dòng)把 Token 存入ThreadLocal并在攔截器里讀取要么使用HystrixRequestVariableDefault這類方案。我現(xiàn)在項(xiàng)目的做法是封裝了一個(gè)UserContextHolder在請(qǐng)求入口處解析用戶信息存入自定義上下文異步任務(wù)里也能拿到。3.3 加上開關(guān)控制聯(lián)調(diào)/生產(chǎn)一鍵切換另一個(gè)實(shí)踐中的剛需是攔截器要能開關(guān)。比如你在聯(lián)調(diào)時(shí)下游并不驗(yàn)證簽名但一上生產(chǎn)就要驗(yàn)。如果把邏輯做成硬編碼每次切換環(huán)境都要改代碼。我的做法是給攔截器加一個(gè)配置開關(guān)openapi: client: sign-enabled: trueComponent public class SigningInterceptor implements RequestInterceptor { private final ClientInfoProperties properties; Override public void apply(RequestTemplate template) { if (!properties.isSignEnabled()) { return; } // 簽名邏輯... } }同時(shí)在配置中心可以動(dòng)態(tài)調(diào)整非常方便。4. 簽名場(chǎng)景的完整鏈路時(shí)間戳、防重放與參數(shù)排序簽名是最能體現(xiàn)RequestInterceptor價(jià)值的場(chǎng)景。我把它單獨(dú)拆開講因?yàn)檫@里面坑最深也最容易出錯(cuò)。4.1 簽名流程總覽一個(gè)相對(duì)規(guī)范的開放平臺(tái)簽名方案通常包含這幾部分客戶端生成timestamp毫秒級(jí)時(shí)間戳客戶端生成nonce隨機(jī)字符串防重放將請(qǐng)求路徑、查詢參數(shù)、請(qǐng)求體等按約定規(guī)則拼接成待簽名字符串使用約定的密鑰通常是appSecret或私鑰對(duì)字符串做HMAC-SHA256或MD5簽名將timestamp、nonce、sign放入請(qǐng)求頭傳給服務(wù)端服務(wù)端校驗(yàn)時(shí)間戳是否過期、nonce 是否第一次使用、簽名是否一致。下面這個(gè)簽名攔截器是綜合了以上要點(diǎn)的完整實(shí)現(xiàn)Component public class SigningInterceptor implements RequestInterceptor { private static final Logger log LoggerFactory.getLogger(SigningInterceptor.class); private final ClientInfoProperties properties; public SigningInterceptor(ClientInfoProperties properties) { this.properties properties; } Override public void apply(RequestTemplate template) { if (!properties.isSignEnabled()) { return; } String timestamp String.valueOf(System.currentTimeMillis()); String nonce UUID.randomUUID().toString().replace(-, ); // 1. 拼接待簽名內(nèi)容 String content buildSignContent(template); // 2. 計(jì)算簽名 String sign sign(timestamp, nonce, content); // 3. 放入請(qǐng)求頭 template.header(X-Timestamp, timestamp); template.header(X-Nonce, nonce); template.header(X-Sign, sign); template.header(X-Api-Key, properties.getApiKey()); } private String buildSignContent(RequestTemplate template) { StringBuilder sb new StringBuilder(); // 請(qǐng)求路徑 sb.append(template.method()).append(\n); sb.append(template.path()).append(\n); // 查詢參數(shù)排序拼接核心難點(diǎn)1 MapString, CollectionString queries template.queries(); if (queries ! null !queries.isEmpty()) { ListString queryParts new ArrayList(); for (Map.EntryString, CollectionString entry : queries.entrySet()) { for (String value : entry.getValue()) { queryParts.add(entry.getKey() value); } } Collections.sort(queryParts); sb.append(String.join(, queryParts)).append(\n); } // 請(qǐng)求體核心難點(diǎn)2編碼時(shí)機(jī)問題 String body template.body() null ? : new String(template.body(), StandardCharsets.UTF_8); sb.append(body); return sb.toString(); } private String sign(String timestamp, String nonce, String content) { String raw properties.getApiKey() \n timestamp \n nonce \n content \n properties.getApiSecret(); return DigestUtils.sha256Hex(raw); } }4.2 參數(shù)排序?yàn)槭裁词呛诵碾y點(diǎn)很多簽名校驗(yàn)失敗問題多半出在參數(shù)順序不一致。服務(wù)端在驗(yàn)簽時(shí)對(duì)查詢參數(shù)的常見處理是先按 key 字典序排序再用keyvalue形式拼接多個(gè)參數(shù)用連接。而RequestTemplate.queries()返回的是MapString, CollectionStringkey 的順序不保證是字典序。如果不排序同一個(gè)請(qǐng)求在客戶端簽名的順序和服務(wù)端驗(yàn)簽的順序就可能不同導(dǎo)致簽名對(duì)不上。我建議在拼接前強(qiáng)制排序一次ListString queryParts new ArrayList(); // ... 拼出 keyvalue 形式 Collections.sort(queryParts);對(duì)于參數(shù)值里有中文、特殊字符的情況還涉及 URL 編碼。通常簽名用的字符串是原始值未編碼還是編碼后的值取決于接口文檔。這個(gè)必須提前和服務(wù)端對(duì)齊否則兩邊各做各的簽名永遠(yuǎn)對(duì)不上。4.3 body 簽名的編碼時(shí)機(jī)問題前面提到攔截器的執(zhí)行時(shí)機(jī)在編碼器之前所以在攔截器里template.body()拿到的是未經(jīng) Encoder 處理的內(nèi)容。如果Encoder用的是默認(rèn)的SpringEncoder它接收的是RequestBody注解的對(duì)象通常會(huì)被MappingJackson2HttpMessageConverter序列化成 JSON。這里有個(gè)非常隱蔽的問題簽名時(shí)你拿到的字符串和傳輸時(shí)真正序列化后的字符串可能不一致。例如對(duì)象中的LocalDateTime在序列化前和序列化后的格式不同字段為null時(shí)可能被JsonInclude注解過濾掉。如果你簽名用的是序列化前的原始 JSON而服務(wù)端驗(yàn)簽用的卻是收到報(bào)文里的 JSON兩邊自然對(duì)不上。針對(duì)這個(gè)問題的常見解法有兩種方案一在調(diào)用 Feign 之前先把請(qǐng)求體序列化成字符串再傳給 Feign 方法這樣攔截器里拿到 body 就是最終字符串。String json objectMapper.writeValueAsString(orderRequest); orderClient.createOrder(json);PostMapping(/order/create) Order createOrder(RequestBody String body);這種做法的缺點(diǎn)是簽名語義和業(yè)務(wù)方法簽名綁定得比較緊但能保證簽名內(nèi)容與傳輸內(nèi)容完全一致。方案二注冊(cè)自定義 Encoder在 Encoder 階段統(tǒng)一序列化并在序列化過程中做簽名。這種方式鏈路更完整但實(shí)現(xiàn)復(fù)雜度高適合在真正需要精細(xì)控制的場(chǎng)景下使用。我現(xiàn)在項(xiàng)目里用的是方案一操作簡(jiǎn)單、定位問題也快。4.4 防重放timestamp nonce 的雙保險(xiǎn)簽名只解決了“內(nèi)容有沒有被篡改”的問題但沒有解決“同一個(gè)請(qǐng)求被原樣重放”的問題。如果黑客截獲了一個(gè)有效請(qǐng)求過幾分鐘再原樣發(fā)一次服務(wù)端驗(yàn)簽依然通過。所以必須加上時(shí)間戳和 nonce 雙保險(xiǎn)timestamp服務(wù)端校驗(yàn)客戶端時(shí)間與服務(wù)器時(shí)間差在允許范圍內(nèi)通常 5 分鐘。超出范圍的直接拒絕。nonce隨機(jī)字符串服務(wù)端需要記錄一段時(shí)間內(nèi)使用過的 nonce。如果同一個(gè) nonce 再次出現(xiàn)說明是重放請(qǐng)求直接拒絕。nonce 的存儲(chǔ)服務(wù)端可以放在 Redis 里設(shè)置與時(shí)間戳窗口相同的過期時(shí)間。這里要注意并發(fā)場(chǎng)景如果同一毫秒內(nèi)兩個(gè)請(qǐng)求生成了相同 nonce概率極低但存在。因此生成 nonce 時(shí)建議加上隨機(jī)數(shù)或線程安全手段String nonce Long.toHexString(System.nanoTime()) UUID.randomUUID().toString().replace(-, );4.5 服務(wù)端驗(yàn)簽的簡(jiǎn)易實(shí)現(xiàn)思路雖然標(biāo)題講的是客戶端攔截器但服務(wù)端驗(yàn)簽邏輯決定了客戶端怎么簽名。我貼一個(gè)簡(jiǎn)單的 Controller 攔截器來模擬服務(wù)端驗(yàn)簽流程方便你本地驗(yàn)證Component public class VerifySignInterceptor extends HandlerInterceptorAdapter { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String timestamp request.getHeader(X-Timestamp); String nonce request.getHeader(X-Nonce); String sign request.getHeader(X-Sign); if (!StringUtils.hasText(timestamp) || !StringUtils.hasText(nonce) || !StringUtils.hasText(sign)) { response.setStatus(401); return false; } // 1. 校驗(yàn)時(shí)間戳 long ts Long.parseLong(timestamp); if (Math.abs(System.currentTimeMillis() - ts) 5 * 60 * 1000) { response.setStatus(401); return false; } // 2. 校驗(yàn) nonce 是否使用過此處應(yīng)查 Redis if (nonceUsed(nonce)) { response.setStatus(401); return false; } // 3. 校驗(yàn)簽名偽代碼真實(shí)場(chǎng)景需要讀取 body String content request.getRequestURI() \n readQuerySorted(request); String expectSign DigestUtils.sha256Hex(canonicalize(content)); if (!MessageDigest.isEqual(expectSign.getBytes(StandardCharsets.UTF_8), sign.getBytes(StandardCharsets.UTF_8))) { response.setStatus(401); return false; } return true; } }看到?jīng)]服務(wù)端驗(yàn)簽和客戶端簽名是一體兩面的設(shè)計(jì)?？蛻舳嗽趺雌醋址?wù)端就必須怎么拼字符串兩邊的canonicalize函數(shù)必須完全一致這是簽名聯(lián)調(diào)中最容易出問題的地方。5. 自帶攔截器的“繼承陷阱”子類庫(kù)重寫 Feign 配置時(shí)為何突然失聯(lián)這一節(jié)是我自己項(xiàng)目的血淚經(jīng)驗(yàn)。我們有一個(gè)基礎(chǔ) SDK 模塊里面定義了一個(gè)公共的 Feign 配置類并注冊(cè)了一個(gè)簽名攔截器。業(yè)務(wù)模塊引入這個(gè) SDK 后只需要寫接口和調(diào)用即可。// 基礎(chǔ) SDK 里的公共配置 Configuration public class BaseFeignConfig { Bean public RequestInterceptor signInterceptor() { return new SigningInterceptor(); } }某一天新業(yè)務(wù)方接入了 SDK但他們自己定義了 Feign 客戶端時(shí)指定了一個(gè)CustomFeignConfigFeignClient(name order-service, configuration OrderFeignConfig.class) public interface OrderClient { }結(jié)果上線后聯(lián)調(diào)一直報(bào) 401簽名校驗(yàn)失敗。排查了很久最后發(fā)現(xiàn)OrderFeignConfig里沒有繼承BaseFeignConfig而是自己定義了一套配置Configuration public class OrderFeignConfig { // 只配置了自定義的 decode/encoder忘了把父類的簽名攔截器帶進(jìn)來 }在這個(gè)配置類生效的 Feign 客戶端上BaseFeignConfig的全局?jǐn)r截器沒有生效因?yàn)?Feign 對(duì)每個(gè) client 都會(huì)獨(dú)立構(gòu)建一套攔截器鏈局部配置可以覆蓋或替換全局配置。5.1 Feign 攔截器集合的構(gòu)建規(guī)則深入了解后我發(fā)現(xiàn)FeignClientsRegistrar在注冊(cè)每個(gè) FeignClient 時(shí)會(huì)讀取你指定的configuration類并把這些類中的 Bean 注冊(cè)到對(duì)應(yīng) client 的 Spring 子容器中。這個(gè)子容器和全局容器是隔離的RequestInterceptor的集合也基于這個(gè)子容器構(gòu)建。所以如果局部配置類里自己也定義了一個(gè)RequestInterceptor這個(gè)攔截器會(huì)替換全局的攔截器而不是疊加。這一點(diǎn)很容易被忽略因?yàn)轫?xiàng)目能正常啟動(dòng)看起來沒有任何報(bào)錯(cuò)。5.2 排查過程從現(xiàn)象到根因當(dāng)時(shí)我們的排查鏈路是這樣的先看下游服務(wù)端日志發(fā)現(xiàn)收到的請(qǐng)求頭里沒有X-Sign確認(rèn)攔截器確實(shí)沒有執(zhí)行在SigningInterceptor.apply()里加斷點(diǎn)發(fā)現(xiàn)根本沒走到檢查是否注冊(cè)了多個(gè)RequestInterceptor用ApplicationContext.getBeansOfType(RequestInterceptor.class)查看只有全局的攔截器一個(gè)但業(yè)務(wù)模塊的 FeignClient 用的并不是這個(gè)最后檢查OrderFeignConfig發(fā)現(xiàn)問題出在局部配置覆蓋了全局配置且沒有把簽名攔截器重新注冊(cè)進(jìn)去。修正方式很簡(jiǎn)單讓業(yè)務(wù)方的OrderFeignConfig繼承 SDK 的BaseFeignConfigConfiguration public class OrderFeignConfig extends BaseFeignConfig { // 業(yè)務(wù)方自己的配置簽名攔截器自動(dòng)繼承 }或者更穩(wěn)妥的做法在業(yè)務(wù)模塊中不要重復(fù)定義RequestInterceptor而是通過Import(BaseFeignConfig.class)把公開配置引入。5.3 設(shè)計(jì)層面的三點(diǎn)建議經(jīng)歷這次踩坑后我在設(shè)計(jì) SDK 時(shí)總結(jié)了三條原則不要在基礎(chǔ)配置類里寫業(yè)務(wù)相關(guān)的攔截器必要時(shí)拆成多個(gè)配置類按場(chǎng)景分別引入如果確定攔截器必須全局生效把它注冊(cè)成基礎(chǔ)配置中的一個(gè) Bean并且讓所有局部配置類繼承基礎(chǔ)配置在 FeignClient 的自定義配置類上盡量不再定義RequestInterceptor類型的 Bean如果一定要就要清楚它是在替換全局?jǐn)r截器而非追加。6. 調(diào)試與驗(yàn)證從日志全開到一個(gè)完整的測(cè)試用例寫完了攔截器關(guān)鍵是怎么驗(yàn)證它真的按照預(yù)期工作。如果只是“感覺沒問題”一旦聯(lián)調(diào)簽不上排查起來極其痛苦。6.1 打開 Feign 的日志Feign 自帶的 Logger 可以輸出請(qǐng)求頭、請(qǐng)求體等關(guān)鍵調(diào)試信息。步驟是在配置類里指定日志級(jí)別Configuration public class FeignLogConfig { Bean Logger.Level feignLoggerLevel() { return Logger.Level.FULL; // NONE、BASIC、HEADERS、FULL } }在application.yml里開啟對(duì)應(yīng)包的日志輸出logging: level: com.example.openapi.client: debug然后把Logger.Level設(shè)為FULL就可以在日志中看到[OrderClient#createOrder] --- POST http://order-service/order/create HTTP/1.1 [OrderClient#createOrder] X-Timestamp: 1735023600123 [OrderClient#createOrder] X-Nonce: 6f2a5c4d8e1b4f2a [OrderClient#createOrder] X-Sign: 3b4c5d6e7f8a9b0c... [OrderClient#createOrder] Content-Type: application/json [OrderClient#createOrder] --- END HTTP (56-byte body)日志級(jí)別對(duì)照表級(jí)別輸出內(nèi)容NONE不輸出任何日志BASIC請(qǐng)求方法、URL、響應(yīng)狀態(tài)碼、耗時(shí)HEADERSBASIC 請(qǐng)求和響應(yīng)頭FULLHEADERS 請(qǐng)求和響應(yīng)體如果開了 DEBUG 日志但沒看到任何輸出先檢查是不是logging.level寫的包名不對(duì)。Feign 日志的 Logger name 是FeignClient 接口的完整類名必須對(duì)應(yīng)到實(shí)際接口的包名。6.2 單測(cè)不啟動(dòng)服務(wù)端直接驗(yàn)證攔截器最方便的驗(yàn)證方式其實(shí)是寫一個(gè)單元測(cè)試直接構(gòu)造RequestTemplate然后調(diào)用攔截器的apply方法。這樣不用啟動(dòng) Spring 容器也不依賴下游服務(wù)。public class SigningInterceptorTest { Test public void testApply() { // 構(gòu)造一個(gè)請(qǐng)求模板 RequestTemplate template new RequestTemplate(); template.method(HttpMethod.POST); template.uri(/order/create); template.query(orderId, 10086); template.body({\name\:\張三\}); // 初始化攔截器 ClientInfoProperties properties new ClientInfoProperties(); properties.setApiKey(client-001); properties.setApiSecret(secret); properties.setSignEnabled(true); SigningInterceptor interceptor new SigningInterceptor(properties); // 執(zhí)行攔截邏輯 interceptor.apply(template); // 斷言 assertNotNull(template.headers().get(X-Timestamp)); assertNotNull(template.headers().get(X-Nonce)); assertNotNull(template.headers().get(X-Sign)); // 打印簽名結(jié)果以便和服務(wù)端算法對(duì)照 System.out.println(X-Timestamp: template.headers().get(X-Timestamp).iterator().next()); System.out.println(X-Sign: template.headers().get(X-Sign).iterator().next()); } }這種方法的好處是本地調(diào)試極其快速還能在 CI 中跑回歸。凡是涉及簽名規(guī)則調(diào)整我都會(huì)先跑一遍單測(cè)確認(rèn)簽名串和服務(wù)端一致再去做接口聯(lián)調(diào)。6.3 跨庫(kù)請(qǐng)求體的特殊處理Content-Type 為 form 表單最后提一個(gè)我在實(shí)際項(xiàng)目中遇到的坑。如果 Feign 方法接收的是RequestBody MapString, Object攔截器里template.body()拿到的字符串是 JSON 格式。但如果某個(gè)接口的 Content-Type 是application/x-www-form-urlencodedbody 就是keyvaluekey2value2格式。這時(shí)候簽名字符串的拼接規(guī)則就完全不同了。針對(duì)不同 Content-Type我建議在攔截器里做分支String contentType template.headers().getOrDefault(Content-Type, List.of(application/json)).iterator().next(); if (contentType.contains(application/x-www-form-urlencoded)) { // 表單格式直接拼原始 urlencoded 字符串 } else { // JSON 格式直接拼 JSON 字符串 }表單參數(shù)在RequestTemplate中的body()拿到的可能是類字段的形式未必是最終的 urlencoded 結(jié)果這一點(diǎn)要特別小心。最穩(wěn)妥的方式是在調(diào)用 Feign 之前就用UriComponentsBuilder等工具手動(dòng)構(gòu)造好表單字符串這樣簽名和傳輸完全一致。最后分享一個(gè)小技巧調(diào)試簽名類攔截器我強(qiáng)烈建議在本地啟動(dòng)一個(gè)僅用于打印請(qǐng)求信息的最小 Mock 服務(wù)。方法很簡(jiǎn)單寫一個(gè) Spring Boot 接口把所有 header 和 body 打出來然后讓 Feign 指向它。這樣你能在幾分鐘內(nèi)看出攔截器到底設(shè)置哪些 header、body 是什么、簽名原文長(zhǎng)什么樣。另外如果你的項(xiàng)目同時(shí)依賴了多個(gè) Feign 庫(kù)以及重試組件要特別小心RequestInterceptor的執(zhí)行次數(shù)。遇到重試時(shí)攔截器會(huì)隨每次重試重新執(zhí)行所以簽名中的時(shí)間戳在重試時(shí)也會(huì)更新。服務(wù)端如果做了嚴(yán)格的時(shí)間窗口校驗(yàn)重試太頻繁可能觸發(fā)時(shí)間戳超過允許范圍。我在項(xiàng)目中就是把這個(gè)時(shí)間窗口放寬到 1 分鐘同時(shí)把 nonce 的 Redis 過期時(shí)間設(shè)為 5 分鐘既防重放又不誤傷正常重試。這套R(shí)equestInterceptor的方案我已經(jīng)在多個(gè)項(xiàng)目中穩(wěn)定運(yùn)行核心思路就是統(tǒng)一收口、動(dòng)態(tài)計(jì)算、可配置開關(guān)、測(cè)試兜底。照著這個(gè)思路做你的 Feign 客戶端在接入第三方接口時(shí)會(huì)省掉很多重復(fù)勞動(dòng)簽名這類復(fù)雜邏輯也能在一個(gè)文件里維護(hù)清楚。