选架构最忌“抄作业”——微服务、事件驱动、CQRS（命令查询职责分离）这些词听着高大上，但实际生产中超过60%的“架构升级”项目，最终回滚或废弃，原因就是架构选型与业务场景错配。

单体架构 vs 微服务：不是规模问题，是团队协作密度问题

很多文章说“用户量超过10万就该上微服务”，这是典型的误导。真实案例：一家电商公司日活50万时仍用单体，拆成微服务后，每次发版需要协调10个小组，一个接口变动引发5个服务连锁重启，交付周期反而从2天拉长到1周。关键判断不是用户量，而是团队规模——8人以下团队，单体架构的调试效率、部署成本远优于微服务；只有当团队超30人、且存在明显“模块耦合冲突”（比如A改支付模块，B的订单模块必受影响）时，才值得拆服务。

分层架构 vs 事件驱动：IO密集型业务的天壤之别

传统三层架构（表现层-业务层-数据层）在报表导出场景下暴露致命短板：某SaaS平台每月1号导出10万条订单数据，三层架构下业务层需先查询数据库，再逐行计算，最后交给表现层压缩——单次请求耗时45秒，CPU飙升到90%。切换为事件驱动架构后，将“导出请求”拆为“查询事件”“计算事件”“压缩事件”，利用消息队列异步处理，前端立即返回“任务已提交”，后台分3个消费者并行处理，总耗时降到8秒，且CPU峰值降到30%。如果你的业务有大量文件处理、实时推送或第三方回调，分层架构的同步阻塞模式就是性能瓶颈。

CQRS（命令查询职责分离）的适用边界：写入多、读取杂的场景才值得

很多人把CQRS当作“万能读写分离”，结果在不该用的地方白增加了50%维护成本。典型误区：一个博客系统，用户每天发布100篇文章，查询却只有首页列表和详情页，写入与读取复杂度相当——此时硬拆CQRS，需要维护写模型（命令端）和读模型（查询端）两个数据库，数据同步延迟导致用户“发完文章刷新看不到”。真正适合CQRS的场景是：写入仅有几百次/天，但查询有上百种维度（比如金融风控系统，交易记录写入少，但需要按商户、时间、金额范围、风控标签组合查询），此时读端可以建专门的物化视图或ES索引，写端保持简洁。

避开这三个最常踩的坑

• 别为“未来可能用”引入技术栈：很多团队为了给简历贴金，用户量不到1000就上Kafka + 微服务。请记住：没有10万级QPS的压力，消息队列的序列化开销、数据一致性补偿代码就是纯粹的运维负债。先用单体+简单队列（Redis List或DB轮询）跑通核心流程，等看到明确的性能瓶颈再升级。
• 警惕“架构文档与实际代码不一致”：选型时画了完美的事件流图，但写代码时图省事让服务之间直接HTTP调用，导致架构退化。确保每个架构决策都对应一条工程规范——比如“服务间禁止直接调用，必须走消息队列”，并在CI/CD中加入调用链检查。
• 把“可回滚性”放在第一优先级：选架构时优先考虑“如果错了，最坏情况多久能回滚”。单体架构回滚只需一个版本号，微服务回滚需要同时协调多个服务的版本兼容性。如果团队没有成熟的服务治理工具（服务网格、灰度发布），宁可用“模块化单体”来过渡，也不要贸然拆成分布式地狱。