AZ-104负载均衡器实战配置，3小时快速上手企业级应用部署

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

Azure 负载均衡器是 Microsoft Azure 提供的核心网络服务之一，用于在多个虚拟机实例之间高效分发入站或出站流量，从而提升应用程序的可用性和可扩展性。它支持公共和内部负载均衡场景，并可在传输层（第 4 层，TCP/UDP）实现低延迟、高吞吐量的流量分发。

基本功能与类型

• 公共负载均衡器：将来自互联网的流量分发到 Azure 虚拟机，适用于面向公网的应用服务。
• 内部负载均衡器：服务于虚拟网络内部流量，常用于多层应用架构中后端服务的负载分发。
• 区域与全局负载均衡：结合 Azure Traffic Manager 可实现跨区域的流量管理。

关键组件

组件	说明
前端 IP 配置	接收流量的公共或私有 IP 地址
后端池	包含处理请求的虚拟机或虚拟机规模集
负载均衡规则	定义如何将流量从前端映射到后端池
运行状况探针	监控后端实例的可用性，自动隔离故障节点

配置示例

以下命令通过 Azure CLI 创建一个基本的公共负载均衡器：

# 创建公共 IP
az network public-ip create --name MyPublicIP --resource-group MyResourceGroup --sku Standard

# 创建负载均衡器
az network lb create --name MyLoadBalancer --resource-group MyResourceGroup \
  --public-ip-address MyPublicIP --sku Standard

# 添加前端 IP 配置
az network lb frontend-ip create --lb-name MyLoadBalancer --name FrontendPool \
  --public-ip-address MyPublicIP --resource-group MyResourceGroup

# 创建后端池
az network lb address-pool create --lb-name MyLoadBalancer --name BackendPool \
  --resource-group MyResourceGroup

上述命令依次创建公共 IP、负载均衡器实例，并配置前端与后端资源，为后续添加负载均衡规则和健康探测奠定基础。

第二章：负载均衡器核心架构与组件解析

2.1 Azure负载均衡器类型与工作原理深度剖析

Azure负载均衡器分为公共负载均衡器和内部负载均衡器两类。前者面向公网流量，提供Internet到虚拟机的入站分发；后者服务于虚拟网络内部通信，实现后端资源间的私有流量调度。

负载均衡机制

通过五元组（源IP、源端口、目标IP、目标端口、协议）哈希算法决定流量转发路径，确保同一会话始终路由至同一后端实例。

健康探测原理

负载均衡器定期向后端池中的实例发送探测请求，仅将流量分发至健康节点。探测支持HTTP、HTTPS或TCP协议。

类型	部署位置	适用场景
公共负载均衡器	虚拟网络边缘	对外服务暴露
内部负载均衡器	虚拟网络内部	内部微服务通信

{
  "frontendIPConfigurations": [{
    "name": "LoadBalancerFrontEnd",
    "properties": {
      "publicIPAddress": { "id": "/path/to/public-ip" } // 公共IP绑定前端
    }
  }],
  "backendAddressPools": [{
    "name": "BackendPool"
  }]
}

上述配置定义了前端IP与后端地址池的映射关系，是负载均衡器规则生效的基础。

2.2 公共和内部负载均衡器的应用场景对比

公共负载均衡器主要用于将来自互联网的外部流量分发到云环境中的后端实例，适用于面向公众的服务，如Web应用或API网关。而内部负载均衡器则在私有网络内部分发流量，常用于微服务架构中服务间的通信。

典型应用场景

• 公共负载均衡器：电商平台前端服务器、对外提供的RESTful API
• 内部负载均衡器：订单服务调用支付服务、数据库读写分离集群

配置示例（AWS Elastic Load Balancing）

{
  "Scheme": "internal", // 可选值：internet-facing 或 internal
  "LoadBalancerAttributes": {
    "access_logs.s3.enabled": true,
    "idle_timeout.timeout_seconds": 60
  }
}

