Microsoft AZ-104: Azure App Service 和 PaaS 计算 — 学习指南

By Laurynas Brazys · 7 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

属于 Microsoft Azure Administrator Associate AZ-104 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Azure 的 PaaS 计算产品组合包括完全托管的 Web/应用托管、无服务器函数、工作流自动化、按需容器和容器编排。作为管理员，成功的关键在于理解每项服务的边界、它们的网络连接和身份验证方式，以及如何可靠地部署和扩展。本节涵盖 App Service（计划、部署槽、网络和内置身份验证）、Azure Functions 和 Logic Apps（计划、触发器、连接器）、Azure Container Instances 和 AKS（调度、扩展、运维工具）以及隔离的 App Service Environment。

App Service 与 Functions 计算基础

App Service 计划决定了运行在专用计划上的 Web 应用、API 应用和函数应用的计算资源池。各层级具有不同的功能和缩放模型：

• 免费 (F1) 和共享 (D1) 层在共享基础设施上运行，有配额限制且无 SLA。它们仅适用于实验。部署槽、VNet 集成和自动缩放等功能不可用。
• 基本 (B) 层以小规模分配专用虚拟机，支持手动横向扩展。它缺少自动缩放和部署槽功能。
• 标准 (S) 层引入了自动缩放、多实例、每日备份和部署槽。它是需要预演环境的生产工作负载的入门选择。
• 高级 (Pv2/Pv3) 层提升了 CPU/内存、I/O 性能和功能限制（更多实例、更多槽），并增加了高级网络功能，如 Private Endpoint 集成和区域冗余。
• 隔离/隔离 v2 层在 App Service Environment 内部运行，在您的虚拟网络内部提供单租户、专用的计算资源，以实现严格的隔离和合规性。

缩放分为纵向扩展（更改定价层/虚拟机大小）和横向扩展（更改实例计数）。自动缩放需要标准层及以上，并由 Azure Monitor 规则（CPU、通过 App Service 指标获取的内存，或自定义指标）驱动。缩放操作针对每个 App Service 计划执行，并影响该计划内的所有应用。

部署槽在同一计划中提供实时应用实例，用于预演更改。标准层及以上支持部署槽，其中标准层支持的数量较少，而高级/隔离层支持的数量更多。交换操作通过交换槽内容和配置来编排零停机时间的提升，同时遵循槽设置（随槽保留的粘性应用设置和连接字符串）。“带预览的交换”会在完成前预热目标槽并评估其运行状况。“生产环境测试”功能将一定比例的生产流量路由到一个或多个槽；路由对每个客户端是粘性的，以在测试ランプ期间保持会话亲和性。

App Service 网络提供受控的出站和入站连接：

• 区域 VNet 集成将出站流量路由到同一区域内虚拟网络中的一个委派子网。它能够将流量出口到私有终结点、通过 VPN/ExpressRoute 连接的本地环境以及服务终结点。它不会改变公共入站行为。
• Private Endpoint 通过将应用的前端映射到私有 IP，在您的 VNet 内私下发布应用；与访问限制结合使用，可在 ASE 之外强制执行仅限私有的入口。
• 混合连接通过 Azure Relay 提供从应用到本地或其他网络中特定 主机:端口 终结点的出站 TCP 连接，无需更改入站防火墙规则。它不是通用的 VNet 隧道，且不支持 UDP。
• 访问限制评估针对客户端 IP、服务标签和虚拟网络流量（通过 Private Endpoints 或多租户 VNet 规则）的有序允许/拒绝规则。锁定到特定的范围、VNet 或前端以满足合规性要求。

内置身份验证/授权（“Easy Auth”）通过一个托管的身份验证处理程序为您的应用提供前端保护，无需更改代码即可分载令牌验证。支持的提供商包括 Microsoft Entra ID (Azure AD)、Microsoft 帐户、Google、Facebook、Twitter 和通用的 OpenID Connect。您可以强制所有请求都需登录，或将请求传递给应用处理，设置允许的受众，以及限制到特定的租户。可选的令牌存储会缓存提供商的令牌，并通过 /.auth/me 终结点和请求头公开声明。与系统分配的托管标识结合使用，以安全地调用下游 Azure 服务。

