掌握这4种负载均衡模式，轻松通过MCP AZ-104实操考试

第一章：MCP AZ-104 负载均衡器设置概述

Azure 负载均衡器是 Microsoft Azure 平台中用于分发入站和出站流量的核心网络服务，支持高可用性应用程序的部署。它工作在传输层（第4层），能够基于 TCP 或 UDP 协议将流量智能地分配到后端虚拟机实例，从而提升应用的性能与容错能力。

负载均衡器类型

Azure 提供两种类型的负载均衡器：

• 公共负载均衡器：用于分发来自互联网的入站流量。
• 内部负载均衡器：用于在虚拟网络内部分发流量，适用于后端服务或数据库集群。

基本配置要素

要成功部署负载均衡器，需定义以下关键组件：

1. 前端 IP 配置：关联公网或内网 IP 地址。
2. 后端池：包含参与负载分发的虚拟机或虚拟机规模集。
3. 运行状况探针：检测后端实例是否可响应请求。
4. 负载均衡规则：定义如何将流量从前端映射到后端池。

创建公共负载均衡器示例

以下 PowerShell 命令用于创建一个基本的公共负载均衡器：

# 创建公共 IP
$publicIP = New-AzPublicIpAddress -Name "LB-PublicIP" -ResourceGroupName "MyResourceGroup" `
    -Location "EastUS" -AllocationMethod Static -Sku Standard

# 创建前端 IP 配置
$frontendIP = New-AzLoadBalancerFrontendConfig -Name "FrontendPool" -PublicIpAddress $publicIP

# 创建后端池
$backendPool = New-AzLoadBalancerBackendAddressPoolConfig -Name "BackendPool"

# 创建运行状况探针
$probe = New-AzLoadBalancerProbeConfig -Name "HealthProbe" -Protocol http -Port 80 `
    -RequestPath "/" -IntervalInSeconds 15 -ProbeCount 2

