Azure 订阅迁移 微软云 Azure 账号负载均衡器类型

前言：别让“负载均衡器”变成玄学

Azure 的世界很大，但对大多数新手来说，真正让人头皮发麻的往往不是“云到底多强”，而是那一串看起来像咒语的产品名称：负载均衡器、应用网关、流量管理器、入口控制器……你可能会想：微软是不是在跟我们玩“猜猜我是谁”？

其实不用怕。只要你把“负载均衡”这件事拆开来看，就会发现它主要在做几件相对朴素的事：把请求分发到后端、做健康检查、必要时维持会话、管理网络流量的入口与出口。不同产品只是定位不同：有的偏网络四层，有的偏应用七层；有的管的是单地域，有的管的是多地域；有的适合“进站”，有的更关心“出站”。

下面我们就围绕标题“微软云 Azure 账号负载均衡器类型”这件事，把 Azure 里常见的负载均衡器类型（以及与之强相关的入口/流量分配组件）讲清楚。你会看到它们的适用场景、关键差异和选型建议。好了，开始“云端点兵点将”。

先澄清：Azure 里“负载均衡器类型”到底指什么？

严格来说，Azure 不是只有一种“负载均衡器”。通常大家口中的“负载均衡器类型”，可能包含几类产品：真正意义上“Load Balancer”的四层负载均衡器、面向应用的“Application Gateway”（七层）、以及“Traffic Manager”（多地域流量调度）。另外，如果你用的是 AKS（Kubernetes），还会遇到 Ingress / NGINX Ingress / Service 类型等，它们也属于“用负载均衡把流量送到应用”的范畴，只是技术栈不同。

为了不让概念打架，我们后面会按“用途与层级”来归类：（1）四层：网络层/传输层负载均衡；（2）七层：HTTP/HTTPS 应用层负载均衡；（3）多地域调度：把流量分配到不同区域；（4）Kubernetes 场景：入口控制器的角色。你看，逻辑一顺，谜题就少一半了。

类型一：Azure Load Balancer（Azure 负载均衡器，四层）

如果你问“最传统的负载均衡器是哪一个”，答案基本是 Azure Load Balancer。它工作在网络的四层（通常理解为 IP、端口、协议层面），会根据传入的连接信息把流量转发到后端实例。

1）公有（Public）与内部（Internal）

Azure Load Balancer 有两大常见形态：Public Load Balancer 和 Internal Load Balancer。

• Public：面对互联网或需要对外暴露的入口。常用于把公网流量转发到后端。
• Internal：只在虚拟网络内部提供负载均衡。比如公司内部服务、跨子网访问、内网 API 等。

你可以把它想成“外网门卫”和“内网门卫”。外网门卫负责“让外面的进来”；内网门卫负责“让内网里的请求找到对的人”。两者都做分流，但面向的边界不一样。

2）健康探测：后端死活全靠它

Load Balancer 通常配合健康探测（Health Probes）。你要告诉它“后端如何算健康”。常见方式包括 TCP 探测或 HTTP 探测（具体能力取决于实现与版本）。当探测失败，后端会被从转发池中移除。

健康探测就像“值班表”。没有它，你可能会把请求继续丢给已经下线的机器，然后日志里就会出现那种让人怀疑人生的错误：怎么都失败？是不是服务坏了？——是，服务可能坏了，但更可能是“你没有把它从池子里赶出去”。

3）会话保持（Session Persistence）：需要就开，不需要就省

有些业务对“同一用户”希望继续落到同一台后端（例如某些非纯无状态应用）。Azure Load Balancer 提供一定形式的会话保持能力（常见做法与配置项相关）。如果你的服务是严格无状态（比如后端都从共享缓存/数据库读取数据），通常不必执着会话粘性；如果业务确实需要，它就很关键。

4）典型适用场景

