阿里云的负载均衡怎么收费，实例和流量分别怎么算

单台服务器扛不住突发流量时，页面一卡一卡，接口时好时坏，团队多半会先想到负载均衡。这篇文章从原理讲起，聊选型，也把费用拆开说清楚。

负载均衡到底解决什么问题

说白了，负载均衡就是放在用户和后端服务器之间的调度层。请求先到它这里，它再按规则转给后端的多台机器。它的用处主要有三个。机器多了，压力就能分开，单机瓶颈不再拖累整体。某台机器出故障时，调度层把流量切走，用户一般察觉不到。业务涨了，加机器并注册进后端池就行，前面的入口不用动。

阿里云的负载均衡服务早期叫 SLB，现在产品名已统一为 CLB。它是托管型服务，调度节点不用自己搭，也不用自己维护。日常会用到的能力大致如下：

选型前先想清楚服务给谁用。面向公网用户的业务，比如官网、App 接口、小程序后端，要用公网型实例，它会分配一个公网 IP 作为统一入口。内部微服务之间的调用，或者数据库读写分流，用私网型实例更合适，网络边界更清楚，延迟也更好控制。

四层和七层的差别也要分清。四层基于 IP 和端口转发，开销小，适合游戏、数据库、长连接这类场景。七层能解析 HTTP 报文，可以按域名和路径做转发，常用于 Web 站点和 API 网关前置。不少团队两层都用：入口走七层做路由，内部服务之间走四层转发。

费用这部分容易被忽略，但采购前最好先算清楚。从计费结构上看，通常分成两块：一块和负载均衡实例本身有关，另一块和公网流量或带宽有关。计费是按量付费还是包年包月，实例规格怎么划分，流量按什么口径计量，都会影响最终账单。价格会调整，也因地域和规格而异，这里不写具体单价，下单前以阿里云官网的定价页为准。

实际估算可以按三步来。第一步确认业务走公网还是私网，公网入口会产生公网流量相关的费用。第二步估算平时流量和峰值流量的差距，如果计费方式和带宽挂钩，就要算清楚峰值带宽；如果按流量计费，就要算每天的总量。第三步确认实例规格能否承接峰值连接数和新建连接速率。规格选小了，省下的钱可能在故障里补回来。

下面是一个虚构的示意场景，方便把前面的内容串起来。某中型电商平台平时有三台应用服务器，其中两台是新机型，一台是旧机型。每次促销，访问量几分钟内能涨到平时的五六倍，原来的架构经常在高峰时出现接口超时。

团队的改法分三步。先在阿里云创建公网型负载均衡实例，把域名解析指过去，并在这一侧配置 HTTPS 证书卸载。再把三台应用服务器加入后端服务器组，给新机型设置更高的权重，让旧机型少分一些流量。健康检查用一个轻量接口，检查间隔和失败阈值则按业务能接受的延迟来调。

活动当天，有一台应用因为内存泄漏响应变慢。健康检查在几十秒内发现异常，负载均衡把它摘除，剩下的节点接住了流量。运维处理完问题后把节点重新加回去，前台页面没有出现大面积报错。复盘时团队的结论很朴素：扩容靠的是机器数量，稳定性靠的是调度策略和健康检查配得是否合理。

负载均衡不是配完就能一劳永逸的东西。它更像业务架构的入口，流量形态变了，权重、检查策略和费用预估都要跟着调整。先把原理讲清楚，再结合自己的业务做选型和算账，这件事才算踏实。