企业官网建设流程全解析

前阵子线上深夜告警，一批接口的P99延迟从80ms直接飙到3秒，重启后端服务也只能撑十几分钟，最后查下来问题居然出在HAProxy的超时配置上——不是后端的锅，是我把timeout server设得太短，导致慢请求被反复掐断重试，把数据库连接池直接打爆。那次之后我把HAProxy的超时配置和负载均衡算法整套重推了一遍，这篇文章就当作那轮折腾的完整复盘。

我一直觉得，负载均衡器是那种“平时没存在感、出问题全是大事”的组件。HAProxy作为四层到七层的流量入口，它的超时配置直接决定后端能容忍多慢、前端能等多久，而负载均衡算法的选择又决定每一台后端机器被分配的流量是否合理。这篇内容适合正在维护HAProxy做接入层、或者打算从Nginx切换到HAProxy的运维和开发同学，里面没有多少高深理论，基本都是可以直接抄走的落地配置和排障思路。

1. 实例引入：一次线上超时故障让我重新审视超时配置

1.1 故障现象

那是一个典型的电商大促后的淡季深夜，流量并不高，但监控突然报警：order-service的接口错误率超过15%，而且表现非常诡异——服务进程还活着，CPU和内存都不高，但大量请求在客户端表现为“连接超时”或“504 Gateway Timeout”。

我先查了应用日志，发现Spring Boot应用本身没有抛出明显的业务异常，也没有OOM。再查数据库，慢查询日志里出现了一批执行时间在2秒左右的update语句，但量不足以解释全部超时。最后打开HAProxy的stats页面，发现一个让我意外的情况：backend order-service下的两台服务器，qcur（当前队列）和ctime（连接建立时间）都异常，而且一台上游服务器的eresp（响应错误计数）在持续增长。

1.2 第一时间排除的误区

很多人的第一反应是“后端处理不过来，加机器”。但那台机器的负载其实很低，加机器可能暂时掩盖问题，却不可能解决根因。第二反应是“数据库慢，优化SQL”，可那条update语句平时执行也就几十毫秒，为什么深夜反而变慢？

我当时的判断逻辑是：既然后端应用本身负载低、数据库慢查询是结果而非原因，那么问题很可能出在流量入口——HAProxy把请求发送给后端之后，等待响应的超时设置是否合理，直接决定了慢请求是被耐心等待还是被强制断开。

1.3 根因定位

查看HAProxy配置后，我发现当时的全局配置是这样的默认值：

timeout connect 5000 timeout client 50000 timeout server 30000

初看没什么问题：连接后端5秒超时，客户端50秒超时，后端响应30秒超时。但问题出在后端的Tomcat线程池和数据库连接池在这种配置下的连锁反应。

当某一刻数据库出现轻微抖动，某个接口的响应时间从100ms涨到2.8秒。第一次请求被HAProxy正常转发并等待，2.8秒后返回成功。如果只是这样，一切还好。但麻烦在于，HAProxy的超时时间是从请求被转发的时刻开始计算的，如果后端处理了2.8秒，距离30秒还很远，请求其实不会超时。那么问题的真正原因是什么？

是客户端超时。上游的移动端App网关设置的读超时是3秒，但HAProxy的timeout client是50秒。App网关等不到响应，立刻重试。重试的请求又堆积到后端，Tomcat的线程池很快被占满，后续请求排进HAProxy的队列，qcur开始上涨，最终雪崩。

这个案例说明，超时配置不是越大越好，也不是越小越好，而是要和整条链路的上下游匹配。HAProxy的timeout client如果比客户端网关的读超时大很多，等于允许后端占用资源更久，但客户端早就放弃了。反过来，如果服务端超时设置过短，一个正常的慢查询会被HAProxy强行断开，而后端还在继续执行，浪费数据库资源。

2. 超时配置拆解：timeout家族里的参数到底该怎么设

2.1 四个最基础的超时参数

