一些朋友在看到上篇文章之后，跟我说阿里云支持在负载均衡上挂载SSL/TLS证书，并给我截了图：

我在这里澄清一下，这是事实。

同样，在【20220707】【公测公告】NLB公测活动说明中：自2022年07月07日起，网络型负载均衡NLB开启公测，诚邀您测试体验。这也是事实。

假设超时空警察让阿里云在几年前推出NLB，我们当时就立即使用了这个产品，我们根据收费标准来算成本。

阿里云NLB费用试算

阿里云NLB还在公测，官方价格计算器目前还没有NLB的计算规则，但是文档中有个计费规则，我们根据这个规则进行试算。

NLB的计算项有三个，分别为新建连接数、并发连接数和处理数据量。计费标准为：

NLB的LCU费按小时收取，不足1小时按1小时算。
每小时LCU费=LCU单价(元/个)×每小时LCU个数
每小时LCU个数=max{新建连接数LCU个数，并发连接数LCU个数，处理流量LCU个数}

新建连接数：指每秒处理的新建TCPSSL连接的数量。LCU换算值为新建连接数÷50
并发连接数：每分钟内并发TCPSSL连接的数量。LCU换算值为并发连接数÷3000
处理数据量：NLB处理的TCPSSL请求和响应的数据处理量，单位为GB。LCU换算值为处理数据量÷1

先从1000个客户端开始吧

假设有1000个客户端，在9月1日0点0分通过TLSv1.3连接至NLB，只进行连接，每隔1分钟发送1个心跳包，心跳包大小为2 Byte，持续到9月30日23点59分。

• 新建连接数：只有第一秒产生1000个连接，平均下来为每秒1000个连接，换算为LCU是20(1000 ÷ 50)，其余时间不产生LCU，我们在此忽略这第一秒产生的LCU

• 并发连接数：连接不会断掉，换算为LCU是0.3333(1000 ÷ 3000)

• 处理数据量：忽略建立连接时交换证书的数据量，每小时心跳包约为0.000111G(2 Byte * 60 * 1000 ÷ 1024 ÷ 1024 ÷ 1024)，换算为LCU则为0.0001

又因：如果某小时内实例各指标换算的LCU不为整数时，按照向上取整原则计算本小时LCU消耗。

根据公式，每小时LCU个数=max{0, 0.3333, 0.0001}=0.3333，上述规则将每小时LCU个数抬至1。9月份有30天，共计720个LCU。按照LCU单价（元/个/小时）为0.049来算，0.049 * 1 * 720 = 35.28，每个月NLB费用为35.28元。

我们现在使用的CLB，能支撑上述连接数的标准为简约型I(slb.s1.small)，我们按规格计费，每小时为0.12元（实例费0.02元，规格费0.1元，流量基本可忽略不计），0.12 * 720 = 86.4，每个月CLB费用为86.4元。

NLB费用比CLB费用便宜了近60%。

客户端数量越来越多，差距肯定也就越来越大

当客户端数量抬升至50000，在同样的前提下：

• 新建连接数：第一秒产生50000个连接，平均下来为每秒50000个连接，换算为LCU是1000(50000 ÷ 50)，其余时间不产生LCU，我们在此忽略这第一秒产生的LCU

• 并发连接数：连接不会断掉，换算为LCU是16.67(50000 ÷ 3000)

• 处理数据量：忽略建立连接时交换证书的数据量，每小时心跳包约为0.0055G(2 Byte * 60 * 50000 * 1024 ÷ 1024 ÷ 1024)，换算为LCU则为0.0055

根据公式，每小时LCU个数=max{0, 16.67, 0.0055}，每小时LCU个数仍然是并发连接数为最大指标。每小时LCU总个数为17，0.049 * 17 * 720 = 587.52，每个月NLB费用为587.52元。

CLB则需要升级至标准型I(slb.s2.small)，每小时为0.34元（实例费0.02元，规格费0.32元），0.34 * 720 = 244.8，每个月CLB费用为244.8元。

这个时候，NLB费用比CLB费用多了1倍。

怎么可能？客户端数量提升至500000呢？

有什么地方不太对，我们再算算500000个客户端连接的情况吧，在同样的前提下：