• HTTP/HTTPS 之外的协议需求（例如更偏 TCP/UDP 的场景）。
• 你不需要复杂的七层路由规则，只要“分摊连接”或“按端口转发”。
• 需要更简单、成本和管理更直接的负载分发。

类型二：Azure Application Gateway（应用网关，七层）

如果 Azure Load Balancer 是“看端口就分流”，那 Application Gateway 就是“看内容再做决策”。它工作在七层（HTTP/HTTPS 应用层），擅长处理 HTTP 相关的功能，比如基于路径/主机名的路由、TLS 终止、WAF（Web Application Firewall，Web 应用防火墙）等。

1）七层带来的能力：路由更聪明

七层负载均衡的“聪明”，体现在它能理解 HTTP 请求。比如同一个域名下不同路径转发到不同后端：/api 转到 API 服务，/static 或 /app 转到前端或网关服务。或者基于主机名把不同域名映射到不同后端。

对比一下：

• 四层：主要按 IP/端口/协议分发；
• 七层：还能按 HTTP 头、路径、协议等做更精细的规则。

2）TLS 终止与证书管理

很多人最关心 HTTPS 的证书问题。Application Gateway 常用于在网关层完成 TLS 终止（也就是在网关解密 HTTPS，再用内部方式转发）。这样后端服务可以更简单，证书也集中管理。

当然，是否要在网关层终止也取决于你架构设计。有些团队希望端到端加密，就会选择其他方案。但如果你想省事、集中管理、安全策略一致性更强，Application Gateway 是个常见选手。

3）WAF：把安全当成系统能力而不是“应急贴纸”

Application Gateway 支持 Web 应用防火墙（WAF）。它可以对常见 Web 攻击模式进行检测与拦截，比如 SQL 注入、跨站脚本等。把 WAF 放在入口处，属于典型的“先把垃圾拦在门外”的思路。

注意：WAF 不等于万能药，但它确实能显著降低很多低成本攻击的成功率。

4）典型适用场景

• 你需要基于 URL 路径、主机名的精细路由。
• 需要集中做 HTTPS/TLS 终止或与安全策略结合。
• 需要 WAF 能力来保护 Web 应用。
• 后端可能是多服务、多版本，入口要能按规则分流。

类型三：Azure Traffic Manager（流量管理器，多地域调度）

当你从“我把流量分到后端服务器”升级到“我把流量分到不同区域/不同数据中心”，就会引入 Traffic Manager。它是典型的多地域流量调度组件。

你可以把它想成“总控台”。后端不止一份（可能在多个区域都部署），Traffic Manager 根据配置的路由策略把用户请求转给最近或最合适的区域。

1）路由策略：你想按什么分？

Traffic Manager 常见策略包括（不同版本/能力可能略有差异）：

• 优先级（Priority）：主用区域优先，主用不可用再切换备选。
• 加权（Weighted）：按权重分配流量，实现灰度或分流。
• 性能（Performance）：基于延迟/响应速度把流量引向更快的区域（大多依赖探测与指标）。
• 地理（Geographic）：按用户地理位置定向。

2）健康探测与故障切换

Traffic Manager 也需要健康探测（对端点/服务）。当某个区域服务不可用，它会把流量从该区域撤走，把请求导向健康区域。

注意一个关键点：Traffic Manager 的“健康探测”更偏整体端点可用性，而不是像七层网关那样能深挖 HTTP 细节。它更像“区域级别的体温计”。

3）适用场景

• 需要跨区域容灾或高可用（HA）。
• 需要多活或准多活架构（不同区域同时服务）。
• 希望根据性能选择用户就近访问。

类型四：Kubernetes 场景的“入口控制”（Ingress / Service / 负载均衡器协作）

如果你使用的是 AKS（Azure Kubernetes Service），你会发现“负载均衡器”这个词会变得更像一个团队协作概念：云里的负载均衡能力 + Kubernetes 的入口资源共同完成流量入口。

