【MCP AZ-104必考核心】：深入解析虚拟机扩展集的5大实战应用场景-优快云博客

第一章：虚拟机扩展集的核心概念与MCP AZ-104考点解析

虚拟机扩展集（Virtual Machine Scale Sets, VMSS）是 Microsoft Azure 中用于部署和管理大量相同配置虚拟机的核心服务，广泛应用于高可用性、自动伸缩和负载均衡场景。作为 MCP AZ-104 认证考试的重要考点，理解其架构设计与实际配置至关重要。

虚拟机扩展集的基本特性

支持统一的虚拟机模板部署，确保实例一致性
集成自动缩放功能，可根据 CPU 使用率、队列长度等指标动态调整实例数量
与 Azure 负载均衡器和应用网关无缝集成，实现流量分发
支持区域和可用区部署，提升容灾能力

创建虚拟机扩展集的典型命令

在 Azure CLI 中，可通过以下命令快速创建一个基于 Ubuntu 镜像的扩展集：


# 创建资源组
az group create --name myResourceGroup --location eastus

# 创建虚拟机扩展集
az vmss create \
  --resource-group myResourceGroup \
  --name myScaleSet \
  --image Ubuntu2204 \
  --vm-sku Standard_DS2_v2 \
  --instance-count 3 \
  --admin-username azureuser \
  --generate-ssh-keys \
  --load-balancer myLoadBalancer

上述命令将创建包含三个实例的扩展集，使用标准 D2s v2 规格，并自动生成 SSH 密钥用于安全登录。

AZ-104 考试重点分布

考点类别	考察频率	相关操作
自动缩放策略配置	高频	设置基于指标的伸缩规则
升级策略类型	中频	选择手动、滚动或自动模式
跨可用区部署	中频	配置区域冗余架构

graph TD A[定义 VM 模板] --> B[创建扩展集] B --> C[配置自动缩放] C --> D[关联负载均衡器] D --> E[监控与维护]

第二章：虚拟机扩展集的高可用性架构设计

2.1 理解VMSS在可用性集与可用区中的角色

虚拟机规模集（VMSS）通过集成可用性集和可用区，提升应用的高可用性与容错能力。在单个数据中心内，可用性集通过将实例分布在多个故障域和更新域中，降低硬件故障带来的影响。

跨区域部署优势

使用可用区时，VMSS 可跨多个物理区域分布实例，实现区域性灾难恢复。相比仅依赖可用性集，该方案提供更强的冗余能力。

特性	可用性集	可用区
故障域范围	机架级	数据中心级
区域跨度	单区域	多区域

{
  "zones": ["1", "2", "3"],  // 启用多可用区部署
  "platformFaultDomainCount": 2
}

上述配置表示 VMSS 实例将跨三个可用区部署，每个区域内部再利用故障域隔离，实现双重容错机制。参数 zones 明确启用跨区能力，适用于对业务连续性要求极高的场景。

2.2 配置跨区域复制提升容灾能力

数据同步机制

跨区域复制通过异步数据同步机制，在主备区域间持续传输数据变更，确保灾难发生时可快速切换。该机制基于增量日志捕获，最小化网络带宽占用。

配置示例

{
  "replication": {
    "sourceRegion": "us-east-1",
    "targetRegion": "eu-west-1",
    "syncIntervalSeconds": 30,
    "encryptionEnabled": true
  }
}

上述配置定义了源与目标区域，每30秒同步一次，并启用传输加密。syncIntervalSeconds越小，RPO（恢复点目标）越低，但需权衡网络成本。

提升数据持久性，避免单区域故障导致服务中断
支持自动故障转移策略，结合DNS切换实现分钟级恢复

2.3 实践：构建多区域部署的Linux VMSS集群

在高可用架构中，跨区域部署虚拟机规模集（VMSS）是提升容灾能力的关键手段。通过将Linux VMSS部署在多个Azure区域，可实现地理冗余与负载分发。

部署流程概览

选择支持可用区的区域（如East US、West Europe）
定义统一的自定义镜像或配置脚本
使用ARM模板或Terraform实现基础设施即代码

核心配置示例

{
  "sku": {
    "name": "Standard_DS1_v2",
    "tier": "Standard",
    "capacity": 2
  },
  "zones": ["1", "2", "3"]
}

上述配置启用三可用区部署，zones字段指定物理分布，确保单点故障不影响整体服务。

网络与同步策略

后端负载均衡器需配置区域性前端IP，结合Azure DNS流量管理器实现全局路由。数据层建议采用异步复制的Cosmos DB或多主模式PostgreSQL，保障跨区写入一致性。

