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

　　编译 | 郑丽媛

　　出品 | 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 或微软走得更快而已。”

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

　　那么，你是否也经历过类似事情，对于这件事又有什么看法呢？

　　原文链接：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 大专题分享，洞察趋势、拆解路径、对话未来。