微软云负载均衡：分层架构与选型逻辑深度解析

Azure Load Balancer是微软云负载均衡体系中最基础、最核心的组件。它运行在OSI模型的第四层——传输层，专注于处理TCP和UDP协议的流量。不关心HTTP请求里是哪个URL，不关心Cookie里存了什么——只关心数据包从哪个IP来、到哪个端口去。

这种“不关心”恰恰是它的优势。因为工作在更低的协议层，Azure Load Balancer能够提供超低延迟和高吞吐量的性能表现，每秒可以处理数百万个请求。对于需要极致性能的场景——比如实时音视频、游戏服务器、数据库连接池——四层负载均衡是不可替代的选择。

Azure Load Balancer分为两种类型：内部负载均衡器和公共负载均衡器。内部负载均衡器在虚拟网络内部工作，用于服务之间的流量分发；公共负载均衡器面向互联网，接收来自外部的请求并分发到后端实例。两者在功能上没有本质区别，只是前端IP地址的类型不同。

在SKU层面，Azure Load Balancer提供标准SKU和网关SKU两种选项。基础SKU已于2025年9月30日正式停用。标准SKU是当前的主力产品，支持可用性区域冗余、跨区域负载均衡、多前端IP配置、出站SNAT规则等高级功能。网关SKU则面向需要集成网络虚拟设备的场景。

标准SKU与已退役的基础SKU之间的差异，不仅是功能层面的，更是架构哲学的不同。基础SKU是“开箱即用”的简单工具，标准SKU则是“可编程”的网络基础设施。标准SKU支持基于IP的后端池、支持HTTPS健康探测、支持HA端口、支持99.99%的SLA——这些基础SKU统统不具备。从基础SKU升级到标准SKU，本质上是从“能用”走向“好用”的必经之路。

三、Application Gateway：七层流量的智能管家

如果说Azure Load Balancer是“不问来路、只问去处”的物流分拣员，那么Azure Application Gateway就是“知根知底、量体裁衣”的智能导购。Application Gateway工作在OSI模型的第七层——应用层，专门处理HTTP、HTTPS、WebSocket和HTTP/2协议。

Application Gateway的核心能力在于基于请求属性的智能路由。同样是发往同一个域名的请求，/images路径下的请求可以路由到专门优化图片处理的服务器池，/video路径下的请求路由到视频服务器池，而API请求则路由到另一组微服务实例。这种基于URL路径、主机标头、查询参数等HTTP属性的路由能力，让Application Gateway成为微服务架构和Web应用交付的理想选择。

除了智能路由，Application Gateway还集成了多项对Web应用至关重要的能力：

• SSL/TLS终止：将CPU密集型的加解密工作从后端服务器卸载到网关层，显著提升后端性能。

• Web应用防火墙（WAF）：提供对SQL注入、跨站脚本等常见Web攻击的防护。

• 自动缩放：Standard_v2版本支持根据流量负载自动调整实例数量，无需预先规划容量。

• 基于Cookie的会话亲和性：确保同一用户的请求始终落在同一后端实例上，对有状态应用至关重要。

值得注意的是，Application Gateway近年来也在向四层能力扩展。随着TCP和TLS终止功能的正式发布，Application Gateway现在也可以作为四层代理使用。但这种扩展并不意味着它可以替代Azure Load Balancer——专业的事交给专业的工具，这个原则依然成立。

四、Traffic Manager与Front Door：DNS级与全球级的流量调度

当业务超出单个Azure区域，需要在全球多个数据中心之间调度流量时，Azure Load Balancer和Application Gateway就力不从心了。这时候需要的是全局流量管理能力——Azure Traffic Manager和Azure Front Door承担了这一角色。

Traffic Manager工作在DNS层面。它不代理流量，不转发数据包——它只是在DNS解析环节告诉客户端“你应该去访问这个IP”。客户端收到DNS响应后，直接连接到对应的服务端点。这种设计意味着Traffic Manager不会成为流量的瓶颈，但也意味着它无法对流量本身做任何加工——没有SSL卸载，没有请求改写，没有WAF保护。

Traffic Manager支持六种流量路由方法：优先级、加权、性能、地理、多值和子网。优先级路由实现主备故障转移；加权路由实现灰度发布和A/B测试；性能路由将用户导向延迟最低的端点；地理路由满足数据主权和内容本地化需求。这些路由方法可以组合使用——通过嵌套Traffic Manager配置文件，实现更复杂的路由策略。