HAProxy的超时配置主要在defaults段和listen/backend段中声明，以timeout关键字开头。最常用的四组如下：

这四个参数是配置HAProxy时绕不开的基础，但这其中有个非常常见的误区：timeout connect只影响建立TCP连接的过程，并不包含后端处理请求的时间。如果你把timeout connect设得很长，比如10秒，它只能容忍后端机器响应慢或者端口不可达的情况，不能容忍应用处理慢。

2.2 容易被忽略的timeout tunnel、client-fin与http-request

除了上面四个，还有两个在生产环境中非常重要的超时参数。

timeout tunnel

当HAProxy运行在TCP模式并且承担WebSocket、长轮询等场景时，客户端和后端之间会建立一条长时间的隧道连接。在这种模式下，timeout client和timeout server如果还按普通HTTP请求的短超时设置，会导致正常的WebSocket连接被无故切断。正确的做法是单独设置：

timeout tunnel 1h

但请注意，timeout tunnel一旦设置，会覆盖timeout client和timeout server，所以如果你在一个既有普通HTTP又有WebSocket的端口上混用，需要小心处理。建议把WebSocket拆成独立的backend或独立的前端端口。

timeout http-request

这个参数针对HTTP模式，控制接收完整HTTP请求头的时间。它可以防止慢速攻击：一个客户端开了连接却一直不发送完整请求头，占用HAProxy的连接槽。默认情况下，HAProxy用timeout client来兜底，但更推荐显式设置：

timeout http-request 10s

对于公网入口，我通常设置成5-10秒。如果业务有上传大文件的场景，过短的http-request超时会让上传请求在传输头部阶段就被切断，这时候需要适当放宽。

2.3 超时的优先级与生效规则：为什么改了不生效

总有人改完超时配置后发现不起作用，多半忽略了一个细节：timeout指令在defaults、frontend、listen、backend段有不同的作用范围。如果你在frontend里设置了timeout client，但backend里设置了更长的timeout server，那么在转发链路中，两段各自生效，并不存在“哪个统一覆盖全局”的说法。

更常见的问题是把timeout client写在defaults里，然后在某个backend里只覆盖了timeout server，却忘了timeout client也需要同步调整。真实环境里前后端超时经常需要联动修改，我建议把超时参数统一整理成一个规范表格，每次调整都按完整链路核对。

3. 负载均衡算法选型：为什么我重点推荐leastconn

3.1 HAProxy常见负载均衡算法

HAProxy的负载均衡算法非常多，生产上常用的有：

• roundrobin：轮询，每个后端服务器按顺序轮流接收请求，权重可调。
• static-rr：静态轮询，权重调整不能动态生效。
• leastconn：最少连接数，优先把请求分给当前活跃连接数最少的服务器。
• first：优先选择编号最小的可用服务器，多用于热备场景。
• source：按客户端源IP哈希，常用于会话保持。
• uri：按请求URI哈希，适合缓存类场景。
• hdr：按指定HTTP头哈希，比如按用户ID或设备ID。

3.2 不同算法的适用场景

如果是清一色的无状态API服务，机器配置也差不多，用roundrobin是最省心的。它的优点是绝对均匀，不会出现某台机器连接数明显偏高的情况，缺点是它只考虑“每个请求轮流一次”，不考虑后端处理速度的差异。如果一台机器性能弱一些，或者某个请求格外耗时，那么分配给它的连接可能一直被占用，后面的请求仍然会轮询到它，造成堆积。

source哈希适合需要按用户粒度路由的场景，比如一个用户的请求始终落到同一台机器，可以利用本地缓存。但哈希算法最大的问题是当后端节点数量变化时，会引发较大的重新映射，对缓存命中率不友好。

我真正想重点说的是leastconn。从名字就能看出，它每次选择当前活跃连接数最少的服务器。这个算法在长连接和高并发场景下非常实用。比如WebSocket服务、消息推送服务，或者接口处理时间波动很大的系统，用leastconn能把连接均匀摊到压力最小的机器上。

