本文永久链接 – https://tonybai.com/2025/08/03/choose-boring-technology

大家好，我是Tony Bai。

大约十年前，Dan McKinley 的一篇经典雄文《选择无聊的技术》（Choose Boring Technology）在工程师圈子里广为流传。它的核心观点简单而深刻：一家公司的“创新代币”（innovation tokens）是有限的，应该用在刀刃上，而不是随意挥霍在那些闪亮但未经证实的新技术上。

“无聊”的技术，比如 Postgres、Python、PHP，它们的优势不在于新潮，而在于其故障模式和能力边界是众所周知的。当系统在凌晨三点崩溃时，你需要的是一个有大量 Stack Overflow 答案可以求助的领域，而不是一片你必须独自开拓的未知“无人区”。

这个原则，在过去十年里，成为了无数资深工程师的技术选型座右铭。然而，十年后的今天，随着 LLMs 和 Agentic AI 编程工具的崛起，业界仍然认为：这个原则不仅没有过时，反而比以往任何时候都更加重要，甚至更加致命。

AI 时代的“诱惑”与“危险”

AI 编程助手带来了一个全新的变数。这个变数既有趣，又极其危险。

这里的“有趣”在于，现代 AI 工具（无论是 Claude 还是 Copilot）已经非常擅长为几乎任何你能想到的技术栈，生成“看起来非常专业”的代码。你给它一个 prompt，让它用最新的 JavaScript 框架、GraphQL federation 和 Kubernetes 来实现一套微服务，它会迅速给你返回一堆代码——这些代码可能遵循了所有社区惯例，命名规范无可挑剔，错误处理看起来也像模像样，甚至，它可能真的能运行。

这就是 AI 的“诱惑”。它让你感觉，掌握任何新技术都不过是弹指一挥间的事。

而“危险”也恰恰源于此。当你在一个你不熟悉的技术领域里使用 AI 时，一个致命的问题出现了：

你根本无法验证，AI 是不是在“一本正经地胡说八道”（bullshitting you）。

我亲眼见过，有工程师接受了 AI 生成的代码，而这些代码里：

• 使用了早已废弃的 API。
• 实现了严重的安全反模式。
• 制造了只有在生产负载下才会暴露的、极其隐蔽的性能问题。

为什么会这样？因为这些代码“看起来是对的”。但它的错误，是深植于技术细节中的，只有真正熟悉这门技术的人才能一眼看穿。

风险的“乘法效应”

过去，我们说选择一门新技术是增加了一个“未知数”。而在 AI 时代，当你将不熟悉的技术与 AI 生成的代码结合时，你不再是简单地增加未知数，而是在乘以未知数。

你不知道这个框架是否是解决你问题的最佳选择；你不知道 AI 的实现是否遵循了最佳实践；你不知道生成的代码中，哪些是无伤大雅的模板，哪些是核心业务逻辑；你更不知道，这套组合拳将会以何种奇特的方式在未来失效。

这已经不是简单的“货物崇拜”（cargo-culting）了，这是指数级的货物崇拜。

注：“货物崇拜”（cargo culting）是一个源自太平洋岛屿的概念，最早用于描述一些岛屿居民对西方物资和技术的崇拜现象。在二战期间，许多西方士兵在这些岛屿上驻扎，带来了大量的物资和现代技术。当地人对这些物品产生了强烈的向往，认为这些物品是神灵的恩赐。

AI 时代的“技术选型第一性原理”

那么，我们该怎么办？答案出奇地简单，它让我们回归到了那个最朴素的原则：

AI 是你所理解技术的“力量倍增器”，却是你不理解技术的“脆弱拐杖”。

当你选择“无聊”的技术，也就是你真正精通的技术时，AI 会变得无比强大。你可以让 Claude 帮你生成 Rails 代码，因为你对 Rails 了如指掌，能轻易发现它何时提出了可疑的建议。你可以让 Copilot 辅助你写 JavaScript，因为你理解这门语言的怪癖，能对它的产出进行事实核查。

在这种模式下，AI 是你的副驾驶，为你处理繁琐的路线，而你始终掌握着方向盘。

给 AI 时代开发者的实践指南

那么，在一个充满 AI 编程助手的世界里，我们该如何应用“选择无聊的技术”这一原则呢？这里有三条黄金法则：

