多語言基準：為正確的工作選擇正確的工具

簡短易讀的伴侶。要深入瞭解完整的架構 - 線束佈局、決策矩陣、反模式以及如何分叉基準 - 請閱讀長文。

您的組織在 2019 年選擇了一個堆疊。您的工作負載沒有。

大多數團隊仍然為每項新服務標準化單一語言：Node 中的所有內容、Python 中的所有內容、Java 中的所有內容，或者僅在 Rust 上進行大膽的賭注。這種習慣是可以理解的——當堆疊統一時，招聘、CI 模板和安全審查都會變得更容易。問題是工作負載不均勻。 API 閘道器、夜間 ETL 作業、NGINX 邊緣轉換、JVM 微服務資產以及具有長期連線的聊天后端對執行時的不同部分產生壓力。從走廊辯論或單個微基準中選出一個獲勝者，最終會導致錯誤的工具承載錯誤的負載。

多語言基準是解藥：一種可重現的工具和實時儀表板，可在上比較的八個執行時以及相同的HTTP 工作負載，因此架構師可以將證據與有界上下文相匹配，而不是預設堆疊偏差。

它測量什麼

公共儀表板比較NGINX njs、OpenResty Lua、Python (FastAPI)、Go (net/http)、Rust (Actix)、Bun、Java (Javalin / Jetty)和Kotlin (Ktor / Netty)跨七個綜合測試，反映真實的 API 和邊緣模式：純文字基線、JSON 序列化、CPU 繫結斐波那契、字串操作、請求檢查、內部子請求 + 轉換和路由邏輯。每個測試都會報告每秒請求數、平均延遲和尾部延遲（包括 P99）、從curl 到第一個位元組的時間以及錯誤計數——在bench.sh完成時進行實時流式傳輸。

Java 和 Kotlin 與編譯和指令碼執行時並存，因此 JVM 商店可以看到 Javalin 和 Ktor 如何在相同的路線上與 Go、Rust、Bun 和 FastAPI 進行交易，而不是與揮手的“企業 vs 綠地”敘述。該工具位於工作流程示例/基準中：Docker Compose 服務、共享wrk配置檔案（10 秒、4 個執行緒、100 個連線）以及儀表板使用的 JSON 結果。您可以為自己的候選人和熱路徑分叉它。

為什麼這是一個決策框架，而不是排行榜

多語言基準測試不會永遠為一種語言加冕。每個測試行的獲勝者都會發生變化——這正是您在設計微服務時想要的。儀表板的結論部分將結果對映到用例（Lua/njs 中的邊緣路由、Rust/Go 中的核心併發、Java/Kotlin 中的 JVM 服務、Python 中的速度）。這就是論文：設計的多語言，使用架構審查委員會的資料而不是意見。

平臺和工程主管的六大優勢

• 證據勝過意見— 將圖表和配置附加到 ADR；透過測量執行來解決堆疊爭論。
• 特定工作負載的獲勝者— 延遲敏感路徑、批處理、邊緣轉換、JVM 資產獲得不同的領先者。
• 總體擁有成本— 原始 RPS 不夠；權衡構建時間、影象大小、團隊技能配合和運營負擔。
• 可重複的工作流程— 相同的儲存庫、相同的 Compose 檔案、相同的 wrk 指令碼；可在 CI 中重新執行。
• 合法的多語言微服務— 每個服務邊界使用不同的語言，無需感到羞恥或驚訝。
• 降低風險— 在組織範圍內授權之前獲得亞軍的原型。

快速入門

1. 在執行過程中開啟實時儀表板（或在本地啟動執行）。
2. 克隆workflow-examples、cd benchmarks、docker compose up— 八種語言服務以及儀表板和工作臺執行程式。
3. 讀取儀表板上的results.json卷，並將獲勝者對映到您的工作負載行。
4. 寫入 ADR — 包括持續時間、執行緒、連線和硬體類別。

閱讀完整版本

長文涵蓋了完整的儲存庫佈局、標準表、決策矩陣圖、每個測試系列的案例模式（包括 Java 和 Kotlin）、反模式、限制以及可與 ARB 共享的 SEO 就緒片段。由Workstation釋出；基準測試網站託管於polyglot-benchmarks.fictionally.org。

#Rust #GoLang #Bunjs #Java #Kotlin #Lua #Python #njs #FastAPI #Javalin #Ktor #OpenResty #polyglot #benchmarks