編譯 | 鄭麗媛

　　出品 | CSDN（ID：CSDNnews）

　　還記得不久前的那篇嗎？

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

　　話雖如此，Drogus卻不由得聯(lián)想到了一段他自己的真實(shí)經(jīng)歷，與其中某些情節(jié)有幾分相似：“Rust 項(xiàng)目做得太成功，反而導(dǎo)致這門語(yǔ)言在公司內(nèi)部被「判了死刑」”。

　　項(xiàng)目背景：一個(gè)快速成長(zhǎng)的獨(dú)角獸初創(chuàng)公司

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

　　Drogus入職幾個(gè)月后，公司便計(jì)劃開發(fā)一個(gè)實(shí)時(shí)服務(wù)，用于顯示用戶的在線狀態(tài)（比如：頭像旁的綠點(diǎn)），以及用戶當(dāng)前的操作行為（例如：有 N 個(gè)用戶正在看演示 X，有 M 個(gè)用戶在某個(gè)市場(chǎng)展臺(tái)內(nèi)等）。

　　這個(gè)功能本身并不復(fù)雜，只是考慮到用戶增長(zhǎng)預(yù)期，初期就需要支撐起 10 萬并發(fā)用戶。雖然這個(gè)規(guī)模在技術(shù)上也不算特別困難，但團(tuán)隊(duì)中的大多數(shù)人都認(rèn)為 Ruby顯然不適合實(shí)現(xiàn)這樣的系統(tǒng)。

　　技術(shù)選型與基準(zhǔn)測(cè)試：Rust 脫穎而出

　　起初，負(fù)責(zé)該項(xiàng)目的團(tuán)隊(duì)傾向用 Rust，不過管理層對(duì)此有疑慮，便要求用不同的語(yǔ)言寫幾個(gè)原型服務(wù)做個(gè)對(duì)比測(cè)試。

　　于是，團(tuán)隊(duì)決定用 Elixir、Rust、Ruby 和 Node.js 分別寫一個(gè)原型——不知為何，當(dāng)時(shí)Go 沒有列入候選，Drogus猜測(cè)可能是因?yàn)槟菚r(shí)他在休假所以沒人提。

　　幾天后，四個(gè)原型都寫完了，他們開始對(duì)其進(jìn)行性能測(cè)試。而測(cè)試結(jié)果屬于是意料之中：

　　Rust 版本速度最快、內(nèi)存占用最低；

　　Elixir 次之；

　　Node.js 表現(xiàn)還可以，但受限于單線程運(yùn)行時(shí)；

　　Ruby 最慢。

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

　　但由于寫這個(gè) Rust 原型的人是第一次寫 Rust，經(jīng)驗(yàn)不足，而其他語(yǔ)言的原型都是由有經(jīng)驗(yàn)的開發(fā)者完成的——所以，即使有些小bug，也不是不能理解。

　　從原型到正式上線，Rust 表現(xiàn)亮眼

　　測(cè)試完成后，團(tuán)隊(duì)成員討論了各種語(yǔ)言的性能表現(xiàn)、易用性、在公司內(nèi)部的適配性等等，最終再次選擇了 Rust。很有意思的一點(diǎn)是，寫 Rust 原型的那位開發(fā)者原本更偏好 Elixir（因?yàn)樗眠^），但實(shí)際寫完后，他投票支持了 Rust。

　　原因很簡(jiǎn)單：Rust 太靈活了。

　　基于評(píng)估結(jié)果和團(tuán)隊(duì)判斷，公司最終決定由 Rust 實(shí)現(xiàn)該實(shí)時(shí)服務(wù)。而出于項(xiàng)目進(jìn)度考慮，原本應(yīng)由獨(dú)立團(tuán)隊(duì)開發(fā)的任務(wù)，轉(zhuǎn)交給了有 Rust經(jīng)驗(yàn)的Drogus，并由他與 Rust 原型作者合作開發(fā)。

　　為了趕進(jìn)度，Drogus決定采用一個(gè)類似于數(shù)據(jù)庫(kù)的極簡(jiǎn)設(shè)計(jì)。在 Rust 中處理 10 萬個(gè)連接不算難事，MVP（最小可行產(chǎn)品）階段也只需要實(shí)現(xiàn)基礎(chǔ)功能：查詢某個(gè)用戶是否在線、用戶在應(yīng)用的哪個(gè)區(qū)域；斷開連接就視為離線；服務(wù)崩了就重啟并讓客戶端重連。

　　他們把所有實(shí)時(shí)數(shù)據(jù)都存儲(chǔ)在內(nèi)存哈希表中，然后通過 Kafka 推送事件供后續(xù)分析處理——正如Drogus所說：整體來說，這個(gè)服務(wù)本質(zhì)上就是一個(gè)基于 WebSocket、封裝了內(nèi)存哈希表的 API。

　　只用了兩周時(shí)間，他們就完成了 MVP 版本，再花兩周部署上線，架設(shè)了兩臺(tái)服務(wù)器做主備切換。

　　上線后，該服務(wù)穩(wěn)定運(yùn)行，支撐起 10 萬并發(fā)用戶毫無壓力。隨后一個(gè)月，團(tuán)隊(duì)又陸續(xù)添加了更多功能，仍然沒有出過任何故障。

　　Rust 項(xiàng)目的成功，埋下“危機(jī)”種子

　　然而，隨著公司戰(zhàn)略的調(diào)整，實(shí)時(shí)相關(guān)功能被暫時(shí)擱置，該服務(wù)也轉(zhuǎn)入維護(hù)模式。原本為這個(gè)Rust 項(xiàng)目臨時(shí)組建的開發(fā)團(tuán)隊(duì)解散，包括Drogus在內(nèi)的工程師們回到原崗位——而這個(gè) Rust 服務(wù)則靜靜運(yùn)行在后臺(tái)，無故障、無宕機(jī)，堪稱基礎(chǔ)設(shè)施團(tuán)隊(duì)的“夢(mèng)中情服”。

