企业官网建设流程全解析

• 文档/教程

本篇是 #90DaysOfDevOps 开源学习计划中 Microsoft Azure 章节的第三站。在 第 30 天 掌握 Azure 安全模型之后，本篇文章将系统梳理 Azure 的计算服务全景：从服务可用性选项、虚拟机选型，到 JSON 模板化部署、VMSS 弹性伸缩，再到容器服务、应用服务与 Serverless 计算。读完本文，你将能够根据可用性、成本、运维抽象层级等维度，在 IaaS、PaaS、容器与 Serverless 之间做出合理的 Azure 计算选型，并为后续动手部署打好理论地基。

从安全模型到计算模型：Azure 资源选型的起点

在 Day 30 中我们讨论了 Azure 的身份、权限与安全治理模型；今天的话题则转向“跑在哪里”。计算服务是任何云上工作负载的底座，Azure 提供了一条从“完全自管的虚拟机”到“只写代码的 Serverless 函数”的完整抽象光谱。理解这条光谱上的每一个层次，是后续在 Day 32 存储模型 与 Day 33 网络模型与管理工具 中把这些“积木”拼装成真实场景的前提。

服务可用性选项：高可用、灾备与备份

在数据中心时代，保证服务可用性就是运维的生命线；在云上这一诉求同样关键。Azure 将可用性拆解为三个层次：

• 高可用（High Availability）：在同一个区域内提供保护，对抗单机或单数据中心故障；
• 灾难恢复（Disaster Recovery）：在区域与区域之间提供保护，对抗整个区域级别的故障；
• 备份（Backup）：提供某个时间点（point-in-time）的恢复能力。

为了实现上述目标，Microsoft 在一个地理政治边界（geopolitical boundary）内会部署多个区域（region）。围绕服务可用性，Azure 引入了两个关键概念——集合与区域：

• 可用性集（Availability Sets）：在单个数据中心内部提供弹性（resiliency）。将多个 VM 放入同一可用性集，Azure 会确保它们分布在不同的容错域与更新域上，避免硬件维护或故障时全部实例同时不可用；
• 可用性区域（Availability Zones）：在区域内多个数据中心之间提供弹性。将实例分布到不同 Zone，可抵御单数据中心级别的故障。

一句话区分：可用性集管的是“机房内的分散”，可用性区域管的是“机房之间的分散”。两者也可以结合使用，以实现更高等级的可用性。选择哪一级冗余，本质上是在可用性、成本与复杂度之间做权衡。

虚拟机（Virtual Machines）：公有云的第一站

虚拟机通常是大多数人进入公有云的第一站，Azure 对 VM 的支持非常丰富：

• 丰富的系列与规格：Azure 提供多种系列的 VM，各有不同的计算能力侧重，例如面向高性能、低延迟场景的系列，以及面向大内存场景的系列，型号之多有时会让人眼花缭乱；
• B 系列可突发（burstable）VM：这是专为“大部分时间 CPU 需求很低，但偶尔（例如每月一次）需要性能尖峰”的工作负载设计的型号，非常适合低成本运行后台任务、开发测试环境等场景；
• 虚拟网络接入：VM 会放置在一个虚拟网络（Virtual Network）上，从而获得与任意网络的连通能力；
• 双操作系统支持：同时支持 Windows 与 Linux 来宾操作系统；
• Azure 调优内核（Azure-tuned kernels）：针对特定 Linux 发行版，Azure 还提供经过专门调优的内核版本，以获得更好的平台兼容性与性能。

模板化部署：Azure 背后的 JSON 与声明式 IaC

贯穿整个 Azure 的一个基本事实是：Azure 表面之下的每一种资源本质上都是 JSON。无论是 Azure 门户（Portal）、CLI 还是 PowerShell，最终都会转化为对资源定义 JSON 的操作。

创建资源有若干种入口——门户、控制台等，但首选路径是基于 JSON 模板的部署，因为它是可重复、可审计的声明式方式。核心特性包括：

• 幂等部署（Idempotent deployments）：支持 **incremental（增量）**与 **complete（完整）**两种模式，即“重复执行同样模板，最终状态一致”，这正是基础设施即代码（IaC）所追求的 desired state（期望状态）；
• 可导出的模板库：Azure 提供了大量可导出的模板，能把已部署资源的定义导出来复用。

这种模板化思路，与 AWS CloudFormation 非常类似；而如果你需要多云（multi-cloud）方案，则可以使用Terraform。在本仓库中，Terraform 的手把手内容属于后续“基础设施即代码（IaC）”章节，仓库里已经留下了可运行的示例：最简的 Hello-world 模块 只需一个output块即可输出"Hello, 90DaysOfDevOps from Terraform"，完整展示了“用代码描述期望状态、由工具负责幂等落地”的 IaC 心智模型。

弹性伸缩：VMSS 与自动缩放

自动缩放是公有云最大的卖点之一：用不到的资源自动缩减，需要时自动拉起，让成本与实际负载对齐。

