徐万新之路复杂的事情简单化
简单的事情量化
量化的事情专业化
专业的事情模块化
SLB（Server Load Balancer）：基础服务器负载均衡，基于 IP + 端口分发请求，解决单点故障、分摊服务器压力。
CLB（Cloud Load Balancer）：云负载均衡，是云厂商提供的 SLB 升级款，支持更多云原生场景（如私有网络、弹性伸缩联动）。
ALB（Application Load Balancer）：应用负载均衡，基于 HTTP/HTTPS 等应用层协议，可根据 URL、Cookie 等精准路由，适配微服务架构。
核心结论：SLB 像 “只看序号的基础排队引导”，CLB 像 “兼顾序号和简单需求的分类引导”，ALB 像 “精准匹配需求的定制化引导”，三者的核心差异在 “分发依据的精细度”。
一、核心类比：餐厅排队对应三种 LB
- SLB（四层负载均衡）：类比 “只按排队顺序分配的保安”。不管你是吃正餐、小吃还是打包，只看你排队的序号，依次分到不同用餐区（服务器），仅依据 IP + 端口判断，不关心请求内容。
- CLB（多层负载均衡，四层 + 七层）：类比 “会简单询问需求的领班”。除了按排队顺序，还会问一句 “吃正餐还是小吃”，把同类需求的人分到对应区域，既能按 IP + 端口分发，也能识别简单 URL、域名等七层信息。
- ALB（七层应用负载均衡）：类比 “精准对接需求的点餐顾问”。会详细问 “吃辣 / 清淡、堂食 / 打包、用优惠券 / 正常付款”，再分到专属窗口（比如川菜窗口、打包专用台），完全基于 HTTP/HTTPS 请求内容、Cookie、请求头等精细信息分发。
二、关键区别：从餐厅场景看核心差异
- 分发依据：SLB 看 “排队规则（IP + 端口）”，CLB 看 “规则 + 简单需求”，ALB 看 “完整需求（应用层信息）”。
- 灵活度：SLB 仅能 “平均分配流量”，CLB 可 “简单分类分配”，ALB 能 “按需求精准匹配”（比如把支付请求分给高性能服务器）。
- 适用场景：SLB 适合 “无特殊需求的基础访问”（如普通网页），CLB 适合 “有简单分类需求的访问”（如同一域名下的不同模块），ALB 适合 “复杂应用场景”（如电商下单、直播推流）。
LB 类型 – 餐厅类比 – 技术特性对照表
| LB 类型 | 餐厅类比 | 核心分发依据 | 技术层级 | 关键特性 | 并发 / QPS 能力 | 适用场景 |
|---|---|---|---|---|---|---|
| SLB（网络型负载均衡） | 只按序号分配的保安 | IP + 端口、协议类型（TCP/UDP） | 仅四层（传输层） | 超高性能、低延迟，支持 SSL 卸载、连接风暴抑制，网络层 DDoS 防护，自动弹性伸缩 | 单实例最大 1 亿并发连接 | 游戏服务器、直播 / 音视频流、IoT 设备通信 |
| CLB（传统负载均衡） | 会简单询问需求的领班 | IP + 端口（四层）、简单 URL / 域名（七层基础） | 四层 + 七层（基础） | 基础负载均衡，支持会话保持（Cookie / 源 IP），简单健康检查，兼容传统应用 | 十万级以下并发 | 中小型 Web 应用、传统单体系统、简单 TCP 服务 |
| ALB（应用型负载均衡） | 精准对接需求的点餐顾问 | URL 路径、请求头、Cookie、查询字符串等 | 仅七层（应用层） | 精细化路由，SSL 终止卸载，支持 HTTP/2/gRPC/QUIC 协议，集成 WAF，灰度发布 | 单实例最大 100 万 QPS | 微服务入口、API 网关、前后端分离项目、HTTPS 服务 |
LB 选型决策流程图
流程核心说明
- 核心判断优先级：应用层需求 > 并发能力 > 应用类型，贴合实际部署中的决策逻辑。
- 无歧义节点：每个判断均为 “是 / 否” 二元选择，避免复杂分支，快速落地。
- 强关联之前特性：每个结果都对应对照表中的并发能力、适用场景，保持一致性。
LB 选型决策 Checklist
| 核查维度 | 具体核查项 | 勾选（是 / 否） | 对应选型倾向 |
|---|---|---|---|
| ### 一、应用层需求（核心优先级） | |||
| 1. 是否需要基于 URL 路径分发？ | 例：/api/* 路由到 API 服务器、/static/* 路由到静态资源服务器 | 是→ALB；否→SLB/CLB | |
| 2. 是否需要识别请求头 / Cookie？ | 例：按用户 Cookie 保持会话、按请求头筛选特定终端请求 | 是→ALB；否→SLB/CLB | |
| 3. 是否使用 HTTP/HTTPS/gRPC/QUIC？ | 例：HTTPS 加密服务、微服务 gRPC 通信 | 是→ALB；否→SLB/CLB | |
| 4. 是否需要精细化功能？ | 例：SSL 卸载、灰度发布、WAF 集成、请求改写 | 是→ALB；否→SLB/CLB | |
| ### 二、并发与性能需求 | |||
| 1. 并发连接数是否超 10 万级？ | 例：直播推流、游戏服务器、IoT 设备批量通信 | 是→SLB；否→CLB/ALB | |
| 2. QPS 是否超 10 万？ | 例：电商大促、热门 APP 接口访问 | 是→ALB/SLB；否→CLB | |
| 3. 是否要求低延迟（毫秒级）？ | 例：实时交易、音视频实时传输 | 是→SLB；否→CLB/ALB | |
| ### 三、应用类型与场景 | |||
| 1. 是否为传统单体应用 / 简单 Web 服务？ | 例：老旧管理系统、静态网页、无特殊路由需求的网站 | 是→CLB；否→SLB/ALB | |
| 2. 是否为微服务 / 前后端分离项目？ | 例：分布式架构、多模块 API 服务、前端静态 + 后端接口分离 | 是→ALB；否→SLB/CLB | |
| 3. 是否为纯 TCP/UDP 服务？ | 例：数据库代理、自定义协议通信、游戏端口服务 | 是→SLB；否→CLB/ALB |
快速选型结论公式
- 勾选 “应用层需求” 任意 1 项 “是” → 直接选ALB
- 应用层需求全 “否” + 并发 / 低延迟任意 1 项 “是” → 直接选SLB
- 应用层需求全 “否” + 并发 / 低延迟全 “否” + 传统应用场景 “是” → 直接选CLB
常见场景选型速查表
| 典型业务场景 | 核心需求关键词 | 推荐 LB 类型 | 关键选型理由（贴合之前特性） |
|---|---|---|---|
| 电商平台（含大促、下单支付） | 高 QPS、HTTPS、URL 路由、会话保持、灰度发布 | ALB | 需精细化路由（商品页 / 支付页分离），兼容 HTTPS 与高并发 |
| 直播推流 / 短视频平台 | 高并发连接、低延迟、TCP/UDP 协议 | SLB | 百万级设备接入，需低延迟传输，无需应用层解析 |
| 微服务集群（Spring Cloud/K8s） | gRPC/HTTP/2、API 路由、服务治理集成 | ALB | 需基于请求头 / 路径分发微服务，支持复杂应用层协议 |
| 传统 OA 系统 / 内部管理平台 | 低并发、简单 Web 访问、会话保持 | CLB | 无复杂路由需求，适配老旧单体应用，部署成本低 |
| API 网关（对外提供接口服务） | 接口鉴权、请求改写、多终端适配 | ALB | 需解析请求头 / 查询字符串，支持 SSL 卸载与精细化控制 |
| 游戏服务器（手游 / 端游） | 高并发 TCP 连接、低延迟、连接风暴抑制 | SLB | 千万级玩家同时在线，需传输层快速分发，抗突发流量 |
| 静态网站（文档 / 图片展示） | 低并发、HTTP 访问、简单负载均衡 | CLB | 无特殊需求，追求部署简便，降低不必要的资源消耗 |
| IoT 设备通信（传感器 / 控制器） | 海量 TCP/UDP 连接、低延迟、稳定性优先 | SLB | 十万级设备批量上报数据，仅需端口转发，无需应用层处理 |
| 前后端分离项目（Vue/React + 后端 API） | 静态资源 / 接口分离、HTTP/HTTPS、跨域支持 | ALB | 需按 URL 路径分发（前端静态 / 后端 API），适配应用层协议 |
| 实时交易系统（股票 / 支付） | 低延迟、高可靠、TCP 协议、高并发 | SLB | 毫秒级响应要求，需传输层直接分发，减少应用层解析耗时 |
| 企业官网（含资讯、客服入口） | 中等 QPS、HTTPS、简单路由（资讯 / 客服分离） | ALB | 需 HTTPS 支持与基础路由，兼顾安全性与用户体验 |
| 数据库代理（MySQL 主从分离） | TCP 协议、高并发、低延迟、连接复用 | SLB | 仅需端口转发，无需解析 SQL，追求传输层高性能 |
企业级 LB 部署配置建议
核心原则：企业级部署优先保障「高可用 + 安全性 + 性能稳定」，配置围绕 “多可用区部署、精细化安全控制、适配业务负载特性” 展开，以下覆盖阿里云、腾讯云、AWS 三大主流厂商。
一、阿里云（SLB = 负载均衡（四层）、CLB = 传统负载均衡（四层 + 七层）、ALB = 应用型负载均衡）
1. SLB（网络型，对应四层负载）
- 核心配置：
- 监听协议：TCP（游戏 / 直播）/UDP（IoT 通信），端口按业务开放（如游戏用 8080、直播用 1935）。
- 调度算法：默认加权轮询，高并发场景切换为「加权最小连接数」（适配服务器性能差异）。
- 健康检查：TCP 端口探测，间隔 5 秒、超时 3 秒、不健康阈值 3 次、健康阈值 2 次（快速剔除故障节点）。
- 高可用配置：必须跨 2 个及以上可用区部署，后端服务器分散在对应可用区（避免单点故障）。
- 安全配置：绑定安全组，仅开放业务端口（如仅允许客户端 IP 段访问）；启用「连接风暴抑制」（阈值设 1 万 / 秒，抵御突发流量）。
- 性能优化：开启「会话保持」（仅 TCP 场景，超时时间 300 秒）；开启「HTTP/2 关闭」（纯四层场景减少冗余处理）。
2. CLB（传统负载均衡）
- 核心配置：
- 监听协议：HTTP（80 端口）/HTTPS（443 端口），后端端口与应用端口一致（如 8080）。
- 调度算法：加权轮询（适合均匀负载），会话保持用「Cookie 植入」（超时 180 秒，适配 OA 系统等需登录状态的场景）。
- 健康检查：HTTP 状态码探测（目标 URL 设 “/health”，期望状态码 200），间隔 10 秒、超时 5 秒。
- 高可用配置：至少 2 台后端服务器（跨可用区更佳），开启「自动弹性伸缩」（绑定 ECS 伸缩组，负载峰值扩容）。
- 安全配置：HTTPS 场景上传 SSL 证书（推荐 RSA 2048 位），开启「HTTP 到 HTTPS 强制跳转」；配置 ACL 白名单（仅允许内部 IP 访问管理系统）。
3. ALB（应用型负载均衡）
- 核心配置：
- 监听协议：HTTPS（443 端口）/gRPC（50051 端口），开启「HTTP/2」（微服务场景必开）。
- 路由规则：按 URL 路径配置转发（如 “/api/” 转发到 API 服务器组，“/static/” 转发到 OSS/CDN）；按请求头筛选（如 “X-Device-Type: Mobile” 转发到移动端服务器）。
- 健康检查：HTTP/HTTPS 深度探测（携带请求头 “Authorization: Token”，适配需鉴权的微服务），间隔 3 秒、超时 2 秒。
- 高可用配置：跨 3 个可用区部署，后端服务器组按业务模块拆分（如支付组、商品组独立）。
- 安全配置：集成阿里云 WAF（开启 SQL 注入、XSS 防护）；启用「SSL 卸载」（ALB 终结 HTTPS，后端走 HTTP，降低服务器压力）；配置「请求限速」（单 IP 100QPS，抵御爬虫攻击）。
二、腾讯云（SLB = 负载均衡（四层）、CLB = 负载均衡（多层）、ALB = 应用型负载均衡）
1. SLB（四层网络型）
- 核心配置：监听协议 TCP/UDP，调度算法「最小连接数」（高并发场景），健康检查 TCP 端口探测（间隔 4 秒、超时 2 秒）。
- 高可用：跨可用区部署，启用「多线路接入」（公网场景，适配不同运营商用户）。
- 性能优化：开启「TCP 快速打开」（TFO），减少连接建立耗时；设置「最大连接数限制」（单实例 1 亿，按业务扩容）。
2. CLB（多层负载均衡）
- 核心配置：监听协议 HTTP/HTTPS，URL 路由仅支持简单前缀匹配（如 “/admin”），会话保持用「源 IP 绑定」（超时 360 秒）。
- 安全配置：HTTPS 绑定 SSL 证书（推荐 EV 证书，提升信任度）；配置安全组，禁止高危端口（如 22、3389）对外暴露。
- 适配场景：传统 OA、静态网站，后端服务器数量建议 2-10 台（避免过度扩容浪费资源）。
3. ALB（应用型）
- 核心配置：监听协议 HTTPS/HTTP/2/gRPC，路由规则支持「路径正则匹配」（如 “/order/[0-9]+”）、Cookie 匹配（如 “user_id=xxx” 转发到固定服务器）。
- 高级功能：启用「灰度发布」（按权重分配流量，如 10% 流量到新版本服务器）；开启「请求改写」（替换请求头 “Host” 为后端服务域名）。
- 监控配置：绑定云监控，设置告警阈值（如 QPS 超 10 万、健康检查失败率超 50% 触发短信告警）。
三、AWS（SLB=Classic Load Balancer、CLB = 无对应产品，用 ALB+NLB 替代、ALB=Application Load Balancer、NLB=Network Load Balancer）
1. NLB（对应 SLB，四层网络型）
- 核心配置：监听协议 TCP/UDP/TLS，调度算法「流量哈希」（低延迟），健康检查 TCP/UDP 探测（间隔 5 秒、超时 2 秒）。
- 高可用：跨多个可用区（至少 2 个），启用「弹性 IP 绑定」（公网场景，固定出口 IP）。
- 性能优化：支持「静态端口映射」（客户端端口与后端端口一致）；处理能力达数百万并发连接，无带宽限制。
2. ALB（应用型，对应阿里云 ALB / 腾讯云 ALB）
- 核心配置：监听协议 HTTP/HTTPS，支持「路径基于变量的路由」（如 “/users/{id}”）、「主机头路由」（多域名共享一个 ALB）。
- 安全配置：集成 AWS WAF 与 Shield（DDoS 防护）；启用「HTTPS 双向认证」（金融场景，验证客户端证书）。
- 微服务适配：支持 ECS/Fargate/K8s 后端，配置「目标组」（按服务拆分，如订单服务目标组、用户服务目标组）。
3. Classic Load Balancer（对应 CLB，传统负载）
- 核心配置：监听协议 HTTP/HTTPS/TCP，仅支持基础轮询 / 最小连接数调度，会话保持用「粘性 Cookie」。
- 适用场景：老旧 EC2 实例部署的单体应用，不推荐新业务使用（功能有限，性能弱于 ALB/NLB）。
四、企业级部署通用注意事项
- 避免单点故障：LB 与后端服务器均需跨可用区部署，核心业务至少冗余 2 台 LB（按云厂商 “负载均衡集群” 功能配置）。
- 监控告警：必监控指标 ——QPS、并发连接数、健康检查失败率、响应延迟（阈值按业务设定，如延迟超 500ms 告警）。
- 容量规划：按 “峰值流量 ×1.5 倍” 预留 LB 性能（如预估峰值 10 万 QPS，选择支持 20 万 QPS 的实例规格）。
- 配置备份：定期导出 LB 配置（云厂商控制台支持），避免误操作导致配置丢失。
