系统架构设计里，80% 的故障都出在 20% 的边界条件处理上，而不是核心业务逻辑本身——这是我经历了三次线上崩溃后最痛的领悟。

一、先搞清楚“非功能需求”比功能需求更致命

很多团队拿到需求就急着画架构图、选中间件，结果上线第一天就因并发超载挂了。真实场景：某电商平台在双十一前只测试了单用户下单流程，没压测“10000人同时秒杀时库存扣减的幂等性”，结果库存超卖三倍。架构师必须提前量化三个硬指标：最大并发数（TPS）、99% 响应时延（RT）、数据最终一致性容忍时长。别听“先上线再优化”的鬼话——这通常意味着永远没机会优化。

二、分层架构的“层间契约”远比分层本身重要

常见错误是把微服务拆得很细，但 API 接口的参数、返回格式、错误码定义得模糊。拿一个支付系统举例：订单服务调用支付服务时，如果支付超时，订单服务直接重试，结果支付成功但订单却显示失败——因为支付服务没提供“是否已扣款”的幂等查询接口。每层之间的契约必须精确到：哪些是同步调用（要求强一致性），哪些是异步通知（容忍短暂不一致），边界异常时由哪一层兜底回滚。

三、缓存不是万能药，用不好就是毒药

缓存穿透、缓存雪崩、缓存击穿这老三样讲烂了，但实际踩坑更隐蔽。有一次我们给用户信息加了 Redis 缓存，缓存过期时间设了 1 小时。结果凌晨业务方批量更新用户状态，缓存没同步，第二天白天用户看到的全是旧状态。正确做法是：缓存必须配合“主动失效 + 被动过期”双策略；对于写多读少的数据（比如实时库存），干脆不缓存，直接用数据库乐观锁。

• 误区一：以为“高可用”就是多副本+负载均衡。实际上，多副本带来的数据一致性问题，往往比单点故障更难解决。建议先画一个“故障矩阵”，列出每种组件（数据库、MQ、缓存）的单点故障场景和应对措施。
• 误区二：把架构文档写成“部署图+组件清单”。真正有价值的文档要包含“决策记录”：比如为什么选 Kafka 而非 RabbitMQ？权衡了哪些延迟指标和吞吐量？方便以后的人理解为什么不是最优方案。
• 误区三：忽视“架构演进成本”。一开始追求完美分层、DDD 领域驱动，结果三个月后业务变了，重构成本比写新代码还高。建议每季度做一次“架构健康检查”，主要看：有多少代码还在用旧的服务接口？新增一个功能需要改动几个服务？