Azure CTO 深度解读：微软为何要用 Rust “替换” C/C++，又将如何用 AI 加速代码迁移？

本文永久链接 – https://tonybai.com/2025/09/11/microsoft-is-getting-rusty

大家好，我是Tony Bai。

近日，微软 Azure CTO、技术巨擘 Mark Russinovich 在一场 Rust 技术会议上发表了闭幕演讲，以前所未有的坦诚和力度，揭示了微软内部正在进行的一场深刻的技术变革：全面拥抱 Rust，并战略性地替代 C/C++。

他不仅分享了 Rust 在 Windows 内核、Office、Azure 云等核心产品中的惊人实践案例，还首次披露了微软正在研发的、利用 AI 大模型自动将 C/C++ 代码转换为安全 Rust 的前沿工具。这既是一次技术分享，也是一份来自行业顶层的宣言。

在这篇文章中，我们就来看看微软在走向Rust的路上究竟做了哪些工作和改变，用户和社区的反馈又是如何。

战略驱动：为何微软必须转向 Rust？

演讲开篇，Mark Russinovich 就抛出了一个触目惊心的数据，这也是驱动微软进行这场变革的根本原因：

在过去十几年中，微软所有产品中 70% 的安全漏洞，均由 C/C++ 中的内存安全问题导致。

他直言，这种趋势仍在继续，这已不仅仅是技术债，更是持续不断的安全事件和威胁。正是基于此，他个人早已成为 Rust 的坚定拥护者，并分享了一段有趣的往事：2022年，他在看到编程语言排行榜后，有感而发地发布了一条推文——“是时候停止在任何新项目中使用 C/C++ 了，业界应该转向 Rust”。

这条推文成为了他有史以来互动量最高的内容，甚至引来了微软 CEO Satya Nadella 的电话询问。而他的回答坚定不移：“是的，我坚信如此。”

这并非一时冲动，而是一场席卷微软的、自下而上与自上而下相结合的运动。从美国国家安全局 (NSA) 呼吁业界放弃内存不安全的语言，到微软自身因不安全代码被攻击后发起的“安全未来倡议 (Secure Future Initiative)”，微软上下已经形成共识：必须摆脱不安全的语言。

实践版图：Rust 在微软核心产品中的落地生根

Mark Russinovich 随后详细介绍了 Rust 在微软内部的实践版图，其广度和深度令人瞩目。

Windows：从内核“阿喀琉斯之踵”开始

Project Mu (UEFI 固件): 微软选择从安全性要求极高的系统引导固件入手，用 Rust 重写了 UEFI 实现（Project Mu）。该项目已应用于 Azure 数据中心和 Surface 笔记本，并已开源，旨在推动整个硬件生态采用 Rust。
DirectWrite (核心图形组件): 团队选择了一个漏洞频发的独立组件——负责字体解析的 DirectWrite 进行移植。两名开发者耗时六个月，将 15.4 万行 C/C++ 代码移植为 Rust。结果不仅消除了安全隐患，还意外获得了 5% 到 15% 的性能提升。
Win32k.sys (GDI 模块): 这是 Windows 安全的“阿喀琉斯之踵”，过去20年间漏洞不断。微软选择用 Rust 重写了其中的 GDI Regions 子系统。两名开发者耗时三个月，移植了 6.3 万行 代码进入内核态。尽管 C++/Rust 的互操作边界带来了巨大挑战，但项目最终成功，且没有性能衰退。如今，在 Windows 系统目录中，你甚至能找到带有 _rs 后缀的内核模块文件。

Office 与 Azure 云：性能与安全的双重胜利

