前两年火热的微服务概念，为什么现在不那么火了？

大家好，我是人月聊IT。经常听到有人问，几年前火热的微服务架构，为什么现在不那么火了？

先把这个问法松一松。微服务不是被证伪了，也不是不火了，它是从潮流话题退回了工程手段。前几年大家聊它，聊的是趋势和方向，谁不跟上谁就落后；现在聊它，聊的是这一次到底要不要拆、拆到多粗。这个变化本身很正常，一个技术从被当成信仰，变成被当成工具，恰恰是它成熟的标志。

再放远一点看，热点轮换本来就是IT行业的常态。有人前几年复盘过一条线，17到18年是微服务，18到19年是中台，19到20年是RPA和数字化营销，20到21年轮到低代码和云原生。每年大会都有一个热点，互联网大厂的造词能力又强，很难不产生新概念。所以微服务话题变少，有一半原因只是话筒递给了别人。

另一半原因才是真要命的。微服务最早是互联网公司被逼出来的，C端海量并发把单体应用压垮了，不拆不行。可这套动因搬到传统企业就经常落空。一个采购系统的用户主要就是采购部门那几十上百号人，业务量和并发完全可控，单体集群扩展加冗余设计足够用了。你再去把它拆成更小的微服务，理由是什么。阿里的电商一天上亿访问、接近百万的TPS，那是为支撑业务必须微服务化，而不是技术先进就必须用。

更要命的是复杂度。只谈微服务的松耦合和高扩展，不谈开发和集成复杂度增加的，都是耍流氓。系统拆开以后，开发复杂度涨、集成复杂度涨、运维复杂度也涨，稳定性反而下降。原来自己能确认稳定的事，现在确认不了了，因为模块稳不稳已经取决于一堆外部依赖。哪怕每个模块的稳定度都有九成，九乘九乘九乘下去，掉得很快。高可用性和弹性扩展能力确实提升了，可高可靠性反而是降低的。

复杂度里最硬的一块是数据库。微服务要真做到独立部署，数据库也得跟着拆，一个系统拆成五个微服务，理论上就是五个独立的库，而且库之间不能随便连。于是两个麻烦就来了。原来一个跨表查询能解决的事，现在得调几个服务拿数据再在逻辑层拼起来；更要命的是，一次业务操作要同时更新两个模块的数据，服务本身又是无状态的，这种分布式事务很难解决。企业内的业务逻辑和规则比互联网更复杂，对事务一致性的要求也更高。

所以拆分从来不是越细越好，得看应用本身是什么类型。以流程和工单为主的系统，比如OA、运维工单，拆得再细影响都不大，因为不同流程落地的数据对象之间没什么关联。可以数据为主的系统就完全不同，像资产、库存这种，所有功能都围着底层那个核心对象转，共享数据层一旦拆开，立刻就是一地跨库查询和分布式事务。传统单体拆六到八个是常见的说法，数据库更该按业务域来拆，不该跟着微服务一比一拆下去。

还有一个绕不开的前置条件，是企业的IT成熟度。这话我讲了很多年：连粗粒度的业务系统以及它们之间的集成都管理不好，就更没有能力去管理细粒度的微服务模块。拆分还会把原来藏得住的问题翻出来。一个系统没拆的时候，架构设计好不好是团队内部的事，设计得不合理，后期集成时总能找到变通办法兜住。拆成几个团队各管一块，黑盒就变成团队间的问题，你得把输入、输出和过程都显性化，写成大家都认的标准工件。到这一步你才会发现，自己的架构能力原来是有欠缺的。

团队这一层跟不上，前面定的规范基本都会失效。技术上拆了二十个微服务，组织还是一个大团队，一个后端开发同时管八个模块，你让他按微服务的边界和约束来写，他做不到。本来该走接口调用的，反正都是自己人，又变成直接连数据库了。所以真正该先行的其实是业务组织和团队的拆分，技术上的微服务拆分只是它的投影。开发团队之间高度自治，只通过粗粒度接口交付，规范才守得住。

