編譯 | 鄭麗媛

　　出品 | CSDN（ID：CSDNnews）

　　還記得不久前的那篇嗎？

　　當時，許多讀者留言稱這故事“離譜”得像是由 AI 杜撰的，其中就包括了本文的主人公——一位 Reddit ID 名為Drogus 的開發者：“一篇用 AI 生成的帖子”、“明顯是假的”。

　　話雖如此，Drogus卻不由得聯想到了一段他自己的真實經歷，與其中某些情節有幾分相似：“Rust 項目做得太成功，反而導致這門語言在公司內部被「判了死刑」”。

　　項目背景：一個快速成長的獨角獸初創公司

　　這件事發生在幾年前。那時，Drogus剛加入了一家在疫情期間快速成長的獨角獸初創公司，其主力應用采用 Ruby on Rails 編寫，一些視頻處理相關工具則用 Node.js 實現。當時，這家公司并沒有使用如 Rust 或 Go 這樣高性能的編譯型語言。

　　Drogus入職幾個月后，公司便計劃開發一個實時服務，用于顯示用戶的在線狀態（比如：頭像旁的綠點），以及用戶當前的操作行為（例如：有 N 個用戶正在看演示 X，有 M 個用戶在某個市場展臺內等）。

　　這個功能本身并不復雜，只是考慮到用戶增長預期，初期就需要支撐起 10 萬并發用戶。雖然這個規模在技術上也不算特別困難，但團隊中的大多數人都認為 Ruby顯然不適合實現這樣的系統。

　　技術選型與基準測試：Rust 脫穎而出

　　起初，負責該項目的團隊傾向用 Rust，不過管理層對此有疑慮，便要求用不同的語言寫幾個原型服務做個對比測試。

　　于是，團隊決定用 Elixir、Rust、Ruby 和 Node.js 分別寫一個原型——不知為何，當時Go 沒有列入候選，Drogus猜測可能是因為那時他在休假所以沒人提。

　　幾天后，四個原型都寫完了，他們開始對其進行性能測試。而測試結果屬于是意料之中：

　　Rust 版本速度最快、內存占用最低；

　　Elixir 次之；

　　Node.js 表現還可以，但受限于單線程運行時；

　　Ruby 最慢。

　　值得注意的是，Rust 版本最初存在也一個小 bug：開發者用 async futures 給客戶端發消息時，會遍歷所有客戶端來獲取發送通道列表，這在高負載下會阻塞運行時幾秒。不過這個問題屬于實現細節，對熟悉 Rust 的人來說并不難修復。

　　但由于寫這個 Rust 原型的人是第一次寫 Rust，經驗不足，而其他語言的原型都是由有經驗的開發者完成的——所以，即使有些小bug，也不是不能理解。

　　從原型到正式上線，Rust 表現亮眼

　　測試完成后，團隊成員討論了各種語言的性能表現、易用性、在公司內部的適配性等等，最終再次選擇了 Rust。很有意思的一點是，寫 Rust 原型的那位開發者原本更偏好 Elixir（因為他用過），但實際寫完后，他投票支持了 Rust。

　　原因很簡單：Rust 太靈活了。

　　基于評估結果和團隊判斷，公司最終決定由 Rust 實現該實時服務。而出于項目進度考慮，原本應由獨立團隊開發的任務，轉交給了有 Rust經驗的Drogus，并由他與 Rust 原型作者合作開發。

　　為了趕進度，Drogus決定采用一個類似于數據庫的極簡設計。在 Rust 中處理 10 萬個連接不算難事，MVP（最小可行產品）階段也只需要實現基礎功能：查詢某個用戶是否在線、用戶在應用的哪個區域；斷開連接就視為離線；服務崩了就重啟并讓客戶端重連。

　　他們把所有實時數據都存儲在內存哈希表中，然后通過 Kafka 推送事件供后續分析處理——正如Drogus所說：整體來說，這個服務本質上就是一個基于 WebSocket、封裝了內存哈希表的 API。

　　只用了兩周時間，他們就完成了 MVP 版本，再花兩周部署上線，架設了兩臺服務器做主備切換。

　　上線后，該服務穩定運行，支撐起 10 萬并發用戶毫無壓力。隨后一個月，團隊又陸續添加了更多功能，仍然沒有出過任何故障。

　　Rust 項目的成功，埋下“危機”種子

　　然而，隨著公司戰略的調整，實時相關功能被暫時擱置，該服務也轉入維護模式。原本為這個Rust 項目臨時組建的開發團隊解散，包括Drogus在內的工程師們回到原崗位——而這個 Rust 服務則靜靜運行在后臺，無故障、無宕機，堪稱基礎設施團隊的“夢中情服”。

　　直到幾個月后，公司籌備一場大型活動，預計將有 50 萬并發用戶。但當時Drogus和另一位原型作者已經忙于其他項目，管理層就決定招聘 3 名 Rust 工程師來提升這個服務的性能。

　　不得不說，這些新來的Rust開發者確實經驗豐富，很快就發現性能瓶頸其實在系統配置層面。稍微調整了內核參數、負載均衡設置后，這個服務便可支撐：

