1. 什么是负载均衡

负载均衡（Load Balancing）是一种将网络请求或工作负载分散到多个服务器或计算机资源上的技术，其核心目标是优化资源使用、提高系统吞吐量、增强数据冗余和故障容错能力，并减少响应时间。在分布式系统、云计算环境、Web服务等领域中，负载均衡是不可或缺的基础设施组件。

负载均衡的基本原理是：负载均衡器作为入口，接收客户端请求，然后根据预定义的规则（如轮询、最少连接、源地址哈希等）将请求转发给后端服务器集群中的一台进行处理。同时，负载均衡器持续监控后端服务器的健康状况，自动隔离故障服务器，确保服务的高可用性。

负载均衡的主要优势：

  • 提高系统吞吐量：通过并行处理，显著提升整体处理能力。

  • 优化资源利用：动态分配请求，避免单点过载。

  • 增强容错能力：故障服务器自动被剔除，不影响整体服务。

  • 降低响应延迟：请求被分配给负载较低的服务器，缩短等待时间。

常见的负载均衡算法包括：轮询（Round Robin）、最少连接（Least Connections）、源地址哈希（Source Hashing）、加权轮询（Weighted Round Robin）等。

2. HAProxy 简介

HAProxy（High Availability Proxy）是一款由法国开发者Willy Tarreau开源的、基于C语言编写的高性能TCP/HTTP负载均衡器。它以其卓越的性能、丰富的功能和极高的稳定性，成为众多大型网站（如GitHub、Stack Overflow等）的首选负载均衡解决方案。

2.1 基本概述

  • 开发者：Willy Tarreau

  • 类型：TCP/HTTP 负载均衡器及代理服务器

  • 许可证：GPLv2

  • 核心功能：负载均衡、健康检查、会话保持、SSL/TLS终止、HTTP内容修改、访问控制等。

2.2 主要特性

  • 高性能：采用事件驱动、单进程多路复用模型（epoll/kqueue），可轻松处理数十万并发连接。

  • 高可用性：内置强大的健康检查机制，支持主动与被动检测，自动故障转移。

  • 灵活的路由能力：支持基于ACL（访问控制列表）的复杂请求路由，可实现动静分离、A/B测试等。

  • 丰富的负载均衡算法：提供静态、动态及一致性哈希等多种算法，适配不同业务场景。

  • SSL/TLS支持：可作为SSL终点，卸载后端服务器的加密负担。

  • 细粒度监控：提供详细的统计页面和指标输出，便于集成到监控系统。

2.3 工作原理

HAProxy的工作流程可概括为：

  1. 监听：HAProxy在前端（frontend）绑定IP和端口，等待客户端连接。

  2. 接受请求：接收客户端请求，解析协议（四层TCP或七层HTTP）。

  3. 匹配规则：根据配置的ACL规则或默认策略，选择对应的后端（backend）服务器组。

  4. 选择服务器：在后端服务器组中，根据指定的负载均衡算法挑选一台目标服务器。

  5. 转发请求：将请求转发至选定的后端服务器，并建立客户端与服务器之间的数据通道。

  6. 记录与监控：记录日志，更新统计信息，并持续对后端服务器进行健康检查。

2.4 核心组件

HAProxy的配置文件由五个主要部分组成：

  • global：进程级全局配置，如用户/组、最大连接数、日志、chroot等。

  • defaults：为frontend、backend、listen提供默认配置，可被继承或覆盖。

  • frontend：定义客户端监听地址、端口及请求处理规则，通过use_backend或default_backend指定后端。

  • backend：定义一组后端服务器及负载均衡算法、健康检查参数。

  • listen：frontend和backend的组合体，适用于简单场景（如端口转发、统计页面）。

2.5 健康检查机制

HAProxy通过定期向后端服务器发送探测请求（如TCP连接尝试、HTTP请求）来评估服务器状态。关键参数包括：

  • inter：检查间隔时间。

  • fall：连续失败次数，达到后标记服务器为宕机。

  • rise：连续成功次数，达到后标记服务器为存活。

  • option httpchk：启用HTTP层健康检查，可指定方法、URI和HTTP版本。

