一、HAProxy 基础知识
1. 核心定义与定位：
HAProxy（High Availability Proxy）是一款高性能、开源的 TCP/HTTP 负载均衡器和反向代理，以其卓越的性能、丰富的功能和稳定性，成为现代高可用架构中的核心组件。
2. 核心特点：
高性能：单实例可处理数十万并发连接，延迟极低，支持百万级 QPS。
高可靠：内置健康检查、故障自动剔除和流量重定向，保障服务不中断。
功能丰富：支持 TCP/HTTP 双模式、ACL 访问控制、SSL 终端、流量调度、自定义错误页等。
开源免费：采用 GPL 协议，社区活跃，文档完善，企业级应用广泛。
可观测性：提供详细的日志、统计数据和监控接口，便于运维排障。
3. 核心应用场景：
Web 服务负载均衡：分发 HTTP/HTTPS 请求到后端 Web 服务器，提升并发能力。
API 网关：作为 API 服务入口，实现流量控制、路由转发和安全防护。
数据库代理：实现数据库读写分离、负载均衡，提升数据库访问性能。
高可用架构：配合 Keepalived 等工具，实现主备切换，避免单点故障。
流量调度：通过 ACL 和路由规则，实现灰度发布、A/B 测试等复杂流量管理。
4.核心组件与配置段
HAProxy 的配置文件（通常为 /etc/haproxy/haproxy.cfg）由多个配置段组成，核心如下：
| 配置段 | 作用 |
|---|---|
| global | 全局配置，如进程管理、日志、最大连接数、SSL 证书路径等。 |
| defaults | 默认配置，定义超时时间、日志格式、健康检查等，可被其他段继承。 |
| frontend | 定义监听端口、协议和路由规则，接收客户端请求并转发到后端。 |
| backend | 定义后端服务器组，配置负载均衡算法、健康检查和服务器参数。 |
| listen | 同时包含 frontend 和 backend 逻辑，简化单一服务的配置。 |
5. 工作模式
HAProxy 支持两种核心工作模式，适配不同业务场景：
TCP 模式（mode tcp）：
工作在四层（传输层），仅转发 TCP 流量，不解析应用层协议。
适用于非 HTTP 服务（如 MySQL、Redis、SSH），性能极高。
HTTP 模式（mode http）：
工作在七层（应用层），解析 HTTP 请求，支持 URL 重写、Header 处理、Cookie 粘性等。
适用于 Web 服务、API 网关等需要精细流量控制的场景。
二、HAProxy 基础安装与负载均衡
1.实验环境：
| 主机角色 | IP 地址 | 安装软件 | 网络配置 |
|---|---|---|---|
| HAProxy 服务器 | 172.25.254.100 | haproxy | 双网卡（NAT + 仅主机），对外提供负载均衡服务 |
| Web 服务器 1 | 192.168.0.10 | httpd | 仅主机模式，提供 Web 服务 |
| Web 服务器 2 | 192.168.0.20 | httpd | 仅主机模式，提供 Web 服务 |
2.实验步骤：
2.1 安装 HAProxy：
2.2 基础负载均衡配置：
[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
frontend webcluster
bind *:80
mode http
use_backend webserver-80
backend webserver-80
server web1 192.168.0.10:80 check inter 3s fall 3 rise 5
server web2 192.168.0.20:80 check inter 3s fall 3 rise 5
# 重启服务生效
[root@haproxy ~]# systemctl restart haproxy.service2.3 实验效果：
三、ACL 访问控制
1. ACL 核心定义与作用
ACL（Access Control List，访问控制列表）是 HAProxy 最核心的特性之一，通过定义匹配规则 识别客户端请求的特征（如客户端 IP、请求路径、域名、请求头、请求方法等），结合转发 / 拒绝策略，实现对请求的精准路由、访问限制、流量分流，是构建复杂业务流量架构的基础。
2. 常用 ACL 匹配规则
| 匹配类别 | 规则语法 | 含义 | 示例 |
|---|---|---|---|
| 客户端 IP 匹配 | src [IP/网段] |
匹配客户端源 IP 或网段 | acl is_internal src 192.168.0.0/24（匹配内网 IP） |
| 请求路径匹配 | path_beg [路径前缀] |
匹配请求路径开头 | acl is_admin path_beg /admin（匹配 /admin 开头路径） |
path_end [后缀] |
匹配请求路径结尾 | acl is_php path_end .php（匹配 PHP 文件请求） |
|
path [精确路径] |
精确匹配请求路径 | acl is_index path /index.html（精确匹配首页） |
|
| 域名 / Host 头匹配 | hdr(Host) [域名] |
匹配请求头中的 Host 字段 | acl is_www hdr(Host) www.example.com（匹配指定域名） |
| 请求方法匹配 | method [HTTP方法] |
匹配 HTTP 请求方法 | acl is_post method POST（匹配 POST 请求） |
| 协议匹配 | ssl_fc |
匹配 HTTPS 加密请求 | acl is_https ssl_fc（判断是否为 HTTPS 请求） |
| 请求头匹配 | hdr([头名称]) [匹配值] |
匹配任意请求头 | acl is_wechat hdr(User-Agent) -i WeChat（匹配微信客户端） |
| 端口匹配 | dst_port [端口号] |
匹配请求的目标端口 | acl is_8080 dst_port 8080（匹配 8080 端口请求） |
3. ACL 配置核心语法
ACL 的配置分为两步：先定义 ACL 规则，再为规则绑定执行策略。
定义 ACL：
acl [ACL名称] [匹配规则] [匹配值]应用 ACL：
HAProxy 支持多种策略绑定，核心包括：
- use_backend 后端名称 if ACL条件：满足条件时路由到指定后端。
- deny if ACL条件：满足条件时拒绝请求（返回 403）。
- redirect 重定向规则 if ACL条件：满足条件时重定向请求。
- 多条件组合：使用 and/or 连接，或直接并列（默认 and）。
4. 实验目标
实现「.com 域名转发至 web1，其他域名转发至 web2」+「拒绝指定 IP 访问」的组合规则。
5. 操作步骤
5.1 配置本地域名解析（测试机）
# Linux 测试机配置
vim /etc/hosts
172.25.254.100 www.zt.com www.zt.org5.2 配置 HAProxy ACL 规则
[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
frontend webcluster
bind *:80
mode http
# 定义 ACL 规则：匹配 .com 结尾域名
acl com_domain hdr_end(host) -i .com
# 定义 ACL 规则：匹配禁止的客户端 IP
acl deny_ip src 172.25.254.1
# 拒绝禁止 IP 的请求
http-request deny if deny_ip
# .com 域名转发至 web1，其他转发至 web2
use_backend webserver-80-web1 if com_domain
default_backend webserver-80-web2
backend webserver-80-web1
server web1 192.168.0.10:80 check inter 3s fall 3 rise 5
backend webserver-80-web2
server web2 192.168.0.20:80 check inter 3s fall 3 rise 5
# 重启服务
[root@haproxy ~]# systemctl restart haproxy.service5.3 测试 ACL 规则
# 测试 .com 域名（转发至 web1）
curl www.zt.com
web1 - 192.168.0.10
# 测试 .org 域名（转发至 web2）
curl www.zt.org
webserver2 - 192.168.0.20
# 测试禁止 IP（返回 403）
curl 172.25.254.100
<html><body><h1>403 Forbidden</h1>
Request forbidden by administrative rules.
</body></html>5.4 实验结果
四、全站加密（HTTPS 配置）
1. 知识点
1.1 核心概念
- 全站 HTTPS：将所有 HTTP 请求自动重定向到 HTTPS，实现数据传输的全程加密，防止窃听、篡改和中间人攻击，是现代 Web 服务的安全标配。
- HAProxy SSL 终端：HAProxy 作为 SSL/TLS 终端，负责处理 HTTPS 的握手、加密和解密，后端 Web 服务器仍通过 HTTP 提供服务，大幅减轻后端服务器的加密负担，同时简化证书管理。
1.2 核心优势
- 性能优化：集中处理 SSL/TLS 运算，避免后端服务器重复加密，提升整体并发能力。
- 证书统一管理：仅在 HAProxy 上部署证书，后端无需配置，降低运维复杂度。
- 灵活扩展：支持多域名证书、SNI（Server Name Indication），适配多站点部署。
- 安全增强：可配置加密套件、禁用弱协议（如 TLS 1.0/1.1），提升安全等级。
1.3 证书要求
HAProxy 要求证书为PEM 格式，需包含：
- 服务器证书（
.crt） - 私钥（
.key） - 中间证书（若有，
.ca） - 合并方式：
cat server.crt server.key ca.crt > haproxy.pem
2. 实验步骤
2.1 生成自签名 SSL 证书
2.2 配置 HTTPS 监听与 HTTP 跳转
[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
# HTTP 前端：自动跳转 HTTPS
frontend webcluster-http
bind *:80
redirect scheme https if ! { ssl_fc } # 非 HTTPS 请求跳转至 HTTPS
# HTTPS 前端：处理加密请求
listen webcluster-https
bind *:443 ssl crt /etc/haproxy/certs/timinglee.pem # 关联 SSL 证书
mode http
balance roundrobin
server haha 192.168.0.10:80 check inter 3s fall 3 rise 5
server hehe 192.168.0.20:80 check inter 3s fall 3 rise 5
# 重启服务
[root@haproxy ~]# systemctl restart haproxy.service2.3 测试全站加密
五、负载均衡算法
1. 核心算法详解
| 算法名称 | 英文名称 | 核心逻辑 | 适用场景 | 配置示例 |
|---|---|---|---|---|
| 轮询 | roundrobin |
按顺序将请求依次分配给后端服务器，支持权重，可动态调整权重。 | 后端服务器性能相近、负载稳定的 Web 服务场景，是 HTTP 模式的默认算法。 | balance roundrobin |
| 加权轮询 | static-rr |
根据服务器权重分配请求，权重越高，处理的请求越多；不支持动态调整权重。 | 后端服务器性能存在明显差异的场景，如一台高性能服务器搭配多台普通服务器。 | balance static-rr``server web1 192.168.0.10:80 weight 2 check``server web2 192.168.0.20:80 weight 1 check |
| 最少连接 | leastconn |
将请求分配给当前活动连接数最少的服务器，适合长连接场景。 | 长连接服务（如数据库代理、WebSocket）、负载波动较大的场景。 | balance leastconn |
| 源地址哈希 | source |
根据客户端 IP 地址进行哈希计算，将同一客户端的请求固定转发到同一台服务器。 | 需要保持会话粘性的场景（如用户登录状态、购物车）。 | balance source |
| URI 哈希 | uri |
根据请求的 URI 进行哈希计算，将同一资源的请求固定转发到同一台服务器。 | 缓存集群、静态资源服务，可提高缓存命中率。 | balance uri |
| URL 参数哈希 | url_param |
根据 URL 中的指定参数（如 userid）进行哈希，将同一参数值的请求固定到同一服务器。 |
按用户 ID 保持会话的场景，如用户中心服务。 | balance url_param userid |
| 请求头哈希 | hdr |
根据指定的请求头（如 Cookie）进行哈希，将同一头值的请求固定到同一服务器。 |
基于 Cookie 的会话保持场景。 | balance hdr(Cookie) |
2.算法选择建议
| 业务场景 | 推荐算法 | 核心原因 |
|---|---|---|
| 普通 Web 服务（短连接） | roundrobin |
简单高效，适配大多数场景。 |
| 后端服务器性能差异大 | static-rr |
可通过权重分配更多请求到高性能服务器。 |
| 长连接服务（数据库、WebSocket） | leastconn |
避免单台服务器连接数过载。 |
| 会话保持（登录、购物车） | source / url_param / hdr |
确保同一用户 / 会话的请求固定到同一服务器。 |
| 缓存集群（静态资源） | uri |
提高缓存命中率，减少后端重复计算。 |
3. 实验示例
1. 配置 static-rr 算法
[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
listen webcluster
bind *:80
balance static-rr # 静态加权轮询
server haha 192.168.0.10:80 check inter 3s fall 3 rise 5 weight 2
server hehe 192.168.0.20:80 check inter 3s fall 3 rise 5 weight 1
[root@haproxy ~]# systemctl restart haproxy.service
# 测试：web1 被转发 2 次，web2 被转发 1 次，循环往复
for i in {1..6}; do curl 172.25.254.100; done
webserver1 - 192.168.0.10
webserver1 - 192.168.0.10
webserver2 - 192.168.0.20
webserver1 - 192.168.0.10
webserver1 - 192.168.0.10
webserver2 - 192.168.0.20
2. 配置 roundrobin 算法
[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
listen webcluster
bind *:80
balance roundrobin # 动态加权轮询
server haha 192.168.0.10:80 check inter 3s fall 3 rise 5 weight 2
server hehe 192.168.0.20:80 check inter 3s fall 3 rise 5 weight 1
[root@haproxy ~]# systemctl restart haproxy.service
# 热更新权重（成功）
[root@haproxy ~]# echo "set weight webcluster/haha 1" | socat stdio /var/lib/haproxy/stats
[root@haproxy ~]# echo "get weight webcluster/haha" | socat stdio /var/lib/haproxy/stats
1 (initial 2)
# 测试：权重更新后，web1 和 web2 轮询转发
for i in {1..6}; do curl 172.25.254.100; done
webserver1 - 192.168.0.10
webserver2 - 192.168.0.20
webserver1 - 192.168.0.10
webserver2 - 192.168.0.20
webserver1 - 192.168.0.10
webserver2 - 192.168.0.20