一、负载均衡器分类与选型策略

负载均衡器（2种类型）

1. 硬件与软件负载均衡的优劣对比   

    硬件负载均衡：具备极强的处理能力，但价格昂贵，适用于对性能要求极高的核心业务场景。硬件负载均衡器（找一个负载均衡器产品） 
    软件负载均衡：以 Nginx 为代表，配置简单、管理方便且成本低，具备高可用特性（单点故障可快速替换），是中小型企业的首选方案。软件负载均衡器（Nginx lvs haproxy kong slb ）

2. 阿里云 SLB 产品体系解析

2.1 slb产品类型

应用型负载均衡（ALB）：面向 7 层（HTTP/HTTPS），基于域名进行流量分发，支持高级路由（如 URL 重写）和自动弹性伸缩，适合 Web 应用场景。

网络型负载均衡（NLB）：面向 4 层（TCP/UDP），基于 IP 和端口进行流量转发，支持亿级并发连接，适用于物联网（IoT）等高并发、低延迟场景。

传统型负载均衡（CLB）：兼具 4 层和基础 7 层能力，基于定制化 LVS+Keepalived 实现 4 层转发，基于 Tengine（Nginx 优化版）实现 7 层转发，适用于通用高可用场景。

2.2 云产品与自建方案的优劣对比

运维成本与弹性能力：云产品（SLB）提供自动容灾（多可用区）和弹性伸缩能力，而自建 Nginx+Keepalived 需要手动维护高可用和扩容，运维成本较高。

技术自主性与厂商绑定：虽然云产品便捷，但大型企业出于技术自主可控和避免厂商绑定的考虑，往往会选择自建负载均衡架构。

2.3 四层与七层负载均衡的应用场景

软件负载均衡器：（2个分支）

七层负载均衡（应用层）：基于 HTTP/HTTPS 协议及域名进行转发，适用于 Web 前端访问及用户登录等业务场景。
四层负载均衡（传输层）：基于 IP 地址和端口进行转发，适用于内网后端服务（如 Java 环境）访问数据库或缓存等内部组件，无需域名解析，降低维护成本。

二、LVS 核心原理与架构优势

2.1 高性能架构设计

内核级转发机制：LVS 的核心功能直接集成在 Linux 内核中，通过 `ipvsadm` 工具管理，转发效率极高，相比 Nginx 减少了用户态与内核态的切换开销。

高并发承载能力：LVS 专注于四层转发，理论并发承载能力可达百万级，远超 Nginx 在七层场景下的 20 万并发上限。Nginx L4层负载均衡器（100w）、L7 基于域名的负载均衡器（20w）

lvs  （起步是百万的扛并发能力） L4 + 简单的健康检查和防火墙的规则（允许拒绝 xx IP xx端口的访问）

2.2 集群化部署概念

集群（Cluster）定义：由多台服务器组成，对外表现为一个统一的访问入口（VIP），共同承担业务压力，通常建议集群节点数量在 3 个以上。

企业级应用形态：在现代云环境中，LVS 通常被封装为标准化产品（如 SLB），企业无需手动配置底层规则，只需通过控制台配置 IP、端口及健康检查策略即可。

2.3 LVS 三种工作模式详解

lvs 模式：
2.3.1 NAT 地址映射（IP 和PORT 内：192.168.110.128:80 -> 映射到外网 10.20.30.40:81）

实现原理：负载均衡器作为网关，负责将公网 IP 转换为内网 IP 进行转发，同时处理回包地址转换，类似于云服务器 ECS 的公网 IP 映射机制。

应用场景：适用于需要隐藏后端服务器真实 IP 的场景，但负载均衡器会成为网络瓶颈，需处理双向流量。

2.3.2 Tunnel 模式（IP 隧道）

实现原理：负载均衡器仅负责请求转发，后端服务器直接通过公网 IP 响应客户端，实现请求与响应的分离。

