📚 课程目录第1章混合云与Azure集成全景

1. 混合云与Azure集成全景

混合云并不是“把一部分服务器搬到云上”这么简单。它指的是本地数据中心与公有云之间形成持续、可管理、可编排的协同关系：身份统一、网络互通、数据可流动、运维可一致、安全策略可贯通。Azure 在这个语境下的定位，是作为公有云侧的统一控制面与资源池，通过 Azure Arc、Azure Stack、ExpressRoute、VPN Gateway、Entra ID、Azure Monitor 等产品，把本地资源“纳入”Azure 的管理与治理体系，而不是要求业务全部重写或全部搬迁。

理解混合云，先要区分三个层次。第一层是连接层：本地与 Azure 之间必须有稳定、低时延、可加密的网络通道，常见选择是站点到站点 VPN（适合中小规模、快速开通）与 ExpressRoute 专线（适合高带宽、低时延、合规要求高的场景）。第二层是身份与治理层：本地 Active Directory 与 Entra ID 通过 Entra Connect 同步，使同一账号既能登录本地应用，也能访问 Azure 资源；Azure Policy、RBAC、Defender for Cloud 则把合规与安全基线延伸到本地服务器。第三层是资源管理层：Azure Arc 把本地或其它云的服务器、Kubernetes 集群、SQL Server 注册为 Azure 资源，从而用 Azure 门户、CLI、ARM/Bicep 统一管理。

Azure 混合云产品栈可以按“控制面—连接面—数据面—运维面”来梳理。控制面以 Azure Arc 和 Azure Stack HCI/Azure Stack Hub 为核心，前者管理存量资源，后者在本地提供与 Azure 一致的 IaaS/PaaS 体验；连接面包括 ExpressRoute、VPN Gateway、Azure Virtual WAN；数据面包括 Azure File Sync、Azure Backup、Azure Site Recovery、Data Box 系列；运维面包括 Azure Monitor、Log Analytics、Update Manager、Automation。它们不是彼此替代，而是按场景组合使用。

业务迁移的驱动力通常来自五类现实压力：一是成本，本地机房折旧、电力、运维人力在业务低峰期无法弹性收缩；二是弹性，促销、报表、训练等峰值负载需要临时扩容；三是灾备与合规，本地单点故障难以满足 RTO/RPO 要求，而 Azure Site Recovery 可按需复制；四是应用现代化，把老旧 .NET 应用迁移到 Azure App Service 或 AKS，获得持续交付能力；五是边缘与数据，工厂、门店等场景需要本地低时延处理，同时把汇总数据送入 Azure 做分析。

典型场景可以归纳为四类。第一类是混合身份与办公：本地 AD 与 Entra ID 同步，员工用同一账号访问本地文件服务器和 Microsoft 365。第二类是混合网络与应用分层：Web 前端放在 Azure，数据库仍留在本地，通过 ExpressRoute 私网互通，避免公网暴露。第三类是备份与灾备：本地 SQL Server 通过 Azure Backup 备份，关键 VM 通过 Site Recovery 复制到 Azure，主站点故障时在 Azure 拉起。第四类是边缘计算：Azure Stack HCI 或 Arc 管理的边缘节点在本地运行容器，把推理结果和遥测数据回传 Azure IoT Hub 与 Data Explorer。

以一个可参考的教学示例说明集成过程。假设某企业本地有一台 Windows Server 2022 文件服务器，希望纳入 Azure 统一管理并实现云端备份。第一步，在 Azure 门户创建 Log Analytics 工作区与 Recovery Services 保管库，记录工作区 ID 与密钥。第二步，在本地服务器上安装 Azure Arc 代理，执行连接脚本：

# 示例：将本地服务器注册为 Azure Arc 资源
az connectedmachine connect \
  --resource-group rg-hybrid-demo \
  --name srv-file01 \
  --location eastasia \
  --tags env=prod role=file

注册成功后，在 Azure 门户的“Azure Arc → 服务器”中可以看到该机器状态为“已连接”，并自动获得 Azure Monitor 代理扩展。第三步，安装 Microsoft Azure Recovery Services (MARS) 代理，把文件服务器上的共享目录加入备份计划，例如每天 22:00 增量备份、每周日 01:00 完整备份、保留 30 天。第四步，在 Azure Monitor 中查看该服务器的 CPU、磁盘、心跳日志，确认数据已上报。判断集成是否成功的依据是：Arc 资源状态为“已连接”、备份作业在保管库中显示“成功”、Log Analytics 中能查询到 Heartbeat 表记录。若 Arc 状态为“已断开”，优先检查 443 出站、代理与时间同步；若备份失败，检查 MARS 代理的缓存盘空间与保管库凭据是否过期。

混合云集成的顺序建议是：先身份、再网络、后资源纳管，最后才是数据与灾备。身份和网络是地基，跳过它们直接做 Arc 纳管，往往会在证书、DNS、出站代理上反复受阻。

需要强调的是，混合云不是“永久共存”的借口，而是迁移过程中的过渡形态与长期架构选择。对可以标准化的无状态应用，应优先考虑迁入 Azure PaaS；对受数据主权、低时延或硬件依赖约束的系统，保留在本地并用 Azure 统一治理。判断某工作负载去留时，可以看四个维度：数据敏感度与合规要求、依赖的硬件或协议、峰值弹性需求、以及团队运维能力。四个维度中合规与硬件依赖是硬约束，弹性和运维能力是软约束，硬约束决定“能不能迁”，软约束决定“值不值得迁”。