Azure Functions 提供事件驱动的计算，有三种托管模型：

• 消耗计划是无服务器的，按次执行、按 GB-秒计费，并能自动横向扩展和缩减至零。它存在冷启动问题，并且在过去，某些触发器不支持 VNet 集成；较新的功能支持范围更广，但网络敏感型工作负载应验证其支持情况。
• 高级计划通过预热实例消除了冷启动，支持 VNet 集成和 Private Endpoints，并根据事件进行扩展，同时可控制最小/最大实例数。
• 专用计划 (App Service Plan) 在您的 App Service 计划容量上运行 Functions；成本是按预留实例计算的，无论使用情况如何，并可在计划级别选择性地进行自动缩放。 Functions 触发器包括 HTTP、计时器、存储（队列/Blob/表）、Service Bus、Event Hubs、Event Grid、Cosmos DB 等，并带有输入/输出绑定以声明方式连接服务。Durable Functions 以代码优先的模型添加了有状态的编排，使用业务流程协调程序函数和活动函数，支持扇出/扇入、异步 HTTP、人工交互和 Saga 等模式。状态被持久化到存储提供程序中（Azure 存储是常用选择），确保了工作流的弹性和可重放性。

App Service 计划模型和消耗模型的成本与缩放行为有本质区别。App Service 计划按始终运行的实例的大小和数量收费，并根据计划规则进行缩放。Functions 消耗模型仅按执行时间和内存收费，并基于并发自动扩展和缩减至零。高级计划介于两者之间，结合了预留的预热容量和突发扩展能力。

容器和 Kubernetes

Azure Container Instances (ACI) 提供按需、按秒计费的容器，无需管理虚拟机或编排器。部署单元是容器组：一个或多个调度在同一主机上的容器，共享 IP、端口、卷和生命周期。可以为每个容器定义 CPU/内存、公开端口，并挂载卷，例如 Azure Files、机密 (secrets) 和 emptyDir。环境变量可以是普通类型或安全类型（会从日志/元数据中排除）。重启策略控制生命周期：Always（长时间运行服务的默认设置）、OnFailure（适用于在非零退出时应重试的作业）和 Never（适用于希望在不重启的情况下检查退出状态的“运行到完成”任务）。网络方面支持公共 IP、通过 VNet 注入到委托子网的私有 IP，以及用于公共终结点的 DNS 名称标签。

Azure Kubernetes Service (AKS) 是一个托管的 Kubernetes 控制平面，其节点池被预配为 Virtual Machine Scale Sets。节点池区分系统工作负载（kube-system 组件）和用户工作负载，支持多种虚拟机大小，并且可以运行 Linux 和 Windows（Windows 至少需要一个 Linux 系统池）。可以为池设置污点 (taint) 以控制调度。升级是按池编排的，而 maxPods、可用区和临时 OS 磁盘则在创建池时配置。集群自动缩放器与 Kubernetes 调度集成，在有 pod 因无法调度而处于挂起状态或节点利用率不足时，在最小/最大边界内修改节点数量；它会遵循 PodDisruptionBudgets，并且只在安全的情况下进行缩减。Horizontal Pod Autoscaler 作为补充，它根据指标来扩展 Deployment 中的副本数量。

集群管理 kubectl 基础：

• 使用 az aks get-credentials 连接，以合并 kubeconfig 并选择上下文。
• 检查资源：kubectl get nodes/pods/deployments -o wide；使用 kubectl describe 查看详细信息和事件。
• 诊断和交互：使用 kubectl logs 查看 stdout/stderr，使用 kubectl exec -it 进行交互式故障排查。
• 应用期望状态：kubectl apply -f manifests.yml；使用命名空间 (namespaces) 来限定资源范围；使用 kubectl config set-context 切换命名空间。