有人问，如果每台后端机器处理速度差不多，leastconn会不会反而导致分配不均匀？实际上不会。因为请求到达频率是随机的，活跃连接数低的机器本来就应该承担更多新请求，这是很自然的“水往低处流”效果。

3.3 leastconn实战中的权重配合

leastconn和权重不是二选一的关系。我们可以给性能强的机器配置更大的权重，HAProxy在选择最少连接数时，会同时考虑权重。配置方式如下：

backend order-service balance leastconn server app-01 192.168.1.11:8080 weight 2 check server app-02 192.168.1.12:8080 weight 1 check

这里app-01的权重是2，app-02的权重是1，意味着在连接数相近时，app-01会被优先选中。实测下来，这种搭配在服务性能差异明显的场景，能比单纯roundrobin提升不少吞吐量。

有一个细节：leastconn对短连接HTTP请求的效果和roundrobin差距其实没有想象中那么大，因为HTTP短连接的存活时间很短，连接数波动很快。但如果你的后端是Tomcat、Node.js这类对并发连接敏感的服务，leastconn仍然更稳。它最大的好处是避免某台机器因为一个慢请求堆积了大量连接，而其他机器却闲着。

3.4 会话保持场景下的算法取舍

业务里如果需要会话保持，比如Cookie里有登录态，要求同一个用户始终打到同一台后端机器，很多人会用source。但source有个问题，一旦用户网络环境变化（从Wi-Fi切到4G），源IP可能改变，导致路由到不同机器。更稳妥的做法是依靠应用层会话共享，让HAProxy专注做负载均衡，不做过多的会话粘滞。如果非要粘滞，可以在HTTP模式下配置cookie指令，让HAProxy在后端选择后种下Cookie，后续请求按Cookie路由，这种方式比source更可靠。

4. HAProxy与Nginx在负载均衡上的差异：什么时候该换

4.1 四层与七层的根本区别

很多人都会纠结：有了Nginx，为什么还要用HAProxy？它们都能做负载均衡，有什么区别？

最简单的理解：Nginx本质上是一个Web服务器，负载均衡是它的重要功能之一，但它的核心还是处理HTTP协议，工作在七层。而HAProxy的看家本领是四层负载均衡，也就是基于TCP/UDP层的流量转发，同时也支持七层HTTP模式。

这个底层差异决定了两个组件在数据路径上的表现。HAProxy处理纯TCP流量时，不关心应用层协议，可以做端口转发、数据库读写分离、Redis代理等；Nginx则很难直接代理MySQL这类非HTTP协议。如果你的架构里有多种非HTTP业务要统一接入，HAProxy是更合适的入口。

4.2 健康检查机制的差异

健康检查是负载均衡器非常重要的能力。HAProxy的健康检查非常精细，支持TCP检查、HTTP检查、自定义预期响应内容等。比如我可以检查后端接口返回的JSON中是否包含"status":"UP"，这比Nginx那种简单的TCP探测更符合业务实际情况。

backend api-server balance leastconn option httpchk GET /healthcheck http-check expect status 200 server api-01 192.168.1.21:8080 check

Nginx在商业版中也有比较强的健康检查能力，但开源版主要依赖max_fails和fail_timeout组合，只能做到“连续失败N次后摘除”，不能对返回内容做精细判断。如果你的团队已经把健康检查标准定义到了HTTP状态码和响应体层面，HAProxy会更顺手。

4.3 高并发下的行为差异

在高并发连接场景，HAProxy的事件模型和内存管理是为“每秒钟成千上万个新建连接”设计的，在四层转发模式下，它的性能损耗非常小。Nginx的七层处理则要解析HTTP头部、管理各种模块，性能开销明显更高。所以很多大型互联网公司会采用“LVS/HAProxy做四层入口，Nginx做七层业务网关”的分层架构。

