前言：
-
负载均衡的部署模式决定了负载均衡器"站在哪里、以何种身份工作"，而核心功能则定义了它"能做什么、提供什么价值"。 部署模式为功能的实现提供了网络基础和可能性，而核心功能的也反过来影响着部署模式的选择
-
该章节是负载均衡章节的第二章，主要介绍一下负载均衡的部署模式，会话保持等内容
一、 负载均衡的部署模式
部署模式主要解决网络流量如何流入和流出负载均衡器的问题，它为所有后续功能的实现划定了规定的空间
-
路由模式（网关模式） ：负载均衡器作为网络中的默认网关。所有进出服务器池的流量（请求和响应）都必须经过它。易于管理，但负载均衡器可能成为性能瓶颈
-
桥接模式（透明模式）：负载均衡器像网桥一样工作在网络中，对客户端和后端服务器"透明"（IP/MAC地址不变）。服务器响应可以直接返回给客户端，部署简单，效率提高
-
服务端直接返回模式：负载均衡器只处理入站请求的分发，后端服务器处理完毕后，直接使用自己的IP地址将响应包发回给客户端（不再经过负载均衡器）。这极大减轻了负载均衡器的压力，但要求服务器与客户端路由可达
二、 会话保持（Session Persistence）
会话保持，也称会话亲和性 ，是指负载均衡器将来自同一客户端 的一系列相关联请求，持续地定向发送到同一台后端服务器上的机制
-
为什么需要会话保持？ 解释在用户登录、购物车等有状态应用中，需要将同一用户的多次请求定向到同一台后端服务器，以保证会话信息的连续性
-
技术本质 ：在客户端（或网络流）与一台特定的后端服务器之间，建立一个临时的、稳定的映射关系，该关系在一个会话周期内持续有效
-
没有会话保持的: 如果用户A的登录请求被分发到服务器1 ，服务器1为其创建了Session。下一秒，用户A添加购物车的请求被轮询到服务器2 ，而服务器2的内存中没有 用户A的Session，系统会认为用户未登录，购物车操作失败。这会直接导致用户登录态丢失、数据混乱、操作中断
-
常见实现方式：
-
Cookie插入：负载均衡器在第一个响应中插入一个唯一Cookie，后续客户端请求会携带此Cookie，负载均衡器据此识别用户并转发
-
Cookie重写：应用服务器已经设置了Cookie，负载均衡器修改其中的服务器标识信息
-
应用层Session ID识别：七层负载均衡器可以解析HTTP请求体或Header中的Session ID进行绑定
-
三、 健康检查机制详解
负载均衡的健康检查是系统高可用性的"生命线"。它如同一套7x24小时不间断的脉搏监控仪，确保流量只会被导向真正健康的服务器
-
检查类型：
-
被动健康检查：通过观察正常请求的响应（如TCP连接失败、HTTP 5xx错误）来判断服务器状态。反应迅速，但存在漏判的情况
-
主动健康检查 ：负载均衡器主动发起探测请求到后端服务器，根据响应判断其状态。可分为：
-
TCP检查：尝试与服务器的指定端口建立TCP三次握手。成功即认为健康
-
HTTP(S) GET检查 ：发送GET请求到特定URL（如
/health），检查返回状态码和内容 -
自定义脚本检查：负载均衡器在本地或通过Agent执行一个自定义脚本。脚本可以检查系统资源（CPU、内存）、依赖服务（数据库连接）、特定文件等，并返回成功或失败
-
-
-
检查参数：间隔时间、超时时间、成功/失败阈值。这些参数的精细配置直接影响高可用性的灵敏度
四、 负载均衡的高级功能
这些功能让负载均衡从单纯的"流量分发器"变为"应用交付控制器"
-
SSL/TLS终结 ：在负载均衡器上完成HTTPS请求的解密 ，并将明文的HTTP请求转发给后端服务器。响应在负载均衡器上再被加密后返回给客户端
-
内容压缩与缓存：压缩响应内容以节省带宽；缓存静态资源（如图片、CSS），直接返回给用户，减轻后端压力
-
Web应用防火墙：提供基础的SQL注入、跨站脚本等应用层攻击防护
-
流量整形与限速：控制到特定服务器或URL的流量速率，防止资源被滥用，保证服务公平性
-
网络隔离与IP隐藏：作为统一的对外入口，负载均衡器背后的服务器群可以部署在私有网络中，不直接暴露公网IP
五、 负载均衡的问题
-
单点故障：负载均衡器本身成为新的单点
-
解决方案：高可用集群（Active-Standby或Active-Active模式），通过VRRP等协议实现故障切换
-
性能瓶颈：负载均衡器的处理能力上限
-
解决方案：选择更高性能的设备/软件，或采用DNS轮询+多层负载均衡架构进行横向扩展
-
配置与管理的复杂性：特别是七层负载均衡的规则配置可能非常复杂。需要良好的运维流程和工具。
-
后端服务器的状态同步 ：当使用会话保持时，如果某台服务器故障，如何迁移用户会话？这引出了分布式会话存储（如Redis）的概念