當我最初決定將我們的後端技術棧從 Python 遷移到 Rust 時,這不僅僅是出於好奇——而是源於在效能、部署成本和負載下可靠性方面的實際痛點。Python 的網路生態系統——尤其是 FastAPI——在生產力和快速迭代方面使用起來令人愉悅。但隨著我們的流量增長和效能瓶頸變得明顯,我想探索 Rust 能提供什麼。
在本文中,我將分享我一路上學到的東西:優勢、陷阱,以及每個生態系統仍然出色的地方。
效能比較:Rust (Actix-Web) 與 Python (FastAPI)
原始吞吐量和延遲
當我進行基準測試時,最先讓我震驚的事情之一就是 Rust 和 Python 網路框架之間的效能特徵有多麼不同。
在各種獨立基準測試中,Rust 的 Actix-Web 在原始每秒請求數和記憶體效率方面始終優於 FastAPI。在一個社群基準測試中,Actix-Web 每秒處理的請求數比 FastAPI 多數千個,且延遲更低,記憶體消耗遠低於 FastAPI。
這與更廣泛的觀察一致,即 Rust 的零成本抽象以及缺乏垃圾收集器,使其在大規模提供 HTTP 服務時異常高效。
實際影響
根據我的經驗,這轉化為:
- 在壓力測試中持續吞吐量高得多。
- 負載下的變化更小。
- 與 Python 程序相比,閒置記憶體使用量更低。
也就是說,基準測試只能說明部分情況:實際瓶頸通常受限於資料庫或網路。對於許多應用程式,FastAPI 的效能綽綽有餘,調整資料庫存取或快取比單純的語言選擇帶來更大的收益。
ORM 差異:Diesel 與 SQLAlchemy
切換 ORM 範式是遷移過程中在文化上最不同的部分之一。
遷移系統
在 Python 中,我們使用 SQLAlchemy 配合 Alembic 遷移——這種方法會比較你的模型並自動生成遷移腳本。
在 Rust 中,我們轉向了 Diesel,它採取了非常不同的立場:
- 遷移作為明確的 SQL 檔案手動編寫。
- 沒有自動比較工具。
- 你獲得了更多控制權——以及更多責任。
這最初令人沮喪,但手動編寫遷移的紀律帶來了更清晰的可審計性和生產環境中更少的意外。
型別安全和編譯時保證
這是 Diesel 真正改變了我對資料庫程式碼思考方式的地方:編譯時的型別安全。
Diesel 根據你的架構生成 Rust 型別,因此不匹配的欄位名稱或無效的查詢結構根本無法編譯。像 check_for_backend 這樣的概念以及要求明確的 table_name 聲明意味著在你執行查詢之前,整類常見錯誤就會消失。
相比之下,SQLAlchemy 只在執行時捕獲許多錯誤。雖然這增加了靈活性,但也意味著更依賴測試來確保正確性。
建構和執行查詢
Diesel 的查詢建構器使用 Rust 的型別系統,與 SQLAlchemy 更動態的表達式風格相比需要更多程式碼行——但權衡是編譯器為你證明了很多東西。
經過一段調整期後,我開始欣賞 Rust 的明確性如何在重構期間幫助導航複雜的查詢邏輯。
自動 OpenAPI 生成支援
Python 在開箱即用的 API 架構生成方面仍然領先的一個領域。
FastAPI 自動生成 OpenAPI 文件,並附帶瀏覽器 UI,如 ReDoc 和 Swagger UI,位於 /docs 和 /redoc,讓客戶端和團隊成員非常容易理解和探索你的 API。
Rust 的生態系統在這方面正在發展。像 utoipa 這樣的工具可以為 Actix-Web 生成 OpenAPI 規範,但與 FastAPI 的無縫體驗相比,它們感覺更手動且分散。也有社群套件來提供 Swagger 或 Redoc UI,但它們需要額外的設定和註釋。
我預計這個差距會繼續縮小——Rust 社群正在積極努力帶來與 FastAPI 相媲美的更流暢的 API 文件體驗。
部署大小:編譯與依賴
Rust 編譯時間
Rust 的編譯速度比解釋型語言慢是出了名的。在開發過程中,重新建構——尤其是對於大型套件——與重新執行 Python 腳本相比可能感覺遲緩。
但這個成本是開發時間,而不是生產時間。一旦編譯完成,Rust 二進位檔案:
- 完全提前編譯
- 自包含(無需虛擬環境,通常沒有動態依賴)
- 在容器映像中佔用空間非常小
這使得部署更簡單且更可預測。
Python 依賴佔用空間
Python 應用程式通常帶來龐大的依賴關係圖:FastAPI 本身、uvicorn、pydantic(現在由於 Rust 內部而快得多)、資料庫驅動程式等。
這增加了:
- 容器大小
- 建構複雜性
- 依賴衝突的表面
Rust 的 Cargo 產生一個封裝一切的二進位檔案(通常),這大大簡化了部署流程。
可維護性
這可能是我個人成長最多的領域。
Rust 推動你朝向清晰的所有權界限、明確的錯誤處理和仔細的設計。一旦你內化了 Rust 的編譯錯誤,編譯器本身就成為防止回歸的強大護欄。
相比之下,Python 的動態性在早期開發中可能感覺輕鬆——但同樣的靈活性有時會導致生產中更難診斷的錯誤,除非有強大的測試套件支援。
我們的 Rust 程式碼庫在大型重構期間感覺更具韌性,這在很大程度上歸功於編譯器的嚴格性。
文件和開發者體驗
FastAPI 的自動文件
FastAPI 與 OpenAPI 的整合,以及 ReDoc 和 Swagger UI,使得新開發者的入職變得極其容易。這是我在團隊生產力方面看到的最大勝利之一。
Rust 文件生成
Rust 的內建文件工具(cargo doc)對於程式碼級文件來說非常出色。它鼓勵在程式碼旁邊編寫文件,Rustdoc 生成乾淨、可搜尋的 HTML 文件。
雖然這無法開箱即用地取代一個漂亮的 /docs 端點,但它確實大大提高了以程式碼為中心的文件品質和可發現性。
結論
從 Python 切換到 Rust 進行後端開發並不是要偏愛一種語言而非另一種——而是要與我們專案的優先順序保持一致。
- Rust 為我們提供了效能、可預測性和可靠性,用於生產流量。
- Python 為我們提供了開發速度和世界級的人體工學。
這兩個生態系統都很強大。Rust 改變的是,許多在 Python 中只會在執行時出現的問題,在 Rust 中被編譯時捕獲,減少了意外和中斷。
選擇 Rust 意味著投資於學習曲線——但對於效能和正確性最重要的團隊來說,這種權衡對我們來說是值得的。
作者註
本文由 Hytale Multiplayer 的創建者撰寫,該網站專注於技術文章和對遊戲 Hytale 的深入探討,包括伺服器開發、工具以及與 Minecraft 等相關生態系統的比較。如果你喜歡實用的、以工程為重點的內容,歡迎探索更多文章。