2.4 利用健康探测实现自动实例修复

在分布式系统中，保障服务高可用的关键在于及时发现并恢复异常实例。健康探测机制通过周期性检查实例状态，自动触发修复流程。

健康探测类型

常见的健康探测包括：

Liveness Probe：判断容器是否存活，失败则重启实例；
Readiness Probe：判断实例是否就绪，未就绪则从负载均衡中剔除。

配置示例

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

上述配置表示：应用启动30秒后开始探测，每10秒一次，连续3次失败则触发容器重启。`httpGet`通过HTTP接口返回状态码判断健康性，适用于大多数Web服务。

自动修复流程

健康探测 → 状态异常 → 触发重启/替换 → 重新加入服务集群

该机制显著降低人工干预频率，提升系统自愈能力。

2.5 模拟故障转移验证高可用性效果

在高可用架构中，模拟故障转移是验证系统容错能力的关键步骤。通过主动关闭主节点服务，观察备用节点是否能自动晋升为主节点并接管服务，可真实还原生产环境中节点宕机的应对机制。

故障转移触发流程

典型的故障转移流程包括：心跳检测超时、集群状态重协商、角色切换与客户端重定向。以下为基于Keepalived的主备切换配置片段：


vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.1.100
    }
}

该配置定义了VRRP实例的优先级和虚拟IP绑定。当MASTER节点宕机后，BACKUP节点在1秒内检测到心跳中断，自动将虚拟IP绑定至本地接口，实现服务接管。

验证方法与指标

使用ping和curl持续监测服务可达性
记录服务中断时间，确保RTO小于30秒
检查数据一致性，防止脑裂导致的数据冲突

第三章：基于负载动态伸缩的自动化实践

3.1 自动缩放规则与性能指标原理剖析

自动缩放的核心在于根据实时性能指标动态调整计算资源。系统通过监控CPU使用率、内存占用、请求延迟等关键指标，触发预定义的扩缩容规则。

常用性能指标

CPU利用率：反映实例的计算负载压力
内存使用量：判断是否存在资源瓶颈
请求并发数：衡量服务访问压力
队列长度：适用于消息驱动架构的伸缩依据

典型缩放规则配置示例

{
  "metric": "CPUUtilization",
  "threshold": 75,
  "comparisonOperator": "GreaterThanThreshold",
  "scalingAction": "increase",
  "adjustmentType": "ChangeInCapacity",
  "scaleBy": 2
}

上述规则表示当CPU平均使用率持续超过75%时，增加2个实例。threshold为触发阈值，scalingAction定义扩展方向，scaleBy控制增量粒度，确保系统在负载上升时及时响应。

3.2 实践：配置CPU驱动的横向扩展策略

在Kubernetes中，基于CPU使用率的横向扩展可通过Horizontal Pod Autoscaler（HPA）实现。通过监控Pod的资源利用率，动态调整副本数量以应对负载变化。

HPA配置示例

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

该配置表示当CPU平均利用率超过50%时，自动增加Pod副本，副本数维持在2到10之间。target.type为Utilization，表示按百分比触发扩缩容。

关键参数说明

minReplicas：确保服务最低可用实例数；
averageUtilization：HPA根据此阈值计算所需副本数；
scaleTargetRef：指定需弹性伸缩的Deployment。

3.3 使用Azure Monitor监控伸缩行为并优化阈值

配置监控指标以捕获伸缩动态

Azure Monitor 提供对应用服务或虚拟机规模集的 CPU、内存、请求率等关键指标的实时采集。通过设置诊断设置，可将指标数据流向 Log Analytics 工作区。

{
  "metrics": [
    {
      "category": "AllMetrics",
      "enabled": true,
      "retentionPolicy": { "days": 30, "enabled": true }
    }
  ]
}

此配置启用所有性能指标的收集，并保留30天，便于回溯分析伸缩触发前后的系统负载趋势。

基于历史数据优化自动伸缩阈值

分析长时间窗口内的指标峰值与业务负载模式，有助于避免误伸缩。例如，可通过 Kusto 查询识别每日高峰：

CPU 超过 75% 持续5分钟 → 触发扩容
平均队列长度 > 10 → 启动额外实例
内存使用率持续低于 30% → 触发缩容

结合警报规则与 Application Insights 数据，实现精准阈值调优，提升资源利用率并控制成本。

第四章：虚拟机扩展集在企业级应用中的集成方案

4.1 与Azure Load Balancer集成实现流量分发

