再见了，微服务：从 100 多个“问题儿童”到 1 个“超级巨星”的架构回归
本文永久链接 – 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。
这个方案在当时是完美的：
- 故障隔离：一个目标的故障，再也不会影响其他目标。
- 独立部署：团队可以独立地维护和部署每个目标的服务。
- 测试隔离：每个 repo 有自己独立的测试套件，互不干扰。
在最初的阶段，微服务架构确实为团队带来了更高的稳定性和开发速度。
规模化的“噩梦”——当“收益”变成“税收”
然而，随着下游目标的数量从几十个增长到超过 140 个，当初的“收益”逐渐变成了无法承受的“税收”。
共享库的“版本地狱”
为了避免在 140 多个 repo 中重复造轮子，团队创建了共享库来处理通用逻辑（如事件转换、HTTP 请求处理）。但这很快就演变成了一场灾难：
* 更新成本巨大：修改一个共享库，理论上意味着需要测试并重新部署 140 多个服务。这是一个极其耗时且风险巨大的操作。
* 版本分歧：为了图方便，工程师们往往只在当前需要改动的服务中更新共享库版本。久而久之，不同服务依赖的共享库版本开始严重分歧，曾经的“统一性”优势荡然无存。
运维的“线性增长”
每增加一个新的下游目标，就意味着：
* 一个新的服务
* 一个新的代码仓库
* 一个新的消息队列
* 一套新的 CPU/内存资源配置
* 一套新的告警和监控
“我们的运维开销，随着每个目标的增加而线性增长。on-call 工程师因为某个小流量目标的负载尖峰而被半夜叫醒，已是家常便饭。”
开发速度的“断崖式下跌”
独立的 repo 曾被认为是优点，但它也导致了测试条件的恶化。由于修复另一个 repo 中不相关的失败测试很麻烦，团队逐渐对失败的测试变得麻木。这导致了技术债的快速累积。
“一个本应一两个小时就能完成的小改动，最终往往需要花费数天甚至一周的时间来完成。”
团队发现，他们已经无法取得任何进展，3 个全职工程师的大部分时间，都花在了“维持系统不死”上。微服务，这个曾经的“解放者”，如今已变成了一个由 100 多个“问题儿童”组成的、难以管理的“泥潭”。
“大迁徙”——回归单体，拥抱 Monorepo
在痛苦的临界点，团队做出了一个在当时看来“离经叛道”的决定：放弃微服务，回归单体。
第一步：合并队列 -> Centrifuge
首先，他们构建了一个名为 Centrifuge 的新组件，来取代 140 多个独立的队列。Centrifuge 作为一个统一的事件中心，负责接收所有事件，并将其智能地分发到一个单一的、统一的目标服务中。
第二步：合并代码 -> Monorepo
既然只有一个服务，那么将 140 多个 repo 合并成一个 Monorepo 就成了顺理成章的选择。这个过程是痛苦的，团队需要解决 120 多个不同依赖的版本冲突，并致力于让所有目标都使用统一的、最新的依赖版本。
第三步：构建“坚如磐石”的测试套件
独立的、频繁失败的测试，是他们当初走向微服务的诱因。为了避免重蹈覆辙，团队构建了一个极其健壮的测试套件。他们创建了一个名为 Traffic Recorder 的工具，它能录制并回放所有测试中的出站 HTTP 请求。
这意味着，测试不再依赖于缓慢且不稳定的真实外部网络。
“在集成了 Traffic Recorder 之后，运行全部 140 多个目标的测试，从过去的一个小时，缩短到了几毫秒。这感觉就像魔法。”
单体的“超级巨星”时刻
回归单体和 Monorepo 之后，团队的生产力得到了戏剧性的提升：
- 部署效率：过去，对共享库的一次改动，可能需要部署 140 多个服务。现在，一个工程师在几分钟内就能完成整个服务的部署。
- 开发速度：在微服务架构下，团队一年内对共享库进行了 32 次改进。回归单体一年后，他们完成了 46 次改进。
- 运维简化：现在只有一个服务需要扩展和监控。一个巨大的统一 worker 池，可以轻松地吸收来自任何目标的负载尖峰，on-call 工程师终于可以睡个好觉了。
小结：没有“最佳实践”，只有“恰当实践”
当然，单体架构并非没有缺点。文章坦诚地指出了其固有的权衡：故障隔离更难（一个 Bug 可能导致整个服务崩溃），内存缓存效率更低。
但 Twilio Segment 的故事，为我们提供了一个关于软件架构的、极其宝贵的教训：
世界上没有普适的“最佳实践”，只有在特定上下文中最“恰如其分”的实践。
微服务在解决他们最初的“队头阻塞”问题时，是正确的。但随着业务的规模化和团队的演进，它又变成了错误的答案。
这个故事提醒我们，要对任何流行的架构趋势保持一份健康的怀疑。在拥抱微服务之前，请先问问自己：我面临的，真的是一个只有微服务才能解决的、组织规模化的问题吗？还是说，一个设计良好的单体（或者叫“宏服务”），才是当前阶段更简单、更高效、也更务实的选择？
有时候，最勇敢的架构决策，不是追随潮流，而是逆流而上。
资料链接：https://www.twilio.com/en-us/blog/developers/best-practices/goodbye-microservices
注：Twilio是一家云计算公司，专注于提供短信，语音以及Email的API通讯接口。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
- 告别低效，重塑开发范式
- 驾驭AI Agent(Claude Code)，实现工作流自动化
- 从“AI使用者”进化为规范驱动开发的“工作流指挥家”
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
- 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
- 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
- 想打造生产级的Go服务，却在工程化实践中屡屡受挫？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
评论