公司Rust团队全员被裁，只因把服务写得「太稳定」：“项目0故障、0报警，那养着3个Rust工程师没用啊”

C语言与CPP编程 2025-06-10 09:00

揭秘：新一代半导体器件如何提升测试电源的性能 超越单处理器嵌入式系统的演进

点击上方“C语言与CPP编程”，选择“关注/置顶/星标公众号”
干货福利，第一时间送达！
最近有小伙伴说没有收到当天的文章推送，这是因为微信更改了推送机制，导致没有星标公众号的小伙伴刷不到当天推送的文章，无法接收到一些比较实用的知识和资讯。所以建议大家加个星标⭐️，以后就能第一时间收到推送了。

编译 | 郑丽媛出品 | CSDN（ID：CSDNnews）

还记得不久前的那篇《“因为一次成功重写，我们 CTO 彻底封杀了 Rust！”》吗？

当时，许多读者留言称这故事“离谱”得像是由 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 或微软走得更快而已。”
“我不会把这家公司 Rust 使用量的下降归咎于其成功。这显然（如文中所述）是个别高层未能看到其益处或机会所致。谁知道实际情况到底怎样呢，有时事情在现实中并不像从个人视角分享的那样清晰。不过我觉得这件事倒是可信的，确实有很多决策者往往对不理解的技术产生抵触情绪，尤其是那些不像「AI」这样时髦的新技术。”