三人团队五个微服务:过度工程的病根不是完美主义

技术博客 var0.xyz 在2026年7月19日发的一篇文章,把"过度工程"重新定义了一遍。作者的核心说法是:问题不是团队把系统做得太完美,而是需求和约束都没搞清楚,就精心解决了一个根本不存在的问题。文章拿"三人团队维护五个微服务"当反例,说很多被骂过度设计的系统,拆分的理由本身就站不住脚。

这个说法对预算和人手紧张的小团队有参照价值。但文章里"约束足够清楚,答案就只剩一个"的推论,本身也偏理想化——真实工程里需求会变,团队能力有上限,所谓的唯一完美解未必真的唯一。

过度工程,病根是选错了问题

作者举了个具体例子。新项目,语言和托管方式随便选,最后挑了 Python 部署 AWS Lambda——不用编译,把文件传上去就能跑。换一个不熟悉 Python、更看重性能的人,答案就不一样了。约束变了,"完美"的定义跟着变,不存在放之四海皆准的正确技术栈。

同样的逻辑放到 Django 和 Flask 上也成立。两个框架能做出效果相近的产品,但设计哲学不同,适合谁要看团队和需求:

文章还补了一句容易被忽略的话:API、内部库、命令行工具本质上也是产品,服务的是使用者的真实需求。判断一个系统有没有过度设计,得先问它的"用户"到底要什么,不能脱离这一点单纯谈技术选型的优劣。

三人团队五个微服务,代价是丢了数据一致性

文章里最扎眼的反例,是一个三人团队维护着五个互相调用的微服务。原本数据库里一个外键就能保证的引用关系,拆分之后变成了服务之间松散传递的字符串 id。一个服务删了记录,另一个服务毫不知情,继续拿着这个悬空引用跑,直到出错才发现。

这张图对比的是三人团队、单一业务域这个具体场景,不是普适结论。业务量真涨起来,某个模块要单独扩容,微服务的独立部署优势会反过来压过单体的一致性优势。图里的"强/弱"只是这个团队规模下的判断,不是永远成立的架构定律。

对资源有限的小型研发团队来说,这段话该落到一个具体动作:先自查有没有真实的独立扩容、独立部署或者跨团队所有权拆分的需求。没有,就先把服务合并回去。把省下的运维精力挪去补测试或者内部工具,不用等到线上出问题才发现悬空引用。

对负责架构选型的技术负责人和工程经理来说,更实际的做法是拿一张清单去判断,而不是凭感觉拆:

真到了要拆的节点,更稳妥的路径是先按模块拆代码、接口先独立,再拆数据库和部署,不是一步到位挪五个服务。数据一致性的问题也可以先用事件通知或者定期对账过渡,不必一开始就上分布式事务。

"完美方案"不是固定答案,团队和需求会变

文章的核心推论是:约束定得足够清楚,方案就只剩一个,而且这个方案天然完美。这个逻辑本身没错,但成立的前提很苛刻。真实项目里,需求会随时间变化,今天没有的扩展诉求不代表明年没有;性能、可维护性、学习成本之间常常要互相让步,不存在单一维度的最优解。

团队自身的能力也是一道隐藏约束。哪怕理论上跨服务保持数据一致更好,三个人有没有精力维护分布式事务,同样得算进成本里。

约束会变,团队会变,所谓唯一解往往只是当下那个瞬间的解。

对技术负责人来说,这意味着"存在一个放之四海皆准的正确答案"这件事本身就该少信。更现实的做法,是把架构判断定期拿出来复核——比如每半年或者需求明显变化时,重新核实一遍团队是不是真的有独立部署、独立扩容的需求。答案是否定的,少拆一个服务,往往比多拆一个更接近"完美"。

接下来值得盯的,是这类判断能不能经受住需求变化的检验。如果这个三人团队真的把五个服务合并回单体,或者业务量涨起来后被迫重新拆分,都会是比这篇文章本身更硬的证据。

【锐评】过犹不及说的从来是分寸不是精细,方向错了,针脚再密也是南辕北辙。