先把概念讲清楚：负载均衡到底是什么
负载均衡，看起来像个“中间人”把请求分给后端服务器，但真正有价值的是它解决的三件事：
- 可用性：某台机器挂了，流量能自动切到健康节点。
- 性能：请求分布让单台机器不会过载，从而保证延迟。
- 扩展性：在流量增长时，可以水平扩容而不是被单点瓶颈卡住。
快连类服务的分层架构（拆解思路）
把负载均衡想成几层筛网，各层有不同职责：
- 全球入口层：Anycast + DNS/GSLB，负责把用户快速引导到最近/最优的区域节点。
- 边缘/区域层：反向代理（Nginx/Envoy等）做SSL终止、缓存、静态加速与基本路由。
- 骨干/L4层：高性能的LVS或云厂商的网络负载均衡器，处理大量短连接与五元组转发。
- 应用/L7层：HAProxy、Envoy或应用网关做细粒度路由、A/B、灰度、会话保持。
- 服务内部：服务发现、Sidecar或Service Mesh管理服务间流量与断路器。
为什么要分层？
分层让每一层专注一件事，便于扩展与故障隔离。比如DNS层应对出口级别的区域故障；L4负责吞吐；L7负责业务感知的路由决策。
常见调度算法与适用场景
理解算法的本质，才能选到正确的策略：
- 轮询（Round Robin）：简单且均衡，适用于性能相近的后端。
- 最少连接（Least Connections）：适合连接时长差异大的场景。
- 权重（Weighted）：对能力差异大的服务器做流量倾斜。
- IP Hash / Session Stickiness：保证会话命中，适合有状态会话或无共享会话存储的系统。
- 基于速率或延迟的智能调度：结合实时指标做流量分配（更复杂但更准确）。
健康检查与熔断：保证“坏节点不接流量”
不只是ICMP探活，更要业务主动探测：
- 被动健康检查：观察请求失败率、响应时间，一旦异常产生自动剔除。
- 主动健康检查：请求 /health、连接握手或数据库简单查询，确认应用状态。
- 熔断与重试策略：快速失败能保护后端，回退策略与指数退避能平滑恢复流量。
SSL终止与性能优化
在边缘终止SSL能减轻后端负担，但要注意密钥管理与前向安全：
- 使用硬件加速或专门的TLS终端（如边缘代理）以降低CPU消耗。
- 启用TLS 1.3/OCSP stapling、合理的证书轮换策略。
- 如果需要端到端加密，采用双层加密：边缘终止后与后端再建立内网TLS。
全球与区域调度：Anycast、GSLB 与 GeoDNS 的比较
| 方案 | 优点 | 缺点 | 典型用途 |
| Anycast | 路由级最近节点，用户感知延迟低 | 故障隔离较困难，调度粒度有限 | CDN、DNS、边缘代理入口 |
| GSLB / GeoDNS | 基于地理或实时指标做智能调度 | 受DNS缓存影响，切换不是实时的 | 跨地域流量分配、灾备切换 |
| 主动健康+控制面 | 切换精度高，可结合业务指标 | 实现复杂，依赖监控与控制平面 | 对SLA敏感的金融、电商业务 |
会话保持（Sticky Session）要不要开？
很多人纠结这个问题。原则上：无状态最好，若业务无法避免（例如老旧的应用服务器），使用粘性会话，辅以会话复制或集中会话存储（Redis），并设计回滚策略和灰度切换避免粘性带来的单点瓶颈。
观测与告警：哪些指标最重要
- 吞吐量（TPS/连接数）：衡量流量级别和并发能力。
- 错误率（4xx/5xx）：快速定位应用或网络问题。
- 响应时间分位数（P50/P95/P99）：用户体验的直接量化。
- 后端健康分布：节点被剔除/恢复的频率。
- 资源利用率：CPU、内存、网络带宽与队列长度。
告警与自动化动作示例
- 当P95延迟持续上升且错误率>1%，触发流量降级或自动扩容。
- 后端单节点错误率短期飙升，自动从负载池中剔除并通知运维。
- 入口层流量异常（突增或瞬时连接暴涨），启动速率限制与WAF策略。
常见故障场景与应对策略
列举几种实操中常见的坑：
- DNS缓存导致切换延迟：通过较短TTL和主动控制面配合减少影响。
- 健康检查盲区：只做端口探活容易被误判，补充业务探针。
- 会话粘滞导致热点：对热点用户做流量分散或迁移。
- 链路抖动或BGP收敛慢：用Anycast+多通路备份降低单链路风险。
快连类实现中的技术栈示例（行业常见）
下面是一个典型的组合，便于理解每一层可能用到的开源或商用组件：
- 全球入口：BGP Anycast + GSLB
- 边缘代理：Nginx、Envoy、Caddy
- L4负载：LVS、云厂商BLB/SLB
- L7调度：HAProxy、Envoy、Traefik
- 服务发现/控制面：Consul、Kubernetes API、Istio
- 监控：Prometheus + Grafana、ELK、Tracing（Jaeger/Zipkin）
调优小贴士（给运维和开发的可执行清单）
- 使用多级健康检查：端口→HTTP→业务探针。
- 针对不同流量类型配置不同的超时与连接池（短链接与长连接分开）。
- 设置合理的权重并周期性基于监控自动调整。
- 为关键接口设置灰度和回滚流程，避免一次发布影响全量流量。
- 常态化做故障演练（Chaos Engineering）以验证切换与扩容策略。
安全与抗DDoS策略
边界保护是必须的：
- 速率限制与连接限制：在L4和L7双层限速。
- 流量清洗或第三方清洗服务：用于大规模流量攻击时防护。
- WAF与行为分析：拦截异常请求模式与业务滥用。
- 黑白名单与地理限制：遇到明显攻击来源可以快速封锁。
实践案例（思路，不是公司内部机密）
假设某次促销导致流量暴涨，典型的应对流程会是：
- 入口Anycast将流量导入最近节点，GSLB按健康分配流量。
- 边缘代理缓存率提高，静态与API路由被区分，非关键请求被限流或返回降级页面。
- L4层将大量短连接高效分发，L7层按权重把会话导向预热的实例池。
- 监控触发自动扩容脚本，新实例加入时通过健康探针和流量预热逐步接流。
- 事故窗口结束后，按灰度策略逐步回收实例并验证无回滚问题。
评估与选型：怎么决定用哪种策略
问自己几个问题：
- 业务是全局分布还是单区为主？（决定是否需要Anycast/GSLB）
- 是否能做到无状态？（能则尽量避免粘滞）
- 对延迟的敏感度如何？（决定L4优先或L7智能调度）
- 运维能力与预算如何？（自建复杂控制面成本高，云托管更方便但受限）
最后一点，实践中的心理模型
把负载均衡看成“流量的经济学与风险管理”：每一次路由决策都有成本（延迟、资源占用）和风险（单点故障、切换抖动）。设计时要平衡短期响应与长期可运维性。别追求完美架构而忘了可观测性和可重复的应急流程。
我刚把这些写下来，想到这里还会修两句：很多细节会跟你所在的云厂商、网络拓扑、以及业务特性深度相关，所以把监控和演练放在首位，慢慢把架构从“能用”变成“稳用”。