再见了，微服务：从 100 多个“问题儿童”到 1 个“超级巨星”的架构回归

本文永久链接 – https://tonybai.com/2025/12/19/twilio-say-goodbye-microservices

大家好，我是Tony Bai。

“微服务”——这个在过去十年间统治了软件架构领域的“最佳实践”，承诺给我们带来更高的模块化、更快的迭代速度和更强的团队自治。然而，当一个团队，深陷于 140 多个服务、140 多个代码仓库、140 多个独立队列的泥潭中，开发速度骤降、缺陷率爆炸、on-call 工程师夜不能寐时，这个“最佳实践”是否已然变成了一个“最大负担”？

这不是一个假设，而是 Twilio Segment 团队曾亲身经历的“噩梦”。

这篇文章，正是对他们那场史诗般的架构“大迁徙”的复盘：一次勇敢的、从微服务“树”的每个痛苦枝桠上坠落，最终回归单体架构“坚实地面”的旅程。这也是一个关于技术选型、规模化陷阱和工程务实主义的真实故事。

img{512x368}

微服务的“蜜月期”——它曾解决了真实的问题

故事的开端，微服务确实是“英雄”。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 工程师终于可以睡个好觉了。