关键决策

决策回顾

在构建 API 平台的三年历程中，我做出了很多关键技术决策。每个决策都有权衡。

数据存储

决策 1：SQLite → MySQL

原因：

• 数据量增长
• 需要更好的并发支持
• 需要主从复制

权衡：

• MySQL 更复杂
• 需要单独维护
• 但功能更强大

决策 2：引入 Redis

原因：

• 需要缓存热点数据
• 需要分布式限流
• 需要会话存储

权衡：

• 增加了复杂度
• 增加了成本
• 但性能提升显著

架构演进

决策 3：单机 → 负载均衡

原因：

• 单机性能瓶颈
• 需要高可用
• 需要水平扩展

权衡：

• 架构更复杂
• 需要维护多台服务器
• 但可用性和性能提升

决策 4：单地域 → 多地域

原因：

• 用户遍布全国
• 需要降低延迟
• 需要容灾能力

权衡：

• 运维复杂度大增
• 数据同步困难
• 但用户体验提升

技术选型

决策 5：为什么先选择轻量应用服务？

优势：

• 开发效率高
• 生态丰富
• 易于维护

劣势：

• 极限性能不是最高
• 单进程并发能力有限

结论：

• 适合快速开发
• 性能够用
• 团队熟悉

决策 6：为什么选择 MySQL？

优势：

• 成熟稳定
• ACID 保证
• 生态完善

劣势：

• 大数据量性能下降
• 水平扩展困难

结论：

• 适合结构化数据
• 配合 Redis 使用
• 必要时分库分表

缓存策略

决策 7：多级缓存

层级：

1. 内存缓存（最快）
2. Redis 缓存（共享）
3. 数据库（持久化）

权衡：

• 数据一致性问题
• 缓存失效策略
• 但性能提升显著

可靠性设计

决策 8：熔断 + 降级 + 限流

熔断： 防止故障扩散 降级： 保证核心功能 限流： 保护系统资源

权衡：

• 增加了复杂度
• 可能误伤正常请求
• 但系统更稳定

成长思维

不要过早优化

错误做法：
- 一开始就考虑千万级用户
- 过度设计架构
- 浪费时间和资源

正确做法：
- 从简单开始
- 遇到问题再优化
- 逐步演进

监控很重要

没有监控 = 瞎子

必须监控：
- 性能指标
- 错误率
- 资源使用
- 业务指标

简单设计最好

KISS 原则

能用简单方案解决：
- 就不用复杂的
- 复杂的维护成本高
- 容易出 bug

最重要的一课

技术服务于业务

技术选择应该基于：

1. 业务需求
2. 团队能力
3. 成本预算
4. 时间限制

而不是：

• 追求最新技术
• 过度设计
• 为了技术而技术