2.6 应用场景

  • Web应用负载均衡：分发HTTP/HTTPS流量到Web服务器集群。

  • 数据库负载均衡：为MySQL、PostgreSQL等数据库提供TCP层负载均衡。

  • 微服务API网关：作为统一入口，实现服务路由、限流、熔断等。

  • TCP代理：对任何TCP服务（如Redis、MQTT）进行负载均衡。

  • SSL卸载：集中处理SSL加密，减轻后端服务器CPU负担。

3. 配置 HAProxy 实验环境

本文所有实验基于三台运行Red Hat 9（或兼容Linux发行版）的虚拟机，网络规划如下：

3.1 主机规划
主机名 IP地址 角色 安装服务
haproxy 192.168.10.10 负载均衡器 haproxy
web1 192.168.10.11 后端Web服务器1 nginx
web2 192.168.10.12 后端Web服务器2 nginx
3.2 基础环境配置

在三台机器上分别执行以下命令，关闭防火墙和SELinux，避免干扰。

[root@haproxy ~]# systemctl stop firewalld && systemctl disable firewalld
Removed /etc/systemd/system/multi-user.target.wants/firewalld.service.
[root@haproxy ~]# setenforce 0
[root@haproxy ~]# sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config

注意（web1、web2 执行相同操作）

3.3 后端 Web 服务器配置

3.3.1 web1 配置 IP 并安装 Nginx

[root@web1 ~]# nmcli connection modify ens160 ipv4.addresses 192.168.10.11/24 ipv4.gateway 192.168.10.1 ipv4.method manual
[root@web1 ~]# nmcli connection up ens160
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)
[root@web1 ~]# dnf install -y nginx
...
Installed:
  nginx-1:1.20.1-10.el9.x86_64
Complete!
[root@web1 ~]# systemctl start nginx && systemctl enable nginx
Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /usr/lib/systemd/system/nginx.service.
[root@web1 ~]# echo "<h1>Web Server 1</h1>" > /usr/share/nginx/html/index.html

3.3.2 web2 配置 IP 并安装 Nginx

[root@web2 ~]# nmcli connection modify ens160 ipv4.addresses 192.168.10.12/24 ipv4.gateway 192.168.10.1 ipv4.method manual
[root@web2 ~]# nmcli connection up ens160
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/4)
[root@web2 ~]# dnf install -y nginx
...
Complete!
[root@web2 ~]# systemctl start nginx && systemctl enable nginx
Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /usr/lib/systemd/system/nginx.service.
[root@web2 ~]# echo "<h1>Web Server 2</h1>" > /usr/share/nginx/html/index.html

4. HAProxy 基本部署与负载均衡实现

4.1 安装 HAProxy
[root@haproxy ~]# dnf install -y haproxy
...
Installed:
  haproxy-2.4.22-3.el9.x86_64
Complete!
4.2 配置文件结构详解

HAProxy 的主配置文件为 /etc/haproxy/haproxy.cfg，其典型结构如下：

  • global：全局参数，影响进程行为。

  • defaults：为其余部分提供默认值。

  • frontend：定义监听套接字和请求接收规则。

  • backend：定义后端服务器池和负载均衡策略。

  • listen：同时定义前端和后端（适用于简单服务）。

​​​4.3 编写基础配置文件

编辑配置文件，实现一个基本的 HTTP 负载均衡，使用轮询算法，并开启统计页面。

bash

