上周去软件大道找老周喝咖啡，他去年牵头把公司攒了5年的单体电商系统，硬拆成27个微服务。
现在呢？
每周上线要跨8个团队拉对齐会，光联调环境的接口超时问题，两个研发每天要花两三个小时排查。拆的时候多风光啊，朋友圈发架构图，拿了公司年度技术创新奖。现在擦屁股擦得头大。
我上次跟他聊到半夜，他说现在最后悔的就是当初为了拿奖，硬撑着拆那么多服务。
谁没踩过这种坑啊。
拆之前先算清楚成本账
很多人对微服务的成本认知，还停留在“拆完就能提效”的美好想象里。
真不是。
单体应用时代，改个商品详情的展示逻辑，从提代码到上线，最多两小时，测试点全在同一个代码仓库里，出问题直接回滚就行。拆成微服务之后呢？同样改个详情字段，要动商品服务、用户服务、库存服务、营销服务，四个仓库分别提PR，分别走流水线，分别部署，中间还要反复确认接口字段有没有对齐，光对齐的时间，都够把原来的单体需求做完两轮迭代。
很多人算成本的时候，只算了研发写代码的时间，没算后面维护这些服务的隐形成本。我见过最离谱的团队，拆完微服务半年，光服务调用链监控、日志聚合、配置中心的云资源成本，每个月就涨了12万。
别拿“行业标配”当借口。你整个研发团队才5个人，拆10个服务，平均一个人要扛两个服务的所有迭代、排障、运维工作，这不是给自己找罪受吗？在南京找个小创业团队做个本地商家展示站，总共就三五个开发，上来就搭全套微服务栈，光调通网关、注册中心、配置中心的时间，都够把整个网站做完上线了。真没必要。
别拿技术理想代替业务实际
很多技术负责人拆服务的时候，标准是照着教科书上的领域驱动设计来的，用户域、订单域、商品域、支付域，拆得整整齐齐，架构图画出来漂亮得能当公司宣传素材。一落地就露馅。
之前接触过一个做本地生活的客户，照着DDD的规范把商家结算逻辑从订单服务里拆出去，单独做了结算服务，本来想的是让财务团队能独立迭代结算规则，不用每次提需求都要找研发排期。结果上线才两周就崩了。
结算逻辑要用到的商家历史订单数据全在订单服务里，每次算账都要跨服务查3次接口，高峰期订单量上来，接口超时率直接飙到30%，财务团队每天核对账单要熬到半夜。我当时去帮他们排查问题，看着监控面板上飘红的曲线，真的想把当初拍板拆服务的架构师拉过来唠两句。
真正的拆分逻辑从来不是按教科书的领域边界硬套，而是跟着协作边界走。比如你团队里做支付的几个人，每个月要迭代好几次风控规则，上线频率高，跟其他团队的迭代节奏完全不一样，那把支付单独拆成服务，确实能让这几个人不用跟其他团队挤同一条流水线，上线效率能提上来。但如果你的结算逻辑，一年才改一次规则，你拆出去干嘛？就为了凑服务的数量好看？
对吧。
真要拆的话先从最痛的地方开始
很多人对微服务的误解，就是要一上来把整个系统拆得七零八落，越碎越先进。真错了。
微服务不是什么一劳永逸的银弹，是个慢慢迭代的过程。你先找系统现在最痛的那个点，从那个点开始拆就行。
比如你现在单体系统一到大促，商品详情页的读流量把数据库打满，根本扛不住。那就先把商品详情的读接口拆出去，单独做个服务，前面配好Redis缓存，其他逻辑暂时不动。等你把这个服务跑稳了，摸透了网关、注册中心、监控告警这些基础组件的脾气了，再慢慢拆其他模块。
之前有个南京本地的教培系统，整个系统是PHP写的老单体，一到开学季选课，数据库就锁表，学生刷半天进不去选课页面，投诉电话能把客服打爆。他们没上来就全拆，先把选课的查询接口拆成独立的Java服务，前面加了一层缓存，就这一步，选课的响应时间从原来的8秒降到了200毫秒，投诉量直接掉了90%。剩下的模块，他们花了整整两年时间，才慢慢拆完，整个过程没影响一次正常的业务迭代。
微服务的核心是解决协作效率问题，不是为了凑服务数量。碎到最后，你连服务之间的依赖关系都理不清，新入职的研发要花两周才能摸清楚整个调用链，光梳理文档就写了厚厚三大本，这成本谁扛得住啊。
说真的，做技术这么多年，见过太多团队被“先进架构”的概念绑住，不管自己的业务规模、团队大小，上来就跟风拆微服务。最后钱花了一大堆，效率没提上来，反而多了一堆要维护的中间件，多了一堆跨团队对齐的破事。
其实不管是单体还是微服务，能帮你把业务跑顺，能让研发少加班，就是好架构。