最近在做的事情正好需要系统地研究微服务与单体架构的取舍与演进。读到这篇文章，许多观点直击痛点、非常启发，于是我顺手把它翻译出来，分享给大家，也希望能给同样在复杂性与效率之间权衡的团队一些参考。
微服务正在悄然消亡：这是一件美好的事
为了把我们的创业产品扩展到数百万用户，我们搭建了 47 个微服务。
用户从未达到一百万，但我们达到了每月 23,000 美元的 AWS 账单、长达 14 小时的故障，以及一个再也无法高效交付新功能的团队。
那一刻我才意识到：我们并没有在构建产品，而是在搭建一座分布式的自恋纪念碑。
我们都信过的谎言
五年前，微服务几乎是教条。Netflix 用它，Uber 用它。每一场技术大会、每一篇 Medium 文章、每一位资深架构师都在高喊同一句话：单体不具备可扩展性，微服务才是答案。
于是我们照做了。我们把 Rails 单体拆成一个个服务：用户服务、认证服务、支付服务、通知服务、分析服务、邮件服务；然后是子服务，再然后是调用服务的服务，层层套叠。
到第六个月，我们已经在 12 个 GitHub 仓库里维护 47 个服务。我们的部署流水线像一张地铁图，架构图需要 4K 显示器才能看清。
当“最佳实践”变成“最差实践”
我们不断告诫自己：一切都在运转。我们有 Kubernetes，有服务网格，有用 Jaeger 的分布式追踪，有 ELK 的日志——我们很“现代”。
但那些光鲜的微服务文章从不提的一点是：分布式的隐性税。
每一个新功能都变成跨团队的协商。想给用户资料加一个字段？那意味着要改五个服务、提三个 PR、协调两周，并进行一次像劫案电影一样精心编排的数据库迁移。
我们的预发布环境成本甚至高于生产环境，因为想测试任何东西，都需要把一切都跑起来。47 个服务在 Docker Compose 里同时启动，内存被疯狂吞噬。
那个彻夜崩溃的夜晚
凌晨 2:47，Slack 被消息炸翻。
生产环境宕了。不是某一个服务——是所有服务。支付服务连不上用户服务，通知服务不断超时，API 网关对每个请求都返回 503。
我打开分布式追踪面板：一万五千个 span，全线飘红。瀑布图像抽象艺术。我花了 40 分钟才定位出故障起点。
结果呢？一位初级开发在认证服务上发布了一个配置变更，只是一个环境变量。它让令牌校验多了 2 秒延迟，这个延迟在 11 个下游服务间层层传递，超时叠加、断路器触发、重试逻辑制造请求风暴，整个系统在自身重量下轰然倒塌。
我们搭了一座纸牌屋，却称之为“容错架构”。
我们花了六个小时才修复。并不是因为 bug 复杂——它只是一个配置的单行改动，而是因为排查分布式系统就像破获一桩谋杀案：每个目击者说着不同的语言，而且有一半在撒谎。
那个被忽略的低语
一周后，在复盘会上，我们的 CTO 说了句让所有人不自在的话：
“要不我们……回去？”
回到单体。回到一个仓库。回到简单。
会议室一片沉默。你能感到认知失调。我们是工程师，我们很“高级”。单体是给传统公司和训练营毕业生用的，不是给一家正打造未来的 A 轮初创公司用的。
但随后有人把指标展开：平均恢复时间 4.2 小时；部署频率每周 2.3 次（从单体时代的每周 12 次一路下滑）；云成本增长速度比营收快 40%。
数字不会说谎。是架构在拖垮我们。
美丽的回归
我们用了三个月做整合。47 个服务归并成一个模块划分清晰的 Rails 应用；Kubernetes 变成负载均衡后面的三台 EC2；12 个仓库的工作流收敛成一个边界明确的仓库。
结果简直让人尴尬。
部署时间从 25 分钟降到 90 秒；AWS 账单从 23,000 美元降到 3,800 美元；P95 延迟提升了 60%，因为我们消除了 80% 的网络调用。更重要的是——我们又开始按时交付功能了。
开发者不再说“我需要和三个团队协调”，而是开始说“午饭前给你”。
我们的“分布式系统”变回了结构良好的应用。边界上下文变成 Rails 引擎，服务调用变成方法调用，Kafka 变成后台任务，“编排层”……就是 Rails 控制器。
它更快，它更省，它更好。
我们真正学到的是什么
这是真相：我们为此付出两年时间和 40 万美元才领悟——
微服务不是一种纯粹的架构模式，而是一种组织模式。Netflix 需要它，因为他们有 200 个团队。你没有。Uber 需要它，因为他们一天发布 4,000 次。你没有。
复杂性之所以诱人，是因为它看起来像进步。 拥有 47 个服务、Kubernetes、服务网格和分布式追踪，看起来很“专业”；而一个单体加一套 Postgres，看起来很“业余”。
但复杂性是一种税。它以认知负担、运营开销、开发者幸福感和交付速度为代价。
而大多数初创公司根本付不起这笔税。
我们花了两年时间为并不存在的规模做优化，同时牺牲了能让我们真正达到规模的简单性。
你不需要 50 个微服务，你需要的是自律
软件架构的“肮脏秘密”是：好的设计在任何规模都奏效。
一个结构良好的单体，拥有清晰的模块、明确的边界上下文和合理的关注点分离，比一团由希望和 YAML 勉强粘合在一起的微服务乱麻走得更远。
微服务并不是因为“糟糕”而式微，而是因为我们出于错误的理由使用了它。我们选择了分布式的复杂性而不是本地的自律，选择了运营的负担而不是价值的交付。
那些悄悄回归单体的公司并非承认失败，而是在承认更难的事实：我们一直在解决错误的问题。
所以我想问一个问题：你构建微服务，是在逃避什么？
如果答案是“一个凌乱的代码库”，那我有个坏消息——分布式系统不会修好坏代码，它只会让问题更难被发现。