这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
问题发现与容量分析
场景
业务继续健康发展。
问题发现
某天下午，我收到了告警：
Inbox
From: 监控系统
To: 运维值班
Time: 周四 14:35
Subject: [P1] 服务器负载过高
- CPU 使用率：95%
- 内存使用率：85%
- 响应时间：500ms+
我查了一下监控，发现：
问题：单机服务器已经到极限了！
容量分析
我分析了当前的瓶颈：
CPU
设计流程
CPU
- 步骤 1：确认请求入口、上游实例和本次转发的选择依据
- 步骤 2：根据延迟、连接数和健康状态调整转发目标
- 步骤 3：返回上游响应，并记录实例、延迟和错误信息
关注点：实例健康、转发策略、故障摘除和扩容验证。
瓶颈：
- 每个请求需要调用外部 API
- 数据处理、缓存操作
- 单实例处理能力有限
内存
设计流程
内存
- 步骤 1：确认请求入口、上游实例和本次转发的选择依据
- 步骤 2：根据延迟、连接数和健康状态调整转发目标
- 步骤 3：返回上游响应，并记录实例、延迟和错误信息
关注点：实例健康、转发策略、故障摘除和扩容验证。
瓶颈：
- 数据库连接池占用内存
- 缓存数据占用内存
- 应用实例会占用固定内存
数据库连接
设计流程
数据库连接
- 步骤 1：确认请求入口、上游实例和本次转发的选择依据
- 步骤 2：根据延迟、连接数和健康状态调整转发目标
- 步骤 3：返回上游响应，并记录实例、延迟和错误信息
关注点：实例健康、转发策略、故障摘除和扩容验证。
瓶颈：
- MySQL 默认最大连接数：151
- 当前使用 50 个，已经占 1/3
- 继续增长会达到上限