在构建高可用的云原生应用时，将Kubernetes集群与Azure Load Balancer集成是实现外部流量高效分发的关键步骤。Azure Load Balancer作为第4层负载均衡器，能够将入站流量分发到集群中多个节点的健康Pod上。

服务配置示例

通过定义Type为LoadBalancer的Service资源，可自动创建或绑定Azure负载均衡器：

apiVersion: v1
kind: Service
metadata:
  name: azure-lb-service
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "false"
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080
  selector:
    app: my-web-app

上述配置中，port指定负载均衡器监听端口，targetPort指向Pod实际暴露的服务端口，selector确保流量仅转发至匹配标签的Pod。

流量调度机制

外部请求通过公共IP进入Azure Load Balancer
负载均衡器基于五元组哈希选择后端节点
Kube-proxy组件通过iptables或IPVS规则将流量导向目标Pod

4.2 结合Application Gateway支持HTTPS应用交付

在Azure环境中，Application Gateway作为第7层负载均衡器，可实现对后端应用服务的安全HTTPS流量代理与统一入口管理。通过集成公共或私有SSL证书，网关可在前端终止HTTPS连接，并基于路由规则将解密后的请求转发至后端池中的HTTP服务。

配置HTTPS监听器

需先上传SSL证书并绑定到HTTPS类型的前端监听器：

{
  "frontendPorts": [
    {
      "name": "httpsPort",
      "port": 443
    }
  ],
  "httpListeners": [
    {
      "name": "httpsListener",
      "frontendPort": { "id": "httpsPort" },
      "protocol": "Https",
      "sslCertificate": { "id": "sslCert" }
    }
  ]
}

上述配置定义了监听443端口的HTTPS监听器，并引用已上传的SSL证书用于加密通信。

安全策略与后端健康检查

Application Gateway自动对后端实例执行HTTPS或HTTP健康探测。若后端为内部HTTP服务，SSL终止发生在网关层，简化后端维护复杂度，同时保障外网访问安全性。

4.3 部署自定义脚本扩展完成应用初始化配置

在Azure虚拟机部署过程中，自定义脚本扩展（Custom Script Extension）可用于自动化应用的初始化配置，提升部署一致性与效率。

扩展安装流程

该扩展通过代理在目标虚拟机上下载并执行指定脚本，支持从公共URL或Azure存储中获取脚本文件。

{
  "fileUris": ["https://mystorage.blob.core.windows.net/scripts/init.sh"],
  "commandToExecute": "sh init.sh"
}

上述配置指定了脚本的远程地址和执行命令。fileUris 支持多个脚本文件，commandToExecute 定义实际运行的指令。

典型应用场景

自动安装Nginx、Python等依赖软件包
配置防火墙规则与系统环境变量
拉取私有仓库代码并启动服务进程

4.4 集成Key Vault实现安全凭据自动化注入

在现代云原生架构中，敏感信息如数据库密码、API密钥等需集中加密管理。Azure Key Vault 提供了高安全性的凭据存储与访问控制机制。

自动化注入流程

通过 Azure Managed Identity 与应用服务集成，可免密访问 Key Vault。应用启动时，从 Key Vault 动态获取配置，避免硬编码。

{
  "vaultUri": "https://myvault.vault.azure.net/",
  "tenantId": "xxxx-xxxx-xxxx-xxxx",
  "clientId": "yyyy-yyyy-yyyy-yyyy"
}

上述配置定义 Key Vault 连接参数，由托管身份认证后用于检索机密。

访问策略配置

为应用服务分配系统托管身份
在 Key Vault 中授予该身份“Get”和“List”权限
使用 Azure CLI 或 ARM 模板实现策略自动化部署

支持与 Azure App Configuration 联动，实现配置与机密分离管理。

第五章：总结与AZ-104考试冲刺建议

构建实战环境进行模拟操作

在备考AZ-104时，建议使用Azure免费账户搭建实验环境。通过实际部署虚拟机、配置虚拟网络和管理存储账户，加深对核心服务的理解。

登录Azure门户并激活免费订阅（含12个月免费服务）
创建资源组用于隔离实验环境
使用PowerShell脚本批量部署测试资源

重点掌握的命令行操作

熟悉Azure CLI是高效管理资源的关键。以下为常用命令示例：


# 创建资源组
az group create --name myResourceGroup --location eastus

# 部署Ubuntu虚拟机
az vm create \
  --resource-group myResourceGroup \
  --name myVM \
  --image Ubuntu2204 \
  --admin-username azureuser \
  --generate-ssh-keys

# 查看运行状态
az vm show --resource-group myResourceGroup --name myVM --query "provisioningState"