Python - Tony Bai

标签 Python 下的文章

金融级基础设施重构：放弃 Rust 拥抱 Go，务实主义的最终胜利？

二月 23, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/02/23/financial-infrastructure-rust-to-go-pragmatism-victory

大家好，我是Tony Bai。

在系统级编程语言的版图上，Go 与 Rust 的对比与争论从未停歇。一个是崇尚大道至简、开发效率极高的“云原生时代王者”；另一个则是以内存安全、零成本抽象和极致性能著称的“极客新宠”。当这两种哲学碰撞在对安全性、稳定性和低延迟要求极高的金融/交易基础设施领域时，开发者该如何抉择？

近日，在 Reddit 的 r/golang 社区中，一场由 Python 开发者发起的关于“金融基础设施长期演进：Go 还是 Rust？”的技术讨论引发了广泛关注。这位开发者试图为机器学习（ML）流水线、分布式后端和内部 DevOps 工具选择一门强类型语言，并一度陷入了“是否应该同时学习两者”的焦虑中。

这场社区讨论不仅揭示了两种语言在现代架构中的真实定位，更展现了 Go 社区一贯的“务实主义”工程哲学。本文将深度提炼这场讨论的核心观点，为正处于技术选型十字路口的架构师和开发者提供极具价值的参考。

核心探讨：金融系统中的“快”与“对”

在金融科技（FinTech）和交易系统中，有两个指标至关重要：性能（Performance/Latency）与正确性（Correctness）。这恰好对应了系统级语言常常被审视的两个维度。

Rust 的诱惑：绝对的控制与“编译即正确”

许多开发者最初被 Rust 吸引，正是因为其在金融领域展现出的“绝对严谨”。

代数数据类型与状态机：社区用户指出，Rust 的表达能力极强。在处理复杂的金融业务逻辑（如订单状态流转、复杂的税务和结算规则）时，Rust 的枚举（Enum）和模式匹配可以迫使开发者在编译期处理所有可能的边缘情况，实现所谓的“使无效状态不可表达”（Make invalid states unrepresentable）。
无数据竞争（Data Race Free）：借用检查器（Borrow Checker）和所有权模型在根本上杜绝了多线程环境下的数据竞争。对于处理资金流水的并发程序而言，这种内存安全性能够极大地降低睡眠被报警惊醒的概率。
无 GC 延迟：针对极度敏感的场景（如做市商系统），Rust 摆脱了垃圾回收器（Garbage Collector）的不可预测性，能够提供稳定、可预测的尾部延迟（Tail Latency）。

然而，正如资深工程师在讨论中指出的：“Rust 的高壁垒不仅体现在初始学习成本上，更体现在它持续要求你的大脑处于高速运转状态。” 在编写普通业务代码时，开发者需要不断与编译器“搏斗”，这在无形中拖慢了业务交付（Shipping）的速度。

Go 的底气：“80% 的性能，20% 的精力”

面对 Rust 强大的理论优势，Go 社区给出的回应并不是在极限性能上去硬碰硬，而是打出了一张工程学上的王牌：投入产出比（ROI）。

极速的开发与迭代：“如果你的目标是尽快发布产品（Ship fast），同时保持系统的可靠性，Go 是完美的折中。” Go 语言的语法极简，没有复杂的生命周期标注，这使得开发者可以把 100% 的精力放在业务逻辑和系统架构上，而不是讨好编译器。
完美的 I/O 并发模型：金融系统的很大一部分工作并非重度 CPU 计算，而是网络 I/O（如对接外部交易所 API、读取数据库、微服务间通信）。Go 内置的 goroutine 提供了极其廉价的上下文切换机制。一位用户精辟地总结：“在处理高度并发或重度 I/O 阻塞的操作时，Go 是无敌的。而在 Rust 中构建高并发的异步（Async）应用，需要极高的经验值，但在 Go 中这就像呼吸一样自然。”
足够好的性能与 GC：虽然 Go 有垃圾回收机制，但经过十多年的演进，Go 的 GC 停顿时间已经达到了亚毫秒级。对于 99% 的金融应用（如支付网关、账单系统、风控后端）来说，Go 的性能已经“快到了性能盈余”的地步。社区用户坦言：“除非你是在证券交易所做内部的高频交易（HFT），否则 Go 的速度绝对绰绰有余。”

