技术志 - Tony Bai

本文永久链接 – https://tonybai.com/2025/06/26/non-deterministic-abstraction

大家好，我是Tony Bai。

在软件开发领域，Martin Fowler 的名字几乎等同于思想的灯塔。他的每一篇文章、每一次演讲，都能为我们揭示行业发展的深层脉络。最近，Fowler 大师又发布了一篇简短但引人深思的博文——《LLMs bring new nature of abstraction》，再次精准地捕捉到了一个正在发生的、可能颠覆我们认知和工作方式的巨大变革。

Fowler 认为，大型语言模型（LLM）的出现，对软件开发的影响，堪比从汇编语言到首批高级编程语言（HLLs）的飞跃。但关键在于，LLM 带来的不仅仅是又一个“更高层次”的抽象，它正在从根本上改变编程的“本质”——迫使我们思考，用“非确定性工具”进行编程究竟意味着什么。

在这篇文章中，我们就来简单解读一下。

从“确定性”的阶梯到“非确定性”的岔路

回顾编程语言的发展史，我们一直在追求更高层次的抽象，以提升生产力、降低复杂度：

汇编语言 vs. 机器指令： 汇编让我们用助记符替代了 0 和 1，但仍需关注特定机器的寄存器和指令集。
高级语言 (HLLs) vs. 汇编： Fortran、COBOL 等早期 HLLs 让我们能用语句、条件、循环来思考，而不用关心数据如何在寄存器间移动。Fowler 回忆道，他用 Fortran IV 编程时，虽然有诸多限制（如 IF 没有 ELSE，整数变量名必须以 I-N 开头），但这已经是巨大的进步。
现代语言、框架、DSL vs. 早期 HLLs： Ruby、Go、Python 等现代语言，以及各种框架和领域特定语言（DSL），进一步提升了抽象层次。我们现在可以本能地将函数作为数据传递，使用丰富的库和模式，而不用从头编写大量底层代码。

Fowler 指出，尽管这些发展极大地提升了抽象层次和生产力，但它们并没有从根本上改变“编程的性质”。我们仍然是在与机器进行一种“确定性”的对话：给定相同的输入和代码，我们期望得到相同的输出。错误（Bug）也是可复现的。

然而，LLM 的介入，打破了这一基本假设。

Fowler 写道：“用提示词与机器对话，其差异之大，犹如 Ruby 之于 Fortran，Fortran 之于汇编”。

更重要的是，这不仅仅是抽象层次的巨大飞跃。当 Fowler 用 Fortran 写一个函数，他可以编译一百次，结果中的 Bug 依然是那个 Bug。但 LLM 引入的是一种“非确定性”的抽象 (non-deterministic abstraction)。

这意味着，即使我们把精心设计的 Prompt 存储在 Git 中，也不能保证每次运行都会得到完全相同的行为。正如他的同事 Birgitta Böckeler 精辟总结的那样：

我们并非仅仅在抽象层级上“向上”移动，我们同时也在“横向”移入非确定性的领域。

Fowler 文章中的配图非常形象地展示了这一点：传统的编程语言、编译器、字节码是一条清晰的、自上而下的抽象路径；而模型/DSL、代码生成器、低代码、框架是其上的不同抽象层次。自然语言（通过 LLM）则像一条从旁边切入的、直接通往“半结构化/接近人类思维”的道路，这条路本身就带有模糊和不确定性。

“非确定性”编程时代的挑战与启示

这种“非确定性”的本质，对我们 Gopher，乃至所有软件开发者，都带来了前所未有的挑战和需要重新思考的问题：

版本控制与可复现性： 当 Prompt 不能保证结果一致时，我们如何管理和版本化我们的“AI辅助代码”？如何确保开发、测试、生产环境的一致性，或者至少是可接受的差异性？仅仅版本化 Prompt 可能不够，我们还需要版本化模型、参数（如 temperature）甚至是一些关键的种子（seed）吗？
测试与调试： 如何测试一个输出不完全固定的“组件”？传统的单元测试、集成测试方法是否依然有效？我们可能需要引入新的测试策略，例如基于属性的测试、对输出结果的统计验证、或者更侧重于行为和意图的验证。当 LLM 生成的代码出现问题，调试的难度是否会指数级增加？
可靠性与契约： 在一个包含非确定性AI组件的系统中，如何定义和保证整体的可靠性？服务间的“契约”又该如何描述和强制执行？
思维模式的转变： 我们习惯了对代码的精确控制，追求逻辑的严密和行为的可预测。现在，我们可能需要学会与“模糊”和“概率”共存，从“指令下达者”转变为“意图沟通者”和“结果筛选者”。

这对我们 Gopher 意味着什么？

Go 语言以其明确性、强类型、简洁的并发模型以及相对可预测的行为，深受开发者喜爱。当我们尝试将 LLM 融入 Go 的生态和开发流程时，这些“非确定性”的特性会带来新的思考：