Azure Front Door则是一个更“重”的全球解决方案。它不仅仅是负载均衡器，更是一个集内容分发网络（CDN）、全球负载均衡、SSL卸载、Web应用防火墙于一体的综合平台。Front Door部署在微软全球边缘网络之上，通过遍布全球的存在点（PoP）将内容和服务交付到离用户最近的位置。

Front Door与Traffic Manager的核心区别在于：Front Door是“主动”的全球加速，而Traffic Manager是“被动”的DNS调度。Front Door在边缘节点上处理请求、缓存内容、执行路由逻辑；Traffic Manager只负责告诉客户端“去哪里”，不参与任何请求处理。对于需要全球加速、边缘计算、WAF保护的HTTP/S应用，Front Door是更强大的选择；对于只需要简单地域调度的场景，Traffic Manager足够且更经济。

五、选型逻辑：四层、七层、DNS层、全球层，如何决策？

面对Azure提供的多种负载均衡服务，选型的困惑往往不是“不知道每个产品做什么”，而是“不知道自己的场景该用哪个”。一个实用的决策框架是从三个维度依次筛选：

第一维度：流量范围。流量只在单个Azure区域内分发？还是需要跨区域甚至全球分发？区域内的负载均衡，选择Azure Load Balancer（四层）或Application Gateway（七层）；跨区域的流量调度，选择Traffic Manager（DNS级）或Front Door（全球级）。

第二维度：协议层级。流量是TCP/UDP协议（数据库、游戏、音视频），还是HTTP/HTTPS协议（Web应用、API）？非HTTP流量，Azure Load Balancer是唯一选择；HTTP/S流量，则可以在Application Gateway和Azure Load Balancer之间做进一步选择。

第三维度：功能需求。是否需要URL路径路由、SSL卸载、WAF保护、会话保持等七层能力？需要这些能力，选择Application Gateway；不需要，Azure Load Balancer更轻量、更低延迟、更经济。

这三个维度筛选下来，大部分场景的答案已经清晰。但还有两个容易被忽略的要点：

一是组合使用。端到端的方案往往需要多个负载均衡服务协同工作。例如，Front Door作为全球入口，将流量分发到不同区域的Application Gateway，Application Gateway再根据URL路径将请求路由到具体的后端服务池，而服务池内部则通过Azure Load Balancer实现实例级的流量分发。这不是“选一个”的问题，而是“如何搭配”的问题。

二是成本考量。标准负载均衡器按规则数和数据处理量计费，空闲时也会产生费用。Application Gateway按小时计费并支持自动缩放。Front Door按请求量和数据传输量计费。选型时不仅要看功能是否匹配，还要评估长期运行的总体拥有成本。

六、高可用架构：健康探测、可用区与出站连接

负载均衡的价值不仅在于“分发流量”，更在于“只把流量发给健康的实例”。健康探测是实现这一目标的机制。

Azure Load Balancer通过健康探测来检测后端实例的状态。探测协议支持TCP、HTTP和HTTPS三种。TCP探测只检查端口是否开放；HTTP/HTTPS探测则检查特定的URL是否返回预期的状态码——后者能更准确地反映应用程序的真实健康状态。当健康探测失败时，负载均衡器自动将该实例从后端池中移除；当实例恢复健康后，自动重新加入。

可用性区域是Azure负载均衡高可用设计的另一支柱。标准负载均衡器支持区域冗余部署——单一前端IP地址可以经受住单个可用区故障的考验。这意味着即使某个可用区的数据中心出现故障，负载均衡器仍然能够将流量分发到其他可用区的健康实例上。对于跨区域的高可用场景，全局负载均衡器可以实现即时全局故障转移——当一个区域整体不可用时，流量自动切换到下一个最佳区域。

出站连接是另一个容易被忽视但至关重要的议题。当后端虚拟机需要主动访问外部服务时，Azure Load Balancer需要通过源网络地址转换（SNAT）为出站流量提供公网IP。标准负载均衡器为后端池中的每个虚拟机实例分配固定数量的SNAT端口。如果某个实例发起大量出站连接，可能耗尽SNAT端口，导致连接失败。针对这一问题，可以通过出站规则调整SNAT端口的分配数量，或者使用NAT网关作为更优的出站连接方案。