但这不是说Nginx不行。如果你已经深度使用了Nginx的缓存、gzip、WAF、重写规则等七层能力，那么让HAProxy顶在前面反而多了一层维护成本。选型的原则应该是：如果是四层流量的统一入口，用HAProxy；如果主要是HTTP七层业务，而且需要大量HTTP头操作和缓存，继续用Nginx。两者并不冲突，甚至可以共存。

5. 一份经过生产验证的基础配置模板

5.1 全局配置与调优参数

下面这套配置来自我维护的一个线上集群，经过压测和真实流量验证，你可以根据自己的场景调整。我没用太多花哨的模块，但每一行都有明确的目的。

global maxconn 50000 log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin nbproc 1 nbthread 4 cpu-map auto 1 0 cpu-map auto 2 1 cpu-map auto 3 2 cpu-map auto 4 3 tune.ssl.default-dh-param 2048

几个值得说明的配置：

• maxconn 50000：这是HAProxy能接受的最大并发连接数，需要结合系统文件描述符和内存评估。别盲目调大，我的经验是每万连接大约需要几十MB内存，具体取决于会话大小。
• nbthread 4：现代HAProxy 2.x支持多线程。根据CPU核数设置，四个线程在四核机器上比较稳妥，设置太多反而引起锁竞争。
• stats socket：这个是运维神器，可以通过命令行实时查看连接数、启停后端节点，比如echo "show stats" | socat stdio /run/haproxy/admin.sock。

5.2 defaults和frontend/backend的完整示例

defaults mode http timeout connect 5s timeout client 30s timeout server 60s timeout http-request 10s timeout check 5s option httplog option dontlognull option redispatch retries 3 maxconn 30000 frontend web-in bind *:80 bind *:443 ssl crt /etc/haproxy/certs/site.pem http-request set-header X-Forwarded-Proto https if { ssl_fc } default_backend web-servers backend web-servers balance leastconn option httpchk GET /health http-check expect status 200 server web-01 192.168.1.31:8080 check inter 3s fall 3 rise 2 weight 2 server web-02 192.168.1.32:8080 check inter 3s fall 3 rise 2 weight 1 server web-03 192.168.1.33:8080 check inter 3s fall 3 rise 2 weight 1 backup

这里我设置timeout server 60s而不是更短的30秒，是因为后端偶尔会有报表类接口跑到40秒。在业务接口规范里，我们把普通查询接口的目标P99控制在500ms以下，但报表导出这种重型接口要走独立的backend，单独设置超时。所以完整的配置应该是多个backend各配各的超时，而不是一个backend包打天下。

inter 3s fall 3 rise 2的意思是每3秒做一次健康检查，连续3次失败后把节点摘除，连续2次成功后恢复上线。这个节奏对大多数HTTP服务够用。如果你的业务健康检查接口本身响应慢，可以把inter放宽到5秒，避免健康检查请求把服务压垮。

5.3 内容切换与AB发布

HAProxy做内容切换比很多人想象的简单。比如我想让10%的流量打到新版本节点上，可以通过use_backend配合ACL实现：

frontend web-in bind *:80 use_backend web-servers-new if { hdr(X-Canary) -i 1 } default_backend web-servers backend web-servers-new balance roundrobin server new-01 192.168.1.41:8080 check server new-02 192.168.1.42:8080 check

这种灰度策略在发布时特别好用，不需要改Nginx上游，也不依赖网关。只是注意ACL的解析顺序，HAProxy会按顺序匹配，匹配到第一个use_backend就终止。

5.4 stats页面的配置

没有一个直观的可视化页面，排障效率会低很多。我习惯配置一个独立端口的stats页面：

listen stats bind :8404 stats enable stats uri /stats stats refresh 5s stats admin if LOCALHOST

只监听本地回环地址，通过SSH隧道访问，避免暴露公网。stats页面能直接看到每台后端的Session速率、请求数、错误数、队列长度，排障时先看这个页面，基本能锁定问题的大方向。

6. 实战复盘：一次完整超时故障的排查链路

