“我们准备把单体拆成微服务。”这句话在技术评审会上出现的频率快赶上“这个需求做不了”了。仿佛不拆微服务就是技术落后不搞分布式就是架构保守。但我想泼盆冷水大多数中小团队拆微服务不是升级是自残。先看看这五个不拆的理由再决定要不要动手。理由一你的团队规模根本不配微服务微服务的第一性原理是康威定律的逆用你想得到什么样的系统就先组建什么样的团队。一个二十人的研发团队拆出十个微服务意味着平均两个人维护一个服务。这两个人既要写业务又要搞部署还要处理线上问题。大厂一个微服务背后是一个团队你一个人扛一个服务扛得动吗更现实的是小团队里一个人往往身兼数职今天写订单明天修支付。拆成微服务后改一个功能要跨三个仓库、协调两个同事沟通成本比代码复杂度还高。理由二分布式事务的坑你填不起单体架构时一个Transactional搞定所有事。拆成微服务后订单扣库存、支付改状态、积分发奖励三个服务三个数据库本地事务直接失效。你要么上TCC每个操作写Try-Confirm-Cancel三套逻辑要么上Saga每个步骤配补偿操作要么搞本地消息表再写一套定时补偿。无论哪种方案代码量翻倍出错概率翻倍。更可怕的是这些分布式事务方案都不能保证强一致只能最终一致。用户下了单库存扣了支付超时了订单状态挂在那客服电话就来了。你确定你的业务能接受这种中间状态吗理由三运维复杂度指数级上升单体应用一台服务器一个Jar包nohup java -jar完事。拆成微服务后服务发现、配置中心、网关、链路追踪、日志聚合、熔断限流一样不能少。Nacos或Consul要搭吧Spring Cloud Gateway要配吧SleuthZipkin要接吧ELK要部署吧Sentinel要上吧这些中间件本身就要维护出了问题谁排查小团队没有专职SRE开发兼职运维白天写代码晚上修集群。你以为拆完是架构升级实际是给自己找了个第二职业。理由四性能不升反降单体内的方法调用纳秒级。微服务间的HTTP调用毫秒级。一个下单流程单体内十个方法调用可能1毫秒搞定拆成微服务后跨五次网络每次5毫秒直接25毫秒起步。如果网络抖动重试、超时、熔断全来了。更别说序列化反序列化的开销、连接池的竞争、DNS解析的延迟。你以为拆完能扛百万并发实际上单机TPS从一万降到三千。性能瓶颈从来不在单体而在数据库和慢SQL。拆微服务解决不了性能问题只会掩盖问题。理由五你还没有非拆不可的理由亚马逊拆微服务是因为贝索斯的“两个披萨团队”原则组织膨胀到不得不拆。Netflix拆微服务是因为全球数亿用户、每天千亿请求单体扛不住。阿里拆中台是因为业务线多到互相打架。请问你的理由是什么“面试官说微服务是趋势”“技术公众号说单体过时了”“隔壁公司拆了我们也拆”如果答案是这些那你不该拆微服务该换技术负责人。真正该拆的理由只有一个单体已经成为业务增长的瓶颈且拆分的收益大于成本。除此之外都是跟风。那不拆怎么演进模块化单体。一个Jar包内部按业务划分模块模块间通过接口调用禁止跨模块直接访问数据库。代码层面清晰隔离部署层面依然简单。等某个模块真的扛不住了再单独拆出去。这叫“按需演进”不是“一步到位”。淘宝不是一天变成微服务的也是从单体长出来的。微服务是手段不是目的。目的是快速迭代、稳定运行、低成本维护。如果单体已经满足这三点为什么要拆别让“技术先进性”绑架你的判断。先活下来再谈优雅。这五个理由希望你拆之前认真想一想。