成本与局限：由于后端服务器需拥有公网 IP 直接响应，导致公网 IP 成本和流量费用极高，且受限于公网带宽，企业级应用较少。

2.3.3 DR 模式（直接路由）

实现原理：负载均衡器接收请求并转发给后端，后端服务器处理后直接通过网关路由器返回给客户端，不经过负载均衡器。

推荐选型：该模式结合了高性能与低成本优势，仅需一个公网 IP（网关），后端服务器位于内网，是企业生产环境中最常用的模式。

2.4 LVS 四层负载均衡原理与实践

2.4.1 核心优势与模式对比

性能与定位：LVS 工作在四层（传输层），基于 IP 和端口进行转发，相较于 Nginx，其转发性能和抗高并发能力更强，但缺乏七层协议处理能力。

2.4.2 环境配置与规则管理

虚拟 IP 配置：通过修改网卡配置文件（如 `ens33:0`）创建永久虚拟 IP，并加载 `ip_vs` 内核模块以支持 LVS 功能。

规则配置命令：使用 `ipvsadm` 工具管理规则，`-A` 添加虚拟服务（VIP），`-a` 添加真实服务器（RIP），`-s` 指定调度算法（如 rr 轮询），`-g` 指定 DR 模式。

ipvsadm -C            #表示清理之前的规则链表
ipvsadm -A -t 192.168.110.100:80 -s rr
-A 开启一个虚拟机的VIP地址
-t 申明vip地址是什么(申明的是lvs监听的是哪个IP:port)
-s 使用哪个负载均衡的模式 rr 轮询 wrr 加权轮询 lc 最小连接 wlc 加权最小连接
ipvsadm -a -t 192.168.110.100:80 -r 192.168.110.130:80 -g
-r 表示realy_server ,后端真实地址 
-g 表示启用的是lvs的DR模式
ipvsadm -a -t 192.168.110.100:80 -r 192.168.110.131:80 -g
ipvsadm    #开启ipvsadm 定义的规则
ipvsadm -ln  # 查看节点状态，Route代表DR模式

ipvsadm -C
ipvsadm -A -t 192.168.110.100:80 -s rr
ipvsadm -a -t 192.168.110.100:80 -r 192.168.110.130:80 -g
ipvsadm -a -t 192.168.110.100:80 -r 192.168.110.131:80 -g

ipvsadm -ln 

状态查询：通过 `ipvsadm -ln` 命令查看当前的负载均衡规则及后端节点状态。

三、Tomcat 核心概念与部署流程

3.1 运行环境与依赖关系

JDK 环境准备：Java 代码运行必须依赖 JDK 环境，类似于 Nginx 编译安装需要 GCC 等依赖，需确保系统已安装对应版本的 JDK。

全局环境变量配置：通过修改 `/etc/profile` 文件添加 `JAVA_HOME` 和 `CLASSPATH` 等变量，确保所有用户均可识别 Java 命令。

服务启动原理：现代开发框架（如 Spring Boot）已将 Tomcat 内嵌，开发人员只需使用 `java -jar` 命令启动 Jar 包即可自动运行 Tomcat 服务。

3.2 核心端口与目录结构

关键端口识别：Tomcat 默认监听 8080（HTTP）和 8443（HTTPS）端口，同时会开启 8005（关闭指令）和 8009（AJP 连接）端口。

核心目录功能：`bin` 存放启动脚本，`logs` 存放日志，`conf` 存放配置文件，`webapps` 为项目部署目录（传统方式），`temp` 存放临时文件。

3.3 Tomcat 配置管理与优化

3.3.1 多站点配置逻辑

基于域名的虚拟主机：在 `server.xml` 的 `<Host>` 标签内配置，通过 `appBase` 指定项目根目录，`Context` 指定具体应用路径。

配置文件语法规范：XML 标签语言以 `<Host>` 开头和结尾，注释使用 `<!-- -->`，配置需严格遵循标签闭合规则。

