腾讯云服务器负载均衡怎么上：CLB 加 ASG 的单机改造最小路径

正文

单台 CVM 扛得住就够了吗？多数时候不是。腾讯云服务器负载均衡 CLB 加弹性伸缩 ASG 是从单机走向多机的标准路径，但它有前提，前提没满足，加了负载均衡反而更不稳。有个客户单台机器扛了半年，某次大促流量翻了三倍，CPU 打满、连接排队，页面转圈直到宕机。事后他问我是不是买台配置更高的就行，我说不一定——从"一台更强的机器"到"多台一起扛"，中间隔的不是预算，而是一次架构改造。

这篇讲的就是从单机到多机的最小改造路径，以及我在给客户做这件事时踩过的坑。核心观点先摆出来：负载均衡负责"分流量"，弹性伸缩负责"加机器"，但能不能横着扩，取决于你的应用是不是无状态的。这一条不解决，后面全是白干。

单机改造：先判断你到底该不该上

不是所有业务都值得上负载均衡。我的判断标准很简单：单机 CPU/内存长期处于高位、有明显波峰波谷、或者业务不允许任何单点停机，这三条占一条才值得考虑。如果只是配置不够，先升配可能更省事。

以云服务器 CVM（行业里常叫 ECS）为例，单机改造的最小路径大致是：先做无状态化，再把应用部署到至少两台实例上，前面挂 CLB 做流量分发，最后用 ASG 管理实例数量。别一上来就上伸缩，先把"两台机器加一个负载均衡"这条最基础的链路跑通、跑稳，再谈自动化。

一个反常识的点：上了负载均衡不代表高可用，只代表有了分流入口。如果两台后端其实跑在同一台物理宿主机上、或者共享同一个数据库单点，那高可用只是纸面上的。

单机过渡路径：能回滚的迁移才安全

从单机切到多机，最容易出事的就是"一步到位"。我推荐的过渡路径是渐进的：先把新版本应用部署到两台新实例上，用 CLB 的转发规则或权重把一小部分流量引过去灰度验证；确认无异常后，再把 DNS 或 CLB 权重逐步切过去，旧机先留着一两天，随时能回滚。这样万一新架构有问题，改个权重就退回去了，而不是被迫通宵救火。能回滚的迁移，才是安全的迁移。

CLB 四层还是七层：买之前先想清楚

腾讯云服务器负载均衡 CLB 分四层（TCP/UDP）和七层（HTTP/HTTPS），选错了后面要返工。

• 四层：只转发 TCP/UDP 包，不看应用层协议。性能高、延迟低、对协议透明，适合数据库代理、非 HTTP 服务、长连接。

• 七层：能解析 HTTP 头，可按域名、路径、Cookie 做转发，能卸载 HTTPS、做会话保持。适合 Web 应用、微服务网关。

对比维度 四层 CLB 七层 CLB

工作层次 TCP UDP 传输层 HTTP HTTPS 应用层

转发依据 IP 与端口 域名 路径 Cookie

HTTPS 卸载 不支持 支持 证书托管

会话保持 基于源 IP 可基于 Cookie

性能与延迟 更低 略高 但功能强

典型场景 数据库 长连接 非HTTP Web 微服务 需要按路径分发

多数 Web 业务选七层。只有确实不需要解析 HTTP、追求极致转发性能时，才用四层。选型时还要想清楚：一个 CLB 实例的转发规则和监听器配置够不够用，业务域名多不多，将来要不要灰度发布。

健康检查：故障能不能自动切走全靠它

健康检查是腾讯云服务器负载均衡 CLB 的灵魂，也是我最常见的配置错误来源。CLB 会按你设的间隔去探测后端，探测失败的实例会被摘除，不再接流量。

关键参数是探测路径、超时时间、检查间隔和不健康阈值。这里有个坑：健康检查的路径必须是后端真正能返回成功的轻量接口，不要拿一个会查数据库的重接口去做健康检查，否则后端稍微慢一点，全被判定为不健康，本该摘掉一台，结果摘掉一片。反过来，如果健康检查太宽松，坏实例又被一直保留，请求持续报错却没人被摘。

我的建议是给健康检查单独准备一个 /healthz 这类接口，只做进程存活和关键依赖的浅检查，秒级返回。探活的归探活，业务监控的归监控，别混在一起。

顺带说一句后端权重的用法：同一组后端可以设不同权重，机器配置不一样时按权重分配流量更合理，灰度发布时也能用一个小权重把少量流量引到新版本上先试。

横向扩容的真正前提：无状态、共享存储与数据库连接数

这一节是全文重点。很多人以为上了 ASG 就能随便加机器，其实横向扩容有一堆前提，其中任何一个不满足，加机器都会变成加故障。

• 无状态：用户会话不能在单机内存里。要把 session 外置到 Redis 或数据库，或者干脆改成基于 Token 的无状态鉴权。会话保持（把同一用户粘到同一台后端）能缓解，但它是权宜之计，不是无状态改造的替代——一旦那台机器挂了，粘在上面的用户照样掉线。

• 共享存储：多台机器要读同一份数据，就不能各自存本地盘。上传文件、用户头像这类要放对象存储或共享文件系统，否则用户这次传的文件，下次请求落到另一台机器就找不到了。

• 数据库连接数：这是最容易被忽略的。两台变十台，应用到数据库的连接数也翻了五倍，数据库最大连接数先被打满。加机器之前，务必算一遍总连接数，必要时上连接池或读写分离。

还有一个常被忽略的点：定时任务和后台作业在多机部署下会重复执行。单机时一个 cron 就够了，多机后每台都跑一遍，轻则重复扣款、重则数据打架。解决办法是让定时任务只在一台执行，加分布式锁或单独抽一台作业机，别让它跟着伸缩组一起扩。

