架构设计不是画几张高可用拓扑图、写几份技术选型文档就完事。据我观察，超过70%的中级工程师在晋升答辩时因缺失某个关键知识模块被评委一票否决，而这个模块往往不是代码能力，而是对“非功能性需求”的系统性认知。

第一性原理：别把“高并发”当成万能钥匙

许多团队一上来就奔着百万QPS去设计，结果业务量只有几百。我见过最典型的案例是某创业公司给内部OA系统上了完整的微服务+分布式事务+消息队列，最后因为维护成本过高而回退单体。真正该先搞懂的是“业务复杂度”与“技术复杂度”的匹配：如果你的数据量在单库百万级以内、日均请求不过万，那么裸写SQL加简单缓存比什么CQRS、事件溯源都靠谱。架构的第一要务是解决可维护性，其次才是性能。

三个必须死磕的底层模块：数据一致性、故障隔离、可观测性

以数据一致性为例，很多人以为用了分布式事务框架就万事大吉。某支付公司曾因TCC模式下的空回滚处理不当，导致双十一期间订单金额对不上账。正确做法是：先按业务场景区分“最终一致性”和“强一致性”边界，再针对边界选择Saga、本地消息表或2PC——绝不能用同一把钥匙开所有锁。故障隔离更常被忽略，比如某社交App因一个图片上传服务OOM拖垮了整个网关，原因是没做线程池隔离和舱壁模式。至于可观测性，光有APM监控不够，必须把错误率、延迟分布的P99值和业务指标（如订单成功率）联动告警，否则出问题时你看到的是CPU飙高，但根因可能是数据库连接池泄漏。

技术选型陷阱：不要为“新潮”支付隐性成本

最近很流行用Kubernetes管理所有服务，但某中型电商在迁移后运维成本翻了3倍，因为团队没人懂CNI网络插件的原理。选型时建议做一张“技术债务清单”：新引入一个中间件，至少需要回答三个问题——团队需要学多久？出故障时能否在1小时内定位？社区活跃度是否支持紧急PR合并？比如用Redis Cluster代替单机，就必须提前测试集群扩容时的数据倾斜场景，否则生产环境可能发生大规模缓存雪崩。

• 误区一：先画架构图再写代码——正确的顺序是先跑通最小闭环的代码，再根据瓶颈反向优化架构。很多项目死在“设计过度”上。
• 误区二：把所有服务拆成微服务——当团队不足10人时，微服务只会增加部署和调试成本。建议用模块化单体+预留扩展点，等业务验证后再拆分。
• 误区三：忽略“人”的因素——架构文档必须包含“怎么扩缩容”“怎么回滚”“怎么排查慢查询”这类操作手册，否则新人接手就是灾难。