1. 评估新技术时先自问：“如果 AI 为它生成了代码，我有能力审查吗？” 如果答案是否定的，那么这项技术或许不应该用于任何对你而言是任务关键型（mission-critical）的项目。

2. 学习新技术时（当你决定用掉一个“创新代币”时）： 请务必花时间深入理解它，达到能对 AI 的建议进行独立事实核查的程度。不要只是复制、粘贴，然后祈祷好运。

3. 抵制诱惑： 不要把 AI 工具当作一个借口，让你能同时拥抱一门新语言、一个新框架和一套新基础设施。AI 可能会给你一种“我能搞定一切”的错觉，但你无法真正验证其中任何一环。

小结：理解，是前所未有的宝贵资产

“选择无聊的技术”这个论点的初衷，是为了降低系统的运维复杂性和团队的认知开销。在 AI 时代，这些理由依然成立，但我们又增加了一个更重大的风险：对抗由 AI 带来的、致命的虚假自信。

如今的风险更高了，因为 AI 生成的代码质量越来越好，使得发现问题变得更加困难。过去，坏代码通常看起来就很糟糕。现在，有问题的代码可能看起来相当不错，直到你对该领域足够了解，才能注意到那些微妙的致命伤。

所以，我的建议始终不变：当你要解决一个问题时，请使用你已经了解的技术。当你想要学习新东西时，那就专心去学习。不要将 AI 生成的代码，误认为是真正的理解。

在一个 AI 可以自信地为你从未用过的技术生成数千行代码的世界里，你自己的、深刻的理解，比以往任何时候都更有价值。

资料链接：

• https://mcfunley.com/choose-boring-technology
• https://www.brethorsting.com/blog/2025/07/choose-boring-technology,-revisited

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2025/07/27/native-prometheus-instrumentation-over-opentelemetry

大家好，我是Tony Bai。

在云原生可观测性的世界里，OpenTelemetry (OTel) 正如日中天。它被誉为“可观测性的未来”，承诺用一个统一的标准，终结 Metrics、Traces、Logs 各自为战的混乱局面。无数的开发者和公司，都在热情地拥抱这个“一次插桩，到处发送”的美好愿景。

但就在这股几乎不可阻挡的浪潮中，一个权威的声音却发出了一个略显刺耳的警告。

这个人，就是 Prometheus 的联合创始人，Julius Volz。

在他最新的博文中，Julius 毫不客气地指出：如果你正在使用 Prometheus 作为你的核心监控系统，并且你真正关心监控的质量和体验，那么，在使用 OpenTelemetry SDK 生成 Metrics 前，请务必三思！

他认为，拥抱 OTel 这个“通用标准”的代价，可能是丢掉 Prometheus 作为一个完整监控系统的“灵魂”，并背上丑陋、低效和复杂的“技术债”。

你正在丢掉 Prometheus 的灵魂

Julius 首先尖锐地指出了一个哲学问题：Prometheus 不仅仅是一个“指标数据库”，它是一个端到端的、有自己思想的监控系统。而 OTel 的“后端无关”设计，恰恰破坏了这种端到端的自洽性。当你选择用 OTel 向 Prometheus 推送数据时，你正在放弃这些至关重要的原生特性：

失去灵魂：Target 健康监控 (up 指标)

Prometheus 最核心的设计之一就是 Pull 模型 + 服务发现。这意味着 Prometheus 主动拉取指标，它清楚地知道“哪些目标应该存在”以及“它们现在是否健康”。如果一个目标拉取失败，Prometheus 会自动生成一个 up{job=”demo”} = 0 的指标。你可以用一条简单的 PromQL 告警规则 up == 0 来发现任何失联的服务。

然而，当你使用 OTel 的 Push 模型时，Prometheus 变成了一个被动的“无情的数据接收器”。它无法再区分一个服务是“正常下线”还是“已经崩溃但没来得及上报”。你可能拥有数百个已经死掉的服务进程，却在监控图表上一无所知。

失去优雅：丑陋的 PromQL 查询

