← 返回

當 JSON 成為 OpenResty 服務的隱形瓶頸

章亦春釋出於 Apr 17, 2026 更新於 Apr 21, 2026

預計閱讀 7 分鐘

閱讀次數

在 OpenResty 的效能調優實踐中，有一類開銷像“暗物質”一樣存在：它無處不在，卻經常被擠出我們的優先排查列表。這就是 JSON 編解碼。無論是作為 API 閘道器解析上游響應，還是在業務邏輯層組裝複雜的請求體，亦或是從共享記憶體（shared dict）中讀取配置，cjson.encode 和 cjson.decode 幾乎滲透在每一條請求路徑上。單次呼叫的 CPU 耗時確實微秒級，但在高併發的洪峰下，這些微小的開銷會迅速堆疊，最終演變成火焰圖上一塊無法忽視的熱區。

很多時候，效能瓶頸並不是突然爆發的。更典型的場景是：隨著業務流量線性增長，CPU 利用率也隨之攀升。團隊習慣性地去最佳化 SQL、調整連線池、重構業務邏輯，結果發現收益遞減。直到這時，大家才會盯著那塊持續存在的 JSON 熱區陷入沉思。

效能的天花板到底在哪一層

意識到 JSON 是瓶頸只是第一步，更核心的判斷在於：這個瓶頸是工程實現問題，還是基礎設施的上限？

在 OpenResty 生態中，lua-cjson 是事實上的標準。它作為 C 擴充套件嵌入 LuaJIT 執行時，這意味著它的吞吐能力上限是由底層 C 程式碼和 LuaJIT 的 FFI/互動機制決定的。無論你在 Lua 層如何精簡程式碼，只要底層的編解碼效率不動，效能的天花板就鎖死在那裡。

作為一個工程判斷，我們必須承認：任何業務層的“奇技淫巧”，都無法逾越基礎設施層的效能紅線。

常見的“繞行”策略及其侷限

面對 JSON 帶來的 CPU 壓力，資深的工程師通常會嘗試幾種路徑，但每條路都有其代價。

快取編解碼結果是最容易想到的。對於配置類或高頻重複的 JSON，這確實立竿見影。但現實是，大多數請求和響應體是動態的，快取命中率往往不盡如人意，且引入快取邏輯本身就會增加狀態管理和資料一致性的複雜度。

減少編解碼頻次則是另一種架構層面的剋制。比如在服務內部儘量傳遞 Lua Table，只在出入口做序列化。這當然是好的實踐，但它解決不了根本問題——對外的 API 互動、跨系統的資料交換，這些邊界上的編解碼是剛需，避無可避。

至於橫向擴容，這是最簡單也最昂貴的方案。它能緩解燃眉之急，但並沒有提升單核的執行效率。隨著流量翻倍，成本也會線性膨脹，這顯然不是一種優雅的工程解法。

這些方案本質上都在“繞著瓶頸走”，而不是去“移動天花板”。

為甚麼“自研”或“魔改”不是個好主意

很多技術實力雄厚的團隊曾想過：能不能自己最佳化 lua-cjson，或者換一個號稱更快的第三方庫？

這個想法在技術上很誘人，但在工程落地上的難度往往被低估了。lua-cjson 深度依賴 LuaJIT 的執行時特性，想要對其進行有效的效能壓榨，不僅需要精通 C 語言，還要對 LuaJIT 的記憶體模型、GC 行為以及 FFI 呼叫約定有極深的造詣。這已經超出了絕大多數應用開發團隊的技術棧邊界。

此外，還有長期維護的“隱形成本”。自行維護一個底層庫，意味著你要獨自承擔後續的安全補丁和版本迭代。對於大多數追求業務交付效率的團隊來說，這並不是一項投入產出比合理的投資。

尋找更直接的破局點

如果問題出在基礎設施層，那麼最理想的解法也應該在這一層。

一個更具戰略眼光的思路是：尋找一個效能更強、但 API 完全相容的替代品，直接替換掉現有的 lua-cjson，而不觸動任何業務邏輯。

這種“無感替換”的吸引力在於收益路徑極短——效能提升直接轉化為 CPU 利用率的下降，不需要重構程式碼，不引入新的架構複雜度。唯一的變數在於：是否存在一個既能保證極致效能，又能完美相容 OpenResty 生態的實現？

基礎設施級的最佳化：`jit.cjson`

OpenResty Inc. 基於對 LuaJIT 和 lua-cjson 的深度理解，推出了一套系統性的最佳化版本：jit.cjson。

