HAProxy 系列（四）：多中间件统一 VIP 入口 — 架构模式与最佳实践

上篇回顾

上一篇讲了 ACL 条件路由、会话保持和三层限流架构。这一篇进入一个实战架构模式：用 HAProxy + Keepalived 为多个中间件（MySQL、Redis、Kafka、ES、etcd、MongoDB）提供统一 VIP 入口。

一、问题场景：中间件越来越多

没有统一入口时的困境

复制代码

MySQL 连 10.0.0.1:3306
Redis 连 10.0.0.2:6379
Kafka 连 10.0.0.3:9092
ES    连 10.0.0.4:9200
etcd  连 10.0.0.5:2379
Mongo 连 10.0.0.6:27017

→ 6 个中间件，6 个 IP，配置复杂
→ 扩容时客户端配置也要改
→ 某个中间件后端扩缩容，所有客户端都要改连接地址

统一入口后的架构

复制代码

所有客户端只管连 VIP:端口
  MySQL → VIP:3306
  Redis → VIP:6379
  Kafka → VIP:9092
  ES    → VIP:9200
  etcd  → VIP:2379
  Mongo → VIP:27017

后端 IP 变化 → 只改 HAProxy 配置，客户端不改

架构图

复制代码

                    ┌─────────────────────────────────┐
                    │         VIP: 192.168.1.200       │
                    │     HAProxy (统一入口)           │
                    ├─────────────────────────────────┤
                    │  :3306   :6379   :9092  :9200   │
                    │  :2379   :27017                 │
                    └──────┬──────┬──────┬───────────┘
                           │      │      │
              ┌────────────┘      │      └──────────────┐
              ▼                   ▼                     ▼
        ┌──────────┐      ┌──────────┐          ┌──────────┐
        │ MySQL    │      │ Redis    │          │ Kafka    │
        │ 主+从    │      │ 主+从    │          │ 3节点    │
        └──────────┘      └──────────┘          └──────────┘

二、完整配置示例

全局配置

haproxy 复制代码

global
    daemon
    maxconn 4000
    user haproxy
    group haproxy

defaults
    mode tcp
    timeout connect 5s
    timeout client 30s
    timeout server 30s
    retries 3

1. MySQL --- roundrobin + TCP 检查

haproxy 复制代码

frontend mysql-in
    bind *:3306
    default_backend mysql-servers

backend mysql-servers
    balance roundrobin
    option mysql-check user haproxy_check
    server mysql1 10.0.0.1:3306 check inter 5s fall 3 rise 2
    server mysql2 10.0.0.2:3306 check inter 5s fall 3 rise 2

说明：MySQL 短连接多，roundrobin 即可；mysql-check 用 MySQL 协议探测，比 TCP 检查更准确。

2. Redis --- first + backup 主从模式

haproxy 复制代码

frontend redis-in
    bind *:6379
    default_backend redis-servers

backend redis-servers
    balance first
    option tcp-check
    tcp-check send PING\r\n
    tcp-check expect string +PONG
    server redis-master 10.0.0.1:6379 check inter 1s
    server redis-slave1 10.0.0.2:6379 check inter 1s backup
    server redis-slave2 10.0.0.3:6379 check inter 1s backup

说明：Redis 是主从架构，用 first + backup 确保写请求只到 master；PING/PONG 检查比 TCP 更准确。

3. Kafka --- source 哈希（客户端会话保持）

haproxy 复制代码

frontend kafka-in
    bind *:9092
    default_backend kafka-brokers

backend kafka-brokers
    balance source
    server kafka1 10.0.0.1:9092 check inter 5s
    server kafka2 10.0.0.2:9092 check inter 5s
    server kafka3 10.0.0.3:9092 check inter 5s

说明：Kafka 客户端与特定 broker 保持长连接，用 source 哈希保证同一客户端始终连到同一 broker。

4. Elasticsearch --- leastconn + HTTP 健康检查

haproxy 复制代码

frontend es-in
    bind *:9200
    mode http
    default_backend es-nodes

