13.1.2 典型应用场景与业务模式

2. 典型应用场景与业务模式#

HAProxy常用于承载高并发入口、协议代理与流量治理。为便于理解典型场景与业务模式，先给出通用原理草图与基础安装示例，再按场景给出配置与验证命令。

原理草图（通用入口）

文章图片

安装与基础启动（示例）

# 以CentOS/RHEL为例
yum install -y haproxy

# 查看版本与特性
haproxy -vv

# 启动与开机自启
systemctl enable --now haproxy

# 验证进程与监听端口
ss -lntp | grep haproxy

场景1：Web与API入口层负载均衡（HTTP/HTTPS）#

业务模式：单入口多服务、灰度发布、A/B测试

示例配置（/etc/haproxy/haproxy.cfg）

global
  log /dev/log local0
  maxconn 20000
  daemon

defaults
  log global
  mode http
  timeout connect 5s
  timeout client  30s
  timeout server  30s

frontend fe_http
  bind *:80
  acl is_v2 path_beg /v2
  use_backend be_api_v2 if is_v2
  default_backend be_api_v1

backend be_api_v1
  balance roundrobin
  server api1 10.0.0.11:8080 check
  server api2 10.0.0.12:8080 check

backend be_api_v2
  balance roundrobin
  server api3 10.0.0.13:8080 check

验证命令

# 语法检查
haproxy -c -f /etc/haproxy/haproxy.cfg

# 重载
systemctl reload haproxy

# 访问验证
curl -I http://<vip>/v1/health
curl -I http://<vip>/v2/health

排错要点
- curl超时：检查timeout设置与后端端口防火墙
- 访问总是到同一台：检查balance算法与后端健康状态
- 规则不生效：确认ACL与use_backend的顺序

场景2：四层TCP代理与中间件访问层#

业务模式：统一入口、读写分离、跨机房访问

示例配置（TCP MySQL代理）

defaults
  log global
  mode tcp
  timeout connect 5s
  timeout client  1m
  timeout server  1m

frontend fe_mysql
  bind *:3306
  default_backend be_mysql

backend be_mysql
  balance leastconn
  option tcp-check
  server db1 10.0.1.11:3306 check
  server db2 10.0.1.12:3306 check backup

验证命令

# 从客户端测试
mysql -h <vip> -P 3306 -u test -p

# 查看后端健康
echo "show stat" | socat stdio /run/haproxy/admin.sock

排错要点
- 连接拒绝：确认后端数据库监听与安全组/防火墙
- 频繁断连：适当调整timeout client/server
- 读写分离需规则：结合ACL或单独前端区分端口

场景3：高可用与故障转移入口（与Keepalived）#

业务模式：双机热备、VIP漂移

架构草图

文章图片

验证命令

# 检查VIP漂移
ip a | grep <VIP>

# 主备切换验证（停主）
systemctl stop haproxy

排错要点
- VIP不漂移：检查Keepalived状态与优先级配置
- 切换慢：检查advert_int与心跳网络

场景4：多租户与多业务隔离#

业务模式：业务分域、路径与Host隔离

示例配置（Host隔离）

frontend fe_host
  bind *:80
  acl is_team_a hdr(host) -i a.example.com
  acl is_team_b hdr(host) -i b.example.com
  use_backend be_team_a if is_team_a
  use_backend be_team_b if is_team_b

backend be_team_a
  server a1 10.0.2.11:8080 check

backend be_team_b
  server b1 10.0.2.21:8080 check

验证命令

curl -H "Host: a.example.com" http://<vip>/
curl -H "Host: b.example.com" http://<vip>/

场景5：安全与合规入口（SSL终止、限流）#

业务模式：统一证书、入口安全策略

示例配置（SSL终止 + 简单限流）

frontend fe_https
  bind *:443 ssl crt /etc/haproxy/certs/site.pem
  http-request deny if { src_conn_cur gt 100 }
  default_backend be_web

backend be_web
  server web1 10.0.3.11:8080 check

验证命令

# 查看证书链与握手
openssl s_client -connect <vip>:443 -servername example.com

# 访问测试
curl -k https://<vip>/

排错要点
- TLS握手失败：检查证书链与crt路径权限
- 频繁被拒：调整限流阈值src_conn_cur

场景6：混合架构与云原生过渡#

业务模式：传统集群 + 容器服务共存

示例配置（后端包含容器与物理机）

backend be_mix
  balance roundrobin
  server vm1 10.0.4.11:8080 check
  server pod1 172.17.0.21:8080 check
  server pod2 172.17.0.22:8080 check

验证命令

curl http://<vip>/health

典型业务模式总结#

  • 单入口多服务：统一入口，后端多集群
  • 业务分域：按Host/路径隔离
  • 多层转发：公网入口 → 内网HAProxy → 应用集群
  • 灰度发布：ACL/权重控制流量

练习题#

  1. 将场景1中的be_api_v2设置为仅10%流量（使用weight），并验证请求分布。
  2. 将场景2的MySQL代理增加backup节点，模拟主节点故障并验证切换。
  3. 结合场景4与5，实现b.example.com强制HTTPS访问。