这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
完整架构
回顾
经过几年的发展，我的 API 平台从一个简单的天气查询服务，成长为一个完整的 API 平台。
现在，一次天气 API 请求不再只是简单地转发到外部服务。它会经过缓存、鉴权、调用记录、统计看板等多个环节，这条链路就是整个平台能力的缩影：
最终架构
核心组件
1. 负载均衡层
Nginx 集群（3 个地域，共 9 台）
- 功能：负载均衡、SSL 终止、静态文件
- 算法：加权轮询 + 健康检查
- 容量：支持 10 万 QPS
2. 应用服务层
应用服务器（26 台）
- 北京：10 台
- 上海：8 台
- 广州：8 台
- 功能：API 处理、业务逻辑
- 技术栈：轻量应用服务
3. 缓存层
Redis 集群（6 主 6 从）
- 功能：热点数据缓存、限流计数
- 容量：500GB
- 命中率：95%+
4. 数据层
MySQL 集群（1 主 5 从）
- 功能：用户数据、订阅、日志
- 容量：2TB
- 读写分离：主库写，从库读
5. 消息队列
RabbitMQ 集群（3 台）
- 功能：异步任务、日志处理
- 容量：100 万消息/分钟
关键技术决策
| 决策 | 候选方案 | 最终方案 | 选择理由 | 主要代价 |
|---|---|---|---|---|
| 负载均衡 | DNS 轮询、HAProxy、云负载均衡、Nginx | Nginx | 能同时承担反向代理、健康检查、SSL 和静态资源入口，适合从单机平滑演进到多实例 | 需要维护配置、健康检查和发布流程 |
| 缓存 | 进程内缓存、MySQL 缓存表、Redis | Redis + L1 本地缓存 | Redis 负责跨实例共享，L1 本地缓存保护热点数据和降低网络 RTT | 缓存一致性、失效策略和 Redis 高可用都要单独设计 |
| 数据库 | SQLite、MySQL、PostgreSQL、托管数据库 | MySQL 主从 | 事务能力、运维经验和生态成熟，足够承载用户、订阅、日志和账单 | 主从延迟、故障切换和读写路由需要持续治理 |
| 消息队列 | 应用内队列、Redis Stream、RabbitMQ、Kafka | RabbitMQ | 更重视任务可靠投递、确认和死信处理，吞吐要求还没到必须上 Kafka | 引入异步状态、重试、积压和失败补偿问题 |
| 任务调度 | cron、APScheduler、Celery、云流程 | APScheduler | 任务数量少时足够轻量，适合先验证缓存预热和定时清理 | 多实例下要处理重复执行和任务漂移 |
| 多地域路由 | GeoDNS、HTTP 重定向、CDN、全局负载均衡 | GeoDNS + 应用层兜底 | 接入成本低，可以先解决明显的跨地域访问延迟 | DNS 缓存导致故障切换不够实时 |
| 监控 | 日志脚本、Prometheus + Grafana、云监控 | Prometheus + Grafana | 指标模型成熟，适合观察 QPS、延迟、错误率、队列积压和缓存命中率 | 需要维护指标口径、告警阈值和看板 |
| 日志 | 文件日志、MySQL 日志表、ELK Stack | ELK Stack | 搜索、聚合和排障能力强，适合海量调用日志分析 | 存储成本、索引设计和冷热分离复杂度上升 |
真实上线还要注意
- 这些数字是案例规模。 10 万 QPS、2TB、100 万消息/分钟是为了帮助你理解架构层次，不是任何项目都能直接照抄。
- 容量要从自己的数据算起。 真实上线前，要先看用户数、调用频率、缓存命中率和每条日志大小。
- 架构不是越满越好。 如果你的平台还在早期，很多组件可以先不引入，等问题真的出现再演进。