说出来你可能不信，去年我们终于把拆出去的八个微服务重新合并回了一个单体。这个决定不是脑子一热，是吵了整整三个星期的会才达成的共识。今天写出来，不是劝大家别学新技术，而是希望那些只有十几人的团队别再被“微服务”这三个字绑架。
先交代背景。2019年我们公司刚开始做一个SaaS产品，当时研发一共五个人，我是后端负责人。我提议用微服务，理由特别冠冕堂皇：业务增长快，需要独立部署，将来团队要扩张。于是我们用了Spring Cloud Hoxton全家桶，Eureka做注册，Zuul网关，还有Config Server和Sleuth链路追踪。光是把这些组件跑通就花了两周，第一个业务功能还一行没写。我们其实就三个模块：用户、订单、支付。在单体里就是一个工程里的三个package，硬生生拆成了三个Spring Boot应用。每次本地联调要启动三个服务，再开着网关，内存直接吃满16G。那时候我就在想，这到底图什么？
后来我读了很多书和文章，也认真复盘过，才意识到微服务的核心收益根本不是技术，而是组织。康威定律说系统结构会复刻沟通结构，如果你的团队已经大到需要多个小组协同，那微服务就是放行条。但如果整个公司就三个后端，你拆微服务就是在人为制造部门墙。更别提运维成本了——单体部署一次，生成个jar包扔到服务器上，最多五分钟搞定。微服务呢？你得先构建镜像、推镜像、更新K8s deployment、等滚动升级。如果服务间还有依赖关系，一次全量发布最快也要半小时。我们当时最崩溃的一次，因为某个服务更新了数据库字段，另外三个服务没有同步更新，结果线上报错，排查了俩小时才知道是版本不一致。
当然，微服务的拥护者会说：性能好、能独立扩展、故障隔离。这些我都认，但前提是你的业务真的需要。你见过哪个十几人的团队做的后台管理系统需要每秒处理上万请求？我们的SaaS平台日活才几百，单体应用在8核16G的机器上跑到负载因子0.5都不到。拆了微服务，每个服务还得单独调优，活活把cpu和内存利用率折腾得比单体还低。我查过一篇文章，说微服务有七成的失败案例是因为过度设计，而不是业务本身需要。我深有体会。
那是不是完全不能碰微服务？也不是。如果你有一个独立的、对CPU或者内存要求极高的任务，比如视频转码、批量报表生成，单独拉一个服务出来是合理的。但不要把整个业务系统打碎成服务。我的建议是：先做模块化单体，把业务边界画清楚，在代码层面用接口隔离，将来模块真的需要独立部署了，再把它拆出去。这个拆的时机，应该是你遇到了单体解决不了的问题，而不是你想在简历上多写一句“精通微服务”。
最后说句得罪人的话，很多技术人追捧微服务，是因为复杂的系统才能显得他们有价值。但好的架构不是堆技术栈，而是花最少的人维护并快速迭代。我现在对后端架构的理解就一句话：如果单体已经能让你睡得着觉，就别自找麻烦去折腾微服务。这是我踩了两年坑换来的，信不信由你。