[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg

清空原有内容，写入以下配置（请根据实际IP地址修改 server 行）：

global
    log         127.0.0.1 local2 info
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon

defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000

listen stats
    bind                    *:1080
    mode                    http
    stats                   enable
    stats                   uri /stats
    stats                   refresh 30s
    stats                   realm Haproxy\ Statistics
    stats                   auth admin:admin

frontend web-frontend
    bind                    *:80
    mode                    http
    log                     global
    option                  httplog
    default_backend         web-servers

backend web-servers
    mode                    http
    balance                 roundrobin
    option                  httpchk GET /
    server web1 192.168.10.11:80 check inter 3s fall 3 rise 5
    server web2 192.168.10.12:80 check inter 3s fall 3 rise 5

参数说明：

  • balance roundrobin：采用加权轮询算法。

  • option httpchk GET /：通过HTTP GET请求 / 路径进行健康检查。

  • server 行：定义后端服务器，check 启用健康检查，inter 3s 每3秒检查一次，fall 3 连续失败3次标记为宕机，rise 5 连续成功5次标记为存活。

4.4 启动与验证 HAProxy 服务
[root@haproxy ~]# systemctl start haproxy
[root@haproxy ~]# systemctl enable haproxy
Created symlink /etc/systemd/system/multi-user.target.wants/haproxy.service → /usr/lib/systemd/system/haproxy.service.
[root@haproxy ~]# systemctl status haproxy
● haproxy.service - HAProxy Load Balancer
     Loaded: loaded (/usr/lib/systemd/system/haproxy.service; enabled; vendor preset: disabled)
     Active: active (running) since Tue 2025-02-25 10:15:30 CST; 10s ago
   Main PID: 23456 (haproxy)
      Tasks: 2 (limit: 49450)
     Memory: 6.1M
        CPU: 28ms
     CGroup: /system.slice/haproxy.service
             ├─23456 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid
             └─23457 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid
4.5 验证负载均衡效果

使用 curl 命令连续访问 HAProxy 的 IP，观察响应内容是否交替变化。

[root@haproxy ~]# curl http://192.168.10.10
<h1>Web Server 1</h1>
[root@haproxy ~]# curl http://192.168.10.10
<h1>Web Server 2</h1>
[root@haproxy ~]# curl http://192.168.10.10
<h1>Web Server 1</h1>
[root@haproxy ~]# curl http://192.168.10.10
<h1>Web Server 2</h1>

输出显示请求被均匀分发到 web1 和 web2，轮询算法生效。

4.6 验证健康检查机制

步骤1：停止 web1 的 Nginx 服务

步骤2：再次从 HAProxy 访问

[root@web1 ~]# systemctl stop nginx
[root@haproxy ~]# curl http://192.168.10.10
<h1>Web Server 2</h1>
[root@haproxy ~]# curl http://192.168.10.10
<h1>Web Server 2</h1>
[root@haproxy ~]# curl http://192.168.10.10
<h1>Web Server 2</h1>

所有请求全部转发至 web2，表明 HAProxy 已检测到 web1 故障并将其从负载均衡池中移除。

步骤3：重新启动 web1 的 Nginx 并在等待后（在检查周期内），再次访问

[root@haproxy ~]# curl http://192.168.10.10
<h1>Web Server 1</h1>
[root@haproxy ~]# curl http://192.168.10.10
<h1>Web Server 2</h1>

流量恢复轮询，证明 HAProxy 自动将恢复的 web1 重新加入集群。

4.7 访问统计页面

在浏览器中打开 http://192.168.10.10:1080/stats，输入用户名 admin 和密码 admin，即可看到 HAProxy 的实时监控页面。页面展示前端、后端的会话数、状态、健康检查结果、流量统计等信息。

5. HAProxy 配置参数及日志分离

5.1 全局配置参数详解

global 段配置影响 HAProxy 进程本身的运行。

进程管理及安全相关参数

  • chroot <dir>：将进程根目录锁定到指定目录，提升安全性（该目录必须为空且不可写）。

  • daemon：以守护进程方式运行。

  • gid <number> / group <name>：指定运行进程的组ID或组名。

  • uid <number> / user <name>：指定运行进程的用户ID或用户名。

  • nbproc <number>：启动的进程数，默认为1。多进程下需注意 stats socket 等配置的兼容性。

  • pidfile <file>：指定 PID 文件路径。

性能调整相关参数

  • maxconn <number>：每个进程的最大并发连接数。

  • ulimit-n <number>：每个进程可打开的最大文件描述符数，通常 HAProxy 会自动计算，但可手动调整。

超时时长相关参数

  • timeout connect <time>：连接后端服务器的超时时间。

  • timeout client <time>：客户端非活动超时时间。

  • timeout server <time>：等待后端服务器响应的超时时间。

  • timeout http-keep-alive <time>：HTTP 长连接超时。

  • timeout check <time>：健康检查的超时时间。

调试及其他参数

  • debug：启用调试模式，输出详细日志。

  • quiet：静默模式，减少日志输出。

  • stats socket <path> [param]：定义 Unix Socket 路径，用于通过外部工具（如 socat）进行运行时管理。

  • node <name>：定义节点名称，在多节点环境中用于标识。

5.2 日志分离配置

默认 HAProxy 将日志输出到 rsyslog 的 local2 设备，我们需要单独配置 rsyslog 接收并写入独立文件。

步骤1：编辑 rsyslog 配置文件

[root@haproxy ~]# vim /etc/rsyslog.conf

取消以下两行的注释（开启 UDP 514 端口接收日志）：

$ModLoad imudp
$UDPServerRun 514

在 RULES 部分添加：

local2.*                                                /var/log/haproxy.log

步骤2：重启 rsyslog

[root@haproxy ~]# systemctl restart rsyslog

步骤3：验证日志输出
多次访问 HAProxy 的 80 端口，然后查看日志文件：

[root@haproxy ~]# tail -f /var/log/haproxy.log
Feb 25 10:30:01 localhost haproxy[23456]: 192.168.10.100:54321 [25/Feb/2025:10:30:00.123] web-frontend web-servers/web1 0/0/1/5/6 200 177 - - ---- 1/1/0/0/0 0/0 "GET / HTTP/1.1"

日志中应包含客户端的访问记录。

6. Proxies 常用配置参数

6.1 前端（frontend）配置

  • bind [<address>]:<port>：指定监听地址和端口，如 bind *:80。

  • mode {http|tcp}：指定处理模式。

  • option httplog：启用 HTTP 格式日志。

  • acl <aclname> <criterion> [flags] [operator] <value>：定义访问控制列表。

  • use_backend <backend> [if|unless] <condition>：根据 ACL 条件选择后端。

  • default_backend <backend>：默认后端。

6.2 后端（backend）配置

  • mode {http|tcp}：指定模式。

  • balance <algorithm>：设置负载均衡算法，如 roundrobin、leastconn。

  • option httpchk <method> <uri> [version]：启用 HTTP 健康检查。

  • server <name> <address>[:port] [param*]：定义后端服务器及其参数。

6.3 监听（listen）配置

listen 段合并了 frontend 和 backend 的功能，适用于简单服务。

listen mysql-cluster
    bind *:3306
    mode tcp
    balance leastconn
    server db1 192.168.10.21:3306 check
    server db2 192.168.10.22:3306 check
6.4 server 配置详解

6.4.1 基本参数

  • name：服务器标识，用于日志和统计。

  • address[:port]：服务器地址和端口，若省略端口则继承 frontend 的端口。

  • weight <value>：服务器权重，默认1。

6.4.2 健康检查参数

  • check：启用健康检查。

  • inter <time>：检查间隔，默认2000ms。

  • rise <count>：连续成功次数后标记为正常。

  • fall <count>：连续失败次数后标记为异常。

  • port <port>：指定检查端口（不同于服务端口）。

6.4.3 其他参数

  • backup：标记为备用服务器，仅当所有非备用服务器都不可用时才启用。

  • maxconn <max>：限制到该服务器的最大并发连接数。

  • slowstart <time>：新启动服务器缓慢增加权重的时长。

7. HAProxy 热更新方法

HAProxy 支持通过 Unix Socket 动态调整配置，无需重启进程。这需要使用 socat 工具。

7.1 安装 socat
[root@haproxy ~]# dnf install -y socat
...
Complete!
7.2 查看 HAProxy 帮助与状态
[root@haproxy ~]# echo "help" | socat stdio /var/lib/haproxy/stats

输出显示所有可用的命令，如 show servers state, set weight, set server 等。

查看当前服务器状态：

[root@haproxy ~]# echo "show servers state web-servers" | socat stdio /var/lib/haproxy/stats
1 web-servers 1 web1 192.168.10.11 2 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2 web-servers 2 web2 192.168.10.12 2 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
7.3 动态调整服务器权重

将 web1 的权重调整为 2：

[root@haproxy ~]# echo "set weight web-servers/web1 2" | socat stdio /var/lib/haproxy/stats
7.4 将服务器设为维护状态与重新上线

将 web1 置为维护模式（不再接收新连接）：

[root@haproxy ~]# echo "set server web-servers/web1 state drain" | socat stdio /var/lib/haproxy/stats

重新上线：

[root@haproxy ~]# echo "set server web-servers/web1 state ready" | socat stdio /var/lib/haproxy/stats
7.5 多进程环境下的热更新配置

若启用了多进程（nbproc > 1），需为每个进程配置独立的 socket：

global
    nbproc 2
    stats socket /var/lib/haproxy/stats1 mode 600 level admin process 1
    stats socket /var/lib/haproxy/stats2 mode 600 level admin process 2

操作时指定对应的 socket 文件。

8. HAProxy 调度算法详解与选型指南

HAProxy 支持多种负载均衡算法，分为静态算法、动态算法及其他高级算法。

8.1 静态算法

  • static-rr：基于权重的轮询，权重不支持运行时调整（只能设为0或1），无慢启动。适用于无需动态调整的场景。

  • first：按服务器列表顺序分配，只有当第一台达到 maxconn 上限后才使用下一台，忽略权重。适合资源独占型任务。

8.2 动态算法

  • roundrobin：加权轮询，支持权重动态调整和慢启动。每个 backend 最多支持 4095 台服务器。默认算法，适用于大部分无状态应用。

  • leastconn：加权最少连接，新请求分配给当前连接数最少的服务器，支持动态权重和慢启动。特别适合长连接场景（如 MySQL、WebSocket）。

8.3 其他算法

  • source：对源 IP 进行哈希，确保同一客户端 IP 始终转发到同一台后端服务器。支持一致性哈希（hash-type consistent），减少后端变化时的影响。

  • uri：对 URI 的左半部分进行哈希，常用于缓存集群，提高缓存命中率。

  • url_param：对 URL 参数中的指定 key 的值进行哈希，适用于需要基于用户标识进行会话保持的场景。

  • hdr(name)：对指定 HTTP 头进行哈希，如 hdr(Host) 可实现基于域名的会话保持。

8.4 算法选型建议
业务场景 推荐算法 理由
普通 Web 应用，请求短且均匀 roundrobin 简单高效，支持动态权重调整
长连接服务（数据库、WebSocket） leastconn 平衡连接数，避免单点堆积
需要基于 IP 的会话保持 source (consistent) 同一 IP 固定后端，一致性哈希减少后端变动影响
缓存集群 uri 相同 URI 请求落到同一台缓存，提高命中率
多租户/域名路由 hdr(Host) 根据请求域名进行哈希，实现域名级别的会话保持

9. HAProxy 状态页面监控

9.1 状态页配置参数

在 listen 或 backend 中添加 stats 相关指令即可启用状态页，常用参数：

  • stats enable：启用统计。

  • stats uri <uri>：访问路径，如 /stats。

  • stats refresh <time>：页面自动刷新间隔。

  • stats auth <user>:<passwd>：启用基本认证。

  • stats admin {if | unless} <condition>：启用页面上的管理功能（如下线服务器）。

10. 基于 Cookie 的会话保持

对于需要会话保持的 HTTP 应用，可以使用 Cookie 插入模式。

10.1 Cookie 插入模式配置

在 backend 中启用 cookie 并指定服务器 cookie 值：

backend web-servers
    mode http
    balance roundrobin
    cookie SERVERID insert indirect nocache
    server web1 192.168.10.11:80 cookie s1 check
    server web2 192.168.10.12:80 cookie s2 check

参数说明：

  • cookie SERVERID：定义 cookie 名称。

  • insert：HAProxy 在响应中插入 cookie。

  • indirect：如果客户端已有 cookie，则不插入。

  • nocache：防止缓存服务器缓存带 cookie 的响应。

10.2 验证会话保持效果

使用 curl -v 观察 cookie 的传递：

[root@haproxy ~]# curl -v http://192.168.10.10
...
< Set-Cookie: SERVERID=s1; path=/
...

后续请求携带此 cookie 时，HAProxy 会根据 cookie 值将请求定向到对应服务器。

11. IP 透传技术

11.1 七层透传（HTTP 协议）

在 HTTP 模式下，HAProxy 通过 option forwardfor 在请求头中添加 X-Forwarded-For 字段，后端服务器需配置日志格式以记录该头。

frontend web-frontend
    option forwardfor except 127.0.0.0/8

后端 Nginx 需在 log_format 中添加 $http_x_forwarded_for。

11.2 四层透传（TCP 协议）

对于 TCP 模式，可以使用 PROXY protocol 传递客户端原始 IP。在 HAProxy 和后端服务器（需支持 PROXY protocol）上配置。

frontend mysql
    bind *:3306
    mode tcp
    default_backend mysql-servers

backend mysql-servers
    mode tcp
    server db1 192.168.10.21:3306 send-proxy-v2 check

后端 MySQL 需配置支持 PROXY protocol（如 MariaDB 10.2+、Percona Server 5.7+）。

12. HAProxy 访问控制列表（ACL）

ACL 是 HAProxy 实现灵活路由和访问控制的核心。

12.1 ACL 基本语法
acl <acl_name> <criterion> [flags] [operator] <value>

  • criterion：匹配条件，如 hdr(Host)、path、src 等。

  • flags：可选标志，如 -i 忽略大小写。

  • operator：匹配操作符，如 -m sub 表示子串匹配。

  • value：匹配值。

12.2 常用 ACL 匹配条件示例

hdr_end(host)：检查 hdr_end(host)：检查 Host 头是否以特定字符串结尾。

hdr_end(host)：检查 Host 头是否以特定字符串结尾。

base_sub：检查请求的完整路径（含 Host）是否包含子串。

base_reg：正则匹配 base。

path_sub：检查 URI 路径是否包含子串。

acl static_host hdr_end(host) -i .example.com
acl api_host hdr_beg(host) -i api.
acl admin_page base_sub -i /admin
acl image_req base_reg -i \.(jpg|jpeg|png|gif)$
acl php_script path_sub .php

13. 利用 ACL 实现高级访问控制

13.1 基于域名的路由
frontend web-frontend
    bind *:80
    acl host_example hdr(host) -i www.example.com
    acl host_blog    hdr(host) -i blog.example.com
    use_backend example-servers if host_example
    use_backend blog-servers    if host_blog
    default_backend web-servers
13.2 基于源 IP 网段的访问控制

拒绝某个网段访问：

frontend web-frontend
    acl blocked_net src 192.168.100.0/24
    http-request deny if blocked_net
13.3 基于浏览器类型的访问控制

禁止旧版 IE 访问：

acl ie_old hdr_sub(user-agent) -i MSIE 6.0
http-request deny if ie_old
13.4 动静分离
frontend web-frontend
    acl static_file path_end -i .jpg .png .css .js
    use_backend static-servers if static_file
    default_backend dynamic-servers

backend static-servers
    server static1 192.168.10.31:80 check

backend dynamic-servers
    server app1 192.168.10.41:8080 check

14. 自定义错误页面

14.1 配置本地错误页面

创建错误页面文件，并在 HAProxy 配置中引用：

backend web-servers
    errorfile 503 /etc/haproxy/errors/503.http

503.http 文件需包含完整的 HTTP 响应头，例如：

HTTP/1.0 503 Service Unavailable
Cache-Control: no-cache
Connection: close
Content-Type: text/html

<html><body><h1>503 Service Unavailable</h1></body></html>
14.2 配置错误页面重定向
backend web-servers
    errorloc 503 http://www.AVICIALIFE.org/error_pages/503.html

5. HAProxy 四层负载均衡示例（以 MySQL 为例）

15.1 后端 MySQL 服务器配置

在两台后端服务器上安装 MySQL，并创建测试用户。

[root@db1 ~]# dnf install -y mysql-server
[root@db1 ~]# systemctl start mysqld && systemctl enable mysqld
[root@db1 ~]# mysql
mysql> CREATE USER 'haproxy'@'192.168.10.%' IDENTIFIED BY 'password';
mysql> GRANT ALL PRIVILEGES ON *.* TO 'haproxy'@'192.168.10.%';
mysql> FLUSH PRIVILEGES;
15.2 HAProxy 四层配置
listen mysql-cluster
    bind *:3306
    mode tcp
    balance leastconn
    option tcp-check
    server db1 192.168.10.21:3306 check
    server db2 192.168.10.22:3306 check
15.3 验证四层负载均衡

使用 MySQL 客户端连接 HAProxy 的 3306 端口，查看连接分配情况。

16. HTTPS 加密访问配置

16.1 证书准备

生成自签名证书或获取权威证书，合并为 PEM 文件。

[root@haproxy ~]# mkdir /etc/haproxy/ssl
[root@haproxy ~]# cd /etc/haproxy/ssl
[root@haproxy ssl]# openssl req -x509 -newkey rsa:2048 -nodes -keyout haproxy.key -out haproxy.crt -days 365
[root@haproxy ssl]# cat haproxy.crt haproxy.key > haproxy.pem
16.2 配置 SSL Termination（前端 HTTPS，后端 HTTP）
frontend https-in
    bind *:443 ssl crt /etc/haproxy/ssl/haproxy.pem
    mode http
    default_backend web-servers

backend web-servers
    mode http
    server web1 192.168.10.11:80 check
    server web2 192.168.10.12:80 check
16.3 全站 HTTPS 配置（前后端均加密）
frontend https-in
    bind *:443 ssl crt /etc/haproxy/ssl/haproxy.pem
    mode tcp   # 使用 tcp 模式透传 SSL
    default_backend web-servers-ssl

backend web-servers-ssl
    mode tcp
    server web1 192.168.10.11:443 check
    server web2 192.168.10.12:443 check

17. 结语与生态联动

在生产环境中，HAProxy往往不是孤立存在的。它需要与周边生态组件紧密配合，才能构建出真正健壮的基础设施架构：

  • 与Keepalived联动：通过VRRP协议实现HAProxy自身的高可用。当主节点发生故障时，备用节点会自动接管虚拟IP（VIP），从而避免了负载均衡器自身的单点故障，保障了入口流量的连续性。

  • 与Nginx联动：两者可以形成优势互补。HAProxy作为四层入口，能够高效处理海量TCP连接；而Nginx则作为七层反向代理，负责精细的路由、缓存、重写等HTTP层处理。这种分层架构兼顾了性能与功能。

  • 与Kubernetes联动：HAProxy可以作为Ingress Controller的实现，动态监听Kubernetes API中Service和Endpoint的变化，实现服务的自动发现和配置更新，完美融入云原生生态。

  • 与BGP/ECMP联动：通过BGP协议和ECMP（等价多路径）技术，可以将流量平均分发到多台HAProxy实例，突破单机的性能瓶颈，实现负载均衡层的水平扩展，支撑更大规模的业务。

    # linux # 运维
    Logo
    开源鸿蒙跨平台开发者社区

    开源鸿蒙跨平台开发社区汇聚开发者与厂商，共建“一次开发，多端部署”的开源生态，致力于降低跨端开发门槛，推动万物智联创新。

    更多推荐

    OpenHarmony-Flutter环境搭建指导

    下载地址：https://git-scm.com/install/windows点击下载并安装：安装过程不用更改任何选项，安装路径可以看个人习惯更改下载链接：https://www.oracle.com/java/technologies/javase/jdk17-archive-downloads.html点击下载并安装：下载地址：https://developer.huawei.com/con

    avatar 开源鸿蒙跨平台开发者社区

    flutter_exit_app 鸿蒙化适配全流程攻略（含踩坑实录）

    在 Flutter 鸿蒙化（OpenHarmony/ArkUI-X）开发过程中，第三方插件适配是核心难点之一。flutter_exit_app 作为常用的应用退出插件，默认仅支持 Android 和 iOS 平台，无法直接在鸿蒙设备上使用。本文将详细记录 flutter_exit_app 插件鸿蒙化适配的完整实操流程，包含环境搭建、代码适配、远程提交、常见问题及解决方案，全程贴合实战，新手也能跟着

    avatar 开源鸿蒙跨平台开发者社区

    Flutter 三方库 flutter_animate 的鸿蒙化适配指南

    flutter_animate 库在 Flutter for OpenHarmony 平台上的适配过程非常顺利。作为一个纯 Dart 实现的库，它无需任何原生适配即可在 OpenHarmony 设备上运行。animate() 扩展方法、then() 链式调用、各种内置动画效果均表现正常，性能稳定可靠。使用 flutter_animate 后，我们的动画代码量减少了约百分之五十五，动画相关的 Bug

    avatar 开源鸿蒙跨平台开发者社区