Golang - Tony Bai

本文永久链接 – https://tonybai.com/2025/12/30/logging-sucks

大家好，我是Tony Bai。

“传统的日志记录（Logging）已经死了。不是说我们不再需要记录信息，而是那种‘写日记’式的记录方式，在微服务和高并发时代，已经彻底破产。”

曾几何时，我们写日志就像写日记：按时间顺序，一行行记录程序跑到了哪儿，发生了什么。但在现代分布式系统中，一个请求可能瞬间穿透几十个服务，留下成千上万行碎片化的文本。面对这种“信息洪流”，传统的 grep 和字符串搜索变得苍白无力。

正如 Boris Tane 在其深度好文《Logging sucks》中所言，我们正处于一个转折点，正在经历一场范式转移（Paradigm Shift）：我们需要从记录零散的“调试日记”，转向构建高维度的“结构化事件”。

img{512x368}

旧范式的崩溃——“调试日记”的局限

我们从入行就被教导的日志写法是这样的：

[INFO] User 123 clicked checkout
[DEBUG] Cart items validated
[WARN] Inventory check took 200ms
[ERROR] Payment gateway timeout

这种写法本质上是线性的、过程导向的。它假设程序的执行流是连续的，且上下文都在本地。

但在微服务架构中，这种假设不复存在。

上下文丢失：当你看到 [ERROR] Payment failed 时，你不知道这个用户的会员等级是什么，也不知道上游的购物车服务是否传递了正确的优惠券代码。
关联困难：为了追踪一个请求，你需要在海量的日志中，像考古学家一样，试图通过时间戳和零星的 ID 把碎片拼凑起来。
基数（Cardinality）限制：传统日志系统为了索引性能，往往惧怕高基数数据（如无限增长的 User ID 或 Request ID），但这恰恰是调试中最需要的信息。

“调试日记”只是在记录代码的执行路径，而我们需要知道的，是业务发生的全部真相。

新范式的崛起——宽事件 (Wide Events)

为了解决这个问题，我们需要引入“宽事件”（也称为规范化日志行）的概念。

核心理念： 不要在这个请求的生命周期内打印 10 行日志，而是等到请求结束时，发射一个包含所有上下文的宽事件。

这就好比从“写日记”变成了“填表格”。无论请求经过了多少逻辑分支，最终我们得到的是一个结构化的事实记录：

{
  "timestamp": "2025-12-26T22:30:00Z",
  "event": "checkout_request_finished",
  "duration_ms": 450,
  "status": "error",
  // --- 关键：在一个事件中包含所有上下文 ---
  "user_context": {
    "id": "u_8848",
    "plan": "enterprise",
    "region": "ap-northeast"
  },
  "infra_context": {
    "service": "payment-srv",
    "host": "k8s-pod-x9s2",
    "db_latency": 120
  },
  "business_flags": {
    "new_checkout_flow": true,
    "promotion_applied": false
  },
  "error_details": {
    "code": "insufficient_funds",
    "upstream": "stripe"
  }
}

范式转移的本质：
* 从非结构化到结构化：不再是字符串的拼接，而是键值对的集合。
* 从低维度到高维度：一个事件可以包含几十甚至上百个字段（维度），这让你可以在任意维度上进行切片和聚合。

OpenTelemetry 只是管道，不是答案

很多人认为：“我用了 OpenTelemetry，我的问题就解决了。”

这是一个巨大的误区。OpenTelemetry (OTel) 提供了标准化的传输协议和 SDK，但它不能帮你决定记录什么。

如果你只是用 OTel 自动插桩（Auto-instrumentation），你得到的只是一些通用的 HTTP 状态码和延时数据。这就像是用最先进的 5G 网络传输没有任何营养的垃圾短信。

真正的范式转移，要求开发者主动设计观测性。 你需要在代码中显式地捕获业务上下文（如 user_tier, cart_size, feature_flags），并将它们注入到当前的 Span 或 Event 中。

工具（OTel）是基础设施，思维（宽事件）才是灵魂。

从“搜索”进化为“分析”

当你完成了这次范式转移，你的调试方式将发生质的飞跃。

你不再是在搜索框里输入 Error 然后祈祷能找到线索。你现在可以像数据分析师一样提问：

“给我看过去一小时，所有企业版用户（Enterprise Plan）在使用了‘新结账流程’特性后，发生的支付失败，并按错误码分组。”

因为所有这些字段都在同一个宽事件中，数据库（如 ClickHouse, VictoriaMetrics 或其他现代观测平台）可以毫秒级地给出答案。

此外，配合尾部采样 (Tail Sampling) 策略——即只保留出错的、慢的或特定特征的完整请求链路，丢弃大量无用的成功请求——你可以在不增加存储成本的前提下，获得极高精度的调试能力。

小结：拥抱数据驱动的调试

“Logging 已死”并非危言耸听，它是对过时习惯的告别。

