在微服務架構中，網關作為流量入口，常常需要承擔身份認證、權限校驗等職責。其中，用戶數據權限的傳遞看似簡單，卻隱藏著不少兼容性陷阱。本文將結合實際項目經驗，聊聊如何解決 Feign 調用時請求頭中 JSON 數據的傳遞問題。

場景再現：數據權限傳遞的常規思路

在我們的微服務系統中，網關負責解析用戶 Token 獲取身份信息，同時需要將用戶的數據權限（如可訪問的部門、資源范圍等）傳遞給下游服務。這些數據權限通常是一個結構化的 JSON 對象，例如：

{"visibleDepts": [1001, 1002, 1003],"allowEdit": true,"maxLevel": 3
}

最初的實現思路很直接：將 JSON 字符串直接放入請求頭（Header）中，下游服務從 Header 中讀取并解析。代碼大概是這樣的：

// 網關層設置數據權限
ServerHttpRequest.Builder builder = exchange.getRequest().mutate();
builder.header("data - permission", jsonData);

下游服務通過 Feign 調用其他服務時，也會自動傳遞這個請求頭。看起來一切合理，直到我們遇到了詭異的解析錯誤。

隱藏的陷阱：Feign 對請求頭的特殊處理

在測試環境中，我們發現下游服務經常解析數據權限失敗，報錯信息多為 “JSON 格式錯誤”。通過日志排查，我們發現服務收到的 JSON 字符串被篡改了，原始的{“visibleDepts”:…}變成了$“visibleDepts”:…。
為什么會出現這種情況？這要從 Feign 的內部機制說起：
Feign 作為聲明式 HTTP 客戶端，在處理請求頭時會觸發表達式解析邏輯。這種機制原本是為了支持類似
${variable}的占位符替換，但它會把 JSON 中的{和}誤認為是表達式的開始和結束標記。
具體來說，當 Feign 遇到{字符時，會嘗試將其解析為表達式占位符，導致原本的 JSON 結構被破壞：

• 原始 JSON：{“visibleDepts”:[1001]}
• Feign 處理后：$“visibleDepts”:[1001]}（注意開頭的{變成了$"）
  這種結構顯然不符合 JSON 規范，下游服務自然無法正常解析。

解決方案：壓縮 + Base64 轉碼

既然直接傳遞 JSON 會被 Feign 的表達式解析邏輯破壞，我們需要一種 “安全” 的傳遞方式 —— 將 JSON 數據轉換為 Feign 不會特殊處理的格式。
最終我們采用了 “壓縮 + Base64 轉碼” 的方案，完整流程如下：

數據處理步驟（網關層）

// 1. 原始JSON字符串
String dataPermission = "{\"visibleDepts\":[1001,1002]}";// 2. 轉為字節數組并Gzip壓縮（減少體積）
byte[] gzip = ZipUtil.gzip(dataPermission.getBytes(StandardCharsets.UTF_8));// 3. Base64轉碼（轉為純字母數字字符串）
String dataPermissionBase64 = Base64.getEncoder().encodeToString(gzip);// 4. 設置到請求頭
builder.header("data - permission", dataPermissionBase64);

經過處理后，請求頭中傳遞的不再是原始 JSON，而是類似H4sIAAAAAAAAA+3TMQ0AAAwE0L/7K3QnGQ…的 Base64 字符串，這種格式不會被 Feign 的表達式解析邏輯干擾。

數據還原步驟（下游服務）

下游服務需要執行反向操作來還原原始 JSON：

// 1. 從請求頭獲取Base64字符串
String dataPermissionBase64 = request.getHeader("data - permission");// 2. Base64解碼
byte[] gzipData = Base64.getDecoder().decode(dataPermissionBase64);// 3. Gzip解壓
byte[] jsonBytes = ZipUtil.unGzip(gzipData);// 4. 轉為JSON字符串
String dataPermission = new String(jsonBytes, StandardCharsets.UTF_8);// 5. 解析為對象
PermissionDTO permission = JsonUtil.jsonToObject(dataPermission, PermissionDTO.class);

為什么這種方案有效？

• Base64 編碼：將二進制數據轉為由 64 個可打印字符（A - Z、a - z、0 - 9、+、/）組成的字符串，不含{、}等特殊字符，避免被 Feign 誤解析
• Gzip 壓縮：在數據量較大時（如復雜的權限配置），可以顯著減少傳輸體積，提高效率
• 通用性：Base64 和 Gzip 都是標準編碼 / 壓縮方式，幾乎所有編程語言都有成熟的處理庫

實踐中的注意事項

• 字符編碼一致性：無論是網關還是下游服務，都要明確指定 UTF - 8 編碼，避免因默認編碼不同導致亂碼
• 異常處理：
  • 對空值、非法 Base64 字符串、解壓失敗等情況做容錯處理
  • 建議在網關層記錄原始數據權限，方便問題排查
• 性能考量：
  • 壓縮和解壓縮會消耗一定 CPU 資源，對于簡單的權限數據可權衡是否需要壓縮
  • 可考慮使用線程池異步處理轉碼操作，避免阻塞網關主線程
• 規范統一：
  • 定義統一的請求頭名稱（如x - data - permission）
  • 制定轉碼 / 解碼的標準工具類，避免各服務實現不一致

總結

微服務間的數據傳遞看似簡單，卻可能因為各組件的特殊機制產生意想不到的問題。Feign 對請求頭的表達式解析邏輯導致 JSON 數據傳遞失敗，正是這種 “隱藏規則” 帶來的典型問題。
通過 “壓縮 + Base64 轉碼” 的方案，我們成功規避了 Feign 的兼容性問題，同時兼顧了數據傳輸的安全性和效率。這個案例也提醒我們：在分布式系統中，對于跨服務的數據傳遞，需要充分考慮中間組件的特性，選擇更通用、更穩定的方案。
希望本文的經驗能幫助大家在類似場景中少走彎路，讓微服務間的 “對話” 更加順暢。