上述配置中，Scheme: internal 表明该负载均衡器仅限VPC内部访问，适合内部服务间调用；若设为 internet-facing，则允许公网访问，需配合安全组严格控制入口规则。

选择依据对比

维度	公共负载均衡器	内部负载均衡器
网络范围	公网可访问	私有网络内
安全性	较低，暴露于外网	较高，隔离性强

2.3 前端IP配置与后端池设计实践

在负载均衡架构中，前端IP配置决定了流量入口的可达性与安全性。通过绑定弹性公网IP并配置监听规则，可实现对HTTP/HTTPS请求的高效分发。

后端池健康检查机制

为保障服务可用性，需配置定期健康检查。以下为Nginx Plus健康检查示例配置：

upstream backend {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    zone backend 64k;
    health_check interval=5s uri=/health fail_count=3;
}

该配置每5秒向各节点发送GET请求至/health路径，连续3次失败则标记为离线。参数interval控制检测频率，fail_count定义容错阈值。

节点权重动态调整策略

根据服务器性能差异，可通过权重分配优化资源利用率：

• 高性能实例设置更高权重（如 weight=10）
• 普通实例采用默认权重（weight=5）
• 灰度环境节点降低权重以引流小流量

2.4 探测健康检查机制的配置与优化策略

在分布式系统中，健康检查是保障服务高可用的核心机制。合理的探测策略能够及时发现故障实例并触发恢复流程。

健康检查类型与适用场景

常见的健康检查包括存活探针（Liveness Probe）、就绪探针（Readiness Probe）和启动探针（Startup Probe）。其中，存活探针用于判断容器是否需要重启，就绪探针决定实例是否可接收流量。

关键参数调优建议

合理设置以下参数可避免误判与资源浪费：

• initialDelaySeconds：首次探测延迟，应大于应用启动时间
• periodSeconds：探测间隔，过短会增加系统负载
• timeoutSeconds：每次探测超时时间，建议设置为1~3秒

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 3
  failureThreshold: 3

上述配置表示：应用启动30秒后开始HTTP健康检查，每10秒探测一次，3秒未响应视为失败，连续3次失败则重启容器。该策略平衡了响应速度与系统稳定性。

2.5 负载分发规则与会话保持技术实战

负载均衡器的分发策略直接影响服务的性能与可用性。常见的负载分发算法包括轮询、加权轮询、最少连接和IP哈希等。其中，IP哈希可实现基础的会话保持，确保同一客户端请求始终转发至同一后端节点。

主流负载分发策略对比

算法	特点	适用场景
轮询	请求依次分发	节点性能相近
最少连接	转发至活跃连接最少节点	长连接业务
IP哈希	基于源IP计算目标节点	需会话保持

Nginx 配置示例

upstream backend {
    ip_hash;  # 启用基于IP的会话保持
    server 192.168.1.10:8080 weight=3;
    server 192.168.1.11:8080;
}
server {
    location / {
        proxy_pass http://backend;
    }
}

上述配置中，ip_hash 指令启用IP哈希算法，避免引入外部Session存储。权重（weight）设置使高性能节点处理更多流量，提升整体吞吐能力。

第三章：企业级部署前的规划与准备

3.1 网络拓扑设计与子网划分最佳实践

合理的网络拓扑设计是保障系统可扩展性与安全性的基础。采用分层架构（核心层、汇聚层、接入层）能有效提升网络稳定性，同时便于故障隔离与管理。

子网划分策略

使用CIDR进行子网划分，可根据业务单元或地理位置分配独立子网。例如，为研发部门分配192.168.10.0/24，运维部门使用192.168.20.0/24，实现逻辑隔离。

• 优先按功能区域划分子网（如DMZ、内网服务、管理网络）
• 预留地址空间以支持未来扩容
• 结合VLAN与ACL增强访问控制

IP地址规划示例