它的定位非常明確：作為 lua-cjson 的 Drop-in Replacement（無縫替換）。API 完全相容，行為高度一致。根據官方在特定負載下的測試，相對其他主流開源 Lua-cjson 實現，編碼效能最高可達約 18 倍，解碼效能最高可達約 6 倍。此外還增加了新能力，例如支援 JSON 註釋，並允許陣列與物件末尾存在尾隨逗號。

當然，作為工程師我們都知道，這些倍數都是上限參考值。實際的收益會根據你的資料結構複雜度、編解碼比例以及併發規模而波動。但對於那些 JSON 已經成為效能瓶頸的服務來說，這個量級的提升足以改變擴容決策。

為甚麼原廠方案更值得託付

第一，是全域性視角。 OpenResty Inc. 是整個生態的創造者。他們對 LuaJIT 執行時與底層 C 庫互動邊界的理解，是外部團隊難以企及的。這種最佳化不是孤立的打補丁，而是基於對整個執行棧深度認知後的產物。

第二，是關於效能資料的誠實態度。 官方將編碼與解碼分開表述為「最高約 18 倍」「最高約 6 倍」，而不是把兩者捏合成一個籠統的倍數，這符合工程邏輯。任何脫離實際負載談固定倍數的宣傳都是耍流氓。這種透明度給了架構師一個合理的預期管理空間。

第三，是風險邊界的可控性。 引入新庫最大的成本不是學習，而是回歸測試。由於 jit.cjson 保持了完全的 API 相容，現有的 require "cjson" 呼叫無需改動。這意味著風險從“大規模程式碼重構”降級為了“配置層面的灰度變更”。

第四，是商業級的工程化保障。 透過標準包管理器分發、持續的安全更新、對 http 和 stream 場景的完整覆蓋——這些訊號表明這是一個長期維護的工業級產品，而非一個隨手丟在 GitHub 上的最佳化 Demo。

極低的接入成本

jit.cjson 和 cjson 的介面保持相容，升級到 jit.cjson 可以不需要修改原有的業務程式碼。具體操作替換方法可以參考 jit.cjson 的使用說明書。

這意味著，你不需要為了獲取效能紅利而去動那些已經穩定執行了很久的業務程式碼。這種“低介入、高收益”的特性，正是資深效能工程師在做技術選型時最看重的特質。

總結

在 OpenResty 服務裡，JSON 編解碼是一個容易被忽視的 CPU 漏斗。當業務層的最佳化空間逐漸收窄，真正的天花板往往就壓在這些底層元件上。jit.cjson 所做的事情很簡單：在不觸動任何業務程式碼的前提下，把編解碼本身的效率提上來。

如果您正在評估如何降低 JSON 編解碼帶來的 CPU 開銷，以下文件可以幫助您進一步判斷 jit.cjson 是否適合您的執行環境：

安裝與前提條件介紹安裝方式、依賴要求以及與 OpenResty 執行時的整合前提。

如果您在當前系統中已經遇到以下問題：

JSON 編解碼在火焰圖上持續佔據顯著熱區
橫向擴容能緩解壓力，但成本隨流量線性膨脹
曾嘗試自行最佳化底層庫，但在正確性或維護成本上受挫

歡迎點選右下角的"聯絡我們"。我們的工程師團隊可以為您提供具體的效能評估和部署建議。您也可以瀏覽 OpenResty Inc. 提供的其他私有庫產品，這些元件同樣圍繞高效能執行時、可控資源模型與生產級穩定性設計。

關於作者

章亦春是開源 OpenResty^® 專案創始人兼 OpenResty Inc. 公司 CEO 和創始人。

章亦春（Github ID: agentzh），生於中國江蘇，現定居美國灣區。他是中國早期開源技術和文化的倡導者和領軍人物，曾供職於多家國際知名的高科技企業，如 Cloudflare、雅虎、阿里巴巴, 是 “邊緣計算“、”動態追蹤 “和 “機器程式設計 “的先驅，擁有超過 22 年的程式設計及 16 年的開源經驗。作為擁有超過 4000 萬全球域名使用者的開源專案的領導者。他基於其 OpenResty^® 開源專案打造的高科技企業 OpenResty Inc. 位於美國矽谷中心。其主打的兩個產品 OpenResty XRay（利用動態追蹤技術的非侵入式的故障剖析和排除工具）和 OpenResty Edge（最適合微服務和分散式流量的全能型閘道器軟體），廣受全球眾多上市及大型企業青睞。在 OpenResty 以外，章亦春為多個開源專案貢獻了累計超過百萬行程式碼，其中包括，Linux 核心、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl 等，並編寫過 60 多個開源軟體庫。