• 新建连接数：第一秒产生500000个连接，平均下来为每秒500000个连接，换算为LCU是10000(500000 ÷ 50)，其余时间不产生LCU，虽然很大，但是我们还是忽略这第一秒产生的LCU

• 并发连接数：连接不会断掉，换算为LCU是166.67(500000 ÷ 3000)

• 处理数据量：忽略建立连接时交换证书的数据量，每小时心跳包约为0.0555G(2 Byte * 60 * 500000 ÷ 1024 ÷ 1024 ÷ 1024)，换算为LCU则为0.0555

根据公式，每小时LCU个数=max{0, 166.67, 0.0055}，每小时LCU总个数为17，0.049 * 166 * 720 = 5856.48，每个月NLB费用为5856.48元。

CLB则需要升级至高阶型II(slb.s3.medium)，每小时为1.93元（实例费0.02元，规格费1.91元），1.93 * 720 = 1389.6，每个月CLB费用为1389.6元。

先让我叉会腰。

你在计算中做了手脚，CLB的流量你就没算

的确。

当客户端数量提升至500000的时候，每个月心跳流量包总流量为40G，0.8元/G * 40G = 32，CLB需要额外交32元的流量费。

当客户端数量同为500000时，假定NLB每月费用为5856.48，则每小时可以处理不超过166个LCU用量的流量，即每个小时可在不增加额外费用的情况下可以处理166G流量。这个量是很惊人的，算下来每个月则可以额外处理近120T的流量。

处理流量费并非流量费，该收还是会收，NLB一样需要额外交32元的流量费。

不是流量的问题，费用不确定因素在新建连接数上。

感觉新建连接数花不了多少钱

新建连接数的收费标准写得很清楚：每秒处理的新建TCPSSL连接的数量。取1小时内某秒最大的连接数÷50，即为该小时内的LCU个数。

当客户端规模非常大，我们无法安排客户端的新建连接均匀分布在每一秒上。

• 假如10000个客户端在同一秒瞬间连接上，那这个小时的LCU会直接抬到200，这一小时费用为9.8元。
• 假如出现网络波动，500000个客户端能在同一秒进行重连，这一小时的LCU则会直接算为10000，这一小时费用为490元。

整体费用很难预估，最早列出的算法仅仅是算出基础费用，新建连接数造成的费用很难预估，但整体费用只会比基础费用高，不会少。

也有可能是计算错误

也有可能，但在客户端数达到50000的时候，NLB的基础费用就已经远超CLB了。

我用JupyerLab画出了一个真实的费用函数，不考虑新建连接数的影响，NLB的费用接近于二次函数，CLB的费用则接近阶梯式费用。随着业务增长，使用最基础的CLB规格就已比NLB要实惠。

几年前未有阿里云NLB时，AWS技术支持建议我们迁移至AWS NLB，使用价格计算器，按当时业务指标来评估费用，不算流量费用，仅在负载均衡器上的支出就已经很夸张，我们表示费用太高负担不起。

结语

实际上，中国区阿里云的服务质量相当不错。

我们在中国区使用阿里云服务，遇到的机器故障不超过5例，一些故障还会提前发信通知“我们下周要维护了请注意点”。AWS则是每个月都会有点小毛病，先是应用哐哐报警，接着Slack开始冒各种instance missing、unhealthy host报警，每隔一段时间就会提示服务有没有好，一般要等20-25分钟，机器恢复正常了，服务自行恢复，最后是Slack哐哐报服务状态已恢复。

当时在阿里云上创建Postgres数据库时使用的版本是10.10，这周做数据库巡检时，发现版本是10.19，应该是阿里云偷偷摸摸升级上去了。和AWS RDS的Minor Version Update每次闹得鸡犬不宁不一样，阿里云RDS升级是无感的，我们没有遇到应用突然报数据库连不上的情况，这点让人非常放心。

我们在投入某项新技术，某个中间件，或开始使用某产品，会经过测试、用量预估、费用预估，一般费用过高、不合理，我这边心里的一关就过不去，也不会继续购买、部署和使用了。阿里云NLB的概念和计费项无限接近AWS NLB，假如我们一开始就使用AWS NLB，到今天的话，仅在负载均衡器这一收费项目上就远超目前所使用的负载均衡器的价格15000倍以上，我对阿里云NLB费用的警觉来源于此。

综上所述，根据我们的业务场景，我们不会选择阿里云NLB。