# 创建负载均衡规则
$rule = New-AzLoadBalancerRuleConfig -Name "LB-Rule" -FrontendIpConfiguration $frontendIP `
    -BackendAddressPool $backendPool -Probe $probe -Protocol Tcp -FrontendPort 80 -BackendPort 80

# 创建负载均衡器
New-AzLoadBalancer -ResourceGroupName "MyResourceGroup" -Name "MyLoadBalancer" -Location "EastUS" `
    -FrontendIpConfiguration $frontendIP -BackendAddressPool $backendPool `
    -Probe $probe -LoadBalancingRule $rule -Sku Standard

该脚本首先分配静态公共 IP，随后配置前端、后端、健康检查及流量规则，最终创建标准 SKU 的负载均衡器。

组件	说明
前端 IP	接收外部流量的入口点
后端池	实际处理请求的虚拟机集合
健康探针	定期检查实例可用性

第二章：Azure标准负载均衡器配置详解

2.1 标准负载均衡器的架构与工作原理

标准负载均衡器位于客户端与后端服务器之间，负责将请求按照预设策略分发至多个服务实例，提升系统可用性与扩展能力。

核心组件构成

主要由监听器、健康检查模块、调度算法引擎和连接管理单元组成。监听器接收外部流量，健康检查持续探测后端节点状态，确保只将请求转发至健康的实例。

流量分发机制

支持轮询、加权轮询、最小连接数等多种调度策略。以下为加权轮询算法的简化实现逻辑：

type Server struct {
    Endpoint string
    Weight   int
    CurrentWeight int
}

func (l *LoadBalancer) SelectServer(servers []*Server) *Server {
    total := 0
    var selected *Server
    for _, s := range servers {
        total += s.Weight
        s.CurrentWeight += s.Weight
        if selected == nil || s.CurrentWeight > selected.CurrentWeight {
            selected = s
        }
    }
    selected.CurrentWeight -= total
    return selected
}

该算法通过动态调整当前权重值，使高权重服务器被更频繁选中，同时避免饥饿问题。

• 监听器：绑定IP:Port，定义协议类型（HTTP/TCP）
• 健康检查：定期发送心跳请求，超时或异常响应则标记为不可用
• 会话保持：可基于Cookie或源IP维持用户会话一致性

2.2 创建公共标准负载均衡器实战演练

在Azure中创建公共标准负载均衡器，首先需通过门户或CLI定义资源组与虚拟网络。负载均衡器将分配一个公网IP，用于接收外部流量。

配置前端与后端池

前端IP配置关联公网IP，后端池绑定虚拟机网卡。确保所有实例位于同一可用性集或虚拟机规模集。

健康探测与负载均衡规则

设置HTTP或TCP健康探测，路径建议为/health。负载均衡规则如下：

{
  "protocol": "Tcp",
  "frontendPort": 80,
  "backendPort": 80,
  "idleTimeoutInMinutes": 4,
  "enableFloatingIp": false
}

该规则将外部80端口流量分发至后端池实例，探测机制每30秒检查一次实例健康状态，连续两次失败则标记为不可用。

2.3 后端池配置与虚拟机实例关联实践

在负载均衡架构中，后端池是承载实际业务流量的核心组件。通过将虚拟机实例注册到后端池，实现流量的分发与容错。

后端池配置步骤

• 创建后端池并指定唯一标识符
• 配置健康检查路径与间隔时间
• 绑定目标协议（如HTTP/HTTPS）与端口

虚拟机实例关联示例

{
  "backend_pool_id": "pool-abc123",
  "instances": [
    {
      "instance_id": "vm-001",
      "ip": "192.168.1.10",
      "port": 8080,
      "weight": 50
    },
    {
      "instance_id": "vm-002",
      "ip": "192.168.1.11",
      "port": 8080,
      "weight": 50
    }
  ],
  "health_check": {
    "path": "/health",
    "interval_seconds": 10,
    "threshold": 3
  }
}

上述配置定义了一个包含两个虚拟机实例的后端池，权重相同表示流量均摊。健康检查每10秒探测一次，连续失败3次则剔除实例。

实例状态监控表

实例ID	IP地址	状态	最后检测时间
vm-001	192.168.1.10	Healthy	2025-04-05 10:20:00
vm-002	192.168.1.11	Unhealthy	2025-04-05 10:18:30

2.4 健康探测与负载分发规则深度解析

健康探测机制详解

负载均衡系统依赖健康探测（Health Check）判断后端节点可用性。常见探测方式包括HTTP、TCP和ICMP。以HTTP探测为例，系统定期向后端服务发送请求，通过响应状态码判断节点健康状态。

{
  "protocol": "http",
  "path": "/health",
  "interval": 5,
  "timeout": 2,
  "unhealthy_threshold": 3,
  "healthy_threshold": 2
}

上述配置表示每5秒发起一次健康检查，超时2秒判定失败，连续3次失败则标记为不健康，恢复需连续2次成功。

负载分发策略对比

不同场景适用不同分发算法，常用策略如下：

• 轮询（Round Robin）：请求依次分配，适合节点性能相近的场景。
• 加权轮询（Weighted Round Robin）：根据权重分配流量，适用于异构服务器集群。
• 最小连接数（Least Connections）：转发至当前连接最少的节点，适合长连接应用。

策略	适用场景	优点	缺点
轮询	均质化服务节点	实现简单，分布均匀	忽略节点负载差异
加权最小连接	异构服务器集群	兼顾性能与负载	配置复杂度高

2.5 高可用端口与出站规则应用技巧

在构建高可用网络架构时，合理配置高可用端口与出站规则是保障服务连续性的关键。通过定义明确的流量策略，可有效避免单点故障并提升系统弹性。

出站规则配置示例

{
  "outbound_rules": [
    {
      "protocol": "tcp",
      "port_range": [80, 443],
      "destination": "0.0.0.0/0",
      "action": "allow"
    }
  ]
}

上述规则允许实例通过TCP协议访问外部80和443端口，适用于Web服务通信。参数port_range限定端口范围，destination指定目标地址段，action定义行为策略。

高可用端口设计原则

• 避免使用单一固定端口，建议采用端口池动态分配
• 结合健康检查机制，自动切换故障节点流量
• 启用会话保持（Session Persistence）确保连接连续性

第三章：内部与基本负载均衡器对比实践

3.1 内部负载均衡器的应用场景与部署

内部负载均衡器（Internal Load Balancer, ILB）主要用于在私有网络内部分发流量，适用于微服务架构、数据库主从集群、中间件高可用等场景。通过将请求均匀分配到后端多个实例，提升系统可用性与横向扩展能力。

典型应用场景

• 跨可用区的微服务通信，实现低延迟访问
• 数据库读写分离前的连接路由
• 企业内部API网关的流量调度

部署配置示例

{
  "loadBalancer": {
    "type": "internal",
    "subnetIds": ["subnet-prod-a", "subnet-prod-b"],
    "listeners": [{
      "protocol": "HTTP",
      "port": 8080,
      "targetPort": 80,
      "algorithm": "round-robin"
    }]
  }
}

上述配置定义了一个基于子网的内部负载均衡器，采用轮询算法将8080端口的请求转发至后端实例的80端口，确保服务间安全高效的通信。

3.2 基本负载均衡器的功能限制与使用时机

基本负载均衡器适用于流量较小、业务逻辑简单的系统架构，其核心功能通常局限于轮询或随机选择后端节点。

典型功能限制

• 缺乏动态健康检查机制，故障节点剔除不及时
• 不支持基于权重的流量分配
• 无法实现会话保持（Session Persistence）
• 扩展性差，难以集成高级路由策略

适用场景示例

在小型Web服务中，可通过简单配置实现请求分发：

upstream backend {
    server 192.168.1.10:80;
    server 192.168.1.11:80;
}
location / {
    proxy_pass http://backend;
}

上述Nginx配置使用默认轮询策略，适合无状态服务。但当应用需维持用户会话或流量特征复杂时，应升级至高级负载均衡方案。

3.3 不同层级负载均衡器迁移策略分析

在系统演进过程中，负载均衡器的迁移需根据网络层级进行差异化设计。四层（L4）负载均衡基于传输层信息进行转发，性能高但灵活性低；七层（L7）则可解析应用层协议，支持更精细的路由策略。

常见迁移路径对比

• L4 到 L4：适用于架构稳定、仅需扩容的场景，迁移成本最低。
• L4 到 L7：为支持微服务治理而升级，可实现基于内容的路由。
• L7 回退至 L4：在性能瓶颈显著时，牺牲部分功能换取吞吐提升。

配置示例：Nginx 作为 L7 负载均衡器

http {
    upstream backend {
        server 192.168.1.10:8080;
        server 192.168.1.11:8080;
        least_conn;  # 使用最少连接算法
    }
    server {
        listen 80;
        location /api/ {
            proxy_pass http://backend;
        }
    }
}

上述配置中，upstream 定义后端服务池，least_conn 策略减少单节点压力，location /api/ 实现基于路径的七层路由，适用于从四层向微服务架构迁移的场景。

第四章：负载均衡器高可用与安全配置

4.1 多区域部署中的全局负载均衡集成

在多区域部署架构中，全局负载均衡（GSLB）是实现高可用与低延迟访问的核心组件。通过将用户请求智能调度至最优地理区域，系统可有效规避单点故障并提升服务质量。

工作原理与流量调度策略

GSLB通常基于DNS机制实现，结合健康检查、地理位置和延迟探测等策略动态解析域名。常见调度算法包括：

• 地理就近性：将用户导向物理距离最近的数据中心
• 加权轮询：根据各区域容量分配请求权重
• 健康优先：自动屏蔽异常区域，保障服务连续性

配置示例（以BIND DNS为例）

zone "app.example.com" {
    type master;
    file "gslb.db";
};

上述配置定义了GSLB的DNS区域文件，后续可在gslb.db中根据不同视图（view）返回对应区域的IP地址，实现基于客户端来源的智能解析。

健康检查机制

用户请求 → GSLB解析 → 健康探测（HTTP/TCP）→ 返回可用节点

持续监控各区域端点状态，确保仅将流量导向健康的实例组。

4.2 NSG与防火墙协同保障负载均衡安全

在现代云架构中，网络安全组（NSG）与分布式防火墙协同工作，为负载均衡器及其后端实例提供多层防护。NSG负责子网和实例级别的流量过滤，而防火墙则实施更精细的应用层策略。

安全策略分层设计

• NSG作为第一道防线，控制入站和出站的IP协议、端口和源/目的地址
• 防火墙部署于关键路径，执行深度包检测（DPI）和威胁防御
• 负载均衡器前端暴露于公网时，二者共同防止DDoS和非法访问

典型配置示例

{
  "nsgRules": [
    {
      "direction": "Inbound",
      "protocol": "TCP",
      "sourcePortRange": "*",
      "destinationPortRange": "80,443",
      "access": "Allow",
      "priority": 100
    }
  ],
  "firewallPolicy": {
    "applicationRules": [
      {
        "name": "Allow-HTTPS",
        "protocols": ["HTTPS:443"],
        "fqdnTags": ["Microsoft.Update"]
      }
    ]
  }
}

上述配置中，NSG允许HTTP/HTTPS流量进入负载均衡前端，防火墙进一步限制应用层行为，确保仅合法请求可达后端服务器。

4.3 TLS终止与后端加密通信配置实践

在现代微服务架构中，TLS终止通常由边缘代理（如Nginx或API网关）处理，而后端服务间仍需加密通信以保障内网安全。

配置TLS终止代理

server {
    listen 443 ssl;
    ssl_certificate /etc/ssl/certs/example.crt;
    ssl_certificate_key /etc/ssl/private/example.key;
    location / {
        proxy_pass https://backend_cluster;
        proxy_set_header X-Forwarded-Proto https;
    }
}

上述Nginx配置实现了HTTPS入口的TLS终止，证书与私钥路径需确保存在且权限受限。proxy_pass指向后端加密集群，确保流量转发安全。

后端服务间mTLS实践

使用双向TLS（mTLS）增强服务间身份验证：

• 为每个服务颁发客户端证书
• 启用证书吊销检查（CRL/OCSP）
• 集成服务网格（如Istio）自动管理密钥分发

通过合理分层加密策略，既减轻边缘节点压力，又保障内部通信完整性与机密性。

4.4 监控与诊断日志分析提升运维效率

集中式日志管理架构

现代分布式系统中，日志分散在多个节点，传统手动排查方式效率低下。通过构建集中式日志平台（如ELK或Loki），可实现日志的统一采集、存储与检索，显著提升故障定位速度。

关键指标监控示例

// Prometheus导出器记录请求延迟
httpRequestsTotal.WithLabelValues("GET", "200").Inc()
httpRequestDurationMs.Observe(45.6)

上述代码记录HTTP请求次数与响应时间，配合Prometheus抓取，可在Grafana中可视化服务健康状态。标签化指标便于多维分析，快速识别异常服务实例。

• 日志结构化：将文本日志转为JSON格式，提升解析效率
• 告警自动化：基于阈值触发告警，减少人工巡检负担

第五章：总结与考试通关建议

制定科学的复习计划

有效的备考始于合理的规划。建议将整个学习周期划分为三个阶段：基础巩固、专项突破和模拟冲刺。每个阶段分配 2-3 周，结合个人时间灵活调整。

• 第一阶段：通读官方文档，完成核心模块笔记整理
• 第二阶段：针对薄弱项进行强化训练，如网络配置或安全策略
• 第三阶段：每周完成两套全真模拟题，严格计时

实战环境搭建技巧

真实考试往往涉及命令行操作与故障排查。建议使用 Vagrant 快速部署测试环境：

# 启动包含多节点的本地实验环境
vagrant init ubuntu/jammy64
vagrant up
vagrant ssh app-server -c "sudo systemctl status nginx"

高频考点应对策略

根据历年考生反馈，以下知识点出现频率极高，需重点掌握：

考点	推荐练习方式
DNS 解析故障排查	使用 dig/nslookup 模拟异常场景
防火墙规则配置	在 iptables 中设置拒绝策略并验证

时间管理与临场发挥

考试中平均每道题仅 2 分钟作答时间。遇到复杂题型时，先标记跳过，确保简单题得分。提交前务必检查脚本类题目的输出格式是否符合要求，例如 JSON 输出缺少换行可能被判错。