领域决定边界：基础设施与业务逻辑的解耦

讨论中一个非常核心的洞见是：不要试图用一种语言解决所有问题，而是要看清具体领域的边界。楼主的背景是 Python，主要涉及 ML 流水线。这引出了现代架构中非常经典的一种组合模式。

Python + Go：现代数据驱动架构的“王炸”组合

Python 主宰数据与模型：在机器学习、量化分析和数据科学领域，Python 的生态（Pandas, NumPy, PyTorch）具有不可撼动的统治地位。强行用 Go 或 Rust 去重写模型训练或复杂的矩阵运算，被社区公认为“过早优化”和“重复造轮子”。
Go 主宰服务与编排：当模型训练完成需要部署上线，或者需要构建处理海量请求的 API 网关、数据搬运管道、以及后端微服务时，Python 的 GIL（全局解释器锁）和性能瓶颈就会显现。此时，引入 Go 作为基础设施层（Infrastructure Layer）是最完美的互补。

这种架构下，系统被清晰地划分为：Go 负责将数据又快又稳地搬运和路由，Python（在底层 C/C++ 的加持下）负责纯粹的数学和模型计算。这种解耦使得整个系统既享受了 Python 的生态红利，又获得了 Go 在分布式系统上的强悍工程能力。

真正的 HFT（高频交易）属于谁？

不可忽视的是，当讨论深入到金融领域的最底端——高频交易（HFT）时，社区展现出了极度客观的技术视野。

多位业内人士指出，在纳秒必争的超低延迟交易领域，C++ 依然是绝对的霸主。尽管 Rust 在试图切入这一市场，但 C++ 在传统金融领域积累的庞大库、成熟的生态以及直接操作硬件的能力，短期内难以被撼动。因此，如果业务的核心真的是 HFT，那么 Go 和 Rust 可能都不是最优解。这就进一步确认了 Go 的主战场：高吞吐的分布式后端与云原生基础设施。

隐性成本：认知负荷、团队建设与代码维护

在架构决策中，语言的特性往往只占 50%，另外 50% 则是关于人的管理。这也是本次社区讨论中，Go 获得压倒性支持的关键原因。

代码的生命周期与可修改性

“在商业应用中，我更看重随着时间的推移，修改代码有多难。业务需求在不断变化，代码也必须随之改变。”

Go 的修改成本极低：Go 的代码结构扁平，没有复杂的隐式抽象。这使得重构和修改极其快速。Go 的接口（Interface）设计是隐式的（Duck Typing），在拆分微服务或调整模块时，不需要像严格继承体系那样大动干戈。
Rust 的“牵一发而动全身”：Rust 高度严格的类型系统是一把双刃剑。虽然它保证了修改后的代码几乎不会出错，但在快速迭代期，添加一个新功能往往意味着要重构一大部分的生命周期标注和类型关系，这对于需要快速响应市场变化的初创项目来说是致命的。

团队招聘与代码交接

“如果你用 Rust 构建了一个工具，当系统在半夜发生故障时，团队里的其他人能轻易地看懂代码并修复它吗？”

Go 的创造者之一 Rob Pike 曾明确表示，Go 的设计初衷就是为了解决 Google 内部大型团队的协作问题。Go 的语法少、规范统一（gofmt），被称为“没有魔法的语言”。一个有其他语言基础的程序员，通常只需一两周就能熟练上手 Go 并提交生产代码。

相比之下，熟练的 Rust 开发者在市场上不仅稀缺，而且薪资高昂。对于一家非底层技术驱动的金融公司而言，使用 Go 可以极大地降低招聘门槛和团队代码交接的风险。

小结：务实主义的胜利

回到这位发帖者的终极问题：“我应该同时深入学习 Go 和 Rust 吗？”

社区给出的答案异常一致：绝对不要。 尤其是在项目初期。同时学习两门底层逻辑截然不同的语言，不仅会带来巨大的认知撕裂，还会严重拖慢项目进度（Shipping speed）。

