“If you can’t build a well-structured monolith, what makes you think you can build microservices?” —— Simon Brown

---

在技术圈，有一种昂贵的迷信：如果不拆分微服务，架构就不够先进。

这种迷信导致了 2026 年最普遍的架构病灶——“分布式单体” (The Distributed Monolith)。我们把一个本身紧密耦合的系统，强行拆成了 20 个独立部署的服务，然后整天在网络延迟、数据一致性和分布式事务的泥潭里打滚。

是时候算算这笔账了。

看不见的"网络税"

当你把一个 UserService.getUser() 的本地函数调用，改成一个 HTTP/gRPC 请求时，你不仅仅是改了一行代码。

你是在向物理学宣战。

你引入了网络延迟。你引入了序列化和反序列化的开销。你引入了网络抖动、超时、重试、熔断。你引入了服务发现的复杂度。

这就是我所谓的 “分布式税” (The Distributed Tax)。

对于 Google 或 Netflix 这样规模的公司，支付这笔税是值得的，因为他们换取了极致的独立扩展性 (Scalability)。但对于绝大多数日活不到百万的系统，这笔税是纯粹的净亏损。

我们见过太多团队，QPS 还没超过 Redis 单机的承载上限，就已经部署了全套的 Kubernetes + Istio + Jaeger。他们在用造航母的预算，造一艘皮划艇。

伪解耦的幻觉

支持微服务最常见的理由是"解耦"。

“拆分后，团队可以独立开发，互不影响。” —— 这是最大的谎言。

现实情况是：当你修改了 Order 服务的 API，Inventory 服务必须跟着改，Payment 服务必须跟着测。这种耦合并没有因为你把代码放到了不同的仓库里就消失了。

你只是把"编译期耦合"变成了"运行时耦合"。

在单体架构里，接口变动会导致编译失败，你立刻就能修。在微服务架构里，接口变动会导致线上报错，你得在半夜三点通过分布式链路追踪 (Tracing) 才能定位到是哪个服务传错了参数。

这不叫解耦，这叫把简单的逻辑问题变成了复杂的运维问题。

模块化单体：理性的回归

2026 年，我们看到这股风向终于变了。

从 Amazon Prime Video 放弃微服务回归单体节省 90% 成本，到 X (Twitter) 重构 Timeline 混排引擎，“模块化单体” (Modular Monolith) 正在成为顶级技术团队的首选。

模块化单体保留了微服务的核心优势——关注点分离 (Separation of Concerns)，但摒弃了它的核心劣势——分布式复杂性。

我们在同一个进程内，通过严格的代码边界（比如 Java 的 Modules，Go 的 private packages）来隔离业务域。订单模块和用户模块之间，通过明确定义的公开接口交互，但底层依然是进程内调用 (In-Process Call)。

没有网络税。没有序列化开销。没有分布式事务。

如果你需要扩展，水平复制这个单体应用即可。如果你需要拆分，因为模块边界清晰，随时可以把某个模块剥离出去。

别为了简历做架构

让我们诚实一点。

很多时候，我们选择微服务，不是因为业务需要，而是因为**“简历驱动开发”**。我们想在简历上写熟悉 gRPC，熟悉 Service Mesh，熟悉分布式一致性。

但作为架构师，你的职责不是以此为练兵场，而是为业务寻找ROI (投资回报率) 最高的解法。

在 99% 的场景下，一个设计良好的单体，配合 Redis 和 CDN，足以支撑你从 0 到 1000 万用户。

去构建业务，不要构建迷宫。不要因为手里拿着锤子（微服务），就把所有问题都看成钉子。