自建内网高并发纯 https 协议(要卸载 ssl)负载均衡器, haproxy 和 nginx 哪个更合适一点?
realpg ·PRO
包含普通 http 和 websocket 要在负载均衡器卸载 ssl
日最高并发 10000, 负载均衡器起三个实例, 本身不分担负载, 主备备, 只有主承担流量, 备纯热备
每个业务后端每日最高并发 10000 连接数 每天热门 6 小平均连接数 8000,websocket 持续无数据连接占比超过 60%(基本平均每个 websocket 连接每分钟发一条 msg 都达不到, 是很少比例的控制指令),剩下的是频繁 ajax 小请求
实践用哪个好一点 大概需要多少内存
不能上容器编排 就得单机搞
日最高并发 10000, 负载均衡器起三个实例, 本身不分担负载, 主备备, 只有主承担流量, 备纯热备
每个业务后端每日最高并发 10000 连接数 每天热门 6 小平均连接数 8000,websocket 持续无数据连接占比超过 60%(基本平均每个 websocket 连接每分钟发一条 msg 都达不到, 是很少比例的控制指令),剩下的是频繁 ajax 小请求
实践用哪个好一点 大概需要多少内存
不能上容器编排 就得单机搞
 |
1
mytsing520 PRO 我只能说，在我们应用过的架构里面，HAproxy 的七层能力垃圾的一匹
|
 |
2
realpg OP PRO @mytsing520
我们有个成型的自己基于 openresty 搞的庞大的 SLB 但是这个项目有点特殊没法用... 现在已经在上面跑了 所以数据是准确的 但是要从这上面把业务迁移下来 挪到开源平台上去 所以就破罐子破摔 找个前人经验省点心的 |
|
3
mytsing520 PRO 结合我们的应用来说：
不清楚你的业务里面，websocket 如果持续无连接，是否可以设置为自动超时断连；持续连接会造成内存耗尽，不管你机器多大内存，都会被吃光 七层业务体系里面目前 Nginx 系列能力总体来说挺强的 HAproxy 用 4 层连接的能力倒是毋庸置疑，7 层的能力人家官方都没太大兴趣做 |
 |
4
MindMindMax 2025 年 12 月 29 日
我记得很多年前，国内有做 SSL 卸载的硬件厂商，弥补 nginx 性能问题。
|
 |
5
defunct9 2025 年 12 月 29 日
caddy traefik ?
|
 |
6
chunjilikafa1456 2025 年 12 月 29 日
我们是专用的 SSL 卸载硬件+HA(SLB)
|
|
7
realpg OP PRO @mytsing520 #3
不是无连接 是必须保持连接 设备断了会自动马上重新连的 需要一直保持 只是上面消息很少 是控制信道 基本上一次连接 1800 秒后断开 直到需要下次连接 现在这就是个七层的 为了不动项目架构 slb 上卸载 ssl 然后走 http/websocket 去 api server nginx 的 health check 真的不如 haproxy 省事 然后我也担心 haproxy 的七层太弱鸡 所以有此问 |
|
8
realpg OP PRO @chunjilikafa1456 #6
有钱 没法提采购 预算决算卡的太严了 之前是给他们白嫖我们其他系统的我们自己卖给他们的 自主知识产权的 SLB 没开新的实例 就在上面新建了个配置 然后现在这个小系统被别的傻子厂商看上了 要移交给新的公司 他们想挣这钱 得剥离 之前合同上和清单上没有的硬件软件 都是没法用的 但是用 nginx haproxy 这类纯软的指定版本的 是可以的 |
 |
9
hbprotoss 2025 年 12 月 29 日
nginx 吧，haproxy 一般只做 4 层代理
|
 |
10
vopsoft 2025 年 12 月 29 日 via Android
Nginx+Intel QAT 硬件加速卡 （二手的 1000 以内）
|
 |
11
bpf2049 2025 年 12 月 29 日
haproxy 四层 1w 并发是小事，七层 HTTP 1W 并发也问题不大，但七层 SSL 卸载还真没试过。另：nginx health check 真的是一坨
|
|
12
realpg OP PRO |
 |
13
xqzr 2025 年 12 月 29 日
kTLS🤔
|
 |
14
clarkethan 2025 年 12 月 29 日
真正可能打垮接入网关的，应该是新建连接，F5 有过一个数据，好像是 intel cpu 单核大概每秒能完成 350 次 RSA-2048 TLS 握手，你可以拿这个大概估算一下。至于你说的 1 万并发，如果是稳定的长连接，随便跑，很低压力
|
 |
15
v1 2025 年 12 月 29 日
让我想到金盾防火墙……
|
|
16
mytsing520 PRO 想到之前 B 站说的那套架构
公网 IP 在 4 层 LB ，后面直接套 7 层 LB ，业务在 7 层 LB 后面用 API 网关实现 |
|
17
realpg OP PRO @mytsing520 #16
我这个单体业务没那么大体量 不需要四层套七层 只需要一个七层就够了 然后主要是要纯的热备 @clarkethan #14 是的 新建连接数是个重要指标 我没提是因为我们实际这个业务 每秒新建连接数不多 远远不会造成瓶颈 而不是我们没关注这个 @hbprotoss #9 因为 nginx 的 health check 过于垃圾 才有此问 |
 |
18
thereone 2025 年 12 月 30 日
不能买设备那就买授权上 NFV ，F5 有对应的 NFV 的。
|
 |
19
Ken1028 2025 年 12 月 30 日
radware+nginx 方案，SSL 卸载在 radware 层
|
|
20
clarkethan 2025 年 12 月 30 日
@realpg 每秒新建连接少的话随便选哪个都行，10000 长连接并发对 nginx 和 haproxy 都非常轻松，这个量不存在需要因为性能而选型
|
 |
21
yinmin 2025 年 12 月 30 日
用 ecc 证书可能会降低握手的资源占用
|
 |
22
colourfulsai 2025 年 12 月 30 日
如果更倾向于 Nginx 方案的话，可以考虑 OpenResty ，和使用 nginx 没多大区别。它可以通过 lua-resty-upstream-healthcheck 模块，实现主动后端健康检查，就是这一块自己写一下就行，别的配置不用动。
|
|
23
realpg OP PRO @colourfulsai #22
我前面说了 我们公司自己有庞大的 openresty slb 产品 这是一个巨大的客户的一个小系统 没采购 slb 我们就在之前的 slb 上开了个配置给他们用了 没有结算 账面也没有这东西 然后总有些头铁的小厂商 他低价把这个小系统的二次开发和运维给抢过去了 我们的别的系统的 slb 就不能给他们用了 得拆一个他们能玩得转的 简单半个小时就配好的 然后把这个小系统移交给他们 还得他们随便找找人就会维护的 要不回头还折腾我们净是事儿 至少移交过程和初期运行得别出毛病才能移交 而且是不是独立服务器运行 会跑在一个边缘服务器上 那个服务器内存有点吃紧 |
Select Language