从“调试日记”到“结构化事件”的转变，标志着软件工程从经验主义的“猜”，走向了数据驱动的“看”。当我们不再被毫无意义的文本淹没，而是能够通过高维数据透视系统行为时，我们才真正拥有了掌控复杂系统的能力。

参考资料：https://loggingsucks.com

聊聊你的“查案”经历

在微服务的迷宫里，你是否也曾因为一条关键日志的缺失而通宵排查？或者，你所在的团队是否已经开始实践“结构化日志”或“宽事件”？

欢迎在评论区分享你的“血泪史”或“最佳实践”！ 让我们一起推动可观测性的进化。

如果这篇文章为你打开了调试的新思路，别忘了点个【赞】和【在看】，并分享给你的架构师朋友！

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

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

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

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2025/12/30/high-concurrency-backend-go-vs-rust

大家好，我是Tony Bai。

在高并发后端开发领域，Go 语言曾是当之无愧的“默认选项”。然而，随着 Rust 生态的成熟和性能神话的普及，越来越多的架构师开始动摇：是继续坚守 Go 的高效与简洁，还是拥抱 Rust 的极致性能与零成本抽象？

近日，r/golang 社区的一场热议将这一抉择摆上了台面。这不仅是语言之争，更是关于工程效率、系统复杂度与团队协作的深度博弈。本文将基于这场高质量的社区讨论，为你梳理出理性决策的核心逻辑。

img{512x368}

坚守 Go 的理由——“早点下班”的生产力

在讨论中，尽管 Rust 呼声很高，但支持坚守 Go 的声音依然占据了工程实践的主流。理由惊人地一致：生产力 (Productivity)。

“可用的软件 > 早期的优化”

一位Reddit 用户的高赞回答道出了软件工程的真谛：“使用让你高效的工具。可用的软件 > 早期的优化。”

对于绝大多数后端业务来说，瓶颈往往在于数据库、网络 I/O 或者架构设计，而不是语言本身的 CPU 执行效率。Go 语言的设计初衷就是为了解决谷歌规模的软件工程问题——快速编译、快速部署、易于阅读、易于维护。选择 Go，意味着选择了更快的交付速度。

“足够好”的并发性能

Go 的 goroutine 和 channel 使得并发编程变得前所未有的简单。正如一位用户所言：“Go 依然是处理高并发请求的王者，因为它简单、易于测试、易于优化。”

在 99% 的场景下（例如 QPS < 100k），Go 的性能已经绰绰有余。为了追求 Rust 那最后 5% 的性能提升，而牺牲 50% 的开发效率，对于大多数追求商业闭环的项目来说，是一笔亏本买卖。

人才与生态的护城河

“如果你不是在造火箭，Go 是大多数公司的最佳选择。” Go 拥有庞大且成熟的云原生生态系统（Docker, K8s, Etcd…），以及大量(相对于Rust)容易招聘的工程师。相比之下，Rust 的学习曲线陡峭，人才库相对较小，且招聘与薪资成本更高。

拥抱 Rust 的动力——当“每一字节”都至关重要

当然，Rust 的崛起并非空穴来风。社区也客观地分析了拥抱 Rust 的必要场景——那些 Go 力不从心 的极端领域。

极致的资源控制

当你的应用对延迟极其敏感（P99 要求极高），或者需要处理海量数据且对内存占用有严格要求时（例如高频交易、嵌入式系统、数据库内核），Go 的 GC (Garbage Collection) 带来的停顿就成了无法忽视的痛点。此时，Rust 的无 GC 特性就成为了杀手锏。

一位用户指出：“当 QPS 超过 100k，或者你需要榨干硬件的每一个周期时，Go 的 GC 可能会成为瓶颈，这时 Rust（或 C++）才是更好的选择。”

“编译期正确”的安全性

Rust 的借用检查器虽然让初学者头疼，但它在编译期就消灭了数据竞争和内存安全问题。对于那些绝对不能崩溃的关键基础设施（如数据平面代理），Rust 提供了比 Go 更强的安全保证。拥抱 Rust，意味着用编译时的痛苦换取运行时的安心。

工程视角的理性决策

这场讨论最终回归到了工程权衡 (Trade-offs) 上。我们不应在真空中做选择，而应根据业务场景裁决：

业务开发：坚守 Go。CRUD、微服务、Web API……Go 写起来快，改起来也快，心智负担低，是构建业务逻辑的首选。
基础设施：分层选择。Go 依然是控制面（Control Plane）的主流（看看 K8s），但在更底层的数据平面（Data Plane，如 Envoy, Linkerd 的代理部分），拥抱 Rust 正在成为趋势。
混合架构：一种越来越流行的模式是——用 Go 写控制面和业务逻辑，用 Rust 写核心的高性能组件。正如一位用户所分享：“我用 Rust 写内核模块和 IO 密集型组件，用 Go 写扩展性后端和 OLAP 管道。”