📚 课程目录第1章课程导入与云化混合部署全景

1. 课程导入与云化混合部署全景

SQL Server 诞生于 Windows 数据中心时代，而今天的企业数据版图已经横跨本地机房、私有云、公有云和边缘节点。所谓SQL Server 云化，是指把 SQL Server 的部署形态、运维方式、可用性架构和成本模型，从"以物理机/虚拟机为中心"迁移到"以云平台能力为中心"；而混合部署则承认一个现实：并非所有数据库都能一次性上云，本地实例与云上实例需要长期共存、互联、互备、互为延伸。本课程要解决的，正是这种"既上云、又留本地"的工程问题。

理解这门课，先要理解它要回答的四类问题：放在哪里（IaaS 自建、Azure SQL 托管实例、Azure SQL 数据库、容器化）、怎么连（网络、身份、加密、链路）、怎么保（备份、高可用、灾难恢复、异地副本）、怎么省与怎么管（许可、弹性伸缩、监控、自动化）。这四类问题贯穿全部 30 章，也是判断一个方案是否"工程上成立"的基本标尺。

云化的三种落地形态与核心价值

SQL Server 上云并不是单一动作，而是三种形态的连续谱。第一种是 IaaS 形态：在 Azure VM 或其它云主机上安装 SQL Server，操作系统、补丁、存储布局、Always On 全部自管，控制力最强，迁移改动最小，适合依赖特定版本、特定扩展或特殊文件系统布局的系统。第二种是 PaaS 托管形态：Azure SQL 数据库、Azure SQL 托管实例、Azure SQL Edge，由平台负责底层补丁与部分高可用，用户聚焦 schema、查询与连接；其中托管实例接近"几乎完整的 SQL Server 实例体验"，而 Azure SQL 数据库更偏向单库/弹性池的云原生模型。第三种是 容器化形态：以 Linux 容器运行 SQL Server，用于 CI/CD、开发测试、边缘轻量部署，配合 Kubernetes 可实现声明式编排。

三种形态的价值侧重不同：IaaS 换来兼容性与控制力，PaaS 换来运维减负与弹性，容器换来交付一致性与快速复制。工程上常见的误区是"一步到位全上 PaaS"，结果被跨库查询、SQL Agent、CLR、链接服务器等特性卡住。因此本课程强调先评估、再选型、后迁移。

混合部署的典型业务场景

混合部署不是过渡期的临时妥协，而是很多企业的长期稳态。典型场景包括：本地主库 + 云上只读副本，用 Always On 可用性组把云节点作为可读次要副本，分担报表压力；本地保留敏感数据、云端承载分析与弹性负载，通过日志传送或事务复制把非敏感数据同步上云；云上主库 + 本地灾备，利用分布式可用性组实现跨站点故障转移；多云/多区域读写分离，借助 Azure SQL 的异地副本或故障转移组实现区域级容灾。这些场景的共同点是：数据要流动、身份要统一、故障切换要可预期。

判断一个混合方案是否合理，可以问三个问题：数据流向是否单向可控？故障切换时应用连接串如何变化？跨站点链路的延迟与带宽是否被实测过？

技术栈总览

本课程涉及的技术栈可以按"承载—连接—数据—运维"四层来理解。承载层包括 Azure VM、Azure SQL 托管实例、Azure SQL 数据库、Azure Kubernetes Service 与 SQL Server on Linux 容器；连接层包括 Azure 虚拟网络、专用终结点、ExpressRoute/VPN、Microsoft Entra ID 身份与 TLS 加密；数据层包括 Always On 可用性组、分布式可用性组、故障转移组、日志传送、事务复制、备份到 URL；运维层包括 Azure Monitor、SQL Insights、自动化脚本、Azure Policy 与成本管理。四层之间不是并列关系，而是下层为上层提供能力、上层对下层提出约束。

学习路径规划

本课程按"认知—选型—迁移—运维—优化"推进。前几章建立全景与评估方法，包括版本特性差异、许可与成本模型、网络与身份前置条件；随后进入迁移实施，覆盖备份还原、日志传送、Always On、分布式可用性组、Azure Migrate 与 Data Migration Assistant 的使用；再进入云上运维，包括监控告警、自动化伸缩、备份策略、安全加固与合规；最后是混合场景的故障排查与性能调优。建议的学习节奏是：每章先明确"要解决什么问题"，再动手在实验环境复现关键配置，最后用检查表验证结果。

需要特别提醒的是，云化不是把数据库"搬上去"就结束。真正的工程价值体现在：迁移后连接串与身份体系是否平滑、故障切换是否在可接受时间内完成、备份与恢复是否满足 RPO/RTO、成本是否随负载弹性变化。这些指标应当在项目开始前就定义清楚，而不是上线后再补。

混合部署中，跨站点链路是最大的不确定因素。同步提交副本对网络延迟敏感，通常要求往返延迟低于 1–2 ms；若跨区域延迟达到 20 ms 以上，应优先考虑异步提交，并接受一定的数据丢失窗口。这一判断必须在架构设计阶段完成，而不是等到切换失败时才发现。

接下来的章节会逐步展开这些内容。你现在需要建立的认知是：SQL Server 云化与混合部署是一套可评估、可选型、可迁移、可运维的工程方法，而不是某个产品的功能清单。带着"数据怎么流、身份怎么认、故障怎么切、成本怎么算"这四个问题进入后续学习，会更容易把零散知识点串成可落地的方案。