1. 企业云架构总览与Azure生产环境建设目标

企业上云并不是把虚拟机从机房搬到公有云那么简单。真正意义上的“企业云架构”，是在 Azure 的全局基础设施之上，重新组织计算、网络、存储、身份与治理能力，使业务系统在可用性、扩展性、安全合规和成本之间取得可度量的平衡。本章作为课程起点，先建立一张全局地图：Azure 的物理与逻辑基础设施长什么样，生产环境必须满足哪些非功能需求，以及本课程将围绕怎样的项目背景和交付物展开。

一、企业上云的核心驱动力

企业选择 Azure 通常由四类驱动力共同推动。第一是业务敏捷：新业务上线周期从数月缩短到数周，需要弹性资源与自动化交付能力。第二是成本结构优化：把一次性资本支出转为按用量计费的运营支出，并通过预留实例、混合权益降低长期成本。第三是安全与合规：Azure 提供全球范围的合规认证、区域数据驻留和细粒度访问控制，帮助企业满足等保、GDPR、行业监管等要求。第四是韧性与全球化：借助多区域部署和边缘节点，业务可以就近服务用户并在故障时快速切换。

这四类驱动力并非彼此独立。例如为了敏捷而采用容器与微服务，会同时改变可用性设计和成本模型；为了合规而选择特定区域，又会影响延迟与容灾拓扑。因此架构决策必须放在一起权衡，而不是逐项优化。

二、Azure 全局基础设施：区域、可用区与边缘节点

Azure 的物理基础设施可以按“区域—可用区—边缘节点”三个层次理解。区域（Region）是部署和计费的基本地理单元，例如“中国东部”“东亚”“西欧”。每个区域内有一组数据中心，区域之间通过 Azure 骨干网互联。可用区（Availability Zone）是同一区域内物理隔离的数据中心组，具备独立的供电、冷却和网络，用于构建高可用架构；并非所有区域都支持可用区，选型时必须先确认。边缘节点则通过 Azure Front Door、CDN 等把内容和服务推到离用户更近的位置，降低访问延迟。

下图展示了这三层关系，以及生产环境在区域内部署时的典型落点：可用区承载跨区冗余的工作负载，区域对之间构成灾备关系，边缘节点面向终端用户。

三、生产环境的关键非功能需求

生产环境与开发测试环境最大的区别，在于它必须对“非功能需求”负责。课程将围绕五个维度展开，它们共同决定架构是否可上线、可运营。

• 高可用（HA）：目标通常用 SLA 表达。例如单虚拟机 SLA 约 99.9%，跨可用区部署可提升到 99.99%。设计时要消除单点，明确故障域与恢复时间目标（RTO）、恢复点目标（RPO）。
• 可扩展（Scalability）：区分纵向扩展（升配）与横向扩展（加实例）。生产系统应优先支持横向扩展，并配合自动缩放规则应对流量波峰。
• 安全（Security）：遵循零信任思路，落实身份认证、最小权限、网络分段、加密与密钥管理、日志审计。安全不是上线前的一次检查，而是贯穿设计、部署、运营的持续过程。
• 合规（Compliance）：根据行业与地域要求选择区域、数据驻留策略和合规认证范围，并通过 Azure Policy、蓝图等把合规要求固化为可审计的配置约束。
• 成本（Cost）：用标签、预算、成本分析建立可见性，结合预留、混合权益和合理规格控制支出。成本优化不能以牺牲可用性和安全为代价。

这五个维度经常互相拉扯。例如为了高可用做跨区域双活，成本会显著上升；为了安全收紧网络策略，可能增加运维复杂度。架构师的价值就在于明确业务优先级，做出可解释的取舍，而不是追求每一项都“最优”。

四、课程项目背景与交付物

本课程以一个虚构但贴近真实的企业场景贯穿始终：某零售企业计划把核心订单与会员系统迁移到 Azure，要求支持大促期间的流量峰值，满足数据合规要求，并控制年度云支出。围绕这一背景，课程将逐步交付以下成果：

需要强调的是，本课程中的参数、配置和结果示例均为教学用途的合理假设，用于说明方法与判断依据，并不代表任何真实环境的实测数据。实际项目中应以业务需求、Azure 官方文档和真实测试结果为准。掌握这套从全局基础设施到生产非功能需求的思考框架，是后续每一章动手实践的基础。