首先，本文主要从应用角度来讲讲HAProxy的常规用法，不会涉及到特别深的东西，另外本文涉及到的实例都是在ubuntu系统下进行的。
1. 方法论
HAProxy是一个开源的可提供高可用性、负载均衡的软件，支持传输层(L4)和应用层(L7)的负载均衡能力，功能丰富，从性能和稳定性上来讲基本能媲美商用的负载均衡软件，因此目前使用非常广泛。
软件特性
- 支持L4和L7两种负载均衡的能力；
- 支持健康检查；
- 支持状态网页监控；
- 支持SSL，能够解析https协议；
- 支持会话保持；
2. L4和L7负载均衡的区别
L4的负载均衡
L4的负载均衡是通过L3转发的IP，加上L4的端口来决定哪些流量需要做负载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。
L7的负载均衡
L7的负载均衡是在L4的基础上，除了通过IP+端口外，还可以通过URL、头信息、浏览器等等应用层的信息来决定哪些流量需要做负载均衡。
3. HAProxy的健康检查
HAProxy的健康检查功能一般配置在backend或者listen区域，最简单的配置即：option httpchk，也就是检查web服务器站点的根目录是否存在，不可靠无法保证后端的服务可用；此外如果后端Web服务器用的是nginx，我们需要在nginx配置http options方法的可用，因为此时健康检查是通过http的options方法来获取web服务器的根目录，否则HAProxy会报405。实际使用中建议采用下面两种健康检查的方式：
- option httpchk get /xxx.html # 获取某个静态文件
- option httpchk HEAD /xxx.html HTTP/1.1\r\nHost:\ www.xxx.com # 获取某个静态文件的同时匹配头信息
4. HAProxy网页统计监控功能
HAProxy支持网页统计功能，配置非常简单，下面给个具体的实例可参照如下：
listen stats
bind 10.5.1.54:10000 # 页面监控功能绑定的ip及端口号
stats uri /haproxy_stats # haproxy页面监控的uri
stats enable # 打开页面监控功能
stats hide-version # 在页面隐藏haproxy版本信息，出于安全考虑
stats refresh 10s # 监控页面刷新时间
stats realm HAProxy\ Stats # 监控页面的认证提示，需要认证时这个配置才有意义
stats auth admin:admin # 监控认证的用户名及密码
-
然后我们在浏览器输入其上配置uri就能打开haproxy的监控页面了：
从haproxy的监控页面我们可以及时侦测到各个后端服务的状态及当前的连接请求数目等信息。
5. 解析https协议
说到HTTPS就不得不提到SSL了，而haproxy的https的配置首先我们得准备个SSL证书，有关SSL证书的创建还请移步：创建HAProxy SSL证书，此处就不多做赘述，下面直接说配置了：
- http和https共存
frontend fe01
bind *:80 # http
bind *:443 ssl crt /path/to/xxx.pem # https
mode http
default_backend backend_server01 # 后端代理server，下面配置会讲到
- only https
frontend fe01
bind *:80
bind *:443 ssl crt /path/to/xxx.pem # https
redirect scheme https if ! {ssl_fc} # 如果是http则重定向到https的url
mode http
default_backend backend_server01
6. 支持会话保持
HAProxy的会话保持策略有好几种，下面仅讲述最常见的两种：
IP Hash
这种策略跟Nginx的ip_hash基本类似，对于同一个源ip的客户端请求都会发送到同一台后端服务器；但是如果多个客户端通过代理或者地址转换访问服务器时，由于源IP相同请求都被分配到同一台服务上，这样这台服务器压力就会比较大。另外这种策略常常会用在L4负载均衡上，配置参数很简单：balance source。cookie
这是L7负载均衡会话保持的一个策略，用户在第一次请求时会插入一个cookie，等到下一次请求时会带着这个cookie，从而达到前后端会话保持的目的，参数配置可参考如下：
listen example_service
...
cookie insert indirect nocache
server node-4 192.168.0.8:3001 check cookie xxxx ## 其中xxxx、yyyy是检测的cookie的值
server node-5 192.168.0.12:3001 check cookie yyyy
7. 常规配置用法
有关HAProxy参数的配置上文中也零零散散地涉及到一些，本节将详细解释常用的haproxy参数配置。
首先haproxy的参数配置有五大快，分别是global、defaults、frontend、backend和listen，而配置文件分两部分：/etc/haproxy/haproxy.cfg和/etc/haproxy/conf.d/*，通常会把global和defaults的配置放到haproxy.cfg，实际的代理配置都放到haproxy的conf.d目录下面，然后在haproxy.cfg通过include conf.d/*.cfg来实现一个完整的haproxy的配置。下面从配置放置的路径来看看haproxy常用的配置参数吧。
- haproxy.cfg包括global和defaults配置，global是haproxy的全局配置，而defaults则对应默认的代理配置，下面通过一个实例来说明：
global
daemon # 指定haproxy服务后台模式运行
user haproxy # haproxy进程所述用户
group haproxy # haproxy进程所述用户组
log /dev/log local0 # 日志输出配置，最多可设置两个，一般这块跟rsyslog紧密相连
maxconn 16000 # haproxy同时能处理最大连接数
pidfile /var/run/haproxy.pid # haproxy进程pid保存文件
spread-checks 3 # 在haproxy后端有着众多服务器的场景中，在精确的时间间隔后统一对众服务器进行健康状况检查可能会带来意外问题；此选项用于将其检查的时间间隔长度上增加或减小一定的随机时长；
stats socket /var/lib/haproxy/stats # 开启haproxy网页监控功能及对应的socket
defaults
log global # 指定日志配置使用global的log配置
maxconn 8000 # 单个代理实例同时允许的最大连接数
mode http # 实例运行模式，tcp或http
option redispatch # 连接失败时会话是不是重新分发
option http-server-close # 一旦服务端响应过后server端的连接关闭
option splice-auto # 启动套接字的内核自动加速
option dontlognull # 没有数据传输的请求连接不记录log
retries 3 # 请求连接失败的retry次数
timeout http-request 20s # 创建连接后客户端没能完整发送http请求的超时时间
timeout queue 1m # 队列等待连接空闲的超时时间
timeout connect 10s # 创建连接的超时时间
timeout client 1m # 创建连接后客户端持续不发送请求的超时时间
timeout server 1m # 后端服务的响应超时时间
timeout check 10s # 健康检查的请求响应超时时间
include conf.d/*.cfg # 具体的实例配置(可能包括frontend、backend、listen的实例)
- conf.d/*.cfg
这一块的配置文件可能会涉及到frontend(前端实例)、backend(后端实例)和listen(前端+后端)三种类型的配置，下面各给出实例以作说明：
frontend frontend_server01
bind *:3001 # 前端服务监听端口
maxconn 3000 # 此端口的最大连接数目
default_backend default_servers # 默认使用的后端server
backend default_servers
balance source # 负载均衡的算法，这里采用ip hash
option httpchk # 开启健康检查功能
option httplog # 开启http log
option httpclose
timeout server 600s # 后端server响应haproxy请求的超时时间
server node-4 192.168.0.8:3001 check inter 10s fastinter 2s downinter 3s rise 3 fall 3 # 配置后端server，可设置haproxy健康检查及间隔时间还可根据server的状态通过fastinter和downinter来优化延迟、判断该server是UP还是DOWN的机制等，在此配置连续三次检查成功才认为server是UP，而连续三次检查失败则认为server是DOWN
server node-3 192.168.0.11:3001 check inter 10s fastinter 2s downinter 3s rise 3 fall 3
server node-5 192.168.0.12:3001 check inter 10s fastinter 2s downinter 3s rise 3 fall 3
listen ripple
bind 192.168.0.3:3000,10.5.1.54:3000
http-request set-header X-Forwarded-Proto https if { ssl_fc }
balance source
option httpchk
option httplog
option httpclose
timeout server 600s
server node-4 192.168.0.8:3000 check inter 10s fastinter 2s downinter 3s rise 3 fall 3
server node-3 192.168.0.11:3000 check inter 10s fastinter 2s downinter 3s rise 3 fall 3
server node-5 192.168.0.12:3000 check inter 10s fastinter 2s downinter 3s rise 3 fall 3
listen其实是把前端和后端的配置放一块了，配置的参数可用时参照前端和后端的配置，更详细的配置参数的说明则可参照HAProxy配置参数详细说明，此处就不一一举例解释了。