13.3.3 前端与后端（frontend/backend）定义与流量模型

前端与后端（frontend/backend）定义与流量模型#

frontend 用于接收客户端连接，定义监听地址、端口、协议与入口规则；backend 用于承载真实服务，定义服务器池、负载均衡与健康检查。典型流量模型为：客户端请求进入 frontend → 依据 ACL/规则选择 backend → backend 进行负载均衡并将请求转发到 server。

原理草图（流量模型）

frontend 关键要素
- bind：监听地址与端口（如 0.0.0.0:80、*:443）。
- mode：工作模式（http/tcp），决定可用的规则与日志格式。
- default_backend：未匹配规则时的默认后端。
- acl 与 use_backend：基于 Host、Path、Header、SNI 等进行分流。
- http-request：请求级处理（重写、添加头、阻断等）。

backend 关键要素
- mode：与 frontend 保持一致（http/tcp）。
- balance：负载均衡算法（roundrobin、leastconn、source 等）。
- server：后端实例定义（IP/端口、权重、健康检查、连接限制）。
- option httpchk/tcp-check：健康检查方式。
- cookie/stick-table：会话保持与粘性。

安装与启用（基于 Debian/Ubuntu）

# 安装
apt update && apt install -y haproxy

# 查看版本
haproxy -v

# 配置文件路径
ls -l /etc/haproxy/haproxy.cfg

# 启动并设置开机自启
systemctl enable --now haproxy

# 查看状态
systemctl status haproxy --no-pager

完整可执行示例（HTTP 按 Host 分流）

# 文件：/etc/haproxy/haproxy.cfg
global
  log /dev/log local0
  maxconn 4000
  daemon

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

frontend fe_web
  bind *:80
  mode http
  acl host_app hdr(host) -i app.example.com
  acl host_api hdr(host) -i api.example.com
  use_backend be_app if host_app
  use_backend be_api if host_api
  default_backend be_app

backend be_app
  mode http
  balance roundrobin
  option httpchk GET /health
  server app1 10.0.0.11:8080 check
  server app2 10.0.0.12:8080 check

backend be_api
  mode http
  balance leastconn
  option httpchk GET /health
  server api1 10.0.0.21:9000 check
  server api2 10.0.0.22:9000 check

验证与请求示例

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

# 重新加载（不中断连接）
systemctl reload haproxy

# 模拟 Host 请求（在客户端）
curl -H "Host: app.example.com" http://<LB_IP>/
curl -H "Host: api.example.com" http://<LB_IP>/

# 预期：请求分流到对应后端，健康检查通过时响应正常

TCP 模式示例（以 MySQL 为例）

# 文件：/etc/haproxy/haproxy.cfg
frontend fe_mysql
  bind *:3306
  mode tcp
  default_backend be_mysql

backend be_mysql
  mode tcp
  balance source
  option tcp-check
  server db1 10.0.0.31:3306 check
  server db2 10.0.0.32:3306 check

排错与日志定位

# 1) 配置检查失败时的常见原因：拼写错误、缩进不影响但关键字需正确
haproxy -c -f /etc/haproxy/haproxy.cfg

# 2) 后端不可用时，查看服务状态
systemctl status haproxy --no-pager

# 3) 查看系统日志（是否有 health check 失败）
journalctl -u haproxy -n 100 --no-pager

# 4) 临时提升日志级别（需要 global/defaults 配置 log）
#   确保 rsyslog/rsyslogd 正常转发 local0

常见注意点
- frontend 与 backend 的 mode 必须匹配，否则规则或日志行为异常。
- default_backend 建议必配，避免无匹配请求被拒绝。
- ACL 顺序与规则冲突会影响路由，建议先定义再使用。
- 连接限制（maxconn）应在 frontend 与 server 两端协同设置，避免拥塞。

练习
1. 将 be_app 的算法改为 leastconn，并观察请求分配差异。
2. 为 fe_web 增加按 Path 分流规则（/api 走 be_api）。
3. 故意将一个后端地址改错，观察 journalctl -u haproxy 中的健康检查日志并恢复。
4. 增加 http-request set-header X-Forwarded-Proto https，验证后端收到的头部变化。