部门	子网地址	可用主机数
研发	192.168.10.0/24	254
运维	192.168.20.0/24	254

3.2 安全组与网络安全组（NSG）协同配置

在混合云环境中，安全组（Security Group）与网络安全组（NSG）的协同配置是保障跨平台网络隔离的关键。通过统一策略规划，可实现虚拟机、子网和应用层面的细粒度访问控制。

策略协同原则

• 优先定义最小权限访问规则
• 确保私有子网仅允许来自可信IP段的流量
• 在安全组中放行必要端口，NSG中限制横向移动

典型配置示例

{
  "security_group_rules": [
    {
      "direction": "ingress",
      "protocol": "tcp",
      "port_range": 80,
      "source": "0.0.0.0/0"
    }
  ],
  "nsg_rules": [
    {
      "priority": 100,
      "access": "Allow",
      "sourceAddressPrefix": "VirtualNetwork",
      "destinationPortRange": "80"
    }
  ]
}

上述配置中，安全组开放Web服务端口，NSG则基于优先级控制子网间通信，形成纵深防御体系。参数priority决定规则匹配顺序，access定义允许或拒绝动作，确保流量按预设路径流转。

3.3 高可用性与跨区域部署策略分析

在分布式系统中，高可用性依赖于跨区域部署来规避单点故障。通过在多个地理区域部署服务实例，结合全局负载均衡器（如DNS-Based LB），可实现流量的智能调度。

数据同步机制

跨区域间的数据一致性是挑战核心。常用方案包括异步主从复制和多活架构：

• 主从复制：中心写入，多地读取，延迟可控但存在单点风险
• 多活架构：多地均可写，需解决冲突合并问题

典型配置示例

// 跨区域健康检查逻辑
func CheckRegionHealth(region string) bool {
    resp, err := http.Get("https://" + region + ".api.service/health")
    if err != nil || resp.StatusCode != 200 {
        return false
    }
    return true
}

上述代码实现对各区域健康状态的探测，由全局负载均衡器调用，决定流量路由方向。参数region标识目标区域，返回bool表示服务可用性。

第四章：实战配置全流程演练

4.1 创建公共标准负载均衡器并配置前端

在Azure中创建公共标准负载均衡器是构建高可用网络架构的关键步骤。首先需通过Azure门户或CLI定义负载均衡器资源，并指定其SKU为“标准”，以支持出站规则和高级路由功能。

创建负载均衡器实例

使用Azure CLI命令创建公共标准负载均衡器：

az network lb create \
  --resource-group myResourceGroup \
  --name myPublicLB \
  --sku Standard \
  --public-ip-address myPublicIP \
  --frontend-ip-name myFrontend

该命令创建名为 `myPublicLB` 的负载均衡器，关联公共IP `myPublicIP`，并初始化前端IP配置。参数 `--sku Standard` 确保启用高级功能如区域冗余和出站SNAT。

前端IP配置说明

前端配置负责接收入站流量。标准负载均衡器自动创建动态前端，也可绑定静态公共IP以保障地址持久性。前端IP将与后续的负载均衡规则关联，实现流量分发。

4.2 构建后端虚拟机池并注册实例

在构建高可用的后端服务架构时，虚拟机池的建立是实现负载均衡与弹性扩展的基础。通过统一管理多个虚拟机实例，系统可动态分配资源，提升整体稳定性。

虚拟机池初始化流程

使用云平台API批量创建虚拟机，并配置统一的镜像、安全组和网络环境。以下为基于OpenStack的Nova API调用示例：

import novaclient.client

nova = novaclient.client.Client(
    version='2.1',
    username='admin',
    password='secret',
    project_name='service',
    auth_url='http://keystone:5000/v3'
)

instance = nova.servers.create(
    name="backend-worker-01",
    image="ubuntu-20.04-base",
    flavor="m1.medium",
    network="internal-net"
)

