上周四在软件大道某栋写字楼的23楼，跟老陈蹲在消防通道抽了根烟。他烟蒂掐在空的瑞幸冰美式杯子里，说上周刚把27个微服务合并回9个。
真的离谱。
他们公司两年前听了几场行业大会的分享，觉得要跟上架构潮流，照着领域驱动设计的书逐字拆服务。连用户改个头像的逻辑，都拆成了“头像校验服务”“头像存储服务”“头像通知服务”三个独立部署的单元，每个服务配了独立的数据库实例。当时拆完大家还挺兴奋，在群里发了好几个庆祝的表情，觉得自己终于摆脱了“落后的单体架构”。
结果爽了不到三个月，麻烦全来了。改个头像大小的限制，要跨三个服务改代码，提四个MR，等流水线跑20分钟，还要协调三个服务的负责人排发布时间。有次线上头像传不上去，排查了俩小时，才发现是存储服务的磁盘满了，而负责这个服务的小哥刚休年假去了牛首山，手机都关了。我当时听的烟都掉裤子上了。
被吹过的服务粒度神话
说实话，很多人对微服务的误解，从一开始就偏了。觉得只要把单体拆得越碎，架构就越先进，技术团队的能力就越强。
微服务的核心边界，是对应一个独立的业务能力，而不是把一个流程的每个步骤都切下来。就拿电商场景来说，订单服务要独立，是因为它的流量峰值跟用户服务完全不一样，大促的时候订单量是平时的10倍，独立部署可以单独扩容，不会把用户服务拖垮；支付服务要独立，是因为它的合规要求高，权限管控严，不能跟其他业务代码混在一起。而整个用户资料修改的逻辑，从校验合法性到存储再到触发通知，本质上是同一个业务能力，硬拆成三个服务，除了增加跨服务调用的网络开销、增加联调成本，没有任何实际收益。
我见过太多10人左右的小团队，做个本地生活服务的小程序，总共日活才两万，上来就搞12个微服务，每个服务配一个数据库实例。改个收货地址的逻辑，要跨三个服务联调，光维护测试环境的时间就占了开发时间的一半。这种情况，单体应用根本够用，甚至写个优化过的单体，都能比现在跑的快三倍。
真要落地先别着急写代码
很多团队算成本的时候，只算了开发的时间，没算后续运维的隐形成本。你拆一个微服务出来，就要给它配监控、配日志、配链路追踪，要有人负责它的版本迭代，要有人处理它的线上故障。这些成本，比你当初写这个模块的代码成本高多了。
我之前见过个创业团队，总共6个开发，为了凑“先进架构”的简历亮点，把一个内容管理系统拆成了18个微服务。结果上线后三个月，有一半的时间都在处理跨服务的调用超时问题，业务功能根本没多少时间迭代，最后钱烧完了，项目也黄了。
那些踩过坑的人总结的判断标准
老陈他们现在判断要不要拆服务，根本不拿什么“架构先进性”当标准，就问三个很实在的问题。
你现在的单体应用，是不是真的到了迭代不动的程度？比如之前改个小功能，要全量回归测三天，团队里每个人都怕碰核心代码，连提交MR的时候都要在群里@所有人求保佑，那确实可以考虑把耦合度最低的模块拆出来独立部署。
你拆出来的服务，是不是真的能独立部署、独立扩容？如果拆完了，每次发版还是要所有服务一起上，扩容的时候还是要把整个应用全量拉起来，那真的是拆了个寂寞。
你的团队有没有足够的运维能力扛住分布式的复杂度？比如有没有统一的日志监控，有没有服务熔断降级的机制，有没有人专门负责处理跨服务的链路问题？我之前见过一个团队，连基本的链路追踪都没搭，微服务出问题的时候，像无头苍蝇一样在十几个服务器日志里翻，翻到下班都找不到根因，最后还是回滚到上个版本才恢复。
前几天跟老陈在软件大道门口的皮肚面店吃饭，他说现在合并完的服务，迭代速度比之前快了两倍多，上周整个团队居然准时下班了。他说之前总觉得架构要够“高大上”才拿得出手，现在才明白，能帮团队少加班、能稳定扛住业务流量的架构，才是真的好架构。
对吧？毕竟谁也不想为了个头像接口，在公司熬到十点半。