网络插件（Azure CNI 或 kubenet）、身份（托管标识 vs 服务主体）以及 RBAC/Entra ID 集成决定了 pod 的 IP 分配、集群身份验证和授权。确保集群身份拥有对负载均衡器、托管磁盘和节点资源组的权限。

集成、网络和安全

Logic Apps 提供了一个托管的工作流引擎，其连接器可连接数百个 SaaS 和 Azure 服务。一个工作流由一个启动运行的触发器 (trigger) 和执行步骤的操作 (actions) 组成。触发器包括 HTTP 请求、定期执行 (Recurrence)、Service Bus 消息、Event Grid 事件、存储事件以及许多 SaaS 事件（例如，在 Dynamics 365 中创建记录时）。操作包括控制结构（条件、循环、切换）、数据操作（撰写、解析 JSON、变量）和连接器操作（发送电子邮件、将消息入队、调用 API）。与 Azure 服务的集成非常深入：

• Service Bus 和 Event Grid 为解耦架构提供可靠的消息传递和事件处理。
• 可以调用 Functions 来执行自定义代码步骤（同步 HTTP 或通过队列异步）。
• 托管标识 (Managed identity) 可以在没有机密的情况下安全地访问 Key Vault、Storage、SQL 和其他 Azure 资源。 Logic Apps Consumption（多租户）按操作执行和连接器使用量计费；Logic Apps Standard（单租户）在 App Service 计划或 Premium 计划中的 Functions 运行时上运行，支持本地开发、VNet 集成、私有终结点和更高的吞吐量。在 Consumption 模型中，Integration Service Environment (ISE) 在需要时为托管连接器提供 VNet 隔离。

App Service Environment (ASE) 实现了 App Service 的 Isolated (独立) 层。ASE 部署在你的虚拟网络中，提供具有网络控制能力的单租户、专用的计算和存储单元 (stamp)。外部 ASE 公开公共入口终结点；内部负载均衡器 (ILB) ASE 则只发布一个私有 VIP，用于严格的私有访问。ASE 中的应用使用 Isolated/Isolated v2 定价层。你需要同时支付环境的单元费用 (stamp fee) 和每个实例的工作器成本。当合规性、网络隔离或规模要求超出多租户 App Service 的能力时，应选择 ASE。在 ASE v3 中，部署和网络得到了简化，但其核心价值主张保持不变：以你的 VNet 作为边界的、专用的、可通过私有地址访问的 App Service。

跨这些服务的访问治理依赖于用于资源操作的 Azure RBAC、用于服务到服务身份验证的托管标识，以及在身份平面的条件访问 (Conditional Access)。对于 App Service 的入站控制，根据需要将 Private Endpoints 或 ILB ASE 与访问限制以及启用 WAF 的前端（例如 Application Gateway 或 Azure Front Door）结合使用。对于出站控制，使用 VNet 集成，并配合 NSG、路由表以及用于数据服务的私有终结点。

部署与扩展操作

对 App Service 进行可靠的发布，可使用部署槽在交换前验证运行状况并预热缓存。将因环境而异的配置标记为“槽设置”，这样它在交换期间就不会移动（例如，连接字符串、功能标志）。使用“带预览的交换”来执行运行状况探测或应用程序特定的预热终结点；如果运行状况不佳，则中止交换。在金丝雀发布期间，启用流量路由，将一小部分粘性会话的流量定向到过渡槽，然后逐步增加比例。特定于槽的应用设置可以安全地切换 Beta 功能。

App Service 计划的自动缩放是在计划资源上配置的，使用配置文件（基于时间的最小/最大/默认实例数）和规则（带有缩放步长和冷却时间的指标阈值）。将 CPU 与自定义指标（例如，队列长度）相结合，以实现更精确的缩放。对于 Functions，消耗计划会自动缩放；监控并发性并配置 host.json 文件以定义每个触发器的行为（例如，Service Bus 的批处理大小和预取）。高级计划可缩放预热实例和突发实例；将最小实例数与延迟目标对齐。

