腾讯云实名关联账号 腾讯云负载均衡实测
你有没有过这种经历？项目上线前夜，老板发来一句：「听说腾讯云负载均衡挺稳，加一层保平安」。你点头如捣蒜，点开控制台，新建一个CLB，填了几个IP，勾了几个框，点了「立即创建」——然后，就真以为它开始「负载」了？
我有过。而且是在一个日活80万的营销活动上线前4小时。
结果呢？活动刚开闸，监控告警像微信消息一样噗噗跳：后端服务器CPU冲到98%，但CLB控制台里，三台机器的流量分配比是——72% : 23% : 5%。不是「均衡」，是「选美」；不是「分担」，是「偏爱」。
腾讯云实名关联账号 于是，那晚我没回家。泡面凉了三回，咖啡续了五杯，和腾讯云工单、官方文档、抓包工具、curl命令，以及我那台快被按出指纹的MacBook，打了一场硬核遭遇战。
今天这篇，不讲「什么是四层/七层」，不背「CLB支持TCP/UDP/HTTP/HTTPS」，也不列参数表格。我们只做一件事：还原一次真实、狼狈、又有点上头的腾讯云负载均衡实测全过程。
第一步：不是建完就完事，是建完才开始
我在上海地域新建了一个公网应用型CLB（ALB），监听端口80，转发规则指向三台CVM（Ubuntu 22.04，Nginx）。看起来很标准，对吧？
但第一次curl -I http://xxx.xxx.xxx.xxx，返回的是502 Bad Gateway。查日志？CLB没日志。查后端？Nginx access.log空空如也。我盯着控制台里三台机器的状态栏——全是灰色的「未注册」。
原来，CLB默认开启「健康检查」，而我的Nginx没配任何响应内容。它每5秒发一次HEAD请求到/，我的Nginx返回404，CLB果断把它们全踢出池子。不是挂了，是被「嫌弃」了。
解决方案？两种：一，在Nginx根路径放个index.html，返回200；二，在CLB健康检查里把路径改成/healthz，再在Nginx里配个location返回200。我选了后者——毕竟生产环境谁敢让/裸奔？
第二步：你以为的「轮询」，其实是「玄学轮询」
健康检查通过了，状态变绿了，流量进来了。但三台机器的CPU曲线，像极了K线图：一台涨停，两台跌停。
翻文档，CLB默认调度算法是「加权轮询（WRR）」。权重？我三台都设成10。那为什么不均？
抓包一看傻眼：CLB在建立TCP连接时做了连接复用（Connection: keep-alive），而我的测试脚本用的是curl循环——每次都是新连接，但CLB内部维护着连接池，同一客户端IP+端口组合，可能被哈希到同一台后端长达数分钟。这不是轮询，这是「哈希绑定」。
换方案：用ab（Apache Bench）压测，并加-k参数模拟长连接，再用-n 10000 -c 100。这下曲线平了——三台CPU稳定在32%/33%/35%。结论：轮询生效，但前提是你得「够量、够持续、够多样」。
第三步：那个让运维同事拍桌的「会话保持」陷阱
业务方提需求：「登录态要一致，别用户刚登完就跳到另一台机器，Session丢了！」
我信心满满打开「会话保持」开关，选择「基于Cookie插入」，超时时间设3600秒。心想：完美，用户带Cookie来，CLB自动路由到同一台。
上线两小时后，报警又来了：某台后端内存暴涨，OOMKilled。查发现，它扛了87%的登录请求。而Cookie？根本没传！前端用的是Vue SPA，登录走的是/api/login，返回JWT存localStorage，压根不设Cookie。CLB等了一晚上，等来的是一堆空Cookie字段，只好把所有请求塞给第一台——因为「找不到有效Cookie就默认打头阵」。
救火方案：要么前端配合写Cookie（改架构）；要么后端统一用Redis共享Session（推荐）；要么……关掉会话保持，用JWT+Redis实现无状态。我们选了第三种。顺便给CLB备注了一句：「此开关非银弹，慎点」。
第四步：延迟突增？先看它是不是在「偷偷重试」
压测中，平均延迟从80ms突然跳到320ms。监控显示后端处理时间仍是80ms左右。问题在哪？
启用CLB访问日志（需单独开通，且延迟1~2分钟），日志里赫然出现大量"request_processing_time":"0.312"，但后端access.log里对应时间戳只有1条记录。说明CLB在中间重试了。
查原因：健康检查间隔设太短（3秒），而某台后端偶发GC停顿达2.8秒，CLB误判为宕机，主动切断连接并重试——重试逻辑默认开启，且不告知用户。
对策：健康检查间隔拉长到10秒，超时时间设为5秒，失败阈值调为3次。重试消失，延迟回归平稳。
第五步：最后的倔强——SSL卸载到底卸给谁？
为了性能，我们开了HTTPS监听，证书上传成功，域名解析也OK。但浏览器打开还是提示「不安全」。
抓包发现：CLB确实解密了TLS，但转发给后端时用的是HTTP（非HTTPS），而后端Nginx配置里强制HSTS，301跳转https://… 结果形成「HTTPS→HTTP→301→HTTPS」死循环。
解法有两个：一，后端Nginx关掉HSTS或判断$http_x_forwarded_proto = 'https'绕过跳转；二，在CLB里开启「后端协议HTTPS」，让CLB与后端也走TLS（需后端配证书）。我们选了一——毕竟，CLB已经干了加密的活，后端何必再劳神？
顺手还发现个小彩蛋：CLB的SSL卸载支持国密SM4，但需要选「国密增强型」实例规格——普通版不支持。这个细节，藏在文档第17页的括号里。
写在最后：它不是魔法盒，是把瑞士军刀
腾讯云CLB本身很稳。我在连续72小时压测中，没遇到一次自身故障。但它不是黑箱，更不是「加了就灵」的符咒。它的每一项默认配置，都在悄悄影响你的流量走向；每一个勾选项背后，都藏着一个需要你理解的网络契约。
实测下来最值钱的三条经验：
- 健康检查不是摆设，是守门员——路径、协议、超时、阈值，一个不对，后端就集体“装死”；
- 调度算法不看PPT，看实际连接模型——短连接猛如虎，长连接才是轮询基本盘；
- 会话保持不是银弹，是双刃剑——没Cookie的前端，等于给CLB递了一张空白支票，让它自由发挥。
所以，下次再有人问「腾讯云CLB好不好用」，我会说：它好用，但前提是——你愿意花两小时，把它当一个有脾气、有习惯、有隐藏菜单的伙伴，而不是一个点了就跑的按钮。
毕竟，真正的负载均衡，从来不是把流量「分出去」，而是把不确定性「管起来」。
（完）