Office (DISKANN 向量搜索): Office 团队将一个前沿的向量搜索算法（DISKANN）从 C++ 移植到 Rust，用于 Office 365 和 Azure Cosmos DB。结果是惊人的：在实现同等 QPS 的情况下，召回率显著提升，内存占用反而下降。
Azure (CTO 的铁腕): Mark Russinovich 透露，早在发布那条著名推文的两三年前，他就已在 Azure 内部颁布指令：“Azure 中不再有新的 C++ 系统代码”。这一指令推动了 Rust 在 Azure 基础架构中的全面应用：
- 硬件层面: 云服务器的开源可信根项目 Caliptra、深入每台服务器的 Azure Integrated HSM 硬件安全模块，其固件均由 Rust 编写。
- 硬件卸载卡: 负责网络和存储处理的智能网卡（DPU）上的新组件，已全部使用 Rust 开发，部分已有 C++ 组件也被迁移到了 Rust。
- 虚拟化: Hyper-V 的 Arm64 模拟代码已用 Rust 重写；最近开源的 Open VMM（一个准虚拟化监视器）完全由 Rust 构建；而革命性的 Hyper-V Lite 项目，能以微秒级速度启动一个超轻量级虚拟机来运行 WASM 负载，其原型虽为 C#，但最终的开源实现完全是 Rust。
Azure 服务:
- Azure Data Explorer (ADX): 这个每天处理 PB 级数据的日志分析平台，其 V2 版本后完全用 35 万行 Rust 代码 重写，性能超越 C++ 版本，成为微软内部 Rust 实践的标杆案例。
- Azure SDK for Rust: 顺应客户需求，Azure 官方已发布了 Rust SDK 的 Beta 版本，标志着 Rust 正式成为 Azure 的一等公民语言。

真实反馈：来自一线开发者的收获与挑战

这场变革并非一帆风顺。Mark Russinovich 坦诚地分享了一线开发者的真实反馈：

** 收获 (The Positives):**

“如果它能编译，它就能工作”: 这是开发者们提到最多的一点，与 C++ 编译通过后仍充满不确定性的体验形成鲜明对比。
减少摩擦，专注创新: 消除了内存安全和数据竞争等底层心智负担。
“两个月的转变”: 一个常见的模式是，C++ 开发者最初会对所有权和借用检查器感到痛苦，但大约两个月后，他们会转变为 Rust 的忠实拥护者。

** 挑战 (The Negatives):**

C++ 互操作性是第一大难题: 在逐步替换大型 C++ 项目时，处理两种语言的边界问题耗费了大量精力。
工具链仍有待成熟。
Crate 生态系统: 开发者不确定应该使用和信任哪些第三方库。
部分依赖的特性尚未稳定。
动态链接: 在 Windows 生态中常见的动态链接，与 Rust 的结合存在问题。

尽管存在这些挑战，但 Mark Russinovich 强调，优点已经足够让微软“全身心投入 (all in)”。

展望未来：用 AI 加速 “去 C++” 进程

演讲的最后，Mark Russinovich 揭示了微软正在探索的、旨在加速 Rust 迁移的“终极武器”——自动化代码翻译。

微软正在从两个方向推进这项工作：

专用转译器 (Transpiler): 针对特定领域，如经过形式化验证的加密库。微软研究团队已开发出一个工具，能将严格遵循特定规范的 C 代码自动、安全地转译为 100% safe 的 Rust 代码，并确保其数学验证在转译后依然有效。
通用 AI 翻译器 (GenAI + GraphRAG): 这是更宏伟的目标。传统的 LLM 在处理多文件、复杂的 C++ 项目时效果不佳。微软正在利用一种名为 GraphRAG (图检索增强生成) 的先进技术。该技术能将代码解析为抽象语法树，并构建一个多层次的、包含代码摘要和依赖关系的图谱。当进行翻译时，AI 可以基于这个图谱进行更精准、更具上下文感知的代码生成。

他现场演示了一个将多文件 Python 小游戏翻译为 Rust 的例子。普通的 GPT-4o 生成的代码无法编译，而 GraphRAG 驱动的翻译器则一次性生成了可完美运行的、100% safe 的 Rust 代码。