先泼一盆冷水：微服务被神化已久
过去十年，微服务成了软件架构领域的“政治正确”。凡是谈到系统设计，言必称微服务，仿佛不拆几个服务就不够现代、不够云原生。但实际上，我在大量技术复盘和故障分析中发现，很多团队连业务边界都没搞清楚，就盲目套用微服务框架，结果每个服务都像一个婴儿——需要独立的部署流水线、独立的数据库、独立的监控告警，甚至独立的团队维护。当服务数量超过团队规模的三到五倍时，认知负担呈指数级上升，而收益却微乎其微。
更讽刺的是，很多号称微服务架构的系统，其内部仍然是“分布式单体”——服务之间通过同步HTTP调用串联，共享数据库表，逻辑耦合严重。所谓的独立部署，往往因为接口兼容性而变成“牵一发动全身”。这不禁让人质疑：我们追求的到底是架构的优雅，还是简历上的亮点？技术的选择本应服务于业务价值，却在很多时候演变成了技术人的自嗨。
对比：微服务 vs 模块化单体，谁在裸泳？
我们不妨做一个冷静的对比。微服务的核心优势是独立伸缩、独立部署、故障隔离以及团队自治。但这些优势的前提是：业务规模足够大，团队足够大，并且有平台化的运维能力支撑。而模块化单体（Modular Monolith）则强调在单一部署单元内，通过模块边界实现高内聚低耦合。它同样支持清晰的领域划分，却避免了分布式带来的网络延迟、数据一致性和复杂编排问题。
从运维角度看，模块化单体只需要一条流水线、一个日志聚合入口、一套监控体系，而微服务则需要服务网格、分布式链路追踪、集中配置中心、注册中心等一整套基础设施。从团队协作看，微服务迫使团队之间通过接口契约沟通，这往往会导致接口腐化和版本碎片化；模块化单体则在代码层面直接依赖模块边界，重构和维护反而更加直观。当然，模块化单体也有天花板——当模块间非业务依赖（如资源竞争）成为瓶颈，或者团队需要完全隔离发布时，它确实会阻碍效率。但这恰恰说明：架构不是非黑即白，而是基于约束条件的动态权衡。
独立观点：先做“正确”的架构，而不是“时髦”的架构
我的核心观点是：对于绝大多数中小型团队（人数在几十人以内）和中等规模业务（日均百万级调用以下），模块化单体是比微服务更理性的起点。它让你的团队以最低成本验证业务模型，同时保留模块化边界，为未来的演进留有余地。很多团队在初期就上微服务，其实是在用架构的复杂度掩盖对业务理解的匮乏。正确的路径应是：从模块化单体开始，当某个模块的独立性、伸缩性或团队边界成为真实瓶颈时，再局部抽取为独立的微服务。这样拆分的服务，每个都有清晰的理由，而不是因为KPI要求“微服务率”。
更进一步，我认为“演进式架构”才是真正的银弹。无论是微服务还是模块化单体，都只是某个阶段的快照。技术决策应当像生物进化一样，随着环境变化而调整。所以，请不要迷信任何“最佳实践”，要敢于在企业内部建立“架构病历”——记录每一次架构决策的假设与后果，定期复盘。当你发现自己花在协调服务间的事物一致性上的时间，远超于业务功能开发时，就是时候考虑回退到更大粒度的模块了。
落地建议：如何避免“过度工程”的陷阱
在实操层面，我给所有团队三条建议。第一，用“模组化”取代“微化”——先在代码层面守住模块边界，通过包结构、接口权限和依赖方向规则来保证模块间只有一个方向依赖。Second，在开发环境里用一个单体启动所有模块，但在CI/CD上允许部分模块独立发布（通过构建参数控制），这样既享受了快速启动和内聚开发，又保留了部署的弹性。Third，对于必须拆分的场景，优先选择“异步消息”和“事件驱动”来解耦，而不是“同步RPC”——同步调用会让每个故障瞬间放大为全链路抖动，而异步消息则天然具有削峰和缓冲能力，但要注意最终一致性的业务容忍度。
最后，我想引用一个行业现象：Amazon Prime Video团队在2023年将部分微服务合并为单体后，成本降低了90%以上。这种“逆流”的案例越来越多，不是因为微服务错了，而是因为脱离场景谈架构就是耍流氓。选择架构就像选择鞋子——合脚最重要，别人穿得漂亮那是别人的事。愿你做出理性、务实、可演进的技术决策。