3.3.2 配置步骤演示

创建项目目录：在 `webapps` 下创建子目录（如 xy502），并编写 `index.jsp` 页面。

修改配置文件：在 `server.xml` 中增加 `<Host>` 配置，指定域名与目录映射关系，重启服务生效。

部分补充

1.Nginx 高可用架构与配置逻辑
1.1 核心架构与组件职责
架构拓扑定义：明确架构由 Nginx01 和 Nginx02 组成热备组，后端连接 Apache01 和 Apache02，通过虚拟 IP（VIP）作为外网访问入口。

组件功能解耦：Keepalived 仅负责提供 VIP 及健康检查，不处理业务流量；Nginx 负责具体的反向代理与负载均衡功能。

配置实现路径：实现高可用需修改 Nginx 配置文件，通过 `location` 匹配规则结合 `proxy_pass` 指令将请求跳转至后端服务器。

1.2 负载均衡与代理配置
单机与集群配置差异：若后端仅部署单台服务器，可直接使用 `proxy_pass` 指定 IP；若为多台服务器，需使用 `upstream` 模块定义地址池。

端口冲突规避：针对克隆环境导致的端口占用问题，建议修改后端服务端口（如 Apache 改为 8080 或 81），或通过防火墙规则释放端口。

2. 典型故障排查与解决方案
2.1 环境初始化与安全策略
SELinux 与防火墙处置：强调环境初始化需关闭 SELinux（`setenforce 0`）并清理防火墙规则（`iptables -F`），以排除安全策略对服务的拦截。

服务冲突排查：指出克隆虚拟机可能导致 Nginx 服务残留占用 80 端口，需检查并关闭冲突服务。

2.2 网络与代理转发故障
502/503 错误分析：针对访问 VIP 出现 502/503 报错，需检查后端服务状态及 Nginx 代理配置，确认 `proxy_pass` 指向的后端地址及端口是否可达。

网络逻辑冲突：分析了因 Nginx 与系统转发逻辑冲突导致的连接超时问题，指出需通过调整防火墙或网络策略解决。

2.3 虚拟 IP 绑定与监听机制
网卡绑定逻辑：VIP 通常绑定在物理网卡（如 ens33）上，Nginx 监听 80 端口时，只要流量到达该物理网卡的 80 端口即可被处理，无需指定具体 IP。

企业级实践：在企业环境中，VIP 通常对应公网 IP，域名解析直接指向公网 VIP，而非内网地址。

2.4 网络连通性验证
内网互通限制：指出直接使用内网 IP（如 192.168.110.100）访问后端服务器可能存在网络策略限制，通常需通过 Nginx 代理进行转发。

实验环境差异：生产环境需严格遵循网络规划，避免随意配置 IP 导致路由不可达。

3. Nginx 反向代理底层机制与网络策略
3.1 数据包转发原理与内核交互
Nginx 无数据包封装能力：Nginx 本身不具备封装数据包（MAC/IP/协议头）的能力，其作用仅限于提供转发策略（如 proxy_pass 指令）。

内核负责具体转发动作：当 Nginx Worker 进程接收到请求后，会与系统内核交互，由内核完成数据包的封装（L1-L7 层）并通过网卡发送给后端服务器。

同机部署的网络策略冲突：当 Nginx 与后端服务（如 Apache）部署在同一台服务器时，转发请求会经过本地防火墙策略（iptables/firewalld），若规则未放行，会导致连接失败。

3.2 服务架构选型与性能对比
Nginx 与 Apache 的角色定位：Nginx 作为前端代理，处理静态资源和高并发连接；Apache 作为后端应用服务器，处理动态请求，两者角色相似但侧重点不同。

高并发场景下的稳定性考量：虽然 Nginx 性能更优，但在亿级用户的高并发场景下，Apache 的稳定性可能优于 Nginx，因此部分云平台会采用 Apache 作为负载均衡器。