AI 生成 Go 代码： 当我们使用 LLM 生成 Go 代码片段、单元测试，甚至整个模块时，如何确保生成的代码符合 Go 的最佳实践、是高效且安全的？如何对生成的代码进行有效的审查和集成？
用 Go 构建与 LLM 交互的工具/Agent： 如果我们用 Go 开发与 LLM 交互的后端服务或智能体（Agent），我们需要在架构设计上充分考虑 LLM 的非确定性，设计更鲁棒的错误处理、重试机制，以及对 LLM 输出结果的验证和筛选逻辑。
利用 LLM 理解复杂 Go 系统： LLM 或许能帮助我们理解遗留的复杂 Go 代码库，但其解释的准确性和一致性也需要我们审慎评估。

Fowler 在文末表达了他对这一变革的兴奋之情：“这种改变是戏剧性的，也让我颇为兴奋。我相信我会为一些失去的东西感到悲伤，但我们也将获得一些我们中很少有人能理解的东西。”

小结：拥抱不确定，探索新大陆

Martin Fowler 的这篇文章，为我们揭示了 LLM 时代编程范式可能发生的深刻转变。它不再仅仅是工具的进化，更是与机器协作方式的本质性变革。

作为 Gopher，作为软件工程师，我们需要开始认真思考这种“非确定性”带来的影响，积极探索与之共存、甚至利用其特性创造价值的新方法。这无疑是一个充满挑战但也充满机遇的新大陆。

你如何看待 Fowler 的这个观点？你认为 LLM 带来的“非确定性”会对你的日常开发工作产生哪些具体影响？欢迎在评论区分享你的看法！

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/06/24/grab-rewrote-go-service-in-rust

大家好，我是Tony Bai。

最近，东南亚科技巨头、出行公司 Grab 的一篇技术博客《Counter Service: How we rewrote it in Rust》在技术圈引起了不小的震动。他们将一个高 QPS（每秒查询率）的 Go 微服务（Counter Service）用 Rust 进行了重写，结果令人瞩目：在保持相似 P99 延迟性能的前提下，基础设施成本降低了高达 70%！ 。

P99延迟对比：Go（紫色），Rust（蓝色）

这个案例无疑给许多以 Go 作为主力语言的团队和开发者带来了强烈的冲击。Go 语言以其简洁、高效并发、快速编译以及强大的生态系统，在微服务、云原生领域早已占据重要地位。那么，Grab 的这次成功“叛逃”，是否意味着 Go 语言在某些场景下的“护城河”正在被侵蚀？Rust 真的是解决一切性能和成本问题的“银弹”吗？

今天，我们就来深入剖析 Grab 的这个重构案例，看看他们究竟“得”了什么，“失”了什么，以及这背后能给咱们 Gopher 带来哪些宝贵的启示。

Rust 的“杀手锏”：极致效率带来的基础设施成本骤降

Grab 的 Counter Service 主要负责计数和提供 ML 模型/欺诈规则的计数器服务，是一个典型的 I/O 密集型和计算密集型并存的服务，QPS 峰值可达数万。用 Go 实现时，该服务需要大约 20 个 CPU Cores 来支撑。

然而，在用 Rust 重写后，同样的负载下，新的 Rust 服务仅需 4.5 个 CPU Cores！这几乎是 近80% 的资源节省，直接带来了 70%以上的基础设施成本降低。

为什么 Rust 能做到如此极致的效率提升？Grab 的文章和 Rust 语言本身的特性共同揭示了答案：

无垃圾回收 (GC)：这是 Rust 相比 Go 在追求极致性能和资源控制上的核心优势。Go 的 GC 虽然已经非常优秀，但在高并发、低延迟场景下，GC 扫描和 STW (Stop-The-World) 仍然可能引入不可预测的延迟抖动和额外的 CPU 开销。Rust 通过所有权系统在编译期保证内存安全，无需运行时 GC，从而消除了这部分开销。
内存安全与零成本抽象：Rust 的所有权、借用检查等机制虽然带来了陡峭的学习曲线，但也确保了内存安全，避免了空指针、数据竞争等常见问题。同时，Rust 的许多高级抽象（如迭代器、闭包）能够在编译期被优化掉，实现“零成本抽象”，性能接近 C/C++。
更精细的控制：Rust 赋予开发者对内存布局、线程模型更细致的控制权，使得在特定场景下可以进行深度优化。

Grab 的案例似乎在证明，当业务场景对资源消耗和运行成本极度敏感，且服务逻辑相对“简单”（Grab 特别强调了选择重写目标时，功能需要足够简单，复杂度可控）时，Rust 的这些特性能够带来实实在在的巨大回报。

光鲜背后的“代价”：Grab 的探索与挑战

