微服务是银弹吗——一个三年程序员的冷静旁观

一、那时的氛围

2019 年，Spring Cloud 已经全面铺开，各种技术大会的议题有一半以上带着”微服务”三个字。

那时候在技术交流群里，有人随手发了一张 JD 截图——某家公司招 Java 开发，要求里写着”熟悉 Spring Cloud 全家桶，有微服务拆分经验”，下面有人评论：现在不会微服务连面试都过不了。我当时看了一眼，没觉得夸张，因为那段时间我自己投过的 JD 里，这类要求已经是标配。

公司内部也在讨论。有个部门负责人在内部分享会上讲了半个小时微服务的优越性——独立部署、弹性扩容、故障隔离——每一个词都很好听。会后走廊里，有同事和我说：你觉得我们要搞吗？

我当时没有很确定的答案。

二、我们团队的实际情况

我们团队那时候大概 8 个后端，加上前端和测试一共 15 人左右，维护一个跑了两年多的 Spring Boot 单体项目，代码量大概在 15 万行，算不上大。

业务量不算高，日均 API 请求大概几十万次，没有明显的峰谷差异，用一台普通云服务器跑得挺稳。数据库是单主 MySQL，偶尔看一眼慢查询，没什么大问题。

听完那场微服务分享会回来，我在本子上画了个表格，把单体拆成微服务之后需要引入的东西列了一遍：服务注册与发现（Nacos/Eureka）、配置中心、API 网关、分布式事务、链路追踪、服务熔断……每一个都是一个独立的学习成本和运维成本。

我数了一下：大概有 7 个新系统要建。

三、我们做了什么选择，为什么

最终我们没有立刻全面拆分。当时给出的理由很朴素：团队规模不够大，业务复杂度还没到单体”扛不住”的程度，强行拆分只会增加协作成本而不是减少。

我们做的折中方案是：在单体内部做更清晰的模块化——把订单、商品、用户、营销拆成独立的 package，互相之间不能直接调用 Service 层，只能通过接口或事件总线通信。这不是微服务，但它解决了单体最让人头疼的耦合问题，同时没有引入分布式复杂度。

有同事认为这是在走弯路，以后迟早要拆，不如早拆。但我们的判断是：等到真的”扛不住”再拆，比提前拆了”不知道拆什么”要稳。

四、现在回头看

这个选择的窗口期在 2020 年底就到头了——业务增速上来了，团队扩到 15 个后端，代码冲突开始变频繁，那时候才开始认真做微服务拆分。

如果早拆，大概率会陷入”为了微服务而微服务”的坑——服务拆太细，团队没有对应的运维能力，结果搞出一堆”分布式单体”，问题没解决，复杂度先上去了。

2019 年那个时间节点，”等一等”是对的。但等的同时，我们也在认真做准备：把单体内部的模块边界理清楚，等到要拆的时候，知道沿哪条线切，而不是乱切一刀。

那个”微服务是银弹”的氛围里，最难的事不是学会 Spring Cloud，而是在周围人都在拆的时候，能对自己的团队说一句：我们现在还不需要。