在 IaaS 层面，Azure 提供虚拟机规模集（Virtual Machine Scale Sets，VMSS）。它能够基于调度计划（schedules）和指标（metrics），从一个黄金镜像（gold standard image）自动创建并扩展实例。典型价值场景是更新窗口：先更新黄金镜像，再以最小影响的方式滚动发布到现有实例，避免大面积停机。

在 PaaS 层面，Azure 应用服务（App Services）自带自动缩放能力，无需像 IaaS 那样自己管理伸缩逻辑。选型要点是：需要细粒度控制底层 OS 与镜像，选 VMSS；只想让平台替你处理伸缩，选 App Service。

容器服务：AKS、ACI、Service Fabric 与容器注册表

容器在 DevOps 学习路线中占有核心地位（后续章节会专门展开“容器”这个用例），这里先梳理 Azure 上几个容器专项服务：

• Azure Kubernetes Service（AKS）：托管的 Kubernetes 解决方案，控制平面与底层集群管理都不需要你操心，开箱即用；
• Azure Container Instances（ACI）：容器即服务（Containers as a Service），按秒计费。直接运行一个镜像并接入你的虚拟网络即可，无需引入容器编排器；
• Service Fabric：能力非常广泛，其中包含对容器实例的编排能力；
• Azure Container Registry（ACR）：提供私有镜像仓库，支持 Docker 镜像、Helm Chart、OCI 制品与镜像的托管。

值得注意的是：许多容器服务内部很可能也在大量使用容器，只是这些细节被抽象掉了，你无需直接管理。上述容器服务，在其他主流公有云中也能找到对等物——这一模式具有普遍性。

仓库也为容器旅程备好了实操素材：IaC 层面有通过 Terraform 拉起 nginx 镜像与容器的 docker.tf，以及用 Kubernetes provider 创建命名空间、Deployment 与 NodePort Service 的 kubernetes.tf；原生 Kubernetes 清单则可参考 nginx-stateless-demo.yaml。

应用服务（Application Services）：面向应用的托管方案

Azure 应用服务（App Services）是一个应用托管解决方案，提供建立服务的简便途径，核心能力如下：

• 自动部署与自动伸缩：应用发布与扩容流程高度自动化；
• Windows 与 Linux 双支持：两种平台的应用均可托管；
• 运行于应用服务计划（App Service Plan）：计划本身有**类型（type）与大小（size）**之分，决定了底层资源规模与定价；
• 多种应用形态：覆盖 Web App、API App、移动 App 等多种服务类型；
• 部署槽位（Deployment slots）：支持通过槽位进行可靠的测试与发布升级（promotion），让“先验证、再切换”成为标准动作。

对于“不想管服务器，但希望保留对运行环境的较大掌控权”的工作负载，App Service 是 IaaS（虚拟机）与 Serverless 之间的理想中间层。

Serverless 计算：只为运行时长付费

Serverless 的核心理念是：只为函数的实际运行时长付费——不再需要常驻的虚拟机或 PaaS 应用，需要时运行函数，运行完它就“消失”。Azure 在这一领域的主要组件包括：

• Azure Functions（函数即服务）：提供 Serverless 代码执行。回顾 Day 30 关于云抽象层的讨论——在 Serverless 模式下，你只管理代码本身。特性包括：
  • 事件驱动（Event-Driven），具备大规模并发能力；
  • 支持输入/输出绑定（bindings），可无缝对接众多 Azure 服务与第三方服务；
  • 多语言支持：C#、NodeJS、Python、PHP、Batch、Bash、Golang、Rust，乃至任何可执行文件；
• Azure Event Grid：负责把服务与事件触发的逻辑串联起来，实现事件路由；
• Azure Logic Apps：提供基于图形化界面的工作流与集成编排；
• Azure Batch：可在 Windows 与 Linux 节点上运行大规模批处理作业，并提供一致的管理与调度能力。

选型建议：纯事件驱动的单段逻辑用 Azure Functions；需要可视化编排多个系统间的集成流程用 Logic Apps；大批量、可并行的计算任务用 Azure Batch。

与后续章节的衔接

本篇完成了 Azure 计算模型的“理论拼图”，接下来的两天将补齐另外两块积木：Day 32 的 Azure 存储模型（存储账户、托管磁盘、冗余选项与数据库模型）与Day 33 的 Azure 网络模型与管理工具（虚拟网络、NSG/ASG、负载均衡，以及 Azure CLI、PowerShell、Cloud Shell 等自动化入口）。理论积累完成后，第 34 天起将进入场景化动手部署，届时计算、存储、网络三大模型将真正拼装成可运行的应用——而无论是门户点击、PowerShell 命令还是 JSON 模板，最终都归结为一件事：在声明式代码中描述并落地你的 Azure 期望状态。

继续学习下一站：Day 32 - Microsoft Azure 存储模型。

• 文档/教程