系统架构设计里，80%的线上故障源于对流量、数据和依赖这三类维度缺乏量化认知，而大多数自学架构的开发者往往只聚焦技术选型，忽略了最核心的取舍逻辑。

流量模型：从并发数反推资源预算

某电商业务在双十一期间预估10万QPS，技术团队直接按10万请求规划服务器数量，结果系统在峰值前20分钟就崩溃。问题出在他们只计算了请求量，没考虑请求的响应时间。真实场景中，一个查询请求平均耗时200ms，单机并发能力 = 1000ms ÷ 200ms × 线程数，假设单机配置64线程，极限并发只有320 QPS。要支撑10万QPS，至少需要313台服务器，而非直觉估算的100台。架构设计的第一步，永远是用最坏情况下的响应时间、请求体大小、超时重试比例三个变量，动态计算所需的资源池大小，而不是拍脑袋定集群数。

数据一致性：CAP定理在支付场景下的硬约束

一个支付核心系统采用最终一致性方案，用户完成转账后在余额页看到扣款成功，但数据库主从同步延迟导致对端账户5秒后才显示到账。这5秒内用户发起退款，系统基于过时数据判断余额不足拒绝操作，引发客诉。如果当时改用分布式事务中的TCC模式，在转账接口里预留冻结资金、确认时真正划转、取消时解冻，虽然响应时间从10ms增加到50ms，但彻底避免了账务不一致。架构设计必须明确数据边界：强一致性场景（支付、库存扣减）必须用事务补偿或两阶段提交，最终一致性只适用于阅读计数、日志写入这类允许短暂偏差的场景。

依赖治理：降级熔断的阈值不是靠经验猜的

某中台系统在第三方风控服务不可用时，自动重试了3次，结果原本1秒的超时等待变成3秒，导致上游调用方全部阻塞，进而引发级联雪崩。正确的做法是：给每个外部依赖设置独立的线程池隔离，并预先通过压力测试得出熔断阈值。例如，设定风控接口的熔断条件为“10秒内失败率超过50%且请求数超过20次”，一旦触发直接返回默认风险等级，而不是无脑重试。同时，降级方案必须回归业务逻辑：库存服务挂了可以返回缓存数据，但支付网关挂了绝不能返回“支付成功”的假响应。

• 误区一：用平均响应时间做容量规划。应该用99.9%分位响应时间，因为平均值隐藏了长尾请求对线程池的阻塞风险。
• 误区二：把所有数据都塞进同一个数据库。按读写比例拆分：热数据放Redis，冷数据用归档表，日志走Elasticsearch，混用只会让缓存失效和慢查询同时爆发。
• 建议三：每次上线前做一次混沌工程演练。随机杀死一个服务节点、模拟数据库CPU飙到100%、延迟网络30ms，看系统是否还能返回正确的兜底数据。