我吃过一次亏：客户上了 ASG，扩到八台后数据库直接拒绝连接，业务雪崩。根因不是负载均衡，是数据库连接数没估。负载均衡只解决入口，扩容的天花板往往在数据库。

ASG 伸缩组：启动配置、冷却时间与扩容触发指标

弹性伸缩 ASG 的核心是三样：启动配置、伸缩规则、冷却时间。

• 启动配置：定义新机器用什么镜像、机型、安全组、user-data 初始化脚本。最佳实践是配合自定义镜像做"黄金镜像"，再用 user-data 注入启动时参数，保证新机器起来就能干活。

• 触发指标：常见的是 CPU 利用率、内存（需装监控 agent）、请求数、CLB 并发连接数。指标选错了会乱伸缩——用 CPU 去衡量一个 CPU 不高但内存吃紧的服务，就永远扩不起来。

• 冷却时间：扩容或缩容后要等一段时间再评估，避免指标还没稳定就来回抖动。缩容更危险，一定要给足冷却时间，且优先摘除最闲或最新的实例，别把有长连接的实例砍了。

另外，伸缩组要和监控告警联动：扩容不是目的，稳住业务才是。把 CPU、内存、后端响应时间都纳入监控，才能在扩容没生效时及时发现——我见过指标选错、扩容触发了但新机器一直起不来，结果业务照样挂，白扩一场。

还有一个实务问题：扩容是给系统"续命"，不是给数据库"续命"。前面说过瓶颈可能在数据库，那 ASG 扩出来的新机器只会加剧后端压力。所以上线前一定要做一次全链路压测，确认扩容真的能提升吞吐，而不是把瓶颈推给下一层。

HTTPS 卸载与证书：让后端轻装上阵

七层 CLB 支持做 HTTPS 卸载，也就是证书装在 CLB 上，CLB 解密后再用 HTTP 转发给后端。好处很实在：后端不用各自配证书、不用承担 TLS 握手开销、证书到期只需在 CLB 一处更新。

证书可以在控制台申请或上传，配合腾讯云的证书托管能力做自动续期提醒。我要提醒两点：一是后端如果依赖真实客户端 IP，七层 CLB 会带 X-Forwarded-For，应用要正确解析这个头，否则限流和审计会认错人；二是卸载后 CLB 到后端这段是明文流量，同 VPC 内可接受，但跨网络安全域时要想清楚是否要重新加密。涉及国际业务、需要多地区部署的团队，还要注意证书与域名解析的地域策略。

现实边界：轻量应用服务器不能直接进 CLB

这一条我劝过很多客户。轻量应用服务器 Lighthouse 是套餐型产品，带宽、流量、系统盘打包在一起，它不能被直接挂到 CLB 后端，因为它走的是独立的网络与计费模型。想上负载均衡和弹性伸缩，得用云服务器 CVM 这类支持完整弹性网络的产品。

那轻量怎么办？如果业务还在起步、单机够用，轻量性价比高；但一旦到了"要负载均衡、要弹性扩缩"的阶段，就是该迁到 CVM 的时候了。迁移靠自定义镜像或快照导出重建，规划要提前。别在轻量上硬凑高可用，那是在跟自己较劲。

如果你现在就在轻量上，迁移节奏我建议这样排：先把应用做成镜像、数据备份好，在 CVM 上重建一套并接入 CLB 灰度验证，业务没问题后再切域名解析，最后才下线轻量实例。整个过程要有一份可靠的中间备份，别边迁边删。

FAQ

Q：上了 CLB 就一定高可用了吗？

A：不一定。CLB 只提供分流入口。后端是否分布在多台宿主机、数据库是否还有单点，才决定真正的高可用。

Q：会话保持是不是就不用做无状态改造了？

A：不是。会话保持是过渡手段，机器一挂粘在上面的用户照样掉线。正解是把 session 外置或改成无状态 Token。

Q：ASG 扩容后数据库连不上是怎么回事？

A：多半是数据库最大连接数被打满。加机器前要核算总连接数，配合连接池或读写分离，否则扩得越多崩得越快。

Q：健康检查总把好机器摘掉怎么办？

A：检查路径别用重接口，单独做 /healthz 轻探针；同时放宽超时和阈值，避免后端偶发抖动就整片摘除。

Q：轻量应用服务器能挂负载均衡吗？

A：不能直接挂。轻量是套餐型产品，网络与计费独立。要上 CLB 和 ASG，需迁到云服务器 CVM。

结语

给一个可执行的改造顺序，照着走就行：先盘点应用是不是无状态、数据是否共享、数据库连接数余量够不够；这三项过关后，用两台 CVM 加一个七层 CLB 跑通基础链路；最后再引入 ASG 和黄金镜像做自动化。记住改造的顺序是"先无状态、再多机、后弹性"，颠倒顺序只会放大故障。卡在腾讯云服务器负载均衡的选型或网络规划上时，找个熟悉 CLB/ASG 的腾讯云服务商陪着做一次架构评审，比上线后救火省心得多；涉及国际腾讯云账号或多账号体系规划的，务必用自己主体合规开户。

如果需要更深入咨询了解可以联系全球代理上TG:jinniuge 他们在云平台领域有更专业的知识和建议，他们有国际阿里云，国际腾讯云，国际华为云，aws亚马逊，谷歌云一级代理的渠道，客服1V1服务，支持免实名、免备案、免绑卡。开通即享专属VIP优惠、充值秒到账、官网下单享双重售后支持。不懂找他们就对了。