上述代码通过Python SDK创建虚拟机实例，image指定基础镜像，flavor定义计算资源配置，确保所有节点环境一致性。

实例注册与健康检查

新创建的实例需向服务注册中心（如Consul）注册自身信息，并定期上报心跳：

• 实例启动后调用Consul API注册服务端口与标签
• 配置TTL健康检查机制，防止故障节点参与调度
• 负载均衡器根据健康状态动态更新后端列表

4.3 配置健康探测与负载均衡规则

健康探测机制配置

为确保后端服务的高可用性，需配置主动健康检查。以下为 Nginx 中定义的健康探测配置示例：

location /health {
    access_log off;
    return 200 'OK';
    add_header Content-Type text/plain;
}

该配置关闭日志记录，返回简洁的 200 响应，用于被负载均衡器定期探测。路径 /health 应由应用实现轻量级状态检查。

负载均衡策略设置

Nginx 支持多种负载均衡算法，常用包括轮询、IP Hash 和最少连接数。配置如下：

• 轮询（默认）：请求按顺序分发到各服务器
• ip_hash：基于客户端 IP 分配固定后端
• least_conn：优先转发至连接数最少的节点

upstream backend {
    least_conn;
    server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
}

参数说明：max_fails 表示最大失败次数，fail_timeout 为判定宕机前的等待时间。此配置提升系统容错能力。

4.4 测试与验证流量分发效果

在完成流量分发策略配置后，必须通过系统化测试验证其实际效果。核心目标是确认请求是否按预期比例分配至不同服务节点，并保障响应性能稳定。

测试方案设计

采用自动化压测工具模拟多用户并发访问，观察各后端实例的负载分布。常用指标包括QPS、延迟和错误率。

验证结果示例

# 使用 wrk 进行并发测试
wrk -t10 -c100 -d30s http://gateway-service/api/v1/resource

该命令启动10个线程，维持100个长连接，持续30秒向网关发起请求。通过监控后端服务的访问日志，可分析流量分配比例是否符合权重设置。

• 检查各实例接收请求数量是否接近预期比例（如 70/30）
• 验证异常实例是否被及时剔除出调度列表
• 确认故障恢复后能否重新接入流量

第五章：性能优化与故障排查指南

监控系统资源使用情况

定期检查 CPU、内存、磁盘 I/O 和网络吞吐量是定位性能瓶颈的第一步。Linux 系统中可使用 top、htop 或 iotop 实时查看资源占用。例如，以下命令可快速识别高负载进程：

# 查看按 CPU 使用排序的前 10 进程
ps aux --sort=-%cpu | head -11

# 监控内存使用情况
free -h

数据库查询优化策略

慢查询是 Web 应用常见的性能瓶颈。启用 MySQL 慢查询日志并结合 EXPLAIN 分析执行计划：

-- 分析查询执行路径
EXPLAIN SELECT * FROM users WHERE email = 'user@example.com';

确保在 email 字段上建立唯一索引，避免全表扫描。

• 避免在 WHERE 子句中对字段进行函数操作
• 使用覆盖索引减少回表次数
• 定期分析和优化表结构（ANALYZE TABLE）

应用层缓存配置建议

引入 Redis 作为缓存层可显著降低数据库压力。以下为 Go 应用中集成 Redis 的典型配置：

client := redis.NewClient(&redis.Options{
    Addr:     "localhost:6379",
    DB:       0,
    PoolSize: 100,
})

设置合理的过期时间（TTL），防止缓存雪崩。采用缓存穿透防护策略，如空值缓存或布隆过滤器。

常见故障排查流程

问题：API 响应延迟突增

1. 检查服务日志是否有错误堆栈
2. 使用 curl -w 测量各阶段耗时
3. 确认外部依赖（如数据库、第三方 API）状态
4. 查看是否触发限流或熔断机制

指标	正常范围	告警阈值
请求延迟 P95	< 200ms	> 800ms
错误率	< 0.5%	> 2%