关键决策
决策回顾
在构建 API 平台的三年历程中，我做出了很多关键技术决策。每个决策都有权衡。
数据存储
决策 1：SQLite → MySQL
原因：
- 数据量增长
- 需要更好的并发支持
- 需要主从复制
权衡：
- MySQL 更复杂
- 需要单独维护
- 但功能更强大
决策 2：引入 Redis
原因：
- 需要缓存热点数据
- 需要分布式限流
- 需要会话存储
权衡：
- 增加了复杂度
- 增加了成本
- 但性能提升显著
架构演进
决策 3：单机 → 负载均衡
原因：
- 单机性能瓶颈
- 需要高可用
- 需要水平扩展
权衡：
- 架构更复杂
- 需要维护多台服务器
- 但可用性和性能提升
决策 4：单地域 → 多地域
原因：
- 用户遍布全国
- 需要降低延迟
- 需要容灾能力
权衡：
- 运维复杂度大增
- 数据同步困难
- 但用户体验提升
技术选型
决策 5：为什么选择 Python/Flask？
优势：
- 开发效率高
- 生态丰富
- 易于维护
劣势：
- 性能不如 Go/Java
- GIL 限制
结论：
- 适合快速开发
- 性能够用
- 团队熟悉
决策 6：为什么选择 MySQL？
优势：
- 成熟稳定
- ACID 保证
- 生态完善
劣势：
- 大数据量性能下降
- 水平扩展困难
结论：
- 适合结构化数据
- 配合 Redis 使用
- 必要时分库分表
缓存策略
决策 7：多级缓存
层级：
- 内存缓存（最快）
- Redis 缓存（共享）
- 数据库（持久化）
权衡：
- 数据一致性问题
- 缓存失效策略
- 但性能提升显著
可靠性设计
决策 8：熔断 + 降级 + 限流
熔断： 防止故障扩散 降级： 保证核心功能 限流： 保护系统资源
权衡：
- 增加了复杂度
- 可能误伤正常请求
- 但系统更稳定
成长思维
不要过早优化
错误做法：
- 一开始就考虑千万级用户
- 过度设计架构
- 浪费时间和资源
正确做法：
- 从简单开始
- 遇到问题再优化
- 逐步演进监控很重要
没有监控 = 瞎子
必须监控：
- 性能指标
- 错误率
- 资源使用
- 业务指标简单设计最好
KISS 原则
能用简单方案解决：
- 就不用复杂的
- 复杂的维护成本高
- 容易出 bug最重要的一课
技术服务于业务
技术选择应该基于：
1. 业务需求
2. 团队能力
3. 成本预算
4. 时间限制
而不是：
- 追求最新技术
- 过度设计
- 为了技术而技术继续学习
系统设计是一个持续学习的过程：
推荐资源：
- 《Designing Data-Intensive Applications》
- 《系统设计面试》
- 大厂技术博客
实践项目：
- 设计一个 URL 短链服务
- 设计一个聊天系统
- 设计一个电商平台
持续思考：
- 如果流量增长 10 倍怎么办？
- 如果某台服务器挂了怎么办？
- 如何在成本和质量间平衡？
恭喜你完成了整个课程！🎉
希望这个课程能帮助我在系统设计的道路上走得更远。