10个微服务，3个运维工程师，凌晨3点的电话

2024年，我们的SaaS平台跑在10个微服务上：用户服务、订单服务、支付服务、通知服务、文件服务、搜索服务、分析服务、配置服务、定时任务服务、API网关。用Kubernetes编排，Istio做服务网格，Kafka做异步消息。

听起来很专业，对吧？代价是：3个运维工程师轮流on-call，凌晨3点的报警电话每周至少一次。一个简单的"用户注册"请求要经过3个微服务，链路追踪面板上密密麻麻的span让人眼花缭乱。

2025年初，一个支付服务挂了，因为订单服务返回了一个空字段。排查花了3个小时，因为错误日志分散在4个不同的服务里，时间戳对不上。

那一天，我决定推倒重来。

合并后的单体：简单到让人不安

我们把10个微服务合并成了一个Node.js单体应用。用Fastify做HTTP框架，Prisma做ORM，BullMQ做后台任务队列，PostgreSQL做数据库，Redis做缓存。

代码量从4.5万行缩减到了2.8万行。因为微服务之间的那些序列化/反序列化代码、RPC调用代码、重试逻辑、熔断器、超时配置 —— 全部被直接函数调用替代了。

部署从"更新K8s manifest、等滚动更新、检查Pod状态、看链路追踪"变成了"pm2 reload app"。一个按钮。

最重要的变化是：on-call电话从每周一次变成了每月一次。因为所有日志都在一个进程里，错误排查从"在多个服务中拼凑线索"变成了"grep一个日志文件"。

单体应用凭什么撑住50万用户？

“单体应用能撑住高并发？“这是最常见的质疑。答案是：能，而且比你想的容易。

我们的单体应用架构是这样的：

第一层：负载均衡。 前面挂一个Nginx，后面跑4个Node.js进程（PM2 cluster模式，利用多核CPU）。每个进程之间零通信开销，因为单体应用不需要跨进程协调。

第二层：读写分离。 PostgreSQL主库写，两个只读副本读。Prisma的读写分离配置只要10行代码。

第三层：缓存。 Redis做多级缓存 —— 热点数据缓存（用户信息、商品信息）、查询结果缓存、Session缓存。95%的读请求在Redis层返回，数据库QPS不到1000。

第四层：异步化。 耗时操作（发邮件、生成报表、图片处理）全部走BullMQ后台任务队列，不阻塞HTTP请求。

实测数据：4核16G的服务器，单进程轻松跑到8000 QPS。4个进程就是32000 QPS。而50万用户，峰值QPS不到5000。

换句话说，一个单体应用处理50万用户，硬件利用率不到20%。

微服务真正的代价不是技术，是组织

做了两年微服务，我最大的反思是：微服务最贵的不是技术复杂性，而是它带来的组织复杂性。

部署协调成本。 一个需求改了3个微服务，需要协调3个团队的发布节奏。每次发布前要做集成测试，测试环境的搭建和维护本身就是一场噩梦。

沟通成本。 用户服务改了API返回格式，通知服务挂了。但这两个服务由不同团队维护，通知服务的团队花了3天才找到问题。微服务声称"解耦团队”，实际上只是把代码耦合换成了API耦合 —— 而API耦合更难发现。

认知成本。 新同事入职，需要理解10个微服务之间的交互关系。画架构图就花了2周。而单体应用，一个IDE就能看到所有代码，F12直接跳转，全程感知。

微服务还有用吗？有，但只在特定场景

我不是说微服务一无是处。它在以下场景确实有价值：

场景一：组织规模大。 200+工程师，如果不拆分成独立团队，代码冲突和发布协调会成为瓶颈。但绝大多数公司到不了这个规模。

场景二：业务域完全独立。 如果你的平台同时做电商、短视频、社交，这三个业务域确实应该独立部署。但大部分SaaS产品只有一个核心业务域。

场景三：差异化技术栈。 如果你的搜索服务真的需要Elasticsearch专属集群，分析服务需要ClickHouse，这些场景确实需要独立部署。但大多数业务模块用同一个数据库就够了。

场景四：独立伸缩。 如果某个模块的流量是其他模块的10倍，独立部署可以节省资源。但大多数情况下，加机器比你想象的便宜。

2026年的架构选型新思路：模块化单体

我推荐一个折中方案：模块化单体（Modular Monolith）。

代码层面按模块拆分（用户、订单、支付、通知），每个模块有清晰的边界和接口。但部署层面是一个应用，一个进程，一个数据库。

Spring Boot 3.4和NestJS 11在2026年都内置了对模块化单体的支持。你可以用DDD（领域驱动设计）来划分模块边界，用接口（而不是RPC）来定义模块间通信。

当某个模块真的需要独立部署时，你只需要把它的接口改成RPC调用，把它的数据库拆出来。这是自然的演进，而不是被迫的重构。

最后

微服务在2015-2022年间被过度神化了。它被包装成"正确架构"的代名词，被用来在简历上堆砌技术名词，被架构师用来证明自己的"前瞻性”。

2026年，行业正在回归理性。Netflix、Uber这些"微服务鼻祖"也公开分享过它们的微服务之痛。Amazon Prime Video在2023年公开了一个案例：把视频监控服务从微服务改回单体，成本降低了90%。

架构不是为了炫技，是为了解决问题。如果你的问题用单体就解决了，恭喜你，你省下了几百万。