负载均衡需嵌入整体架构并匹配业务特征，企业级接入须统筹协议层、部署位、健康闭环与故障隔离；DNS层适跨地域调度但切换慢，L4层基于IP+端口转发且延迟低。
负载均衡不是加一台设备或配一个IP就完事，关键在于它如何嵌入你的整体架构、匹配业务流量特征、并随系统演进持续调优。真正落地的企业级接入，要同时考虑协议层级、部署位置、健康反馈闭环和故障隔离边界。
明确负载均衡在你架构中的层级定位
现代系统普遍采用多层负载分发，每一层解决不同问题：
- DNS层（全局）：适合跨地域调度，比如把北京用户导到华北节点、广州用户导到华南节点；但受DNS缓存影响，故障切换慢（通常5–30分钟），不适合秒级容灾。
- L4层（传输层）：如LVS、阿里云NLB、HAProxy TCP模式，基于IP+端口转发，延迟低（
- L7层（应用层）：如Nginx、ALB、HAProxy HTTP模式，能解析URL、Header、Cookie，支持灰度发布、AB测试、会话保持、重写与重定向；但引入解析开销，单实例QPS通常在数万量级。
典型组合是：DNS → NLB（抗压/容灾）→ ALB/Nginx（路由/鉴权）→ 后端服务。不要用L7扛全部流量，也不要用L4做路径路由。
选型必须匹配你的协议与扩展需求
协议类型决定产品边界，盲目套用会导致功能缺失或性能浪费：
- 只跑HTTP/HTTPS/gRPC？优先选应用型负载均衡（ALB）：支持域名/路径转发、WAF联动、自动证书管理、请求头透传，运维成本最低。
- 有大量TCP长连接（如IM、IoT心跳）、UDP流媒体或需要微秒级延迟？必须用网络型负载均衡（NLB）：不终止连接，直接转发，支持固定EIP和源IP透传。
- 还在用传统CLB或自建LVS+Nginx组合？注意CLB已停止新购，LVS维护门槛高，建议评估迁移至ALB/NLB双栈架构，保留四层能力的同时获得七层灵活性。
健康检查不是“开着就行”，而是策略闭环
健康检查失效是线上故障高频原因——配置了不代表有效，有效也不代表及时。
- HTTP类服务，检查路径别只写/，应设为/health或/actuator/health，返回码严格校验2xx/3xx，禁用302跳转干扰判断。
- 超时时间要小于后端服务自身超时设置，例如后端超时设为3s，健康检查timeout建议≤1.5s，否则可能漏判卡死进程。
- 连续失败次数建议设为3次，间隔设为5–10秒；太敏感易误剔，太迟钝则故障扩散。
- 务必开启健康检查日志并接入SLS/ES，当某台机器反复进出健康池时，可快速关联排查是网络抖动、应用GC还是资源争抢。
安全与可观测性必须从接入第一天就设计进去
负载均衡是流量入口，也是第一道防线和核心观测点：
- 所有公网SLB/ALB必须绑定WAF或开启CC防护，至少配置基础规则（如单IP QPS限流、恶意User-Agent拦截）。
- 开启访问日志，并投递至日志服务；关键字段如client_ip、upstream_addr、request_time、status、upstream_response_time必须保留，用于分析慢请求、异常分布和攻击溯源。
- 监控指标不能只看“QPS”和“错误率”，要关注后端连接复用率、健康节点比例、5xx上升拐点、SSL握手失败率——这些才是真实瓶颈信号。
- 配置变更必须走灰度：先切1%流量，观察5分钟无异常再逐步放大；ALB支持按权重、Header或Cookie灰度，比改DNS或重启Nginx更可控。