6.1 日志现场

回到文章开头那次故障，我当时并没有直接改超时，而是先做了一个完整的链路梳理。HAProxy的日志默认使用option httplog格式，会记录Tw（等待客户端超时）、Tq（客户端发送请求耗时）、Tr（等待后端响应耗时）等关键字段。

当时抓到的日志片段大概是：

Jul 15 23:31:27 lb1 haproxy[12345]: 10.0.0.18:52001 [15/Jul/2024:23:31:27.812] web-in order-service/web-01 0/0/1/3004/3005 504 2747 - - cD-- 2/2/2/1/0

看中间那串数字：0/0/1/3004/3005，依次代表Tq/Tw/Tc/Tr/Tt。Tr为3004ms，说明HAProxy转发到后端后，等待后端响应超过了3秒；Tt为3005ms，意味着总耗时约等于等待后端的时间。而返回状态码是504，说明这是HAProxy判定的后端响应超时。

6.2 逐步排查过程

第一步：确认流量是不是真的打到了后端。我登录web-01，用tcpdump抓8080端口，发现请求确实收到了，而且Tomcat也返回了200，但响应时间确实在2.8-3.5秒。问题进一步收敛到“后端处理慢，不是转发故障”。

第二步：检查是哪个环节慢。Tomcat的access log显示的耗时和HAProxy日志基本一致，确认耗时发生在业务代码或数据库访问，而不是Tomcat本身排队。

第三步：抓数据库。慢查询日志里出现了一条update语句，执行计划显示走了全表扫描。原来是某个大促期间新增的字段没有建索引，后台任务在更新这个字段时把表锁住，前端请求操作同一行记录时全部阻塞。

第四步：回到HAProxy视角。为什么只有一部分请求报504，而不是全部？因为timeout server是30秒，大部分请求虽然等了2-3秒，仍然在30秒内返回了，所以HAProxy层面没有超时，真正超时的其实是客户端网关的3秒读超时。这就解释了为什么监控显示的是“大量504”而不是全部504。

6.3 修复与验证

修复分两步。第一步是立即止血：给数据库加上索引，解锁阻塞的update语句，流量在几分钟内恢复。第二步才是调整超时配置：把timeout client从50秒改到10秒，同时要求上游网关把读超时放宽到8秒，给后端留出合理的处理时间。

这个配置调完以后，虽然网关读超时和数据索引的修复已经解决了当时的问题，但超时链路从此变成了一条规范：接入层超时、网关超时、后端P99，三者必须符合“依次递减”的原则。

6.4 值得写进团队规范的经验

这次故障给我最大的教训，不是索引缺失，而是超时配置从来不是单个组件的事。很多团队在维护HAProxy时只盯着HAProxy本身的参数，却忽略了整条链路的超时契约。

我后来整理了一份简单的超时清单，写进了团队的运维规范：

• 每个后端接口要有明确的P99和P999目标，据此推导timeout server。
• 客户端网关读超时应大于后端P99，建议为P99的2倍以上。
• HAProxy的timeout client必须大于网关读超时，防止网关重试导致后端流量翻倍。
• 重试必须有次数上限和熔断机制，不能无限重试。
• 健康检查的频率要低于业务接口的QPS，避免健康检查本身干扰业务。

规范看起来朴素，但每一条都是真实事故换来的。超时配置这件事，本质上是在给系统的每个环节划边界：谁负责等待、谁负责放弃、谁负责重试。边界的唯一标准是整条链路的吞吐和延迟表现，而不是某一个组件的默认值。

现在再回头看，我在很多业务线里最终都把核心接入层定成了HAProxy + leastconn的组合，配合精细化的超时配置和健康检查。它能扛住突发的流量尖峰，也能在某个后端节点出问题时快速摘除，不至于让一个慢节点拖垮全局。这套方案谈不上多新，但胜在稳定、可控，至少我在多次故障中证明它经得住真实流量的考验。