去年双十一，某电商平台每秒处理 48 万笔订单后崩溃，原因不是流量太大，而是底层架构中“服务拆分粒度错误”——订单和支付模块强耦合，导致扩容时资源互相抢占。这件事说明：选架构不是选“最流行的”，而是选“最匹配业务瓶颈”的。

单体 vs 微服务：业务规模在 500 万 DAU 以下是分水岭

一家教育公司做了 3 年垂直课程平台，日活 200 万，一直用单体架构。技术负责人发现，每次修改“课程推荐算法”都要重启整个应用，导致用户无法购买课程 10 分钟。换成微服务后，算法模块独立部署，但带来的新问题是：服务间调用延迟增加 80 毫秒，首页加载慢了一倍。对比来看：当业务逻辑变更频率低于每月 2 次、且用户对延迟敏感（比如金融交易、视频直播）时，单体更稳妥；而当业务模块间依赖度高、需要独立迭代（比如电商促销与库存分离）时，微服务才值得投入。

事件驱动 vs 请求-响应：高并发场景下的两种“堵车”方案

某物联网公司处理 10 万台设备实时数据上传，最初用传统请求-响应模式（HTTP REST）。高峰期时，后端数据库连接池被占满，响应超时率达到 12%。改为事件驱动架构（Kafka + 流处理）后，数据先写入消息队列，再异步消费，超时率降到 0.5%。但代价是：用户查询最新数据时，必须接受 2 秒左右的延迟（因为异步处理有缓冲）。如果业务要求“用户点击后立刻看到结果”（如在线支付、聊天），事件驱动会破坏体验；只有“数据可以稍后到达也能接受”（如日志分析、IoT 传感数据），才该选后者。

分层架构 vs 六边形架构：团队协作效率的决定因素

一家 50 人团队维护的 SaaS 系统，采用传统分层架构（Controller-Service-DAO）。每次添加新功能，开发人员先改数据库层、再改业务层，最后调整接口层——因为各层强依赖，一个字段改动影响 4 个模块。换成六边形架构（又称端口适配器架构）后，核心业务逻辑与外部输入（数据库、API、UI）解耦，新功能只需在“端口”处配置适配器。但缺点是：初期搭建成本高，需要额外花 3 天定义接口协议。对于少于 20 人的小团队，或者需求频繁变动的初创期，六边形架构容易变成“过度设计”，分层架构更务实。

最常踩的 3 个误区与建议

• 误区一：盲目追求“解耦”，忽略团队能力。如果团队只有 3 个后端，强行上微服务会导致运维成本翻倍。建议：先评估 CI/CD 自动化程度、容器化经验，低于 60 分就老老实实单体+模块化。
• 误区二：把架构选择当成“一次性决策”。某公司创业时选事件驱动，3 年后发现用户需要实时交互，重构花了 3 个月。建议：每 6 个月复盘一次业务核心场景（延迟要求、更新频率、团队规模），动态调整，不要死守一个模式。
• 误区三：忽视“流量预测”的准确性。某电商用分层架构扛住 500 万 QPS，但促销流量预测偏差 20% 后直接雪崩。建议：无论选哪种架构，都必须预留 30% 的资源弹性，并提前做压力测试，重点测“依赖最长的链路”（比如微服务里调用链最长的那个）。