backend es-nodes
    mode http
    balance leastconn
    option httpchk GET /_cluster/health
    http-check expect status 200
    server es1 10.0.0.1:9200 check inter 5s
    server es2 10.0.0.2:9200 check inter 5s
    server es3 10.0.0.3:9200 check inter 5s

说明：ES 查询请求多、响应时间差异大，leastconn 最优；/_cluster/health 检查集群级别健康。

5. etcd --- roundrobin + HTTP 健康检查

haproxy 复制代码

frontend etcd-in
    bind *:2379
    mode http
    default_backend etcd-nodes

backend etcd-nodes
    mode http
    balance roundrobin
    option httpchk GET /health
    http-check expect string true
    server etcd1 10.0.0.1:2379 check inter 5s
    server etcd2 10.0.0.2:2379 check inter 5s
    server etcd3 10.0.0.3:2379 check inter 5s

说明：etcd 客户端自带重连和故障转移，roundrobin 即可；/health 返回 {"health":"true"} 表示节点健康。

6. MongoDB --- roundrobin + TCP 检查

haproxy 复制代码

frontend mongo-in
    bind *:27017
    default_backend mongo-replicaset

backend mongo-replicaset
    balance roundrobin
    server mongo1 10.0.0.1:27017 check inter 5s
    server mongo2 10.0.0.2:27017 check inter 5s
    server mongo3 10.0.0.3:27017 check inter 5s

说明：MongoDB 驱动自己做主从切换和读写分离，HAProxy 只做负载均衡。

三、各中间件配置要点速查

中间件	推荐算法	健康检查	注意事项
MySQL	roundrobin	mysql-check 或 TCP	读写分离需额外方案（如 ProxySQL）
Redis	first + backup	tcp-check PING/PONG	主从架构，写请求只到 master
Kafka	source	TCP	同一客户端保持同一 broker
ES	leastconn	HTTP /_cluster/health	查询多且响应差异大
etcd	roundrobin	HTTP /health	客户端自带重连，HAProxy 只做负载
MongoDB	roundrobin	TCP	驱动自己处理主从切换

核心原则

算法选择看连接特性：短连接 roundrobin → 长连接 leastconn → 状态保持 source
健康检查选最准的：有协议层检查就用协议层，没有就用 HTTP，最后才是 TCP
每个中间件独立 frontend：同 IP 不同端口，配置隔离，故障互不影响
后端扩缩容只改 HAProxy：客户端只管连 VIP:端口，不关心后端 IP 变化

四、架构模式总结

这个"一个 HAProxy 统一多个中间件"的模式，本质上是四层代理的架构抽象：

复制代码

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  客户端      │ ──→ │  VIP:端口    │ ──→ │ 后端中间件   │
│  (应用)      │     │  (HAProxy)   │     │  (集群)      │
└──────────────┘     └──────────────┘     └──────────────┘
                            │
                    解耦了客户端和后端
                    客户端只认 VIP:端口
                    后端变化对客户端透明

这个模式的好处

配置简化：N 个中间件只需要 1 个 VIP，客户端配置量减少 N 倍
扩缩容透明：后端节点增减，客户端无需任何变更
故障隔离：某个中间件后端故障，HAProxy 自动摘除，不影响其他中间件
统一治理：健康检查、限流、日志、监控都在 HAProxy 层统一管理

与 Keepalived 配合

这个配置通常与 Keepalived 配合部署，实现 HAProxy 自身的高可用：

复制代码

                    VIP: 192.168.1.200
                           │
             ┌─────────────┴─────────────┐
         HAProxy A                    HAProxy B
         Keepalived MASTER             Keepalived BACKUP

下一篇将进入 Keepalived 系列，详细讲解 VRRP 原理、参数调优和生产最佳实践。

本期总结

一个 HAProxy 可以为多个中间件提供统一 VIP 入口，每个中间件一个 frontend
算法选择：短连接用 roundrobin，长连接用 leastconn，有状态用 source
健康检查优先用协议层检查，其次 HTTP，最后 TCP
所有中间件共享同一个 VIP，客户端只认 VIP:端口
后端扩缩容对客户端透明，只改 HAProxy 配置即可