常见路径大致是：外部流量进来（可能通过 Azure LB 或 Ingress Controller），再由 Ingress Controller 根据 Ingress 规则把请求转发到 Kubernetes Service，Service 再把流量送到具体 Pod。

1）Service 类型：ClusterIP / NodePort / LoadBalancer

Kubernetes 的 Service 有不同类型。最接近“云负载均衡器”的是：

• LoadBalancer：让云提供一个外部负载均衡入口。
• NodePort：在节点端口上暴露服务（通过集群节点端口转发）。

在 AKS 上，Service 选择 LoadBalancer 往往会触发 Azure 侧创建一个负载均衡对象（具体还要看你集群的配置与网络模式）。

Azure 订阅迁移 2）Ingress Controller：七层规则真正落地的地方

Ingress 更像是“七层规则的编排”。Ingress Controller（例如 NGINX Ingress 等）负责把 Ingress 配置翻译成实际的反向代理/转发规则。

因此在 Kubernetes 里，你可能遇到两种看法：

• “我有个 Azure Load Balancer 负责把外部流量送到集群边缘”；
• “我有个 Ingress Controller 负责按 HTTP 路径、域名等做七层路由”。

二者一起工作，构成完整入口链路。

类型五：NAT Gateway 与“出站负载均衡”的错觉

很多人会把“负载均衡器”与“出口汇聚”混在一起。事实上，Azure 里还有 NAT Gateway（网络地址转换网关）。它主要解决的是出站流量的稳定源地址、端口复用等问题。

虽然 NAT Gateway 不是传统意义上“把入站请求分发给多个后端”的负载均衡，但它经常出现在“同一个出口、稳定访问”的网络设计里。

你可以把它理解为：如果四层/七层网关负责“把人送到不同的商场”，NAT Gateway 更像“让大家用同一个工牌出门”，从而简化出站策略与连接一致性。

所以当你问“负载均衡器类型”，如果你的真实诉求是“出站稳定性”而不是“入口分流”，那你要考虑的是网络出站方案，而不是在入口产品里死磕。

如何选型：别买错就像别买错鞋

选型这件事，说白了就是：你需要哪个层级、要不要做七层规则、是不是多地域、后端是无状态还是要会话粘性。

1）我只想把连接分到后端：选四层 Load Balancer

• 协议偏 TCP/UDP 或简单 HTTP 转发；
• 不需要复杂的 HTTP 路由；
• 成本与部署复杂度要低；

这时候 Azure Load Balancer 基本是最合适的起点。

2）我需要 URL 路由、证书终止、WAF：选 Application Gateway

• 需要按路径/主机名分流；
• 需要集中管理 TLS；
• 需要 WAF 提升 Web 安全；

那七层 Application Gateway 更像“正中靶心”的选择。

3）我需要跨区域容灾/就近访问：选 Traffic Manager

• 多区域部署；
• 主备切换或按性能/权重分配流量；

这时 Traffic Manager 是核心调度器。

Azure 订阅迁移 4）我在 AKS：Ingress + Service +（可能的）Azure Load Balancer

• 你想要 Kubernetes 原生的路由与治理；
• 要在集群内完成七层规则编排；

通常要考虑 Ingress Controller 与 Service 类型的组合。

“账号负载均衡器”这个说法怎么理解？

你给的标题里写了“Azure 账号负载均衡器类型”。这里我先郑重声明：在 Azure 官方产品命名里，通常不会有一个叫“账号负载均衡器”的明确产品。更合理的理解可能是：

• 你在某个场景里看到“账号”（可能是指 Azure 订阅 subscription、租户 tenant，或访问入口账号权限管理）与负载均衡器一起出现；
• 你在讲“某个 Azure 账号/订阅下有哪些负载均衡器类型可用”；
• 或者你想问的是“Azure 中负载均衡器有哪些类型（面向账号/项目的选型）”。