最终，这位发帖者更新了他的决定：选择 Go。

“我不想在开始阶段就陷入困境，既然我是独立开发，我开始觉得 Go 才是正道。对于沉重的数学计算，我会继续让 Python 负责。我意识到 Go 真的非常好用，只要我懂得正确使用它，它能在所有的用例中大显身手。此外，Go 社区是我见过最友好的社区之一，你们太棒了！”

在 AI、区块链、量化金融等技术泡沫层出不穷的今天，技术选型很容易陷入“追逐时髦”（Hype Driven Development）的陷阱。Rust 无疑是一门伟大的语言，代表了系统编程的未来探索。然而，Go 语言的伟大之处在于它始终保持着极其清醒的工程边界感。

它不追求类型理论的极致完美，也不苛求消除最后百分之一的性能损耗，它追求的是：在开发者心智负担、编译速度、运行性能、并发模型和部署便利性之间，找到一个无可挑剔的全局最优解。

对于现代分布式系统、网络服务和金融后端基础设施而言，Go 依然是那个能够让你“早点下班、安心睡觉”的最优选择。这也是务实主义在工程世界里，又一次漂亮的胜利。

资料链接：https://www.reddit.com/r/golang/comments/1ra0dza/go_vs_rust_for_longterm_systemsfinance/

你怎么选？

软件工程永远是权衡的艺术。在你看来，对于非高频交易的后端业务，Rust 带来的安全性是否足以抵消它的开发成本？如果你现在接手一个新项目，你会优先选择“能让你早点下班”的 Go 吗？

欢迎在评论区分享你的选型“心法”！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

告别低效，重塑开发范式
驾驭AI Agent(Claude Code)，实现工作流自动化
从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

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

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

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

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

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

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

AI 基础设施的语言之争：为何构建 LLM 网关时，我们放弃了 Python 选择了 Go？

二月 18, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/02/18/why-we-chose-go-over-python-for-llm-gateways

大家好，我是Tony Bai。

在 2026 年的今天，人工智能早已走出了实验室，成为企业级应用的核心驱动力。Python，凭借其在机器学习领域的绝对统治地位——拥有 PyTorch、TensorFlow、Hugging Face 等无可匹敌的生态系统——长期以来被视为 AI 开发的“默认语言”。

然而，随着 AI 应用从模型训练（Training）走向推理服务（Inference）和应用编排（Orchestration），工程重心发生了微妙的转移。当我们谈论模型本身时，Python 是王者；但当我们谈论承载模型流量的基础设施——网关、代理、路由器时，Python 还是最佳选择吗？

近日，开源 LLM 网关项目 Bifrost 的维护者在 Reddit 上分享了一篇题为《Why we chose Go over Python for building an LLM gateway》的技术复盘，引发了社区的强烈反响。他们放弃了拥有 LiteLLM 等成熟竞品的 Python 生态，转而使用 Go 重写了核心网关。结果令人咋舌：延迟降低了约 700 倍，内存占用降低了 68%，吞吐量提升了 3 倍。

这场技术选型的背后，折射出的是 AI 工程化进入深水区后，对并发模型、资源效率与部署架构的重新审视。

Python 的“舒适区”与“性能墙”

在项目的初期，选择 Python 似乎是理所当然的。

1. 生态惯性与“胶水”优势

绝大多数 AI 工程师都是 Python Native。从 LangChain 到 LlamaIndex，几乎所有的 Agent 开发框架都优先支持 Python。使用 Python 构建网关，意味着可以直接复用现有的库，甚至可以直接挂载一些轻量级的 Python 逻辑来处理 Embeddings 或 RAG（检索增强生成）流程。FastAPI 的易用性更是让开发者能在几分钟内搭建起一个服务。

2. 遭遇瓶颈：网关的本质是 I/O

然而，LLM 网关的业务属性决定了它的性能痛点。与计算密集型（CPU-bound）的模型推理不同，网关是典型的 I/O 密集型应用。它的核心职责是：