然而，享受 Rust 带来的极致效率并非没有代价。Grab 团队在博客中也坦诚地分享了他们遇到的挑战和权衡：

陡峭的学习曲线，尤其是 async

文章提到：对于习惯了 Go 语言简洁 go关键字和 GMP 调度模型的 Gopher 来说，Rust 的所有权、生命周期已经是第一道坎，而 async/await 异步模型及其“函数着色”问题、显式 yield（通过 await）等概念，则带来了更高的认知负荷。Grab 团队也曾因错误地在异步代码中使用了同步 Redis 调用而导致性能不佳。

生态系统与内部库的“阵痛”

虽然 Rust 的生态在快速发展，但在某些特定领域，库的选择可能不如 Go 那样成熟和丰富。Grab 团队在选择 Datadog 和 Redis 客户端库时就进行了一番评估和取舍。

更痛的是内部库的迁移。Grab 内部大量基础库是用 Go 编写的，例如一个使用 Go Templates 进行配置管理的库。在 Rust 项目中，这些 Go 库无法直接复用，团队不得不使用 nom 解析器组合库在 Rust 中重写了类似的功能。这无疑增加了重构的成本和时间。

开发体验的差异

Go 的设计哲学之一就是“简单”，这使得开发者能够快速上手并高效迭代。Goroutine 和 Channel 的易用性，让并发编程的门槛大大降低。相比之下，Rust 为了安全和性能，在语言层面引入了更多复杂性，需要开发者投入更多精力去理解和驾驭。

“Rust 一定比 Go 快得多”是迷思

一个非常重要的发现是，Grab 明确指出：“神话 1：Rust 非常快！比 Golang 更快！判定：被驳斥。Golang 对于大多数使用案例来说“足够快”……仅仅为了性能提升而将 Golang 服务重写为 Rust 不太可能带来显著的好处。”

在 P99 延迟方面，Rust 版本与 Go 版本表现相当，甚至有时略差。这告诉我们，Go 在其设计领域内性能已经足够优秀，单纯为了追求“更极致”的速度而用 Rust 重写 Go 服务，可能并不能带来预期的巨大性能提升，反而可能因为生态、开发效率等问题得不偿失。Grab 的主要收益点在于显著的 资源效率 提升。

Gopher 何去何从？几点思考

Grab 的案例无疑是 Go 社区的一面镜子，它照见了 Go 的优势，也揭示了在特定场景下可能存在的“天花板”。作为 Gopher，我们应如何看待这个案例，并从中吸取经验呢？

首先，Go 的核心优势依然稳固。Go 语言以其简洁性、强大的并发模型（Goroutine + Channel）、高效的编译速度、完善的工具链以及成熟的生态系统，继续在云原生、微服务、中间件和 DevOps 工具等领域占据首选或极具竞争力的地位。对于绝大多数业务场景，Go 提供的开发效率和运行性能是“足够好”的，且具有高性价比。

其次，关于何时考虑使用 Rust 进行“动刀”，Grab 的案例提供了几个关键的决策参考点。

在面对极高的 QPS 和资源消耗时，如果服务本身成为性能瓶颈且占用了大量服务器资源，那么迁移可能是合适的。
当功能相对简单且逻辑内聚时，重写的复杂度较低，易于验证，这样可以避免对复杂业务系统进行大规模重写。
当基础设施成本成为显著负担，优化能带来巨大的商业价值时，也应考虑使用 Rust。
团队必须具备掌握 Rust 的能力，成员需熟悉 Rust 并愿意投入时间和资源进行团队赋能。在不满足这些前提条件的情况下，盲目追求 Rust 可能弊大于利。

再者，在考虑语言迁移之前，我们应充分挖掘 Go 本身的优化潜力。例如，进行代码层面的性能分析与优化、架构调整、选择更优的 Go 库，甚至是通过 Go 版本升级带来的 GC 改进等。重写通常应视为最后的手段。

关于 Gopher 是否需要拥抱 Rust，这取决于个人的发展方向和兴趣。如果你专注于业务开发和应用层构建，Go 依然能让你游刃有余。但如果你对系统编程、底层优化、嵌入式或游戏引擎等领域感兴趣，或者所在的公司/团队正在引入 Rust，那么学习 Rust 无疑会为你打开一扇新的大门。即使不深入学习，了解 Rust 的核心理念（如所有权、生命周期和无GC）也能帮助我们更好地理解程序运行的本质，从而写出更健壮、更高效的 Go 代码。

最后，Go 语言的未来同样值得关注。Go 社区在持续进化，例如对泛型的支持提升了表达力，而持续优化的 GC 以及不断丰富的高性能标准库也在不断减少对性能的影响。未来，Go 是否会在某些方面借鉴其他语言的优秀特性，以保持其核心优势的同时，进一步拓展能力边界，值得我们期待。