过去十年，微服务几乎成为了互联网架构的政治正确。

如果你在 2018 年左右参加架构面试，大概率会被问：

• 服务怎么拆？
• 怎么治理？
• 怎么做注册发现？
• 怎么做链路追踪？

那几年有一种特别强烈的氛围：

系统不拆微服务，好像就不够先进。

于是很多团队开始拆。

订单服务。
库存服务。
支付服务。
营销服务。

甚至有些团队：

一个业务拆十几个服务。

当时大家都觉得：

这是架构升级。

但有趣的是。

最近几年越来越多公司开始讨论：

• Modular Monolith
• Monorepo
• 合并服务
• 减少 RPC

甚至一些曾经疯狂拆分的团队，也开始悄悄把服务重新合回来。

为什么？

因为大家终于开始看见微服务真正的成本。

---

微服务最大的成本，从来不是性能

很多工程师第一次接触微服务的时候，会担心：

• RPC 慢
• 网络抖动
• 序列化开销

但这些通常不是最致命的问题。

一次 RPC 可能只是几毫秒。

真正昂贵的东西是：

认知成本。

系统拆开以后。

业务被切碎。

团队开始失去整体视角。

---

服务拆开之后，业务反而变复杂了

假设一个简单需求：

用户下单。

单体时代：

createOrder();
deductStock();

结束。

---

拆成微服务后：

OrderService
↓
InventoryService
↓
CouponService
↓
PaymentService

每一步都变成网络调用。

每一步都可能超时。

每一步都需要补偿。

于是原本几十行逻辑。

变成：

• 重试
• 熔断
• 降级
• 补偿

复杂度指数级上升。

---

很多团队拆出来的不是服务，而是 RPC 耦合

这是特别常见的问题。

服务按照数据库表拆：

• 订单服务
• 库存服务
• 支付服务

看起来边界清晰。

但半年之后：

每个需求都要同时修改多个服务。

这说明什么？

说明：

业务边界根本没拆开。

只是把原来的方法调用。

变成了远程调用。

耦合没有消失。

只是从 JVM 内部搬到了网络上。

---

真正的大厂为什么能玩微服务？

很多人看到：

阿里在拆。
字节在拆。

于是觉得：

微服务就是最佳实践。

但忽略了一个事实。

这些公司首先拆开的不是服务。

而是组织。

订单团队。
支付团队。
营销团队。

都是独立团队。

有自己的：

• 开发
• 测试
• 运维

服务边界其实来自组织边界。

而不是反过来。

---

很多团队的问题是：组织没拆，服务先拆了

于是出现一种特别尴尬的场景：

三个人维护十几个服务。

每次上线：

改一个需求。

要发五个服务。

最后：

业务没复杂。

运维先复杂了。

---

为什么 Modular Monolith 又开始流行？

因为大家终于意识到：

很多问题和部署方式无关。

真正的问题是：

• 领域边界混乱
• 模块职责不清
• 团队协作失控

这些问题：

拆服务解决不了。

---

于是很多团队开始回归一个思路：

先把边界做好。

再决定要不要拆服务。

这其实就是 Modular Monolith 的核心。

---

架构演进最容易犯的错误：过度设计

很多系统出问题。

不是因为架构太简单。

而是因为：

架构太复杂。

系统还没几万用户。

先上：

• 微服务
• Service Mesh
• CQRS
• Event Sourcing

结果：

业务还没复杂。

架构先复杂了。

团队大量时间花在：

修基础设施。

而不是解决业务问题。

---

微服务真正解决的是什么？

很多人以为：

微服务解决代码问题。

其实不是。

微服务解决的是：

组织规模问题。

当团队大到：

一个代码仓库已经无法协作。

一个发布周期已经无法承受。

这时候：

微服务才真正体现价值。

---

写在最后

过去几年最大的变化之一。

不是微服务失败了。

而是大家终于开始理性看待微服务。

微服务当然有价值。

但它不是银弹。

更不是技术先进的象征。

很多团队最后重新合并服务。

也不是因为技术倒退。

而是因为：

他们终于发现。

真正困难的从来不是怎么拆。

而是：

怎么控制复杂度。

而控制复杂度这件事。

远比选择单体还是微服务重要得多。