概念被当成工具用，也是很常见的一种走偏。很多人以为只要用了SpringCloud这类框架就是微服务架构了，这是个很大的误解。微服务架构的核心在于怎么拆、在于粗粒度的API接口设计、在于模块之间是不是真的松耦合，这几条没做到，框架用得再全也不算。这个道理和SOA一样，不是说用了ESB就是SOA，如果接进去的是一堆没标准化、不可复用的混乱接口，那ESB就只是个接口平台，什么SOA思想都没实现。

那为什么话题会凉下去？厂商的夸大是很大的推手。中台是同一套剧本：本身是个好思路，强调共性业务能力下沉再复用，可一堆厂商一味夸大，给企业画大饼，说搞了中台就无所不能，还要求企业把已有的系统全部改一遍。最后项目没达到预期，用户就开始反噬。这不能怪用户，只能怪厂商。RPA也一样，火的时候一塌糊涂，几年后有些厂商和团队已经解散了。任何一个新事物，脱离企业实际的业务目标、场景和需求空谈，再好的东西也会变成垃圾。

数据中台降温几乎是同一个剧本。有些问题本来建个小型BI系统就能解决，非被规划成复杂的数据中台大项目，最后交付的还是几张传统报表。有些该由ESB服务总线或者服务共享平台解决的集成共享问题，硬塞进中台，数据多了一次落地存储，及时性和一致性反而受影响。最关键的是，数据中台要真跑起来，靠的不只是技术平台，还需要懂业务的治理专家，而这个角色在项目里往往缺失。所以问题不在思想，在于跟企业的发展阶段、业务和IT成熟度对不对得上。

与此同时，接棒的概念一个接一个冒出来。云原生把微服务、DevOps和容器云打包成了一个整体，原来单看微服务的注意力被吸收了进去。再往后是Serverless，把微服务进一步拆成一个个无状态的云函数，连共性的技术框架都交给云平台。不过这里得泼点冷水，Serverless在传统企业信息化领域落地很少，这类应用业务规则复杂，又存在大量长事务和状态保持场景，短期内基本不可能整个转过去。

还有一个转向也很能说明问题，就是从面向技术走向面向业务。微服务说到底是个技术词汇，面向的是技术人员，谈的是怎么拆、提供哪些粗粒度API。而PBC业务能力组件是面向业务用户的，是业务能感知的一个功能，比如一个供应商查询组件，背后聚合了底层的API能力还带上了界面。EBC这套企业级业务能力构建，核心就两个词，平台化复用和敏捷化组装。字面上微服务和PBC很像，但一个谈接口层面的复用，一个谈业务功能层面的复用。

真正的大变量还是AI。连我对低代码的判断都变了，早些年我觉得它是好东西，现在我明确认为低代码和AI编程是相互排斥的，未来的快速开发最适合走AI编程这条路，哪怕低代码已经简单适配了AI能力。道理不复杂，低代码像是给一部性能不佳的手机外挂加速器，等手机芯片本身够强了，没人还愿意挂个累赘。RPA受到的冲击也一样，随着MCP生态丰富起来，爬网页、生成文档这些活，大模型自己就能干。

再往上拉一层，连企业架构本身都得重新想。我的判断是EA不会消亡，但必须完成一次范式级的重构。它独特能做到的三件事要保留：把战略翻译成能力、给业务和技术提供共同的沟通语言、做架构治理和标准化，这些本体和AI都替代不了。该废弃的也很清楚：几百页的架构说明书、纯靠人工在Excel里维护的映射矩阵、瀑布式的阶段门控流程。真正要补的，是在四层视图之下建一个统一的语义底座。

回到开头那个问题。微服务不是不火了，是回到了它本来该待的位置。它从来不是一张方向标，只是一个解决特定问题的技术手段，用对了省力，用错了全是债。这些年我看下来，判断标准其实特别简单，就八个字：业务驱动，价值驱动。一旦脱离了这两样，再宏大的框架、再先进的工具，最后都会变成一潭死水。所以真正该问的不是微服务还火不火，而是我手上这件事，到底需不需要它。