每年省30万美元！实习生用Rust给TikTok火速降本，开发者吐槽：放在小公司顶多省300块
整理 | 郑丽媛
出品 | CSDN（ID：CSDNnews）
在开发者圈内，时而会听到这样一个观点：
“别费劲去做优化了，反正计算机运行速度快，没必要为了那点性能而浪费开发时间。”
这话说得有些道理，但并不完全对，毕竟——某些情况下，服务器账单也很贵。
不久前，一位 TikTok 实习生 Xiaoyun Wu 分享了一件很有代表性的事：他在 TikTok 实习期间，用 Rust 重写了核心支付服务中的部分 Go 模块，让性能提升 2 倍、延迟降低 76%、CPU 使用率减少三分之一，并为公司节省了每年约 30 万美元（约合人民币 213 万元）的云成本。
虽然对 TikTok 这样的大公司来说，30 万美元的节省看似不多，但别忘了——这只是一个服务的部分重写，还是实习生干的。
「外科手术式」重构：只用 Rust 重写“最疼的那一块”
在 Xiaoyun Wu 的个人博客中，他提到 TikTok LIVE 的支付服务原本是用 Go 编写的核心系统，多年来运行稳定。本身 Go 凭借简洁语法和并发模型，就非常适合快速迭代微服务。
但随着 TikTok LIVE 业务爆发式增长，这个“老黄牛”开始吃不消了——CPU 占用居高不下、服务频繁触发稳定性告警，团队不断扩容以维持性能，导致云成本也一路飙升。
经过分析，问题主要集中在几个高频 API：用户余额查询与统计数据拉取。这些接口计算密集、流量极大，占据了大部分 CPU 时间。然而常规 Go 层面的优化空间有限，因此不是代码写得不好，而是语言特性已到极限。
“普通的 Go 优化手段已经难以带来突破性改进，”正如 Xiaoyun Wu所说，“我们需要一个更强大的解决方案来解决这个有针对性的问题。”
在导师和同事的指导下，Xiaoyun Wu 将解决方案分为三个关键阶段：
（1）精准重写：Rust “外科手术式”介入
他们没有盲目推倒重来，而是进行了一次“外科手术式”重构：只将性能最关键、最吃CPU的几个接口用 Rust 重写，其他逻辑仍保持在 Go 中。毕竟Rust 以接近底层的性能和内存安全著称，本身就非常适合这种高并发、高密度计算场景。这种多语言架构（polyglot approach）让团队既能保持 Go 的开发效率，又能在性能关键点释放 Rust 的威力。
简言之——Rust 只进攻“瓶颈”，而 Go 继续守全局。
（2）正确性验证：快，不代表对
性能再好，如果结果错误也毫无意义，因此第一步不是压测，而是验证“结果完全一致”。为此，Xiaoyun Wu 他们先让 Rust 版本的新服务在“影子模式（shadow mode）”下运行：实时接收生产流量的副本，与原 Go 服务并行处理。
每一个请求的响应结果都会通过验证管线进行逐条对比。经过数周比对，确保 Go 和 Rust 版本之间的数据一致率达到 100% 后，他们才进入了下一阶段。
（3）压测阶段：看它能跑多快
正确性无误后，终于到了关键时刻。他们在生产环境中建立了两个完全相同的集群：一个跑原版 Go 服务，一个跑新的 Rust 服务，用 16000 个真实（已匿名化）用户 ID 构造数据，从低负载逐步拉升到极限， 整个过程中监控二者的 QPS、延迟、CPU 和内存使用率。
优化结果：性能翻倍，成本腰斩
测试结果超出所有人的预期：
此外，Xiaoyun Wu 提到在某关键的接口中，Rust 服务在同等硬件下的处理能力从 85000 QPS 提升至 150000 QPS——性能提升约 1.8 倍；在另一个高频接口中，Rust 版本更是从 105000 QPS 提升到 210000 QPS——实现性能翻倍。
得益于这种性能飞跃，每台机器都能承载更多流量，团队也因此直接削减了约 400 个 vCPU 核心，折算下来一年可节省约 30 万美元的云开销。
尽管如此，但 Xiaoyun Wu 也在博文中强调，这并不是一个“Rust 比 Go 更强”的故事：“选对工具，才能解决对问题。Rust 在极少数瓶颈服务中能发挥奇效，但 Go 的开发效率和性能平衡依然让它成为 95% 微服务的最佳选择。”
从 NUS 到 TikTok：一名实习生的成长轨迹
翻看 Xiaoyun Wu 的履历，他能实现这样的结果也并非偶然。
目前他就读于新加坡国立大学计算机科学专业，辅修统计学，研究方向集中在编程语言与并行计算。在校期间，他已经多次主导性能优化项目，并开发了自己的语言实验项目 “RustScript”——一个融合 Rust 语法与 TypeScript 简洁性的静态编译语言。
与此同时，他的实习经历也几乎都在围绕“性能优化”展开：
● 在 TikTok Global LIVE Wallet 团队（2024.12-2025.08）期间，除了上文提到的把部分 Go 服务重写为 Rust，他还在Oncall Agent中开发了AI驱动的分析器和自动结论功能，显著提升了Wallet服务的值班效率；并运用Golang、LLM及向量数据库对相关事件进行排序，能自动分析日志并给出问题定位建议，大幅减轻运维负担。
● 在 TikTok LIVE Money Platform（2024.05-2024.08）期间，他负责前端构建优化，将资产打包速度提升一倍，将 CI/CD 流水线时间从 15 分钟压缩至 10 分钟，并通过迁移到 Rspack 提升构建性能。
● 更早之前（2023 年），他还曾在志愿福利组织计算部门中，将一个 Ruby on Rails 系统迁移至 Go，让后端响应速度提升 5 倍。
或许正因这种“学术与实战结合”的背景，让他在面对 TikTok 这样的大规模分布式系统时，能够采取一些严谨的“科学方法”进行工程优化。
“优化到底是否有意义？”——开发者的分歧
Xiaoyun Wu 的这篇博文在 Reddit 上引发了广泛讨论，尤其是那句“实习生用 Rust 给 TikTok 省了 30 万美元”成为了开发者的焦点。
一些人认为这证明了优化依然重要；也有人觉得，这其实只是“大公司特有的游戏”：
“如果你的创业项目比 TikTok 小 1000 倍，那同样的优化你最多只能省 300 美元，而团队人力成本将远超这个收益。”
“规模越大，优化带来的节省也越惊人。没人会为了省几块钱就去用 Rust 重写服务。TikTok 的节省之所以可观，是因为他们本来每年就在这部分云资源上花费数百万美元，所以他们省下的这 30 万美元，并不算“性能优化奇迹”。而绝大多数初创公司，根本不会有这种流量规模，也不需要这么多算力。”
“关键词其实是‘规模’。在一家公司的成长中，会经历一个微妙的转折点：从“服务器比人便宜”，到“人比服务器便宜”。而如何跨过这道坎，是扩张中的最大挑战之一。
大致可以分成三个阶段：
（1）初期阶段：服务器账单太低，性能优化赚不回投入的工程时间。
（2）中间阶段：服务器开销高到值得优化，但还不如花精力去开发能带来收入的新功能。
（3）成熟阶段：服务器成本高到必须关注性能，否则利润会被吃光。
很多工程师（包括我）都喜欢钻研性能，但在第二阶段，这样做往往不是最优决策。优化的时机，和优化的必要性，其实比优化本身更重要。”
在众多开发者的讨论中，一个共识逐渐浮现：性能优化不是无意义的，但必须精准、量化、聚焦在值得和合适的地方。那么，你对于这个问题又有何看法呢？
参考链接：
https://wxiaoyun.com/blog/rust-rewrite-case-study/
https://www.reddit.com/r/programming/comments/1okf0md/tik_tok_saved_300000_per_year_in_computing_costs/
页:
[1]