接收成千上万的客户端请求。
将请求转发给上游提供商（如 OpenAI, Anthropic, 或自建的 vLLM）。
等待上游响应（这是最耗时的环节，LLM 的首字延迟 TTFT 通常在秒级）。
将流式响应（SSE）回传给客户端。

在这个过程中，网关绝大部分时间都在“等待”。

3. Python 的并发痛点

Bifrost 团队在测试中发现，当并发请求数达到 500-1000 RPS（每秒请求数）时，Python 的瓶颈开始显现。

GIL（全局解释器锁）的幽灵：虽然 Python 的 asyncio 可以处理 I/O 并发，但 GIL 依然限制了多核 CPU 的利用率。对于需要处理大量并发连接、同时可能涉及少量数据处理（如 Token 计数、PII 过滤）的网关来说，线程竞争（Thread Contention）成为了不可忽视的开销。
昂贵的上下文切换：在 Python 中维持数千个并发连接，其上下文切换的开销远高于编译型语言。

Go 的降维打击——数据背后的技术真相

Bifrost 团队最终选择了 Go。这一决定并非出于对语言的偏好，而是基于冷冰冰的 Benchmark 数据。让我们深入分析他们披露的核心指标。

延迟（Latency）：微秒与毫秒的鸿沟

数据对比：
* Bifrost (Go): ~11 微秒 (0.011ms) / 请求
* LiteLLM (Python): ~8 毫秒 / 请求

这是一个惊人的 700 倍 差距。

虽然 8 毫秒在人类感知中似乎微不足道，但在高并发架构中，这被称为“开销放大”。

累积效应：在一个复杂的 AI Agent 工作流中，可能涉及几十次 LLM 调用。如果每一层网关都增加 8ms 的延迟，累积起来就是可感知的卡顿。
高负载下的劣化：在 10,000 个并发请求下，Go 引入的总处理时间仅为 110ms，而 Python 方案则产生了惊人的 80 秒总 CPU 时间开销。这意味着 Python 方案需要消耗更多的 CPU 核心来维持同样的响应速度，否则请求就会排队，导致尾部延迟（Tail Latency）飙升。

此外，Go 的 net/http 标准库在处理 HTTP 请求时经过了极致优化。Go 不需要像 Python 那样依赖 ASGI/WSGI 服务器（如 Uvicorn），其原生的 HTTP 处理能力配合 Goroutine，使得每个请求的内存分配和 CPU 周期都降到了最低。

并发模型：Goroutine vs Asyncio

架构对比：
* Go: 10,000 个 Goroutines，每个仅占用 ~2KB 栈空间。
* Python: 受限于 OS 线程开销或 Event Loop 的单核瓶颈。

LLM 网关的特殊性在于长连接。LLM 的流式输出可能持续数秒甚至更久。这意味着网关必须同时维护成千上万个活跃连接。

Go 的 GMP（Goroutine-Machine-Processor）调度模型天生适合这种场景。成千上万个 Goroutine 可以复用少量的系统线程，上下文切换由 Go Runtime 在用户态极速完成，几乎不消耗系统内核资源。

相比之下，Python 即使使用了 uvloop，在面对海量并发连接的数据搬运时，其解释器的开销依然是一个沉重的包袱。

内存效率与成本

数据对比：
* Go: 内存占用降低 ~68%。
* 生产环境: Go 跑在 t3.medium (2 vCPU, 4GB) 上即可；Python 则需要 t3.xlarge。

对于大规模部署 AI 服务的企业来说，这意味着基础设施成本直接减半。

Python 的动态类型系统和垃圾回收机制导致其对象内存占用较大。而 Go 的结构体布局紧凑，且编译器能进行逃逸分析（Escape Analysis），将大量对象分配在栈上而非堆上，从而显著降低了 GC 压力和内存占用。

社区深度探讨——AI 时代的语言版图重构

这篇帖子在 r/golang 引发了极高质量的讨论，评论区揭示了行业内更深层次的趋势。

“AI 能够写代码”改变了竞争规则

过去，Python 的一大优势是“开发效率高”。写 Python 代码通常比写 Go 或 Rust 快。

