微服务不是错了，是边界放错了：从分布式单体回到运行时调度

微服务这几年被重新审视，并不是因为“单体又赢了”，而是很多团队终于承认：把系统拆成很多可独立部署的服务，并不会自动带来更好的架构。真正的问题，是把逻辑边界、部署边界和团队边界混成了一件事。

Google 关于现代云应用开发的论文、Prime Video 将部分无服务器/微服务方案合并为单体后的降本案例，都指向同一个结论：模块化是必要的，但过早把模块变成远程服务，往往会把复杂度从代码里搬到网络、发布、观测和治理里。

微服务最常见的失败不是拆多了，而是边界没设计

一个健康的系统应该先有清晰的领域模型和模块依赖，再决定哪些模块值得独立部署。很多团队反过来做：先按功能包、表名、接口或团队喜好拆服务，再用 RPC、网关、消息队列和配置中心把它们重新粘起来。结果不是微服务，而是分布式单体。

分布式单体的问题更难处理。单体里的函数调用至少在一个进程内，调试、测试和事务边界都相对明确；分布式单体把同样的耦合放到网络上，每一次发布、回滚、排障都要跨服务协调。

Google 的思路：代码模块化，部署交给运行时

更值得关注的不是“抛弃微服务”，而是“把物理分布延后”。开发者仍然按逻辑组件组织代码，但不要把每个逻辑组件天然等同于一个部署单元。运行时可以根据延迟、成本、资源和可靠性决定工作负载放在哪里。

这条路线对中小团队尤其现实。大多数业务的开发成本、协作成本和事故成本，远高于所谓“每个服务独立伸缩”带来的收益。先把系统做成模块化单体，再在确实需要时拆部署边界，通常更稳。

Prime Video 案例的真正启示

Prime Video 的案例常被简化成“微服务不行，单体更省钱”。更准确的读法是：某些高吞吐、强链路、按状态转换计费的工作流，用分布式编排会把账单和限额问题放大。合并后成本下降，是因为执行路径变短、状态转换减少、数据流更直接。

这不意味着所有系统都该回到巨型单体，而是提醒架构师：架构选择必须落到延迟、吞吐、账单模型、团队规模、测试方式和发布风险上，而不是落在流行词上。

实务判断清单

• 团队是否有足够的观测、CI/CD、契约测试和 on-call 能力维护多个服务。
• 服务之间是否存在高频同步调用，如果有，拆分可能只是在制造网络损耗。
• 业务边界是否稳定，如果边界还在变化，先保持模块化单体更容易重构。
• 独立部署是否真的能降低发布风险，还是让跨服务发布更难。
• 运行成本是否被状态机、消息、网关、日志和监控放大。

结论

微服务没有全错，错的是把“模块化”误解成“到处部署”。好的架构应该先保护业务边界，再选择物理形态。能在一个进程里解决的协作，不必急着搬到网络上；确实需要独立扩展和隔离的部分，再拆成服务。