　　●100 萬并發（p99 延遲僅 10ms）

　　●200 萬并發（p99 延遲約 25ms）

　　優化成果令人驚嘆，但也帶來了問題：這個服務太穩定了，導致 3 名 Rust 工程師無事可做。

　　新管理層上任，Rust 被全面「封禁」

　　原本，招聘 Rust 團隊的那位高層是希望在公司內部推廣 Rust 的。

　　然而，隨著公司從 30 人擴張到 1000 人、組織架構也變動頻繁，那位支持推廣Rust 的高層選擇離職，新上任的主管則對該 Rust 服務的態度完全不同。

　　而他最大的不滿竟然是：“這個服務沒啥事做了，養著那 3 個 Rust 工程師沒用啊。”

　　不僅如此，這位新主管也根本不采納Drogus等工程師提出想在公司內繼續推廣Rust、將其用于事件處理、實時通知等需求的建議，而是轉頭強硬地通知那 3 位 Rust 工程師：“要么學 Ruby 或 Node.js，要么你們另謀高就。”

　　結果，這 3 位Rust開發者全部離職。Drogus 對此惋惜不已：“可惜，真的太可惜了。”

　　某種程度上，Drogus 也能理解管理層擔心 Rust 相對小眾、人才難招等問題。但他也指出，公司放棄了一個原本可以深入推廣 Rust 的寶貴時機：不僅已有成熟服務和三位經驗豐富的Rust 工程師，還有多個實際業務場景亟需高性能組件。

　　在Drogus 看來，整件事最諷刺的地方莫過于：如果這個 Rust 服務沒那么成功，反而可能會保住這個團隊。如果他們需要花幾個月去優化性能，和公司里其他服務一樣“正常拖延”，管理層大概也就不會這么關注了。

　　換句話說——正因為這個 Rust 服務“太成功”，沒有維護成本，才被公司高層視為“冗員項目”；如果它性能差，需要持續地去調優維護，反而更能“證明團隊價值”？

　　更荒唐的后續：Rust 服務被強行用 Node.js 重寫

　　最終，管理層決定將該 Rust 服務重寫為 Node.js 版本，以便公司現有團隊維護。

　　然而，第一次重寫嘗試失敗了。

　　“坦白說，我知道用 Node.js 實現這類服務是可行的——但前提是你要重構架構。”Drogus解釋道，Node.js受限于單線程運行時，本就不適合高并發，想要靠它支撐百萬連接，就不能再像 Rust 那樣用單進程單服務器搞定，而是要搞多進程、多節點、隊列或數據庫做中轉。

　　據說，當時負責用Node.js重寫的那位開發者選用了一個第三方平臺 Ably 來托管 WebSocket 連接，以避免自行處理復雜邏輯。但兩個月后大家發現，這個方案的性能遠遠不達標。

　　也就是說，雖然Node.js不是做不到，但遠比用 Rust 實現要復雜得多。

　　最后關于這個Rust 服務的近況，Drogus 只遺憾表示：“它現在仍在運行著——只在需要擴展時才會被提起，但由于沒有維護團隊，所有的擴展需求最終都會被放棄或改用次優方案替代。”

　　引起開發者熱議：“所有公司都會這樣”

　　Drogus的帖子發布后，同樣引起了許多開發者的關注和討論，其中有不少人也分享了類似的經歷：

　　“我曾經把一個服務從 PHP 改寫成 Rust，也遇到了類似的問題。這個服務從不需要維護，也沒有開發人員需要對其進行維護。于是，作為公司中唯一的 Rust 服務，它自己就成了一個問題——但我們又能做什么呢？畢竟悄無聲息的成功很難向管理層解釋明白。”

　　另外，也有部分開發者指出，這種事情幾乎在所有公司都會發生：

　　“這不過是司空見慣的事：企業不斷發展，新的管理者上任，他們做出“明智的管理決策”，卻破壞了企業的創新能力，于是你所看到的唯一創新要么是給已有的產品貼上新標簽，要么就是買來的現成產品……所有公司都會經歷這樣的過程，只不過這家公司比谷歌、IBM 或微軟走得更快而已?！?/p>

　　“我不會把這家公司 Rust 使用量的下降歸咎于其成功。這顯然（如文中所述）是個別高層未能看到其益處或機會所致。誰知道實際情況到底怎樣呢，有時事情在現實中并不像從個人視角分享的那樣清晰。不過我覺得這件事倒是可信的，確實有很多決策者往往對不理解的技術產生抵觸情緒，尤其是那些不像「AI」這樣時髦的新技術?！?/p>

　　那么，你是否也經歷過類似事情，對于這件事又有什么看法呢？

　　原文鏈接：https://www.reddit.com/r/rust/comments/1kp74t2/rust_success_story_that_killed_rust_usage_in_a/

　　2025 全球產品經理大會

　　2025 年 8 月 15–16 日

　　北京·威斯汀酒店

　　2025 全球產品經理大會將匯聚互聯網大廠、AI 創業公司、ToB/ToC 實戰一線的產品人，圍繞產品設計、用戶體驗、增長運營、智能落地等核心議題，展開 12 大專題分享，洞察趨勢、拆解路徑、對話未來。