负载均衡与高可用LVS Nginx Sentinel 三层防护架构问题场景流量上来单机扛不住→加 Nginx→Nginx 成瓶颈→加 LVS→某服务挂了拖垮整个调用链→需要熔断。负载均衡三层架构——LVS 四层转发→Nginx 七层路由→Sentinel 应用层熔断少一层流量就从哪里把你压垮。30秒速览LVS 四层IP端口转发极快不能按 URL 路由→ Nginx 七层看 URL/Header/Cookie 按路径分流性能低于 LVS→ Sentinel 熔断慢调用比例/异常比例/异常数三种策略滑动窗口防边界重置。双活数据中心——两地三中心流量按比例切流数据实时同步。系列第 13 篇共 172 篇。一、四层负载均衡与七层负载均衡维度四层L4传输层七层L7应用层工作层级TCP/UDP仅解析 IP 地址与端口号HTTP/HTTPS可解析 URL、Header、Cookie性能高不解析应用层数据纯转发较低需完整解析 HTTP 协议功能简单转发、NAT 地址转换按 URL 路由分发、会话保持、缓存、限流、SSL 卸载代表性方案F5硬件、LVS、Nginx stream 模块Nginx http 模块、HAProxy类比快递总站——根据包裹上的城市标签分拣根据包裹内的物品清单决定处理方式常见负载均衡算法算法原理适用场景轮询Round Robin按顺序依次分发后端服务器性能均匀加权轮询Weighted RR按预设权重比例分发后端服务器性能不均ip_hash对客户端 IP 哈希取模同一 IP 固定分配到同一后端需要 Session 粘滞的场景最少连接Least Connections分发到当前活跃连接数最少的后端长连接场景如 WebSocket最短响应时间分发到平均响应时间最快的后端性能敏感的核心接口健康检查机制TCP 检查验证后端端口是否可连接HTTP 检查返回 HTTP 200 状态码方判定为健康可配置检查路径、期望状态码、超时阈值检查间隔 超时时间 重试次数 决定故障发现延迟的三要素二、LVS Nginx 应用三层负载架构用户请求 │ ▼ ┌──────────────────────────┐ │ LVS / F5四层负载均衡 │ ← 第一层VIP 直接转发仅检查 IP:Port性能最高 │ 轮询/最小连接 │ F5 双活两个机房各分配 50% 权重故障自动剔除 └──────────────────────────┘ │ │ ▼ ▼ ┌────────┐ ┌────────┐ │ Nginx │ │ Nginx │ ← 第二层七层反向代理按 URL 路径路由至不同应用服务 │ 反向代理│ │ 反向代理│ SSL 卸载、限流、静态资源缓存 └────────┘ └────────┘ │ │ ▼ ▼ ┌──────┐ ┌──────┐ │ App │ │ App │ ← 第三层应用实例无状态化部署 └──────┘ └──────┘分层设计的依据L4 性能高但功能弱——仅能根据 IP:Port 转发不解析应用协议。L7 功能强但性能较低——需完整解析 HTTP 协议后才能执行 URL 路由和 Header 处理。三层架构将 L4 部署于最前端拦截第一波流量纯转发、低延迟L7 在第二层按需进行协议级处理URL 路由、SSL 终止各层职责明确运维解耦。LVS 三种工作模式模式原理优缺点适用NAT网络地址转换Director 同时修改请求/响应报文的源目 IP简单但 Director 是瓶颈所有流量双向经过小规模Director 性能足够的场景DR直接路由Director 只改请求帧的目标 MACReal Server 直接回客户端性能最高Director 只处理入站Real Server 出站直连但要求 Director 和 Real Server 在同一物理网段高性能场景最常用TUNIP 隧道Director 在原始 IP 报文外封装一层 IP 头Real Server 解封后直接回客户端支持跨网段Real Server 可分布在不同机房但 IP 隧道封装有额外开销跨机房部署KeepalivedVRRP 协议与 VIP 漂移LVS 本身只做负载均衡不能解决 Director 单点故障。Keepalived 通过 VRRP虚拟路由器冗余协议实现高可用正常状态 Director AMaster—— 持有 VIP 192.168.1.100 Director BBackup —— 监听 A 的心跳组播 224.0.0.18 故障切换 A 宕机或心跳超时默认 3 秒 × 3 次 9 秒 → B 检测到 Master 消失 → 发送 VRRP 通告优先级更高 → B 接管 VIP → 切换为 Master → ARP 广播通知交换机更新 MAC 地址表 恢复后 A 恢复 → 检测到已有 MasterB→ 以 Backup 身份加入 是否抢占取决于 nopreempt 配置关键参数router_idVRRP 路由器标识同一组 Keepalived 必须相同priority优先级0-255高者成为 Masteradvert_int心跳间隔秒默认 1 秒nopreempt禁止抢占避免频繁切换upstream 健康检查upstream backend { server 192.168.1.10:8080 max_fails3 fail_timeout30s; server 192.168.1.11:8080 max_fails3 fail_timeout30s; server 192.168.1.12:8080 backup; # 仅当其他节点全部不可用时启用 }max_failsfail_timeout 时间内最大失败次数超限后标记为 downfail_timeout统计窗口 故障恢复等待时间backup热备节点正常时不参与流量down手动下线运维标记被动检查 vs 主动检查upstream 默认使用被动检查根据请求失败判断Nginx Plus 支持主动健康检查定期发送探测请求在用户流量到达前发现问题。Nginx 反向代理完整配置# /etc/nginx/nginx.conf upstream app_backend { # 负载均衡算法默认轮询 # least_conn; # 最小连接数 # ip_hash; # IP 哈希会话保持 server 192.168.1.10:8080 weight3 max_fails3 fail_timeout30s; server 192.168.1.11:8080 weight2 max_fails3 fail_timeout30s; server 192.168.1.12:8080 backup; # 热备仅其他节点全部不可用时启用 keepalive 32; # 长连接池大小减少握手开销 } server { listen 443 ssl http2; server_name api.example.com; # SSL 终止——Nginx 解密后以 HTTP 转发到后端 ssl_certificate /etc/nginx/certs/api.example.com.pem; ssl_certificate_key /etc/nginx/certs/api.example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; # 限流——请求速率限制 limit_req_zone $binary_remote_addr zoneapi_limit:10m rate100r/s; limit_req zoneapi_limit burst200 nodelay; # 静态资源——Nginx 直接返回不穿透到后端 location /static/ { root /var/www; expires 30d; add_header Cache-Control public, immutable; } # API 路由——反向代理到应用集群 location /api/ { proxy_pass http://app_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 超时与重试 proxy_connect_timeout 5s; proxy_read_timeout 30s; proxy_next_upstream error timeout http_502 http_503; proxy_next_upstream_tries 2; } }关键参数解读weight加权轮询的权重——生产环境用于滚动发布时临时降低某台权重keepaliveNginx 与后端的长连接池——减少 TCP 握手开销高并发下 QPS 提升 30%proxy_next_upstreamproxy_next_upstream_tries请求失败后自动重试下一台后端——仅在幂等接口GET/PUT/DELETE上开启limit_reqburst200 nodelay 正常 QPS 100突发允许 200 个排队超过立即 503会话保持Session Stickiness的场景选择方案原理适用缺点ip_hash客户端 IP 哈希固定路由到同一后端中小规模、无 NAT 网关公司出口统一 IP→负载严重不均sticky cookieNginx Plus 向下游 Set-Cookie后续请求按 cookie 路由大规模、多级代理Nginx Plus 付费功能无状态化推荐将会话数据外置到 Redis后端实例完全无状态所有场景需要 Redis 高可用Token 路由网关在 Header 中植入路由标记API 网关层统一管理增加网关复杂度首选无状态化——将 Session 数据存入共享 Redis任一后端实例挂掉后流量切换到其他实例时无状态丢失。ip_hash是解决不了无状态化时的妥协方案不是首选。三、双活架构与主备架构维度主备Active-Standby双活Active-Active流量分布一台处理全部流量另一台空闲等待两台或多台同时承载流量故障切换时间几十秒到几分钟需 DNS 切换或 VIP 漂移F5 层面秒级健康检查探测到故障后自动摘除资源利用率约 50%备用节点空闲接近 100%全部节点参与服务复杂度低高数据同步、缓存一致性、跨机房延迟双活架构的四层设计要点两机房服务完全等价应用配置、数据库连接串、消息中间件 Topic、路由地址均保持一致确保任一机房可独立承接全部流量F5 按权重分发各机房初始 50%健康检查间隔 5-10 秒 重试 N 次判定故障后自动摘除该机房数据库策略机房内部读写分离跨机房主备同步数据单向复制Redis 策略各机房部署独立实例不走跨机房主从复制网络延迟过高导致复制不可靠。缓存丢失场景通过消息广播触发重同步关键工程认知双活的目标是一个机房故障后用户无感知切换而非两机房数据实时强一致。前者是可用性设计后者是一致性设计——两者存在根本性冲突四、熔断器 Sentinel防止级联故障熔断机制的必要性服务A → 服务B → 服务C └── 服务C 故障响应超时 服务A 持续调用 B → A 的工作线程全部阻塞等待 B 的响应 → A 的线程池队列占满 → A 的调用方网关也超时 → 故障以多米诺骨牌效应逐级向上扩散 → 整个系统瘫痪Sentinel 三级防护体系级别机制判定逻辑慢调用比例慢调用比例熔断响应耗时超过阈值的请求占比超出设定比例 → 触发熔断异常比例/异常数异常比例熔断异常率或单位时间异常数超过阈值 → 触发熔断流量控制QPS 限流每秒请求数超过阈值 → 直接拒绝不进入调用链核心算法滑动窗口固定时间窗口如 0s-1s 和 1s-2s在两个窗口边界处存在统计盲区——边界附近的请求可被双倍放行。滑动窗口将时间窗口切分为 N 个格子窗口向前滑动时丢弃最旧格子的数据、纳入最新格子的数据统计精度不受窗口边界影响。滑动窗口示例假设 1 秒窗口分为 2 个格子各 500ms当前时间为 t1250ms格子数组[G0(0~500ms), G1(500~1000ms), G2(1000~1500ms)] 当前窗口 G1 G2最近 1 秒内的两个格子 t1501ms 时窗口滑动 → 丢弃 G1纳入 G3(1500~2000ms) 当前窗口 G2 G3每个格子的统计数据在格子的 500ms 时间片内持续累积窗口滑动时一次性丢弃最旧格子的全部数据。Sentinel 的滑动窗口实现默认将 1 秒统计窗口分为 2 个格子各 500ms每 500ms 窗口滑动一次。通过LeapArray数据结构维护格子数组CAS 无锁更新当前格子的统计值调用量、异常量、响应时间。三种降级策略返回默认值如用户会员等级查询熔断后返回普通用户保障核心业务流程不被阻断返回缓存数据返回 Redis 中预存的最近一次成功响应数据作为兜底降级为简化逻辑如个性化推荐模块熔断后前端隐藏推荐栏仅展示通用内容“熔断器的核心能力 快速失败避免线程阻塞等待 优雅降级保障核心业务流程可用 半开恢复探测下游恢复后自动恢复调用。关键不在’如何熔断’而在’降级后用户体验损失的最小化’——这是技术方案与产品体验的交叉决策点。”核心要点回顾L4 与 L7 的职责划分是负载均衡的核心设计考量L4 工作在 TCP/UDP 层仅解析 IP 地址和端口号性能高但功能受限LVS DR 模式下 Director 仅修改目标 MACReal Server 出站直连客户端性能最高L7 工作在 HTTP 层可解析 URL/Header/Cookie按路径路由分发、SSL 卸载、会话保持功能强但性能较低。三层架构的分工是 L4LVS/F5在最前端以纯转发拦截第一波流量、L7Nginx/HAProxy在第二层按需进行协议级处理、应用层实现无状态化水平扩展。双活架构与主备架构的核心差异在于资源利用率和故障切换时间——双活两机房同时承载流量F5 按权重分发故障切换在 F5 层面秒级完成但核心挑战不在流量调度而在数据一致性数据库跨机房主备同步、Redis 各机房独立部署不走跨机房主从复制、跨机房延迟的业务容忍度。熔断器的核心机制是滑动窗口实时统计请求指标Sentinel 默认 1 秒窗口切为 2 个 500ms 格子LeapArray 数据结构维护格子数组CAS 无锁更新达到阈值后触发熔断快速失败通过半开状态探测下游恢复后自动恢复调用。三种降级策略按场景选择返回默认值保障核心业务流程不被阻断、返回缓存数据Redis 中预存的最近一次成功响应、降级为简化逻辑非核心功能隐藏或简化。核心能力不在如何熔断而在降级后用户体验损失的最小化。高可用铁律任何一层禁止出现单点——负载均衡器VRRP VIP 漂移、应用服务器多实例无状态化、数据库主从故障切换、缓存哨兵/Cluster均需冗余部署。上一篇《计算机网络基础》 |下一篇《容器与K8s核心知识》系列专栏《Java 后端核心知识图谱》Java专栏聊聊你的经历你们公司几层负载均衡从外到内 LVS→Nginx→Gateway→Sentinel——最外层用什么遇到过某一层成为瓶颈的情况吗如果这张三层架构图帮你下次扩容时不再漏掉某一层欢迎收藏点赞
负载均衡与高可用LVS Nginx Sentinel 三层防护架构问题场景流量上来单机扛不住→加 Nginx→Nginx 成瓶颈→加 LVS→某服务挂了拖垮整个调用链→需要熔断。负载均衡三层架构——LVS 四层转发→Nginx 七层路由→Sentinel 应用层熔断少一层流量就从哪里把你压垮。30秒速览LVS 四层IP端口转发极快不能按 URL 路由→ Nginx 七层看 URL/Header/Cookie 按路径分流性能低于 LVS→ Sentinel 熔断慢调用比例/异常比例/异常数三种策略滑动窗口防边界重置。双活数据中心——两地三中心流量按比例切流数据实时同步。系列第 13 篇共 172 篇。一、四层负载均衡与七层负载均衡维度四层L4传输层七层L7应用层工作层级TCP/UDP仅解析 IP 地址与端口号HTTP/HTTPS可解析 URL、Header、Cookie性能高不解析应用层数据纯转发较低需完整解析 HTTP 协议功能简单转发、NAT 地址转换按 URL 路由分发、会话保持、缓存、限流、SSL 卸载代表性方案F5硬件、LVS、Nginx stream 模块Nginx http 模块、HAProxy类比快递总站——根据包裹上的城市标签分拣根据包裹内的物品清单决定处理方式常见负载均衡算法算法原理适用场景轮询Round Robin按顺序依次分发后端服务器性能均匀加权轮询Weighted RR按预设权重比例分发后端服务器性能不均ip_hash对客户端 IP 哈希取模同一 IP 固定分配到同一后端需要 Session 粘滞的场景最少连接Least Connections分发到当前活跃连接数最少的后端长连接场景如 WebSocket最短响应时间分发到平均响应时间最快的后端性能敏感的核心接口健康检查机制TCP 检查验证后端端口是否可连接HTTP 检查返回 HTTP 200 状态码方判定为健康可配置检查路径、期望状态码、超时阈值检查间隔 超时时间 重试次数 决定故障发现延迟的三要素二、LVS Nginx 应用三层负载架构用户请求 │ ▼ ┌──────────────────────────┐ │ LVS / F5四层负载均衡 │ ← 第一层VIP 直接转发仅检查 IP:Port性能最高 │ 轮询/最小连接 │ F5 双活两个机房各分配 50% 权重故障自动剔除 └──────────────────────────┘ │ │ ▼ ▼ ┌────────┐ ┌────────┐ │ Nginx │ │ Nginx │ ← 第二层七层反向代理按 URL 路径路由至不同应用服务 │ 反向代理│ │ 反向代理│ SSL 卸载、限流、静态资源缓存 └────────┘ └────────┘ │ │ ▼ ▼ ┌──────┐ ┌──────┐ │ App │ │ App │ ← 第三层应用实例无状态化部署 └──────┘ └──────┘分层设计的依据L4 性能高但功能弱——仅能根据 IP:Port 转发不解析应用协议。L7 功能强但性能较低——需完整解析 HTTP 协议后才能执行 URL 路由和 Header 处理。三层架构将 L4 部署于最前端拦截第一波流量纯转发、低延迟L7 在第二层按需进行协议级处理URL 路由、SSL 终止各层职责明确运维解耦。LVS 三种工作模式模式原理优缺点适用NAT网络地址转换Director 同时修改请求/响应报文的源目 IP简单但 Director 是瓶颈所有流量双向经过小规模Director 性能足够的场景DR直接路由Director 只改请求帧的目标 MACReal Server 直接回客户端性能最高Director 只处理入站Real Server 出站直连但要求 Director 和 Real Server 在同一物理网段高性能场景最常用TUNIP 隧道Director 在原始 IP 报文外封装一层 IP 头Real Server 解封后直接回客户端支持跨网段Real Server 可分布在不同机房但 IP 隧道封装有额外开销跨机房部署KeepalivedVRRP 协议与 VIP 漂移LVS 本身只做负载均衡不能解决 Director 单点故障。Keepalived 通过 VRRP虚拟路由器冗余协议实现高可用正常状态 Director AMaster—— 持有 VIP 192.168.1.100 Director BBackup —— 监听 A 的心跳组播 224.0.0.18 故障切换 A 宕机或心跳超时默认 3 秒 × 3 次 9 秒 → B 检测到 Master 消失 → 发送 VRRP 通告优先级更高 → B 接管 VIP → 切换为 Master → ARP 广播通知交换机更新 MAC 地址表 恢复后 A 恢复 → 检测到已有 MasterB→ 以 Backup 身份加入 是否抢占取决于 nopreempt 配置关键参数router_idVRRP 路由器标识同一组 Keepalived 必须相同priority优先级0-255高者成为 Masteradvert_int心跳间隔秒默认 1 秒nopreempt禁止抢占避免频繁切换upstream 健康检查upstream backend { server 192.168.1.10:8080 max_fails3 fail_timeout30s; server 192.168.1.11:8080 max_fails3 fail_timeout30s; server 192.168.1.12:8080 backup; # 仅当其他节点全部不可用时启用 }max_failsfail_timeout 时间内最大失败次数超限后标记为 downfail_timeout统计窗口 故障恢复等待时间backup热备节点正常时不参与流量down手动下线运维标记被动检查 vs 主动检查upstream 默认使用被动检查根据请求失败判断Nginx Plus 支持主动健康检查定期发送探测请求在用户流量到达前发现问题。Nginx 反向代理完整配置# /etc/nginx/nginx.conf upstream app_backend { # 负载均衡算法默认轮询 # least_conn; # 最小连接数 # ip_hash; # IP 哈希会话保持 server 192.168.1.10:8080 weight3 max_fails3 fail_timeout30s; server 192.168.1.11:8080 weight2 max_fails3 fail_timeout30s; server 192.168.1.12:8080 backup; # 热备仅其他节点全部不可用时启用 keepalive 32; # 长连接池大小减少握手开销 } server { listen 443 ssl http2; server_name api.example.com; # SSL 终止——Nginx 解密后以 HTTP 转发到后端 ssl_certificate /etc/nginx/certs/api.example.com.pem; ssl_certificate_key /etc/nginx/certs/api.example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; # 限流——请求速率限制 limit_req_zone $binary_remote_addr zoneapi_limit:10m rate100r/s; limit_req zoneapi_limit burst200 nodelay; # 静态资源——Nginx 直接返回不穿透到后端 location /static/ { root /var/www; expires 30d; add_header Cache-Control public, immutable; } # API 路由——反向代理到应用集群 location /api/ { proxy_pass http://app_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 超时与重试 proxy_connect_timeout 5s; proxy_read_timeout 30s; proxy_next_upstream error timeout http_502 http_503; proxy_next_upstream_tries 2; } }关键参数解读weight加权轮询的权重——生产环境用于滚动发布时临时降低某台权重keepaliveNginx 与后端的长连接池——减少 TCP 握手开销高并发下 QPS 提升 30%proxy_next_upstreamproxy_next_upstream_tries请求失败后自动重试下一台后端——仅在幂等接口GET/PUT/DELETE上开启limit_reqburst200 nodelay 正常 QPS 100突发允许 200 个排队超过立即 503会话保持Session Stickiness的场景选择方案原理适用缺点ip_hash客户端 IP 哈希固定路由到同一后端中小规模、无 NAT 网关公司出口统一 IP→负载严重不均sticky cookieNginx Plus 向下游 Set-Cookie后续请求按 cookie 路由大规模、多级代理Nginx Plus 付费功能无状态化推荐将会话数据外置到 Redis后端实例完全无状态所有场景需要 Redis 高可用Token 路由网关在 Header 中植入路由标记API 网关层统一管理增加网关复杂度首选无状态化——将 Session 数据存入共享 Redis任一后端实例挂掉后流量切换到其他实例时无状态丢失。ip_hash是解决不了无状态化时的妥协方案不是首选。三、双活架构与主备架构维度主备Active-Standby双活Active-Active流量分布一台处理全部流量另一台空闲等待两台或多台同时承载流量故障切换时间几十秒到几分钟需 DNS 切换或 VIP 漂移F5 层面秒级健康检查探测到故障后自动摘除资源利用率约 50%备用节点空闲接近 100%全部节点参与服务复杂度低高数据同步、缓存一致性、跨机房延迟双活架构的四层设计要点两机房服务完全等价应用配置、数据库连接串、消息中间件 Topic、路由地址均保持一致确保任一机房可独立承接全部流量F5 按权重分发各机房初始 50%健康检查间隔 5-10 秒 重试 N 次判定故障后自动摘除该机房数据库策略机房内部读写分离跨机房主备同步数据单向复制Redis 策略各机房部署独立实例不走跨机房主从复制网络延迟过高导致复制不可靠。缓存丢失场景通过消息广播触发重同步关键工程认知双活的目标是一个机房故障后用户无感知切换而非两机房数据实时强一致。前者是可用性设计后者是一致性设计——两者存在根本性冲突四、熔断器 Sentinel防止级联故障熔断机制的必要性服务A → 服务B → 服务C └── 服务C 故障响应超时 服务A 持续调用 B → A 的工作线程全部阻塞等待 B 的响应 → A 的线程池队列占满 → A 的调用方网关也超时 → 故障以多米诺骨牌效应逐级向上扩散 → 整个系统瘫痪Sentinel 三级防护体系级别机制判定逻辑慢调用比例慢调用比例熔断响应耗时超过阈值的请求占比超出设定比例 → 触发熔断异常比例/异常数异常比例熔断异常率或单位时间异常数超过阈值 → 触发熔断流量控制QPS 限流每秒请求数超过阈值 → 直接拒绝不进入调用链核心算法滑动窗口固定时间窗口如 0s-1s 和 1s-2s在两个窗口边界处存在统计盲区——边界附近的请求可被双倍放行。滑动窗口将时间窗口切分为 N 个格子窗口向前滑动时丢弃最旧格子的数据、纳入最新格子的数据统计精度不受窗口边界影响。滑动窗口示例假设 1 秒窗口分为 2 个格子各 500ms当前时间为 t1250ms格子数组[G0(0~500ms), G1(500~1000ms), G2(1000~1500ms)] 当前窗口 G1 G2最近 1 秒内的两个格子 t1501ms 时窗口滑动 → 丢弃 G1纳入 G3(1500~2000ms) 当前窗口 G2 G3每个格子的统计数据在格子的 500ms 时间片内持续累积窗口滑动时一次性丢弃最旧格子的全部数据。Sentinel 的滑动窗口实现默认将 1 秒统计窗口分为 2 个格子各 500ms每 500ms 窗口滑动一次。通过LeapArray数据结构维护格子数组CAS 无锁更新当前格子的统计值调用量、异常量、响应时间。三种降级策略返回默认值如用户会员等级查询熔断后返回普通用户保障核心业务流程不被阻断返回缓存数据返回 Redis 中预存的最近一次成功响应数据作为兜底降级为简化逻辑如个性化推荐模块熔断后前端隐藏推荐栏仅展示通用内容“熔断器的核心能力 快速失败避免线程阻塞等待 优雅降级保障核心业务流程可用 半开恢复探测下游恢复后自动恢复调用。关键不在’如何熔断’而在’降级后用户体验损失的最小化’——这是技术方案与产品体验的交叉决策点。”核心要点回顾L4 与 L7 的职责划分是负载均衡的核心设计考量L4 工作在 TCP/UDP 层仅解析 IP 地址和端口号性能高但功能受限LVS DR 模式下 Director 仅修改目标 MACReal Server 出站直连客户端性能最高L7 工作在 HTTP 层可解析 URL/Header/Cookie按路径路由分发、SSL 卸载、会话保持功能强但性能较低。三层架构的分工是 L4LVS/F5在最前端以纯转发拦截第一波流量、L7Nginx/HAProxy在第二层按需进行协议级处理、应用层实现无状态化水平扩展。双活架构与主备架构的核心差异在于资源利用率和故障切换时间——双活两机房同时承载流量F5 按权重分发故障切换在 F5 层面秒级完成但核心挑战不在流量调度而在数据一致性数据库跨机房主备同步、Redis 各机房独立部署不走跨机房主从复制、跨机房延迟的业务容忍度。熔断器的核心机制是滑动窗口实时统计请求指标Sentinel 默认 1 秒窗口切为 2 个 500ms 格子LeapArray 数据结构维护格子数组CAS 无锁更新达到阈值后触发熔断快速失败通过半开状态探测下游恢复后自动恢复调用。三种降级策略按场景选择返回默认值保障核心业务流程不被阻断、返回缓存数据Redis 中预存的最近一次成功响应、降级为简化逻辑非核心功能隐藏或简化。核心能力不在如何熔断而在降级后用户体验损失的最小化。高可用铁律任何一层禁止出现单点——负载均衡器VRRP VIP 漂移、应用服务器多实例无状态化、数据库主从故障切换、缓存哨兵/Cluster均需冗余部署。上一篇《计算机网络基础》 |下一篇《容器与K8s核心知识》系列专栏《Java 后端核心知识图谱》Java专栏聊聊你的经历你们公司几层负载均衡从外到内 LVS→Nginx→Gateway→Sentinel——最外层用什么遇到过某一层成为瓶颈的情况吗如果这张三层架构图帮你下次扩容时不再漏掉某一层欢迎收藏点赞