在容器中，ACI 的重启策略应反映其意图：批处理作业应设为 Never 或 OnFailure 以避免无限循环；服务应使用 Always。使用环境变量进行配置，使用 Azure Key Vault 存储机密，通过托管标识和启动代码注入，或在适当情况下将机密挂载为卷。在 AKS 中，为每个节点池启用具有合理最小/最大边界的集群自动缩放器，并为关键的 Deployment 配置 HPA。为冗余容量做好预算，并设置 Pod 中断预算以在升级和缩减期间保障可用性。在广泛推广集群或节点池升级之前，先在金丝雀节点池中验证升级。

实际问题场景

Fabrikam 公司运行一个客户门户和后台处理服务。他们必须现代化到 PaaS，强制对数据存储进行专用网络访问，支持蓝绿部署，并在不管理虚拟机的情况下运行每晚的容器化 ETL 作业。

1. 使用带有部署槽的 App Service Premium 托管门户

• 在 Premium v3 中创建一个 App Service 计划以获得更高性能和更多槽位，并部署带有过渡槽的 Web 应用。
• 为特定于环境的值配置槽设置，并启用带预览的交换和运行状况检查。
• 原因：Premium 计划提供自动缩放、更多槽位、专用终结点支持以及适合生产流量的 SLA。部署槽提供安全的蓝绿发布和金丝雀路由。

2. 强制实施专用入站和受控出站

• 为 Web 应用启用专用终结点，并设置访问限制以拒绝公共网络访问。
• 配置区域 VNet 集成到一个委托子网，以便通过 ExpressRoute 对专用数据存储和本地资源进行出站访问。
• 原因：专用终结点加上访问限制可保证仅限专用访问；VNet 集成通过 VNet 边界路由出站流量，以实现一致的防火墙策略。

3. 使用 Azure Functions Premium 实现后台处理

• 在 Premium 计划上部署一个带有系统分配的托管标识的 Function App，使用 Service Bus 和 Storage 触发器来处理队列驱动的工作负载。
• 设置最小预热实例数以消除冷启动，并与同一个 VNet 集成。
• 原因：Premium Functions 满足低延迟和 VNet 要求，同时为突发性工作负载保留了无服务器的扩展能力。

4. 使用 Logic Apps Standard 编排跨服务工作流

• 构建工作流以协调客户引导流程：由 Service Bus 消息触发，调用 Function App，写入 Storage，并通过 Microsoft 365 连接器发送通知。
• 使用托管标识访问 Key Vault 和 Storage，并部署在同一个 App Service 计划中，以利用 VNet 集成和专用终结点。
• 原因：Logic Apps 提供有弹性的可视化编排和原生连接器；Standard 套餐提供 VNet 集成和单租户性能。

5. 在 Azure Container Instances 中运行夜间 ETL 作业

• 定义一个包含 ETL 容器的容器组，挂载一个 Azure 文件共享用于存储中间数据，设置安全的环境变量，并使用 restartPolicy: Never。
• 将该容器组附加到 VNet 委托子网，以实现对数据库的专用访问。
• 原因：ACI 提供面向作业的按秒计费的计算能力，没有集群开销，并与 VNet 集成以实现数据局部性和安全性。

6. 为容器化微服务准备 AKS

• 创建一个 AKS 集群，包含一个小型 Linux 系统节点池和一个根据预期负载调整大小的用户节点池，启用集群自动缩放器（设置最小/最大边界），并与 Entra ID 和 Azure CNI 集成以实现 Pod 级别的 IP。
• 使用 kubectl 部署一个金丝雀微服务，并根据 CPU 和自定义指标设置 HPA。
• 原因：当服务数量增多时，AKS 提供企业级编排；自动缩放器和 HPA 使容量与需求保持一致，而 kubectl 提供标准的操作控制。

← Azure 存储 · 所有领域 · Azure 数据库和数据服务 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Microsoft →