七、实践建议：从入门到生产级部署

基于上述分析，针对不同阶段的用户给出以下实践建议：

入门阶段：从Azure Load Balancer标准SKU开始。它是所有负载均衡服务的基础，理解它的工作原理——前端IP、后端池、负载均衡规则、健康探测——是理解其他服务的前提。在单一区域内部署一个简单的Web应用，通过公共负载均衡器暴露服务，观察流量分发和健康探测的运作。

进阶阶段：当应用需要七层路由能力时，引入Application Gateway。将SSL证书卸载到网关层，配置基于URL路径的路由规则，集成WAF保护。理解Application Gateway如何与Azure Load Balancer协同工作——Application Gateway作为七层入口，后端可以对接Azure Load Balancer管理的四层服务池。

生产级阶段：设计跨区域的高可用架构。在主要区域和备份区域分别部署完整的应用栈，每个区域内部使用Application Gateway + Azure Load Balancer的组合。区域之间使用Traffic Manager或Front Door进行全局流量调度。配置好健康探测的阈值和间隔，避免因网络抖动导致不必要的故障转移。启用Azure Monitor的多维指标和诊断日志，建立负载均衡器的可观测性体系。

负载均衡的选型和架构设计，本质上是在性能、功能、成本和复杂度之间寻找平衡。没有“最好”的方案，只有“最合适”的方案。理解每个产品的设计哲学和适用边界，比记忆功能列表更重要——这也是本文试图传达的核心观点。

关于上饶市万云信息科技有限公司： 国内深耕多年的综合型多云服务合作商，业务覆盖阿里云、腾讯云、华为云、天翼云、火山云、微软云、谷歌云、亚马逊云八大主流公有云平台，服务场景覆盖全行业企业数字化需求。企业整体业务体量成熟稳定，八大云平台全年综合销量突破20亿人民币，累计服务超100万合作客户，累计助力企业部署云服务器近1亿台。公司现有全职员工500人，团队架构完善、服务体系标准化，具备承接大、中、小型企业规模化上云项目的完整能力。微软云业务找上饶市万云信息科技可享9折优惠（微软云ChatGPT等AI大模型产品可享8折），作为微软云头部一级代理商，依托10年+行业经验与成熟的多云服务能力，为客户提供稳定可靠的上云解决方案。

常见问题解答

问：Azure Load Balancer和Application Gateway可以同时使用吗？
答：可以，而且这是生产环境的常见最佳实践。Application Gateway作为七层入口处理HTTP/S流量的智能路由和SSL卸载，后端对接Azure Load Balancer管理的四层服务池，实现分层负载均衡。

问：标准负载均衡器和已停用的基础负载均衡器有什么区别？
答：标准负载均衡器支持可用性区域冗余、跨区域负载均衡、HTTPS健康探测、HA端口、99.99% SLA等高级功能，基础负载均衡器不具备这些能力。基础SKU已于2025年9月30日正式停用，建议尽快升级。

问：Traffic Manager和Front Door有什么区别？
答：Traffic Manager工作在DNS层面，只告诉客户端“去哪里”，不处理任何流量；Front Door是全球边缘网络上的综合平台，集负载均衡、CDN、SSL卸载、WAF于一体，实际处理请求和流量。

问：负载均衡器的健康探测失败会怎样？
答：当健康探测失败时，负载均衡器自动将该后端实例从分发池中移除，不再向其转发新流量。实例恢复健康后自动重新加入。标准负载均衡器在实例探测失败时TCP连接保持活动，而基础负载均衡器在所有探测失败时会终止所有TCP连接。

问：如何避免后端虚拟机出站连接时的SNAT端口耗尽？
答：可以通过出站规则调整SNAT端口分配数量，或使用Azure NAT网关替代负载均衡器作为出站连接方案。NAT网关提供更弹性的端口分配，没有SNAT耗尽的顾虑。

问：跨区域部署时如何实现自动故障转移？
答：使用Azure标准负载均衡器的全局负载均衡功能，或使用Traffic Manager的优先级路由方法。当主区域不可用时，流量自动切换到下一个优先级区域。Front Door也提供即时全局故障转移能力。