不管哪种理解，你真正要关心的仍然是上面那些产品与能力：四层 LB、七层 Application Gateway、多地域 Traffic Manager，以及 AKS 场景的入口组件。权限与账号层面更多影响你能否创建、能否访问资源，但不改变产品本质。

常见坑位与“踩雷指南”（用幽默的方式提醒你别哭）

负载均衡相关的事故通常不是因为产品不行，而是因为配置不当。下面这些坑你要尽量避免：

1）健康探测没配好：它以为你的服务还活着

Azure 订阅迁移 最典型的“诡异错误”是：后端其实挂了，但负载均衡还在把流量送过去。或者相反：后端其实正常，但探测失败导致节点被踢出。最后你看到的是请求失败、错误码飘忽不定。

解决办法通常是：确认探测端点返回码、协议与端口、探测路径是否存在、后端是否能从探测源访问到。

2）七层规则写得像玄学诗：最后全都路由失败

如果你用了 Application Gateway 或 Ingress，并配置了路径匹配规则，常见问题包括：

• 路径前后斜杠不一致（/api vs /api/）。
• 重写规则导致后端路由不对。
• 证书/域名配置与实际访问域名不一致。

建议：一开始用最简单的规则跑通，再逐步加复杂度。别一上来就“全都匹配”，最后所有请求都像迷路的快递：找不到地址。

3）会话保持与无状态冲突：你以为它粘了，其实没粘

如果你的应用依赖会话状态（比如内存会话），却没有正确配置会话保持，就会出现同一用户多次请求落到不同后端，导致登录状态丢失或业务异常。

解决方向：要么正确做会话粘性，要么把会话改成集中式存储（更推荐后者，长期维护更稳）。

4）多地域切换测试没做：切换那天你才发现探测不通

Traffic Manager 的价值在故障切换。可很多团队只在“正常情况下”看流量分配，故障演练却从未进行。等到真的区域异常，探测发现端点不可用的逻辑可能不符合预期。

建议：做演练。哪怕小规模、短时间，也能避免“灾难当天才学习”。

一份“快速对照表”：看完就能下决定

你可以用下面这个思路来做初选：

• 需要四层转发、简单分摊连接：Azure Load Balancer。
• 需要七层（HTTP 路由、TLS 终止、WAF）：Application Gateway。
• 需要多地域故障切换/就近访问：Traffic Manager。
• Azure 订阅迁移 使用 AKS：Ingress Controller + Service（必要时结合 Azure LB），由 Ingress 负责七层规则。

至于 NAT Gateway，更偏出站稳定性与网络地址转换，不属于典型入站“负载均衡”。但如果你遇到“出口策略、源地址不稳定、被防火墙盯”的问题，它可能才是你真正要的答案。

结语：把名词变成选择，把选择变成上线

Azure 的负载均衡器类型看似多，其实核心就几种：四层负责“快把流量分出去”，七层负责“看懂 HTTP 再分流”，多地域负责“区域级别调度”，Kubernetes 场景则是入口编排的组合拳。

当你下次再看到一串产品名称时，别急着“背”。你只要先问自己三句话：

• 我需要分发的是连接还是 HTTP 语义？
• 我的后端在单区域还是多区域？
• 我需要的是入口分流还是出站稳定？

答案一出来，选择就不玄学了。毕竟云上运维最怕的不是难，而是“你不知道为什么选它”。希望这篇文章能让你的选型更像“买对鞋”，而不是“买到只适合看不适合走”。

补充：如果你愿意，我可以帮你做更精确的选型

你可以告诉我：你是要做 Web 服务还是 API？是否需要 HTTPS、是否需要按路径路由？是否跨区域？后端是虚拟机还是 AKS？大概的并发量与是否会话依赖？我就能把上面的“类型”映射到你的具体架构，并给出更落地的推荐组合（比如“LB + App Gateway + Traffic Manager”这种怎么搭、健康探测怎么设计）。你一句需求，我来帮你把方案从名词变成图纸。