Azure 开户代办 Azure负载均衡实测

你有没有试过，在Azure上吭哧吭哧配好三台虚拟机，挂上负载均衡器，信心满满点下“测试访问”，结果浏览器卡在转圈圈——而三台VM的IIS日志里，连一条请求都没见着？

别慌。这不是你的代码写错了，也不是网络安全部署太严，更不是Azure抽风（虽然它偶尔真会抽）。这大概率，是你和Azure负载均衡器（Load Balancer）之间，还没完成一场心平气和的「婚前谈话」。

今天不讲概念定义，不贴微软文档截图，不堆术语金字塔。咱们就当是两个老运维蹲在机房门口啃包子，边嚼边聊：Azure LB到底怎么干活？它认什么、怕什么、吃几碗饭、拉几泡屎？实测数据全摊开，锅谁背、坑谁填，一五一十。

第一幕：不是所有LB都叫Standard

Azure负载均衡器分两种SKU：Basic 和 Standard。别被名字骗了——Basic不是“入门版”，而是“退休版”。它不支持可用性区域、不支持出站规则、不支持基于端口的健康探测、不支持浮动IP……它唯一坚持的，是“不给你添太多麻烦”的佛系哲学。

我们这次实测，只用Standard SKU。为啥？因为生产环境没人敢拿Basic赌命。就像你不会用诺基亚3310跑Kubernetes集群一样。

创建命令？一行足矣（用Azure CLI）：

az network lb create \
  --resource-group rg-lb-test \
  --name lb-web \
  --sku Standard \
  --public-ip-address pip-lb-web \
  --frontend-ip-name feip-public \
  --backend-pool-name bkp-web-servers

注意那个--sku Standard——没它，后面所有骚操作都会在第五步报错：“对不起，您订购的是老年怀旧套餐，不支持健康探测。”

第二幕：健康探测——LB的“查岗”哲学

Azure LB不像Nginx那样看HTTP状态码，它用的是TCP或HTTP探测。我们选HTTP，路径设为/healthz，间隔15秒，失败阈值2次——意思是：连续两次收不到200，就立刻把后端踢出轮询池。

但问题来了：你三台VM的IIS都配了/healthz，返回200，可LB还是标红？查日志发现：探测源IP是169.254.1.1（Azure内部保留地址），而你的NSG（网络安全组）默认拦掉了所有来自非10/12/172.16-31/192.168网段的入向流量。

所以第一坑：在NSG里加一条规则——允许源IP 169.254.0.0/16 访问探测端口（比如80）。别写成*，那等于给黑客递刀。

第二坑更隐蔽：IIS默认不监听0.0.0.0:80，而是绑定到具体IP。探测包打进来，没地方接。解决？PowerShell一句：

netsh http add iplisten ipaddress=0.0.0.0

重启HTTP服务，再刷一次LB仪表盘——红变绿，世界清静。

第三幕：会话亲缘性（Session Persistence）——甜蜜的误会

文档里说“Source IP affinity”，听着像“用户登录后永远打到同一台机器”。实际呢？它只对同一个客户端IP+同一端口有效。而现代浏览器开8个TCP连接并行下载，每个连接端口不同；手机App切后台再唤醒，IP可能变；公司出口NAT后面几百人共用一个公网IP……

我们实测：开启Source IP affinity后，用curl模拟100次请求（同一IP不同源端口），分布比例仍是≈33%/33%/34%。所谓“粘性”，只是统计学上的轻微抖动。

结论：别指望它做购物车会话保持。真要Session粘性，请上Application Gateway，或者自己在应用层用Redis共享Session。

第四幕：跨区域故障转移？别做梦了

有人问：“LB能不能自动把流量切到另一个Region？”答案很干脆：不能。Azure LB是Region级资源，它不知道隔壁East US有台备用VM。它的世界观，仅限于自己VNet里的后端池。

想搞跨区容灾？得组合拳：Traffic Manager（DNS层路由） + 每个Region部署独立LB + 后端VM镜像同步。而Traffic Manager的故障检测延迟，实测平均在60–90秒——这期间用户看到的，就是“网站打不开”。

我们故意关掉东区三台VM，等Traffic Manager切换。第67秒，curl开始收到西区响应。第72秒，浏览器页面加载成功。这67秒，够用户骂三遍“你们网站又崩了”。

第五幕：性能实测——数字不说谎

Azure 开户代办 工具：wrk（单机压测），三台D2s_v3 VM（双核8GB），Nginx静态页（1KB HTML），LB前端为Standard Public IP。

• 直连单台VM：QPS ≈ 12,400，P99延迟 ≈ 18ms
• 经LB转发（3节点）：QPS ≈ 35,800，P99延迟 ≈ 22ms
• LB自身引入延迟：≈ 4ms（稳定，不随QPS飙升）

重点来了：当QPS冲到5万时，LB没崩，但后端VM CPU飙到98%，其中一台开始丢包。此时LB健康探测依然绿灯——因为它只看端口通不通，不管CPU烧不烧。

所以：LB不是性能救星，而是流量调度员。真正的瓶颈，永远在你的后端。LB能帮你摊薄压力，但不能替你优化SQL慢查询。

第六幕：那些没人告诉你、但会让你凌晨三点爬起来的细节

• 出站SNAT端口耗尽：Standard LB默认提供1024个SNAT端口/后端实例。如果你的应用疯狂调外部API（比如每请求调5个第三方服务），1024很快见底，表现为“Connection timed out”。解法：调大--idle-timeout，或显式配置SNAT端口数（最高64K）。
• 浮动IP（Floating IP）≠ 高可用VIP：它只在Internal LB中启用，用于将流量直接导向特定后端（如SQL AlwaysOn主节点）。公网LB不支持。别在ARM模板里硬塞，会报错。
• 删除LB？先删探针，再删规则，最后删LB：顺序反了，会卡在“正在删除”三天不动。Azure Portal里点删除，后台其实按依赖链走——这是云平台的温柔暴政。

尾声：LB不是银弹，而是杠杆支点

折腾完这一轮，我对着Azure门户长舒一口气。LB没有魔法，它只是个沉默的守门人：不猜你意图，不替你决策，不修你代码，但它极度诚实——你给它清晰的规则，它还你确定的结果；你漏掉一个NSG规则，它就冷眼旁观你抓狂。

它最迷人的地方，不是多高大上，而是足够透明。所有配置可审计、所有探测可验证、所有延迟可测量。在云时代，这种“可控的确定性”，比任何炫技都珍贵。

所以，下次再遇到LB不转发，别急着怀疑人生。打开Cloud Shell，敲三行命令：

az network lb probe list -g rg-lb-test --lb-name lb-web
az network nic ip-config address-pool list -g rg-lb-test --lb-name lb-web --ip-config-name ipconfig1
az network watcher flow-log show --resource-group rg-lb-test --nsg nsg-web --location eastus

真相，永远藏在日志和配置里。而你，只需要一把耐心的螺丝刀，和半包没吃完的辣条。

（全文完。实测环境：Azure East US & West US2，2024年Q2，无任何SDK魔改，纯原生服务。）