为了兼容 PromQL，OTel 的指标在进入 Prometheus 时，往往需要经过“魔改”。
* 命名冲突： OTel 允许在指标名中使用“.”，而 Prometheus 的传统是不允许的。所以，一个 OTel 指标 k8s.pod.cpu.time 在进入 Prometheus 后，会被翻译成 k8s_pod_cpu_time_seconds_total。这种不一致性会给开发者带来困惑。
* 繁琐的查询语法： 为了支持 OTel 更宽泛的字符集，如果你想查询原始的 OTel 指标名，你的 PromQL 查询会从优雅的 my_metric{…} 变成丑陋的 {“my.metric”, …}。

失去便利：复杂的标签 Join

Prometheus 的 target labels（如 instance, job）会被自动附加到从该目标拉取的所有指标上。而 OTel 的 resource attributes（包含更多非关键元数据）则不会。为了避免高基数问题，大部分 OTel 的资源属性被打包进了一个单独的 target_info 指标里。

这意味着，如果你想在查询时使用这些属性，你必须写出类似下面这样繁琐的 group_left join 查询：

// 想加一个 k8s_cluster_name 标签，查询变得如此复杂
rate(http_server_request_duration_seconds_count[5m])
* on(job, instance) group_left(k8s_cluster_name)
target_info

这些问题，都在不断地增加你的认知负荷和工作复杂度。

性能鸿沟：Go SDK 的“血案”现场

如果说失去优雅和可靠性还不足以让你警醒，那么接下来的硬核性能数据，可能会让你大吃一惊。Julius 特别对比了 Prometheus Go SDK 和 OpenTelemetry Go SDK 在执行最常见操作——计数器递增——时的性能。

结论是毁灭性的。

Julius 的基准测试显示，在不同的并行度和标签缓存条件下：
* 在最坏情况下，Prometheus Go SDK 比 OTel Go SDK 快 26 倍。
* 在有标签缓存的最佳情况下，Prometheus Go SDK 甚至可以比 OTel Go SDK 快 53 倍！
* 更致命的是，Prometheus Go SDK 在所有情况下都实现了零新内存分配，而 OTel SDK 在设置标签时则会持续产生内存分配。

为什么会有如此惊人的差距？
* 复杂性 vs. 专注性： OTel SDK 是一个试图统一三驾马车（Metrics, Traces, Logs）的庞大系统，内部抽象层次多，路径长。而 Prometheus SDK 的目标极其单一和专注：用最高效的方式生成 Prometheus 指标。
* 主观代码体验： Julius 更是用一个生动的例子佐证了这一点——他想在两个 SDK 中找到核心的 Inc() 函数实现。在 Prometheus Go SDK 中，他花了 5 秒；而在 OTel Go SDK 中，他在复杂的抽象和间接调用中迷失了 15 分钟后，最终放弃了。

对于性能至关重要的 Go 后端服务来说，选择 OTel SDK 进行指标插桩，无异于在你的性能快车道上，悄悄地铺上了一层厚厚的沥青。

结论：在“通用标准”与“原生体验”之间做出选择

Julius 的文章并非是否定 OpenTelemetry 的价值。OTel 作为一个中立的、后端无关的“可观测性瑞士”，在构建异构系统、避免厂商锁定的场景中，依然具有不可替代的战略意义。

但他的警告是在提醒我们一个深刻的权衡：
* OpenTelemetry 的世界观： 追求最大的通用性和互操作性。它是一个数据生成和传输的标准，它不关心数据最终如何被使用。
* Prometheus 的世界观： 追求一个深度整合、端到端优化的系统体验。它的每一个设计——从 Pull 模型到 PromQL 语法——都在为最终用户能以最优雅、最高效的方式进行监控和告警服务。

如果你已经选择 Prometheus 作为你的核心监控“城邦”，那么使用它原生的客户端库，并非是选择“封闭”，而是选择一个经过千锤百炼的、高度自洽的、性能卓越的解决方案。

所以，在你为下一个 Go 项目 go get OTel SDK 之前，请先问自己一个问题：我是在追求一个“放之四海而皆准”的通用标准，还是在追求一个能将我的核心工具发挥到极致的原生体验？

答案，可能决定了你未来无数个夜晚的睡眠质量。

资料链接：https://promlabs.com/blog/2025/07/17/why-i-recommend-native-prometheus-instrumentation-over-opentelemetry/

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

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

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

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

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

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