但用户从未达到过百万，我们却每月要支付 2.3 万美元的 AWS 账单，经历长达14 小时的服务中断，而且团队也没办法再发布新功能。

这些工具帮我节省了无数时间来排查奇怪的 bean 问题和上下文重新加载错误。

那时我才意识到：我们不是在打造产品，而是在打造一座自恋的分布式纪念碑。

五年前，微服务架构风靡一时。Netflix用了微服务，Uber也用了。每一场技术大会、每一篇文章、每一位资深架构师都在强调同一个观点：单体架构无法扩展，微服务架构可以。

于是我们采取了行动，将Rails单体应用拆分成了多个服务：用户服务、身份验证服务、支付服务、通知服务、分析服务、邮件服务，然后是子服务，最后是调用服务的服务，这些服务又会调用其他服务，层层叠加。

到第六个月，我们已经在12个GitHub代码库中部署了47个服务。部署流程图就像一张地铁线路图，架构图需要4K显示器才能看清。

我们不断安慰自己：一切都在顺利进行。我们有Kubernetes、服务网格、Jaeger 的分布式追踪，还有 ELK的日志记录，我们很现代化。

但那些光鲜亮丽的微服务博客文章中却没有人谈到这一点：分布式系统的隐性成本。

每一项新功能的开发都变成了跨团队的协商：想在用户个人资料中添加一个字段？那需要五个服务、三个 PR、两周的协调，以及一场堪比犯罪电影一样复杂的数据库迁移。

我们的测试环境比生产环境成本更高。因为要测试任何东西，需要将一切运行起来。47个服务在 Docker Compose 中同时启动，内存在疯狂消耗。

凌晨2点47分，Slack崩溃了。

生产系统宕机了。不是某个服务宕机，而是所有服务都宕机了。支付服务无法连接到用户服务，通知服务超时，API 网关对所有请求都返回 503 错误。

我打开了分布式追踪面板：一万五千个span，全部标红。请求瀑布图看起来就像抽象画，我花了四十分钟才找到故障的源头。

结果发现，原来是一位初级开发人员对身份验证服务进行了配置更改。仅仅是一个环境变量的更改，就导致令牌验证延迟了 2 秒。这一延迟波及了下游 11 个服务，超时不断累积，最终导致系统崩溃。重试机制引发了请求风暴，整个系统不堪重负而崩溃。

我们搭建了一个摇摇欲坠的纸牌屋，却称之为“容错架构”。

我们花了六个小时才修复这个问题。倒不是因为这个bug有多复杂，其实只需要改一行配置就能解决。而是因为调试分布式系统就像侦破一桩谋杀案，每个证人都说着不同的语言，而且其中一半都在撒谎。

一周后，我们的首席技术官在复盘会议上说了一些让所有人都不自在的话：

“如果我们……回去呢？”

回归单体架构，回归单一代码库，回归简洁。

房间里一片寂静。你能感受到那种认知上的不协调。我们是工程师，经验丰富。单体架构是老牌公司和编程训练营毕业生的专利，而不是A轮融资创业公司构建未来的工具。

但随后有人调出了我们的指标。平均恢复时间：4.2 小时；部署频率：每周 2.3 次（单体架构时代每周 12 次）；云成本：比收入增长速度快 40%。

数据不会说谎，这种架构正在害死我们。

我们花了三个月时间进行整合。47 个服务合并成一个模块定义清晰的 Rails 应用，Kubernetes 集群简化成负载均衡器后面的三个 EC2 实例，原本12个代码仓库的工作流程合并成一个边界清晰的代码仓库。

结果令人尴尬。

部署时间从 25 分钟缩短到 90 秒，AWS 账单从 23,000 美元降至 3,800 美元。由于我们减少了 80% 的网络调用，P95 延迟降低了 60%。最重要的是什么？我们又开始发布新功能了。

开发人员不再说“我需要和三个团队协调”，而是开始说“我会在午饭前完成”。

我们的“分布式系统”变成一个结构良好的应用，限界上下文变成Rails 引擎，服务调用变成方法调用，Kafka 变成后台任务，“编排层”变成……Rails 控制器。

它速度更快、更便宜、更好。

我们花了40万美元和两年痛苦才明白这个真相：

微服务不是一种架构模式，而是一种组织模式。Netflix 需要微服务是因为他们有 200 个团队，但你不需要。Uber需要微服务是因为他们每天要部署4000次，但你不需要。

复杂性之所以诱人，是因为它看起来像是在进步。拥有 47 个服务、Kubernetes、服务网格和分布式追踪，会让人看起来很专业。而使用单体架构和 Postgres 数据库，则会让人感觉很业余。

但复杂性是一种代价。它会增加你的认知负担和运营成本，降低你的开发者满意度和开发速度。

而且大多数初创公司都负担不起。

我们花了两年时间优化我们根本不具备的规模，却牺牲了达到该规模所需的简洁性。

软件架构的不可告人的秘密：好的设计在任何规模下都有效。

一个结构良好的单体应用，拥有清晰的模块、限定的上下文和关注点分离，会比一堆靠希望和 YAML 勉强维系的微服务走得更远。

微服务并非因为自身不好而消亡，而是因为错误地使用了它们。我们选择了分布式复杂性而非本地化规范，选择了运维开销而非交付价值。

那些悄悄回归单体架构的公司并非承认失败，而是承认了一个更难接受的事实：我们之前解决的是错误的问题。

所以我的问题是：你使用微服务是为了逃避什么？

如果答案是“代码库混乱”，那我得告诉你一个坏消息：分布式系统并不能修复糟糕的代码，它只会让问题更难被发现。