引入负载均衡
我决定引入负载均衡。
用户请求
GET https://dashboard.kuaiyizhi.cn/api/v2/weather?city=北京Nginx 负载均衡
Nginx
Public API
Admin API
Admin Dashboard
MySQL
Redis 集群
MySQL 主从
外部天气 API
方案对比
| 方案 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| Nginx | 成熟稳定、功能丰富 | 配置相对复杂 | 生产环境 |
| HAProxy | 性能极高、专门做负载均衡 | 配置复杂 | 高流量场景 |
| 云负载均衡 | 免运维、自动扩展 | 成本较高 | 云环境 |
| DNS 轮询 | 简单 | 无健康检查 | 简单场景 |
选择 Nginx
我选择 Nginx 作为负载均衡器：
- 免费开源
- 社区活跃
- 功能丰富（健康检查、SSL、静态文件）
- 性能优秀
选型边界
为什么此时选择 Nginx
- 触发问题
- 单台应用服务器已经成为入口瓶颈，需要把请求分发到多台实例，并在实例异常时自动摘除。
- 候选方案
- DNS 轮询、云负载均衡、HAProxy、Nginx。
- 选择理由
- Nginx 对当前规模足够稳定，既能做反向代理和健康检查，也能顺手承接 SSL 和静态资源入口。
- 代价
- 需要维护 upstream 配置、健康检查策略和发布流程；配置错误会影响整个入口。
- 暂不解决
- 暂不引入云负载均衡和多活入口，先把单地域多实例的流量分发跑通。
配置负载均衡
设计流程
配置负载均衡：流量配置
- 步骤 1：维护可用后端实例列表
- 步骤 2：把请求转发到健康实例
- 步骤 3：选择负载均衡策略
- 步骤 4：发现故障并自动摘除异常节点
关注点：实例健康、转发策略、故障摘除和扩容验证。
启动负载均衡层
设计流程
启动负载均衡层：部署操作
- 步骤 1：准备运行环境并启动服务
- 步骤 2：部署、重启或检查服务状态
- 步骤 3：确认请求入口、上游实例和本次转发的选择依据
- 步骤 4：根据延迟、连接数和健康状态调整转发目标
关注点：实例健康、转发策略、故障摘除和扩容验证。
Server 1-4 的配置
设计流程
Server 1-4 的配置
- 步骤 1：获取共享依赖连接并检查可用性
- 步骤 2：检查健康状态并触发告警
- 步骤 3：按负载均衡策略选择可用实例并转发请求
- 步骤 4：刷新上游健康检查结果和路由配置
关注点：实例健康、转发策略、故障摘除和扩容验证。
发现内容有问题？
告诉我们哪里需要改进。