多年来，我们一直坚信"微服务是未来"的理念。

"把所有东西拆成独立的微小服务"，"让团队独立扩展"，"部署更快，迭代更猛"。

但最近出现了诡异的现象：许多曾迁移到微服务的团队，正在回归单体架构。

这不仅是小创业公司的选择——亚马逊、Shopify、Basecamp、Segment，甚至谷歌都在这么做。

没错。这些国外微服务的先驱者正在悄悄承认：

"我们当初做过头了。"

微服务到底哪里不好？

说实话，微服务听起来很美好。理论上它们承诺：

• 独立部署

• 弹性扩展的团队

• 清晰的关注点分离

但现实中你往往得到的是：

• 上百个无人理解的代码仓库

• 过多网络通信导致的延迟问题

• 开发者花在基础设施的时间比产品还多

• "这见鬼的bug到底是从哪个服务冒出来的？"

如果你真正用微服务构建过系统，大概率亲眼见过这些场景。

举个简单例子

假设要构建电商系统。

采用微服务架构可能会拆成：

• 认证服务

• 商品服务

• 购物车服务

• 订单服务

• 通知服务

看起来很酷对吧？

但是，紧接着你就会遇到如下问题……

• 你需要用Kafka或RabbitMQ串联所有服务

• 需要Redis实现会话共享

• 完整部署一次需要30分钟CI/CD

• 你开始编写大量服务间通信代码

更可怕的是：

现在要实现一个"简单"功能，需要改动5个服务、而不同的服务所属不同的开发小组，跨组评审需求、拉会、联调、测试，想想都头大。

微服务放大了复杂性

有件事我们当年没敢完全承认：

微服务不会减少复杂性——它只是转移了复杂性。

在单体架构中，复杂性体现在代码层。而微服务让复杂性弥漫到：

• 网络IO延迟

• API接口约定

• 数据一致性

• 部署流水线

• 服务发现机制

• 日志/追踪/监控体系

随便询问一个资深开发者都会得道相同的答案：维护50个微服务，比维护一个结构良好的大型单体应用要困难得多。

为什么单体架构正在回归

单体架构更简单。不是"容易"，而是组件更少。

在单体架构中：

• 所有代码都在同一处

• 调试过程直截了当

• 代码变更是原子性的

• 没有跨服务API的噩梦

• 本地开发不需要启动Kubernetes

如今借助现代化部署实践（Docker、k8s），单体架构同样能良好扩展。

国外案例：Shopify 和 Segment 的回归

Shopify：曾全面转向微服务，如今正在积极迁回模块化单体架构

Segment：类似经历，在遭遇扩展性、延迟和团队效率问题后，发布了博客文章《再见微服务》

模块化单体架构：两全其美？

模块化单体架构正在成为众多企业的新选择。

不再是混乱的巨无霸，而是构建：

• 单一可部署单元

• 保持清晰的内部边界

• 按微服务理念组织，但运行在单一进程中

你仍然可以获得业务分离的优势，同时避免网络跳转、复杂工具链和部署痛苦。

按领域划分模块：

• /cart

• /order

• /notification

但整体仍是单个应用。

该放弃微服务吗？

未必，具体情况需要具体分析。

在以下场景微服务仍然适用：

• 真正需要应对海量用户（百万级规模）

• 拥有多个需要极速迭代的产品团队

• 已建立完善的监控体系和部署流水线

但如果你符合以下情况：

• 工程师少于50人

• 专注于单一产品

• 花在基础设施的时间超过功能开发

那么选择单体架构或许更能拯救你的团队。

最终建议

技术趋势总是一波三折。我们曾过度追捧微服务，现在正在理性回归。

不要盲目追随热潮。选择能让团队更高效、更从容、更专注产出的方案。

有时候，最好的架构不是最时髦的——而是能让你睡个安稳觉的那个。