但在 2026 年，“Agentic Coding”（即利用 AI Coding Agent 辅助编程）已经成为主流。

有开发者指出：“LLM 让编写 Rust 和 Go 变得非常高效，你完全可以享受到高性能语言的红利，而不用支付编写它们的‘学习成本’。”

这是一个极其深刻的洞察。

Rust 的借用检查器：以前是新手的噩梦，现在 LLM 可以很好地处理生命周期标注。
Go 的样板代码：if err != nil 虽然繁琐，但 Copilot/Cursor/Claude Code等可以一键生成。

当“编写代码”不再是瓶颈时，“运行时性能”和“稳定性”的权重就被无限放大了。这进一步削弱了 Python 在后端基础设施层的竞争力。

Rust 还是 Go？

既然要高性能，为什么不直接上 Rust？

评论区对此展开了激辩。虽然 Rust 在理论上拥有比 Go 更高的性能上限和内存安全性（无 GC），但 Go 在“开发效率”与“运行效率”之间找到了完美的平衡点。

Rust: 适合构建数据库、搜索引擎内核等对延迟极其敏感且逻辑复杂的底层组件。但 Rust 的“认知负担”依然较重，且编译速度较慢。
Go: 提供了 80% 的 Rust 性能，但只有 20% 的开发难度。对于网关、代理这类中间件，Go 的标准库（特别是 net/http）极其成熟，编译速度极快，且自带 GC 能让开发者从内存管理的细节中解脱出来，专注于业务逻辑（如限流、计费）。

对于大多数 AI 网关场景，Go 是性价比最高的选择。

Python 的归宿：模型与胶水

这是否意味着 Python 将被淘汰？绝不。

社区共识非常明确：Python 的护城河在于 ML 生态。

模型训练与微调：PyTorch/JAX 无可替代。
数据科学与探索：Jupyter Notebook 是数据科学家的后花园。
快速原型开发：在验证想法阶段，Python 依然是最快的。

但在生产环境部署（Production Serving）阶段，架构正在发生分离：

控制平面（Control Plane）：由 Go/Rust 接管，负责流量调度、鉴权、日志、监控。
数据平面（Data Plane）：核心推理引擎（如 vLLM）虽然内部可能有 C++/CUDA 优化，但外层接口仍常由 Python 封装。

Go 在 AI 领域的未来展望

Bifrost 的案例只是冰山一角。我们正在目睹 Go 语言在 AI 领域的“新基建”运动。

静态二进制文件的魅力

Deployment simplicity 是作者提到的另一个关键点。

部署 Python 应用通常意味着：配置 Docker -> 安装 Python -> pip install requirements.txt -> 解决依赖冲突 -> 虚拟环境管理。

而部署 Go 应用：COPY bifrost /usr/local/bin/ -> Run。

在容器化和 K8s 盛行的今天，Go 的静态链接二进制文件极大地简化了 CI/CD 流程，减小了镜像体积，提升了冷启动速度（这对于 Serverless AI 推理尤为重要）。

AI 专有工具链的完善

虽然 Go 在 Tensor 操作库上不如 Python 丰富，但在应用层工具上正在迅速补齐。

LangChainGo: 社区正在移植 LangChain 的核心能力。
Vector Database Clients: Milvus, Weaviate, Pinecone 等向量数据库都有优秀的 Go SDK。
主流大模型 GenAI SDK: 像Google等主流大模型厂商官方对 Go 的支持力度都很大，Gemini、Claude、OpenAI 等模型的 Go SDK 体验都还不错。

架构师的决策建议

如果你正在构建一个 AI 应用平台：

不要用 Python 写网关：不要让 GIL 成为你高并发路上的绊脚石。
不要用 Go 写模型训练：不要试图挑战 PyTorch 的地位，那是徒劳的。
采用“三明治架构”：
- 上层：Go 处理高并发 HTTP 请求、WebSocket、SSE。
- 中层：Go 处理业务逻辑、数据库交互、Redis 缓存。
- 底层：Python/C++ 容器专门负责模型推理，通过 gRPC 与 Go 层通信。