为何微服务概念突然不火了？那么单体究竟该不该拆分微服务？原创

大家好，今天聊聊微服务是不是已经过时了？是啊，这两年好像确实没什么人聊了，不是过时，是从潮流话题退回了工程手段，这算好事还是坏事？一个技术从被当成信仰变成被当成工具，恰恰是他成熟的标志。还有很多企业在推全面微服务化，理由是单体架构太落后。微服务这套动因最早是互联网公司被海量并发逼出来的，阿里电商一天上亿访问，不拆真撑不住，那是互联网的量级，可你一个采购系统，用户就是采购部门那几十上百号人，单体集群加冗余设计完全够用，硬要拆拆，理由是什么？那拆开之后是不是就更灵活更稳了？只谈松连铁和扩展，不谈复杂上涨的都是耍流氓，开发集成运营复杂速全涨，稳定性反而下降，每个模块就算9成稳，9成9 9成成下去掉的很快。最硬的一块是数据库拆原来一个跨掉塔比哈斯9服务在逻辑层拼一次业务操作是两块要同时更新状态的服务，不是事务，非常难解决，那到底怎么判断该该拆故事会非常难解，看应用类型。

流程和订单为主的，像OA运维，单单拆细点影响不大，因为数据对象之间没什么关联，那数据型的系统呢，完全相反，资产库存这类所有工都围着底层那一个核心对象转，共享数据层一拆开，立刻就是一堆跨库查询和分布式域。所以传统单体拆6~8个是常见业务材，可很多团队拆完以后，规范根本守不住。技术上拆了20，微服务组织还是一个大团队，一个后端开馆，8个模块，他严格按微服务边界来写，他做不到，然后就走回老路了，该走接口调用的反正都是自己人，又变成直连数据库，所以真正该先行的是组织拆分，技术拆分只是它的投影，所以微服务到底还火不火，火不火不重要，它从来不是方向标，只是一个解决特定问题的技术手段，用对了省力，用错了全是债，那判断标准是什么？8个字，业务驱动，价值驱动，真正该问的不是微服务还火不火，而是我手上这件事儿到底需不需要他？