主题
第 9 章 · 综合实战案例
生活类比：学完理论，来看几家「店」怎么在实战中布置柜台、应对客流高峰、处理收银员请假——每个案例都是真实架构的简化版。
9.1 案例一：个人博客 → 小型 Web 应用
初始状态
用户 ──► 单机 Nginx + PHP ──► MySQL日 PV 1 万，够用。
流量上涨后
┌──► CVM1: Nginx + PHP
用户 ──► 云 CLB ────┼──► CVM2: Nginx + PHP
└──► CVM3: Nginx + PHP
│
▼
云数据库 MySQL| 决策 | 选择 | 原因 |
|---|---|---|
| 入口 | 云 CLB 七层 | 免运维、HTTPS 证书托管 |
| 算法 | 轮询 | PHP 实例同质 |
| Session | Redis | 避免 IP Hash |
| 静态资源 | CLB 分流到 COS/CDN | 减轻应用机压力 |
关键配置思路
- CLB 健康检查
GET /healthz每 5s - 应用 Session 存 Redis，PHP
session.save_handler = redis - 上传静态文件到 CDN，Nginx 只反代动态 API
9.2 案例二：电商大促（秒杀场景）
挑战
- 平时 QPS 500，大促瞬间 5 万
- 下单接口不能重复扣款
- 库存不能超卖
架构（简化）
用户 ──► CDN（静态页）
│
└──► WAF + 云 LB
│
▼
API 网关（APISIX）
├── 限流：每用户 10 QPS
├── 鉴权：JWT
└── 路由
│
┌────────┼────────┐
▼ ▼ ▼
订单服务 库存服务 支付服务
(20 Pod) (10 Pod) (5 Pod)负载均衡相关决策
| 点 | 做法 |
|---|---|
| 入口 | 云 LB + API 网关双层 |
| 算法 | least_conn（下单耗时差异大） |
| 重试 | 订单 POST 禁止 LB 重试；业务幂等键 |
| 扩容 | K8s HPA 按 CPU/QPS 自动加 Pod |
| 预热 | 大促前 30 分钟逐步加压，JVM warmup |
生活例子
秒杀像 限量款发售——门口保安限流（网关限流），多个收银台但 同一订单号只能结一次（幂等），临时加开柜台（HPA）。
9.3 案例三：微服务 + 内部 RPC
拓扑
┌── order-svc (3 实例)
gateway ──L7───────┼── user-svc (5 实例)
└── pay-svc (2 实例)
order-svc ──gRPC──► user-svc
（客户端 LB + 服务注册中心 Nacos/Consul）两层 LB
| 层级 | 组件 | 算法 |
|---|---|---|
| 南北向（外→内） | Ingress / API 网关 | 路径路由 + least_conn |
| 东西向（服务间） | gRPC client LB | round_robin 或 pick_first |
要点
- 外部流量 不过度重试 POST
- 内部 RPC 配置 超时 + 熔断（resilience4j / envoy）
- 服务注册中心实时更新实例列表，避免打到已下线 Pod
9.4 案例四：多机房容灾
[DNS Geo + 全局 LB]
/ \
[广州机房] [上海机房]
CLB + K8s CLB + K8s
│ │
同城 Redis 同城 Redis
│ │
广州 MySQL 主 ──复制──► 上海 MySQL 从负载均衡角色
| 组件 | 作用 |
|---|---|
| DNS GSLB | 广州用户解析到广州 VIP |
| 机房 CLB | 机房内 Pod 负载均衡 |
| 故障切换 | 广州机房故障，DNS 切到上海（分钟级） |
生活例子：连锁品牌在 天河店 和 浦东店 都有柜台，你 GPS 在广州就去天河，天河装修就去浦东。
9.5 案例五：WebSocket 在线客服
特点
- 连接建立后 长时间挂在一台 上
- 消息要顺序、客服状态要实时
用户 ──WS──► LB（支持 WS）──► 客服服务 Pod
（粘性：连接级）配置要点
nginx
location /chat {
proxy_pass http://chat_backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 3600s;
}- LB 要支持 协议升级（Upgrade: websocket）
- 读超时设长（1 小时+）
- Pod 下线前 draining：不再接新 WS，旧连接办完
9.6 端到端排查剧本
当用户说「网站时快时慢」，按此顺序查：
1. 云 LB 健康后端数是否正常？
2. 是否某台 Pod CPU/内存飙高（热点）？
3. LB 到后端延迟？长连接开了吗？
4. 是否有重试放大流量？
5. 数据库/Redis 是否拖慢（健康检查能通过但业务慢）？
6. 最近是否发布（readiness/预热问题）？9.7 动手作业
任选一题完成：
- 画架构图：为你熟悉的一个网站（B站、淘宝简化版）标出 LB 在哪一层
- 写配置：Nginx
upstream实现 3 后端 + least_conn + keepalive + 被动健康检查 - 写方案：一个「抢红包」接口，如何保证幂等、如何限流、用什么 LB 算法
- 模拟面试：2 分钟讲「秒杀场景下负载均衡要注意什么」
9.8 一句话总结
没有万能架构，只有场景匹配：博客用云 CLB + 轮询，大促加网关限流 + 幂等，微服务分南北东西向，多机房靠 DNS + 机房 LB。