可扩展架构设计指南

先回答：你的系统为什么“扛不住了”

多数扩展问题不是缺架构，而是缺数字。团队常在一句“QPS 太高了”之后就开始讨论微服务拆分，结果要么过早分布式，要么加完了机器问题还在。本指南的第一原则是：可扩展性是演进出来的，不是一次设计出来的。在动手之前，必须先量化四个指标：

• QPS / 峰值 QPS：没有监控数据就不做架构决策；
• 数据量与增速：100GB 和 10TB 对应完全不同的方案；
• 读写比：读多写少优先缓存，写多优先分片或异步；
• 可用性目标：99.9% 允许每月宕机约 43 分钟，99.99% 只剩约 4 分钟，每多一个 9，成本翻倍。

核心方法：按性价比排序的四板斧

指南给出的扩展路径是有序的，前一步没做到位之前不推进下一步：

1. 无状态化：会话外置到集中式存储，应用层可以随意加机器；
2. 缓存：多级缓存从本地到分布式再到 CDN，但先定失效策略再上线；
3. 异步化：用消息队列削峰解耦，把非关键路径移出同步链路；
4. 数据分片：分库分表或分区，复杂度陡增，放到最后。

一致性方面，指南把 CAP 翻译成工程口径：不是给整个系统选 C 或 A，而是按业务动作选——钱相关强一致，展示相关最终一致，流程相关用补偿机制。分布式事务优先用“本地事务 + 消息表 + 幂等消费”替代。

评审与演进的判断标准

指南附了可直接使用的架构评审检查清单，例如逐个组件追问“挂掉时系统行为是什么”“流量涨 10 倍第一个爆的是哪里”。拆微服务的判断也很克制：满足团队规模、负载差异、故障隔离三条中的至少两条才考虑拆，且组织结构没准备好之前，拆服务只会把函数调用变成网络故障。

适用边界

这是通用方法框架而非选型清单，具体中间件要结合团队技术栈和官方文档。所有决策建议落档为 ADR，写清当时的约束与取舍，避免后人用新常识审判旧决策。