初创项目别急着上微服务：单体架构的边界和拆分的时机判断

前段时间帮一个创业团队看架构，六个人的技术组，产品上线四个月，代码仓库里赫然是九个微服务、一套服务注册发现、独立网关加全链路追踪。问他们为什么这么拆，答案是"招来的高工说大厂都这么搞"。结果两周之内团队没有产出任何业务功能，全在修服务间的超时和配置漂移。这个场景太典型了，值得写一篇认真聊聊。

单体不是技术债，是初期的高效形态

先说结论式的判断：在业务验证期，单体是效率上的理性选择。需求以周为单位变化，模块边界天天在动，这时候拆服务的收益（独立部署、独立扩缩容）几乎拿不到，而成本（分布式事务、链路调试、运维复杂度）一分不少地付。三个人的团队在单体里改一个功能，从改代码到上线可能二十分钟；同样的改动摊在五个服务里，联调加上发布流水线的等待，半天能落地质量就算不错。创业公司的核心矛盾是"验证速度"，不是"流量洪峰"。

但单体不等于一锅粥

支持单体不等于鼓励乱写。真正有生命力的是模块化单体：代码按业务域分包，模块之间只通过明确的接口调用，数据库层不允许跨模块 join。做到这一步，未来无论拆不拆，边界都是现成的。反过来说，很多团队的单体最后拆不动，不是因为单体本身，而是因为三年积累下来数据库里两百张表互相引用，谁也不敢先动手。所以在单体阶段要守的纪律，恰恰是为将来的拆分留门。

拆分的时机信号

什么时候该认真考虑拆？几个信号值得留意。部署成为瓶颈：改一行营销文案也要全量回归整个应用，发布频率高到互相踩脚。团队规模过了临界点：十来个人同时往一个仓库提交，合并冲突和领域归属开始模糊，需要按业务域划分团队所有权。流量结构分化：某个模块（比如导出、报表、消息推送）周期性把整个应用拖垮，扩容只能整体扩，成本不划算。这几个信号同时出现两三个，才是动手的合理窗口。

拆的时候怎么少踩坑

真到了要拆的那天，顺序比工具重要。先从有清晰读写边界、故障可以容忍的边缘模块下手（消息推送、文件处理这类），别一上来就拆交易核心。同步调用改异步消息能消掉一大类耦合，数据库先按模块拆 schema 再谈物理分离。可观测性（日志、指标、链路）要在拆之前就铺好，否则拆完出了问题连定位的抓手都没有。

架构选型的答案从来不在大厂的经验里，而在自己的业务阶段里。验证期用模块化单体跑速度，攒好边界纪律；等部署、团队、流量三个信号亮起来，再按"边缘先行、异步解耦、观测先行"的顺序拆。我们在天使创客内部系统上也是这么走过来的：单体起步，边界清晰，拆分只发生在它真正带来收益的那一天。技术选型跟业务节奏合拍，才是初创团队该有的底座。