　　直到幾個(gè)月后，公司籌備一場(chǎng)大型活動(dòng)，預(yù)計(jì)將有 50 萬并發(fā)用戶。但當(dāng)時(shí)Drogus和另一位原型作者已經(jīng)忙于其他項(xiàng)目，管理層就決定招聘 3 名 Rust 工程師來提升這個(gè)服務(wù)的性能。

　　不得不說，這些新來的Rust開發(fā)者確實(shí)經(jīng)驗(yàn)豐富，很快就發(fā)現(xiàn)性能瓶頸其實(shí)在系統(tǒng)配置層面。稍微調(diào)整了內(nèi)核參數(shù)、負(fù)載均衡設(shè)置后，這個(gè)服務(wù)便可支撐：

　　●100 萬并發(fā)（p99 延遲僅 10ms）

　　●200 萬并發(fā)（p99 延遲約 25ms）

　　優(yōu)化成果令人驚嘆，但也帶來了問題：這個(gè)服務(wù)太穩(wěn)定了，導(dǎo)致 3 名 Rust 工程師無事可做。

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

　　原本，招聘 Rust 團(tuán)隊(duì)的那位高層是希望在公司內(nèi)部推廣 Rust 的。

　　然而，隨著公司從 30 人擴(kuò)張到 1000 人、組織架構(gòu)也變動(dòng)頻繁，那位支持推廣Rust 的高層選擇離職，新上任的主管則對(duì)該 Rust 服務(wù)的態(tài)度完全不同。

　　而他最大的不滿竟然是：“這個(gè)服務(wù)沒啥事做了，養(yǎng)著那 3 個(gè) Rust 工程師沒用啊。”

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

　　結(jié)果，這 3 位Rust開發(fā)者全部離職。Drogus 對(duì)此惋惜不已：“可惜，真的太可惜了。”

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

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

　　換句話說——正因?yàn)檫@個(gè) Rust 服務(wù)“太成功”，沒有維護(hù)成本，才被公司高層視為“冗員項(xiàng)目”；如果它性能差，需要持續(xù)地去調(diào)優(yōu)維護(hù)，反而更能“證明團(tuán)隊(duì)價(jià)值”？

　　更荒唐的后續(xù)：Rust 服務(wù)被強(qiáng)行用 Node.js 重寫

　　最終，管理層決定將該 Rust 服務(wù)重寫為 Node.js 版本，以便公司現(xiàn)有團(tuán)隊(duì)維護(hù)。

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

　　“坦白說，我知道用 Node.js 實(shí)現(xiàn)這類服務(wù)是可行的——但前提是你要重構(gòu)架構(gòu)。”Drogus解釋道，Node.js受限于單線程運(yùn)行時(shí)，本就不適合高并發(fā)，想要靠它支撐百萬連接，就不能再像 Rust 那樣用單進(jìn)程單服務(wù)器搞定，而是要搞多進(jìn)程、多節(jié)點(diǎn)、隊(duì)列或數(shù)據(jù)庫(kù)做中轉(zhuǎn)。

　　據(jù)說，當(dāng)時(shí)負(fù)責(zé)用Node.js重寫的那位開發(fā)者選用了一個(gè)第三方平臺(tái) Ably 來托管 WebSocket 連接，以避免自行處理復(fù)雜邏輯。但兩個(gè)月后大家發(fā)現(xiàn)，這個(gè)方案的性能遠(yuǎn)遠(yuǎn)不達(dá)標(biāo)。

　　也就是說，雖然Node.js不是做不到，但遠(yuǎn)比用 Rust 實(shí)現(xiàn)要復(fù)雜得多。

　　最后關(guān)于這個(gè)Rust 服務(wù)的近況，Drogus 只遺憾表示：“它現(xiàn)在仍在運(yùn)行著——只在需要擴(kuò)展時(shí)才會(huì)被提起，但由于沒有維護(hù)團(tuán)隊(duì)，所有的擴(kuò)展需求最終都會(huì)被放棄或改用次優(yōu)方案替代。”

　　引起開發(fā)者熱議：“所有公司都會(huì)這樣”

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

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

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

　　“這不過是司空見慣的事：企業(yè)不斷發(fā)展，新的管理者上任，他們做出“明智的管理決策”，卻破壞了企業(yè)的創(chuàng)新能力，于是你所看到的唯一創(chuàng)新要么是給已有的產(chǎn)品貼上新標(biāo)簽，要么就是買來的現(xiàn)成產(chǎn)品……所有公司都會(huì)經(jīng)歷這樣的過程，只不過這家公司比谷歌、IBM 或微軟走得更快而已。”

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

　　那么，你是否也經(jīng)歷過類似事情，對(duì)于這件事又有什么看法呢？

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

　　2025 全球產(chǎn)品經(jīng)理大會(huì)

　　2025 年 8 月 15–16 日

　　北京·威斯汀酒店

　　2025 全球產(chǎn)品經(jīng)理大會(huì)將匯聚互聯(lián)網(wǎng)大廠、AI 創(chuàng)業(yè)公司、ToB/ToC 實(shí)戰(zhàn)一線的產(chǎn)品人，圍繞產(chǎn)品設(shè)計(jì)、用戶體驗(yàn)、增長(zhǎng)運(yùn)營(yíng)、智能落地等核心議題，展開 12 大專題分享，洞察趨勢(shì)、拆解路徑、對(duì)話未來。