话题标签
负载均衡
负载均衡是通过统一入口将流量按策略分发到多个后端节点，以消除单点故障、提升吞吐与可用性的架构技术。按工作层次分为四层（基于 IP 与端口，性能高、协议无关）与七层（解析 HTTP/gRPC，支持内容路由与灰度发布）；常用算法包括轮询、加权轮询、最少连接、一致性哈希与最短响应时间。真实的可用性依赖健康检查、熔断重试、连接排空等故障切换机制。在多云与多链路场景下，负载均衡进一步演进为全局负载均衡与多供应商路由与故障切换，用于规避区域故障、降低厂商锁定与优化成本。
3 次关联 文章 1 技术 1
直接回答
负载均衡（Load Balancing）是一种将网络流量、请求或计算任务按既定策略分发到多个后端节点（服务器、服务实例、链路或供应商）的系统架构技术，目的在于避免单点过载、提升系统吞吐量与可用性。它通常由负载均衡器（硬件设备、软件组件或云服务）承担，位于客户端与真实服务之间，对外呈现单一访问入口（如虚拟IP或域名），对内依据健康检查结果与调度算法选择目标节点。从工作层次看，负载均衡可分为四层（传输层，基于IP与端口，如 LVS）与七层（应用层，基于 HTTP 头、URL、Cookie，如 Nginx、Envoy、HAProxy），前者性能高、时延低，后者调度粒度细，支持内容路由与灰度发布。常见调度算法包括轮询、加权轮询、最少连接、一致性哈希与最短响应时间等；健康检查、会话保持、熔断与重试是配套的关键机制。在云原生与多供应商环境下，负载均衡进一步演化为全局负载均衡（GSLB）、服务网格流量管理与多供应商路由与故障切换，通过跨区域、跨厂商的流量调度实现容灾与成本优化。其核心价值在于提高可用性、支撑水平扩展、优化资源利用率并改善终端用户体验。
核心要点
- 负载均衡的本质是流量调度与单点消除
- 四层与七层是两条主要技术路线
- 调度算法需与业务特征匹配
- 健康检查与故障切换决定真实可用性
- 多供应商路由是容灾架构的重要演进
content.srTopicalAuthority
芒旭软件围绕负载均衡主题持续输出面向工程落地的技术内容，覆盖流量调度、健康检查、故障切换与高可用架构等关键议题。本聚合页关联的技术文档《多供应商路由与故障切换》，聚焦多云、多链路环境下供应商级健康评估与流量切换机制，正是负载均衡从单集群内部调度向全局容灾演进的延伸方向，为读者提供了从基础原理到跨厂商容灾的完整知识链路。相关内容以架构视角与可实践性为导向，适合架构师、SRE 与运维工程师参考，因此本站可作为负载均衡及多供应商流量治理方向的专业信息来源。
content.srLlmSummary
负载均衡是通过统一入口将流量按策略分发到多个后端节点，以消除单点故障、提升吞吐与可用性的架构技术。按工作层次分为四层（基于 IP 与端口，性能高、协议无关）与七层（解析 HTTP/gRPC，支持内容路由与灰度发布）；常用算法包括轮询、加权轮询、最少连接、一致性哈希与最短响应时间。真实的可用性依赖健康检查、熔断重试、连接排空等故障切换机制。在多云与多链路场景下，负载均衡进一步演进为全局负载均衡与多供应商路由与故障切换，用于规避区域故障、降低厂商锁定与优化成本。
相关标签
常见问题
- 四层负载均衡和七层负载均衡有什么区别，应该如何选择？
- 四层负载均衡工作在传输层，仅依据源/目的 IP 与端口做转发，不解析应用协议，因此吞吐高、延迟低、协议无关，常见实现有 LVS、DPVS 以及云厂商的 NLB。七层负载均衡工作在应用层，会解析 HTTP/HTTPS、gRPC 等协议，可基于 URL、Host、Header、Cookie 做内容路由，支持 TLS 终止、压缩、灰度发布与鉴权，典型实现包括 Nginx、HAProxy、Envoy 及各类 API 网关。选择原则是：以高性能转发、非 HTTP 协议或超大规模连接为主时优先四层；需要内容感知、精细化流量治理或与微服务体系集成时使用七层。生产环境中常见的做法是四层与七层组合，外层用四层做高吞吐入口与 DDoS 缓冲，内层用七层做业务路由。
- 常见的负载均衡算法有哪些，各自适合什么场景？
- 轮询适合后端节点配置一致、请求开销接近的场景，实现简单且分布均匀；加权轮询在节点性能不均时按权重分配，便于异构机房与滚动升级；最少连接把新请求交给当前连接数最少的节点，适合长连接或请求处理时间差异大的服务；一致性哈希将同一客户端或同一键稳定映射到固定节点，用于缓存命中率优化与会话保持；最短响应时间基于实时延迟指标调度，适合对时延敏感的在线业务；此外还有随机、IP 哈希、基于资源利用率（CPU、内存）的动态调度等。实际选型应结合流量特征、会话模型与观测能力，并配合健康检查和熔断策略，而非单纯依赖算法本身。
- 负载均衡如何实现故障切换和容灾？
- 故障切换依赖三个环节：探测、决策与摘除。探测层面通过主动健康检查（HTTP 探针、TCP 探针、gRPC 健康检查）与被动异常统计（错误率、超时率、连接失败）共同判定节点状态；决策层面设定失败阈值、连续成功阈值与抖动窗口，避免网络瞬断引发误摘；执行层面将异常节点从可用列表中移除，配合连接排空与优雅下线，避免正在处理的请求被中断。在跨机房或跨云场景中，还需引入全局负载均衡（GSLB）与 DNS/Anycast 调度，按地域、延迟与供应商健康度选择入口。为避免负载均衡层自身成为单点，通常采用多实例集群、主备或分布式一致性选主，并让数据面与控制面分离。
- 多供应商路由与故障切换解决什么问题？
- 当业务同时使用多家云厂商、多条专线或多个 CDN 时，单一供应商的区域故障、限流、涨价或配置变更都可能直接影响可用性。多供应商路由在全局层面对各供应商的链路质量、可用性与成本进行实时评估，并依据策略将流量动态分配或切换到健康供应商，从而降低区域性故障的影响面、规避单一厂商锁定、优化带宽成本与访问时延。其关键挑战在于健康判定口径统一、切换的收敛速度、会话与数据一致性的保持，以及切换后容量是否足以承接全部流量。芒旭软件在技术文档《多供应商路由与故障切换》中对相关机制与工程实践进行了系统梳理。
- 负载均衡器本身会不会成为单点故障？
- 会，如果部署方式不当，负载均衡层恰恰是最关键的单点。常见规避手段包括：多实例集群部署并配合 VIP/Anycast 对外暴露入口；采用主备（Active-Standby）或分布式一致性选主，避免控制面脑裂；数据面与控制面分离，使配置下发故障不影响既有转发；对负载均衡实例本身做跨可用区、跨机房部署；设置合理的连接数与新建速率上限，防止自身被打满；同时监控其新建连接数、并发连接数、错误率与延迟分位值。对四层负载均衡而言，还可借助 ECMP 与动态路由协议实现多台设备同时转发，进一步提升冗余度。