2025-12-21 18:57:06
本文永久链接 – https://tonybai.com/2025/12/21/real-programmers-dont-fix-computers-ai-stars-and-seas
大家好，我是Tony Bai。
最近陪家人看几部青春都市剧，实在忍不住想吐槽。
无论题材如何变，编剧笔下的程序员永远是那副德行：戴着黑框眼镜，背着双肩包，唯唯诺诺。而他们的戏份，似乎永远逃不开那一幕——
男主角或者女神的电脑坏了，喊一声：“喂，那个谁，来修一下。”
然后镜头一转，程序员满头大汗地重启电脑，憨厚一笑。
别演了，真的。
都2025年了，大众对程序员的误解依然停留在“修电脑”和“当备胎”的阶段。
今天，我想撕掉这些标签，聊聊真实的程序员到底在做什么，以及为什么我们这群看似“无趣”的人，实则是未来 30 年人类文明的推手。
在中国人的传统潜意识里，什么是“有才华”？什么是“有智慧”？
是引经据典，是出口成章，是懂《周易》懂历史，是酒桌上推杯换盏间的人情练达。我们推崇的是“国学”与“人学”。
而程序员呢？
我们脑子里装的是 GMP 调度模型，是 Transformer 架构，是 Raft 共识算法。
这些知识的认知门槛极高，掌握难度远超背诵几首唐诗。但在大众眼里，这叫“技能”，不叫“学问”；这叫“工具”，不叫“智慧”。
这就造成了一个巨大的荒诞：
一个能徒手写出操作系统内核的顶级工程师，可能因为在饭局上接不上关于“职场厚黑学”的梗，或者不懂得先敬领导一杯酒，就被贴上“木讷”、“情商低”、“读书读傻了”的标签。
我们不是学不会那些，我们只是不Care。
程序员的思维通过了严苛的逻辑训练，我们习惯了用 O(1) 的复杂度直达本质。对于那些充满了冗余、虚伪和 O(n^2) 复杂度的繁文缛节，我们的大脑会自动执行 Garbage Collection（垃圾回收）。
这种对他人的“降噪”处理，让我们在影视剧里看起来像个“怪胎”，但在代码的世界里，这正是我们构建万物的基石。
如果我们把目光从影视剧移开，看一眼身边真实的 95 后、00 后程序员，你会发现那个“木讷”的标签早已过期。
程序员这个物种，正在经历一次剧烈的“版本迭代”。
去看看现在的互联网大厂，那个传说中的“格子衫军团”正在消失。取而代之的，是滑板少年、是汉服爱好者、是玩死亡重金属的贝斯手。
斜杠青年（Slash）：
你以为他只是个写 Go 语言的后端？下班后，他可能是 B 站拥有十万粉丝的科普 Up 主，可能是独立游戏的制作人，也可能是用 AI 生成艺术画作的数字艺术家。
拒绝被定义：
如果说上一代程序员的特征是“忍耐”和“沉默”，那么新一代程序员的特征就是“表达”和“重塑”。他们不屑于酒桌文化，因为他们更崇尚“技术平权”和“透明沟通”。
这不再是一群只会修电脑的“工具人”，而是一群试图用技术手段去重构生活方式的“新人类”。
他们在 Github 上构建世界，也在小红书和 Tiktok 上分享生活。他们不是不懂生活，他们是在用代码重新定义什么是“酷”的生活。
影视剧还在忙着刻画我们“修电脑”的窘态，却完全没意识到，这群“配角”，此刻正在现实世界中酝酿着怎样的惊涛骇浪。
我们正站在人类历史最疯狂的转折点上。
当你嘲笑程序员不懂“风花雪月”时，他们正在做上帝的工作：
左手，赋予机器“灵魂”与“肉体”：
那些让你惊叹的 ChatGPT、Claude、DeepSeek，背后是程序员用代码搭建的神经网络。宇树G1/H1，特斯拉的 Optimus等人形机器人，正在走进现实。是程序员将逻辑注入钢铁躯体，让机器人学会行走、抓取，甚至学会思考。具身智能的爆发，将彻底重塑物理世界。
右手，征服星辰大海：
SpaceX 的“筷子”夹住星舰的那一刻，全球沸腾。那毫秒级的姿态调整，不是靠吟诗作对实现的，而是靠几十万行严密的控制算法。
谁才是这个时代的“男一号”？
是那些在剧里谈情说爱的主角吗？不。
是那些在屏幕后，用 Go 语言重构微服务，用 Python 训练大模型，用 C++ 控制火箭姿态的所谓“码农”。
流行文化在消费我们，而我们在重塑流行文化赖以生存的世界。
国学典籍是面向过去的接口，它教我们如何维系一个稳定的人情社会；
编程语言是面向未来的接口，它教我们如何与硅基生命对话，如何在此刻定义未来 30 年的规则。
也许在未来的很长一段时间里，影视剧里的程序员依然会是那个戴着眼镜、不懂风情的“路人甲”。
没关系。让我们接受这种“误读”。
因为这种“忽视”，恰恰是一种保护色。它让我们这群人能远离嘈杂的名利场和复杂的人际关系，心无旁骛地坐在屏幕前。
我们不需要修电脑，我们在修补这个世界的 Bug；
我们不需要当偶像剧的主角，我们在编写人类文明的下一个版本。
致敬每一位“不善言辞”，但正在改变世界的程序员。
作为程序员，你曾在哪一刻因为“不懂人情世故”或“不关注大众话题”而被误解过？而在那一刻，你脑子里其实正在思考什么硬核的技术问题？
欢迎在评论区，分享你的“社死”与“高光”时刻。
未来30年，是属于工程师的黄金时代。
别让你的技能停留在“修电脑”的阶段。想要掌握 Go 语言在云原生、AI 工程化 中的核心能力，紧跟 具身智能 的浪潮？
加入我的 「Go & AI 精进营」。在这里，我们不聊厚黑学，只聊如何拿到通往未来的船票。
[此处放置知识星球二维码]
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
2025-12-21 10:02:59
本文永久链接 – https://tonybai.com/2025/12/21/go-1-26-cryptographic-storm-vault-compliance-vs-go-security
大家好，我是Tony Bai。
近日，一个看似不起眼的 Go 语言issue，在社区引发了一场“地震级”的辩论。这场辩论的主角，一方是 Go 安全团队的灵魂人物 Filippo Valsorda，另一方则是开源安全巨头 Hashicorp Vault 的核心开发者。
辩论的焦点是：Go 1.26 计划“废除” crypto 包中一系列密钥生成函数（如 rsa.GenerateKey）的 rand io.Reader 参数，使其在默认情况下强制使用 crypto/rand.Reader 作为唯一的熵源。
这一变更，对于绝大多数 Gopher 来说，似乎无关痛痒甚至更安全。但对于 Hashicorp Vault 这样需要满足硬件安全模块 (HSM) 和 FIPS 合规性等严苛要求的项目而言，这无异于一场“釜底抽薪”。
这场“加密风暴”，深刻地揭示了 Go 语言在追求普适安全性与满足特定企业级需求之间的永恒张力。
Hashicorp Vault 的开发者 sgmiller 首先发难。他指出，Vault 的许多客户，出于合规性或审计要求，强制要求所有密钥的生成，必须直接源自经过认证的硬件随机数生成器（通过 PKCS#11 HSM 设备）。
Vault 的实现方式，正是通过 crypto 包中那些 GenerateKey 函数的 rand io.Reader 参数，将来自 HSM 的“硬件熵”直接注入到密钥生成过程中。
Go 1.26 的变更——即保留该参数，但在默认情况下忽略它——将使这一核心功能完全失效。sgmiller 认为，这是一种破坏 API 语义的重大变更，唯一的出路似乎只剩下：
1. Fork 标准库：自行维护一套密钥生成代码，但这将带来巨大的维护成本和安全风险。
2. 依赖一个临时的 GODEBUG 环境变量：但这并非长久之计。
Go 安全团队的 Filippo Valsorda 随后给出了堪称“教科书级别”的回应。他的论点层层递进，不仅解释了“为什么这么做”，更深刻地阐述了 Go 团队的安全哲学。
Filippo 首先从纯粹的安全角度，直接否定了 Vault 需求的合理性。
“说实话，我看不出这个功能有什么安全意义。如果你担心操作系统的熵池，那就一次性从你的 HSM 读取 256 比特的随机数，然后写入 /dev/urandom。Go（以及其他所有程序）都会在系统熵池的基础上，使用你注入的这份熵。这比你自己实现一个用户空间的 DRBG 要安全得多。”
“我保守估计，你的 PKCS#11 驱动程序、DRBG 或 HSM 本身出 Bug 的概率，是 Linux 内核随机数子系统出 Bug 概率的 100 倍。”
这段话的潜台词是：你以为你在增强安全性，但实际上，你引入的复杂性和潜在的 Bug 源，远比你试图解决的问题更危险。
接着，Filippo 展现了惊人的同理心和务实精神。他承认，现实世界中充满了各种“荒谬的”合规要求。
“然而，有时客户就是有一些他们愿意花钱满足的、毫无意义的需求，我懂的！（我TMD就在做 FIPS 140-3 的业务，我怎么会不懂呢？）”
“但是，这些荒谬的需求，不能通过增加上游库的复杂性来满足，因为上游库的目标是真正的安全，而不是帮你勾选审计清单。如果需要，客户的钱应该用来支付变通方案 (workarounds) 的成本。”
在这里，Filippo 明确地划清了界限：Go 标准库的职责，是为 99.999% 的用户提供默认安全、简单清晰的 API。 为了满足极少数用户的、非安全驱动的“合规复选框”，而让标准库的实现和维护变得更加复杂，是一种本末倒置。
最后，Filippo 指出，所谓的“破坏”其实被夸大了。
这场辩论并未就此结束。Hashicorp 的另一位开发者 jefferai 指出，rand 参数的另一个重要用途是确定性密钥生成 (deterministic key generation)，例如，通过对一组输入进行哈希，得到一个可预测的密钥。这在某些测试和特定协议中非常有用。
Filippo 再次明确了 Go 的设计哲学：
“这正是我们想要避免的。GenerateKey 这个函数，其唯一的语义就是生成随机密钥。如果你想要确定性密钥生成，你需要的是一个明确的规范和实现，而不是通过‘滥用’一个用于注入随机性的参数。”
这揭示了 Go 团队进行此次变更的另一个深层原因：简化 API 语义，消除模糊地带。他们希望 GenerateKey 只做一件事，并把它做好。
这场发生在顶尖工程师之间的“神仙打架”，为我们所有 Gopher 带来了几点极其宝贵的启示：
理解 Go 的安全哲学：默认安全
Go 团队正越来越多地采取一种“家长式”的安全策略：默认提供最安全、最简单的选项，并逐步移除那些可能被误用的“高级”选项。 这要求我们信任标准库，而不是试图用自己的“小聪明”去绕过它。
API 设计：清晰的语义胜过一切
一个 API 的每个参数都应该有其明确、单一的用途。Filippo 的论点提醒我们，不要设计那些可以被“巧妙地滥用”的 API。如果一个功能是必要的，就为它设计一个专门的、语义清晰的 API。
拥抱 GODEBUG：一个“软弃用”的缓冲带
Go 团队通过 GODEBUG 环境变量，为这类破坏性变更提供了长达数年（通常是 2 年）的过渡期。我们应该学会利用 //go:debug 指令和 godebug go.mod 设置，来有意识地管理这些变更，而不是等到最后期限才手忙脚乱。
这场“加密风暴”，最终以 Go 团队坚持其设计哲学而告终。它或许会让 Hashicorp 这样的重量级用户付出一些额外的开发成本，但从长远来看，一个更简单、更安全、语义更清晰的 crypto 标准库，将使整个 Go 生态受益。
这正是 Go 语言持续成功的秘诀：在无尽的特性需求和复杂的现实世界面前，勇敢地、有时甚至是“固执”地，对复杂性说“不”。
资料链接：https://github.com/golang/go/issues/76856
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
2025-12-20 11:31:28
本文永久链接 – https://tonybai.com/2025/12/20/ai-coding-era-productivity-leap-2025-developer-ecosystem-report
大家好，我是Tony Bai。
“如果你觉得今年的 PR (Pull Request) 变大了，你的感觉是对的。如果你觉得代码写得更快了，这也是对的。事实上，整个软件开发的节奏，正在被 AI 全面重塑。”
近日，Greptile 发布了《2025 年 AI 编码现状报告》(The State of AI Coding 2025)。这份基于大量真实开发数据的报告，为我们描绘了一个令人兴奋，同时也充满挑战的新世界。AI 不再是一个锦上添花的辅助工具，它正在成为驱动工程效能指数级增长的核心引擎。
本文将带你深入解读这份报告的核心发现，看看在 AI 的加持下，软件工程正在发生怎样的巨变。
报告中最直观、也最令人震撼的，是关于工程效能 (Velocity) 的数据。AI 工具的普及，正在让开发者以一种前所未有的速度产出代码。
数据显示，开发者的平均代码产出量，从 年初的 4,450 行/人，飙升到了年底的 7,839 行/人。
这是一次 76% 的惊人增长。AI 就像是一个不知疲倦的“外挂”，让每一位开发者都变成了“高产作家”。
这种生产力的提升，直接反映在代码提交的形态上：
这意味着，开发者不再是小心翼翼地修补代码，而是更有底气进行大刀阔斧的重构和功能开发。AI 赋予了我们处理更大上下文、更复杂逻辑的能力。
有趣的是，6-15 人的中型团队成为了这场变革的最大赢家，其人均产出增长了 89%。这或许暗示了，在这个规模下，沟通成本尚在可控范围，而 AI 带来的单兵作战能力提升被最大化地释放了出来。
在 AI 工具的生态位之争中，我们也看到了一些明显的赢家和趋势。
随着 AI 应用变得越来越复杂，如何让 AI “记住”上下文成为了关键。报告显示，mem0 以 59% 的市场份额，在 AI 记忆基础设施领域占据了绝对的统治地位。这表明，开发者正在从简单的“问答式”交互，转向构建具有长期记忆和个性化能力的智能体。
与记忆领域的“一家独大”不同，向量数据库市场呈现出群雄逐鹿的态势。Weaviate 虽然以 25% 暂时领先，但还有 6 个竞争对手（如 Pinecone, ChromaDB, pgvector 等）的市场份额都在 10%-25% 之间。这场关于 AI “长期存储”的战争，远未结束。
在 LLM 提供商的 SDK 下载量上，OpenAI 依然以 1.3 亿次下载量遥遥领先。但 Anthropic (Claude 的母公司) 的增长速度令人咋舌——自 2023 年 4 月以来增长了 1547 倍！两者之间的差距正在迅速缩小，这反映了 Claude 系列模型（尤其是 Sonnet ）在编码能力上的卓越表现，正在赢得越来越多开发者的青睐。
对于开发者来说，选择哪个模型作为“副驾驶”至关重要。报告对几大主流模型进行了详尽的基准测试。
在吞吐量 (Throughput) 方面，OpenAI 的 GPT-5 Codex 和 GPT-5.1 依然是无可争议的王者，能够维持每秒 50-60 个 token 的生成速度。这意味着在需要快速生成大量代码或进行即时交互的场景下，OpenAI 依然是首选。
然而，在 首字延迟 (TTFT) 上，Anthropic 的 Claude Sonnet 4.5 和 Opus 4.5 实现了反超。它们能在 2.5 秒内返回第一个 token，比 OpenAI 的模型快了一倍以上。这种“秒回”的体验，对于维持开发者的心流状态至关重要。
在价格上，GPT-5 Codex 和 GPT-5.1 设定了基准线 (1.00x)。相比之下，Claude Sonnet 4.5 的价格是其 2 倍，而 Opus 4.5 更是达到了 3.3 倍。
这就需要开发者在“极致的智能/响应速度”与“成本”之间做出权衡。对于复杂的逻辑推理任务，Claude 的高溢价或许是值得的；而对于日常的代码补全，OpenAI 的模型可能更具性价比。
报告的最后，还梳理了近期学术界和工业界的几项关键突破，指明了未来的方向：
2025 年的 AI 编码报告，向我们展示了一个正在加速奔跑的世界。代码的生产成本正在极速趋近于零，但这并不意味着程序员将要失业。相反，这标志着“超级个体”时代的到来。
在这个时代，一个工程师所能撬动的杠杆，比以往任何时候都要大。我们不再仅仅是代码的“搬运工”，而是 AI 智能体的“指挥官”。
面对这 76% 的产出增长，我们不仅要问“怎么写得更快”，更要问自己：“我们该用这些多出来的生产力，去构建什么更伟大的东西？”
资料链接：https://www.greptile.com/state-of-ai-coding-2025
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
2025-12-20 07:29:30
本文永久链接 – https://tonybai.com/2025/12/20/goroutine-bubble-universe-go-concurrency-new-dimension
大家好，我是Tony Bai。
goroutine 是 Go 并发模型的基石，我们习惯于将其视为一个个轻量、独立的执行单元。然而，近年来，Go 语言中出现了一种新的、微妙的并发概念，Go 核心团队的成员们亲切地称之为 “Goroutine 气泡” (Goroutine Bubbles)。
这种“气泡”，本质上是一种临时的、附加在 goroutine 上的特殊状态。它像一个无形的罩子，让处于其中的 goroutine 及其执行的代码，表现出与平时不同的行为。
近日，一个旨在统一所有“气泡”行为的提案（#76477）被 Go 官方接受。这个看似微小的内部“合理化”工作，却深刻地揭示了 Go 语言在可观测性、安全性与并发抽象方面的未来演进方向。本文将带你深入这个正在形成的“气泡宇宙”。
截至 Go 1.25 及即将到来的 Go 1.26，Go 的“气泡宇宙”中已经有了好几位成员，它们各自服务于不同的目的：
pprof 标签 (pprof.SetGoroutineLabels):
这是最早期的气泡雏形。它允许你为 goroutine 附加键值对标签，从而在 CPU 或内存性能剖析（Profiling）中，根据请求 ID 或用户 ID 对 goroutine 进行分类筛选。
testing/synctest:
一个用于并发测试的“时间与调度”气泡。在此气泡内创建的所有 goroutine，都会被一个虚拟的时钟和调度器所控制，这让测试复杂的并发逻辑（如超时、定时任务）变得像测试同步代码一样简单且确定。
crypto/subtle.WithDataIndependentTiming (Go 1.25 新增):
一个“数据无关时序”气泡。它强制其中的代码以常量时间执行，无论输入数据如何变化，执行时间都保持一致，从而抵御时序侧信道攻击（Timing Attacks）。
secret.Do (Go 1.26 计划新增)
一个“机密数据”气泡。其中的代码在执行时会受到运行时的特殊照顾（例如防止变量逃逸到堆上、更积极的内存清零），以确保敏感数据（如私钥、密码）不会在内存中意外泄露。
fips140.WithoutEnforcement (Go 1.26 计划新增): 一个 FIPS 合规性的“逃生舱”气泡
在 Go 1.24 引入的 FIPS 140-3 严格模式（GODEBUG=fips140=only）下，任何非 FIPS 认证的加密算法都会导致程序崩溃。但在现实中，我们有时需要合法地使用非标准算法（例如，使用 SHA-1 计算 Git 的 commit ID，这并非用于安全签名；或者使用 X25519 配合后量子算法进行混合加密）。
WithoutEnforcement 就是为了解决这个问题而生：它划定了一个“免责区域”，允许在该区域内暂时关闭严格的合规性检查，让代码可以灵活地处理这些特殊场景。
这个新提案的核心矛盾在于：当一个处于“气泡”中的 goroutine (父 goroutine)，启动了一个新的 goroutine (子 goroutine) 时，子 goroutine 是否应该自动“继承”父 goroutine 的“气泡”状态？
在 Go 1.25 中，这个行为是不一致的：
* pprof 标签和 synctest 气泡，会被继承。
* 而 secret.Do 和 WithDataIndependentTiming 这两个与安全密切相关的气泡，则不会被继承。
提案的发起人、Go 团队负责人 Austin Clements 认为，这种不一致性是“临时性的、特别处理的”，需要被“合理化”。
提案的核心：让 secret.Do 和 WithDataIndependentTiming 的气泡也变成可继承的，从而建立一个统一的规则：“所有气泡默认都会被新创建的 goroutine 所继承。”
这个看似简单的“统一”决定，却在 Go 核心团队内部引发了一场关于设计哲学的深刻辩论。
Austin Clements 提出的主要论据是解耦。
“一个 API 内部是否使用 goroutine，必须是一个实现细节，而不应成为其 API 表面的一部分。”
Go 安全团队的 DanielMorsing 等人则提出了强烈的反对意见，尤其针对 secret.Do。
“继承可能会将 secret.Do 的状态‘泄漏’到其他 goroutine 中……一个典型的例子是 net/http.Client，一个 goroutine 可能会因为 keep-alive 连接而存活很久。”
为了避免这种情况，反对者甚至提出了一个更激进的方案：在 secret.Do 或 WithDataIndependentTiming 气泡内启动 goroutine，应该直接 panic！ 因为这“几乎可以肯定是一个错误”。
经过激烈的讨论，Go 团队最终达成了一个务实的共识，并接受了提案：
1. 统一规则：所有“气泡”都将被继承。
团队的最终权衡是，保持 API 解耦的重要性，高于防止开发者“误用”的可能性。Filippo Valsorda 的观点极具代表性：
“我们不能让语言的限制，悄无声息地跨越模块的边界……‘你误用了 secret.Do，所以你的程序没那么安全或变慢了’，这是可以接受的。但‘你误用了 secret.Do，所以现在你的依赖库必须束手束脚’，这是不可接受的。”
2. 增加可观测性作为“解毒剂”
为了缓解“性能时间炸弹”的担忧，团队也采纳了 mknyszek 的建议：必须为这些继承的状态，增加相应的可观测性。
* 未来的 goroutine 堆栈转储 (goroutine dumps) 中，应该能清晰地标记出一个 goroutine 当前是否处于 secret 或 DIT (数据无关时序) 状态。
* runtime/metrics 中也应该考虑增加相应的指标，来统计处于这些特殊状态的 goroutine 数量。
3. 对 panic 方案的否定
激进的 panic 方案被否决了。因为它同样违反了“实现细节隐藏”的原则。你无法预知你调用的某个第三方库，在未来的某个版本中，是否会为了优化而引入并发。
“Goroutine 气泡”的出现及其继承规则的统一，标志着 Go 的并发模型，正在从一个纯粹的“执行单元”模型，向一个附加了“上下文状态”的、更丰富的模型演进。
这个变化，对于大多数日常开发者来说，可能在短期内是无感的。但它深刻地体现了 Go 团队在设计语言时所秉持的、高度一致的哲学：
密切关注这些“气泡”的发展，将是我们理解 Go 语言未来走向的一个重要窗口。
资料链接：https://github.com/golang/go/issues/76477
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
2025-12-19 12:13:21
本文永久链接 – https://tonybai.com/2025/12/19/twilio-say-goodbye-microservices
大家好，我是Tony Bai。
“微服务”——这个在过去十年间统治了软件架构领域的“最佳实践”，承诺给我们带来更高的模块化、更快的迭代速度和更强的团队自治。然而，当一个团队，深陷于 140 多个服务、140 多个代码仓库、140 多个独立队列的泥潭中，开发速度骤降、缺陷率爆炸、on-call 工程师夜不能寐时，这个“最佳实践”是否已然变成了一个“最大负担”？
这不是一个假设，而是 Twilio Segment 团队曾亲身经历的“噩梦”。
这篇文章，正是对他们那场史诗般的架构“大迁徙”的复盘：一次勇敢的、从微服务“树”的每个痛苦枝桠上坠落，最终回归单体架构“坚实地面”的旅程。这也是一个关于技术选型、规模化陷阱和工程务实主义的真实故事。
故事的开端，微服务确实是“英雄”。Twilio Segment 的核心业务是每秒接收数十万个事件，并将它们分发到上百个不同的下游目标（如 Google Analytics, Mixpanel 等）。
最初的单队列架构，很快就遇到了“队头阻塞” (Head-of-Line Blocking) 的问题：只要一个下游目标（例如 Mixpanel）出现故障或变慢，它的重试事件就会堵塞整个队列，导致所有其他正常目标的事件分发都被延迟。
为了解决这个问题，团队自然而然地拥抱了微服务：为每个下游目标创建一个独立的服务、一个独立的队列和一个独立的 repo。
这个方案在当时是完美的：
在最初的阶段，微服务架构确实为团队带来了更高的稳定性和开发速度。
然而，随着下游目标的数量从几十个增长到超过 140 个，当初的“收益”逐渐变成了无法承受的“税收”。
为了避免在 140 多个 repo 中重复造轮子，团队创建了共享库来处理通用逻辑（如事件转换、HTTP 请求处理）。但这很快就演变成了一场灾难：
* 更新成本巨大：修改一个共享库，理论上意味着需要测试并重新部署 140 多个服务。这是一个极其耗时且风险巨大的操作。
* 版本分歧：为了图方便，工程师们往往只在当前需要改动的服务中更新共享库版本。久而久之，不同服务依赖的共享库版本开始严重分歧，曾经的“统一性”优势荡然无存。
每增加一个新的下游目标，就意味着：
* 一个新的服务
* 一个新的代码仓库
* 一个新的消息队列
* 一套新的 CPU/内存资源配置
* 一套新的告警和监控
“我们的运维开销，随着每个目标的增加而线性增长。on-call 工程师因为某个小流量目标的负载尖峰而被半夜叫醒，已是家常便饭。”
独立的 repo 曾被认为是优点，但它也导致了测试条件的恶化。由于修复另一个 repo 中不相关的失败测试很麻烦，团队逐渐对失败的测试变得麻木。这导致了技术债的快速累积。
“一个本应一两个小时就能完成的小改动，最终往往需要花费数天甚至一周的时间来完成。”
团队发现，他们已经无法取得任何进展，3 个全职工程师的大部分时间，都花在了“维持系统不死”上。微服务，这个曾经的“解放者”，如今已变成了一个由 100 多个“问题儿童”组成的、难以管理的“泥潭”。
在痛苦的临界点，团队做出了一个在当时看来“离经叛道”的决定：放弃微服务，回归单体。
首先，他们构建了一个名为 Centrifuge 的新组件，来取代 140 多个独立的队列。Centrifuge 作为一个统一的事件中心，负责接收所有事件，并将其智能地分发到一个单一的、统一的目标服务中。
既然只有一个服务，那么将 140 多个 repo 合并成一个 Monorepo 就成了顺理成章的选择。这个过程是痛苦的，团队需要解决 120 多个不同依赖的版本冲突，并致力于让所有目标都使用统一的、最新的依赖版本。
独立的、频繁失败的测试，是他们当初走向微服务的诱因。为了避免重蹈覆辙，团队构建了一个极其健壮的测试套件。他们创建了一个名为 Traffic Recorder 的工具，它能录制并回放所有测试中的出站 HTTP 请求。
这意味着，测试不再依赖于缓慢且不稳定的真实外部网络。
“在集成了 Traffic Recorder 之后，运行全部 140 多个目标的测试，从过去的一个小时，缩短到了几毫秒。这感觉就像魔法。”
回归单体和 Monorepo 之后，团队的生产力得到了戏剧性的提升：
当然，单体架构并非没有缺点。文章坦诚地指出了其固有的权衡：故障隔离更难（一个 Bug 可能导致整个服务崩溃），内存缓存效率更低。
但 Twilio Segment 的故事，为我们提供了一个关于软件架构的、极其宝贵的教训：
世界上没有普适的“最佳实践”，只有在特定上下文中最“恰如其分”的实践。
微服务在解决他们最初的“队头阻塞”问题时，是正确的。但随着业务的规模化和团队的演进，它又变成了错误的答案。
这个故事提醒我们，要对任何流行的架构趋势保持一份健康的怀疑。在拥抱微服务之前，请先问问自己：我面临的，真的是一个只有微服务才能解决的、组织规模化的问题吗？还是说，一个设计良好的单体（或者叫“宏服务”），才是当前阶段更简单、更高效、也更务实的选择？
有时候，最勇敢的架构决策，不是追随潮流，而是逆流而上。
资料链接：https://www.twilio.com/en-us/blog/developers/best-practices/goodbye-microservices
注：Twilio是一家云计算公司，专注于提供短信，语音以及Email的API通讯接口。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
