什么是区域？
区域是指地球上的某个地理区域，包含至少一个（但很可能是多个）数据中心，这些数据中心彼此相邻并通过一个低延迟的网络相互连接。 Azure 智能地分配和控制每个区域内的资源，以确保适当平衡工作负载。
在 Azure 中部署资源时，通常需要选择要部署资源的区域。 重要 某些服务或虚拟机功能（例如特定的虚拟机大小或存储类型）仅在特定区域可用。 也有一些全球性 Azure 服务不需要用户选择特定的区域，例如 Microsoft Azure Active Directory、Microsoft Azure 流量管理器和 Azure DNS。
下面是一些示例区域：美国西部、加拿大中部、西欧、澳大利亚东部和日本西部。 以下是截至 2020 年 2 月所有可用区域的视图：
特殊 Azure 区域
在生成应用程序时，出于合规性或法律方面的考虑，可能需要使用特殊的 Azure 区域。 其中包括：
US DoD 中部、US Gov 弗吉尼亚州、US Gov 爱荷华州等更多区域：这些区域是适用于美国政府机构和合作伙伴的 Azure 物理和逻辑网络隔离实例。 这些数据中心由甄选出来的美国公民运作，并包括其他合规性认证。
中国东部、中国北部及更多区域：这些区域在 Microsoft 和 21Vianet 达成唯一合作关系之后可供用户使用，通过这种合作关系，Microsoft 就无需直接维护相关数据中心。
区域用于确定资源位置，但还应注意另外两个术语：“地域”和“可用性区域”。
么是可用性区域？
可用性区域是 Azure 区域中的物理上独立的数据中心。
每个可用性区域都由一个或多个数据中心组成，这些数据中心都配置了独立的电源、冷却和网络设备。 可用性区域被设置为_隔离边界_。 如果一个区域出现故障，其他区域会继续正常工作。 可用性区域通过高速专用光纤网络相连。
支持的区域
并非每个区域都支持可用性区域。 为确保能够进行复原，以下区域必须至少有三个单独的区域。
- 美国中部
- 美国东部 2
- 美国西部 2
- 西欧
- 法国中部
- 北欧
- 东南亚
什么是区域对？
在同一地域（例如美国、欧洲或亚洲）内，每个 Azure 区域始终与至少距其 300 英里外的另一区域配对。 此方法适用于跨地域复制资源（例如虚拟机存储），有助于减少因自然灾害、社会动乱、电力中断或物理网络中断等事件（同时影响两个区域）造成服务中断的可能性。 例如，如果一个区域对中的某个区域受到自然灾害，则服务会自动故障转移到其区域对中的其他区域。
Azure 中区域对的例子有美国西部与美国东部、东南亚与东亚。
由于区域对是直接相连的，并且距离足够远，能够与区域性灾难相隔离，因此可以使用它们来提供可靠的服务和数据冗余。 某些服务使用区域对提供自动异地冗余存储。
区域对的其他优点包括：
- 如果发生大规模 Azure 服务中断，则优先考虑每个区域对中的一个区域，确保针对该区域对中托管的应用程序尽快恢复至少一个区域。
- 对配对区域逐一进行计划内 Azure 更新，以尽量减少停机时间并降低应用程序中断风险。
- 出于税务和执法管辖权方面的考虑，数据仍以配对的形式驻留在同一地域内（巴西南部除外）。
拥有一组广泛分布的数据中心使 Azure 能够提供高可用性保证。 我们来探讨一下这意味着什么。
了解 Azure 的服务级别协议
Microsoft 通过遵守全面的运营策略、标准和做法，坚持不懈地致力于为客户提供高质量的产品和服务。 名为服务级别协议 (SLA) 的正式文档涵盖了许多特定术语，这些术语定义了适用于 Azure 的性能标准。
- SLA 描述 Microsoft 为 Azure 客户提供特定性能标准的承诺。
- 各个 Azure 产品和服务都有相对应的 SLA。
- SLA 还规定当服务或产品无法履行适用 SLA 的规范时会发生什么情况。
Azure 产品和服务的 SLA
Azure 产品和服务的 SLA 有三个主要特征：
- 性能目标
- 运行时间和连接性保证
- 服务信用额度
性能目标
SLA 定义了 Azure 产品或服务的性能目标。 SLA 定义的性能目标特定于每个 Azure 产品和服务。 例如，某些 Azure 服务的性能目标以运行时间保证或连接速率表示。
运行时间和连接性保证
典型 SLA 为每个相应的 Azure 产品或服务规定了从 99.9%（“三个九”）到 99.999%（“五个九”）的性能目标承诺。 这些目标可以应用于诸如服务运行时间或响应时间之类的性能标准。
下表列出了各个 SLA 级别在不同持续时间内的潜在累积停机时间：
| SLA % | 每周停机时间 | 每月故障时间 | 每年停机时间 |
|---|---|---|---|
| 99 | 1.68 小时 | 7.2 小时 | 3.65 天 |
| 99.9 | 10.1 分钟 | 43.2 分钟 | 8.76 小时 |
| 99.95 | 5 分钟 | 21.6 分钟 | 4.38 小时 |
| 99.99 | 1.01 分钟 | 4.32 分钟 | 52.56 分钟 |
| 99.999 | 6 秒 | 25.9 秒 | 5.26 分钟 |
例如，Azure Cosmos DB（数据库）服务的 SLA 提供 99.999% 的运行时间，其中包括针对 DB 读取操作少于 10 毫秒的低延迟承诺，以及针对 DB 写入操作少于 10 毫秒的低延迟承诺。
服务信用额度
SLA 还描述了当 Azure 产品或服务无法履行其适用 SLA 的规范时，Microsoft 将如何响应。
例如，客户可能会对其 Azure 帐单应用折扣，作为对 Azure 产品或服务表现不佳的补偿。 下表更详细地解释了此示例。
下表中的第一列显示单实例 Azure 虚拟机的每月运行时间百分比 SLA 目标。 第二列显示当实际运行时间少于该月的指定 SLA 目标时所收到的相应服务信用额。
| 每月运行时间百分比 | 服务信用额度百分比 |
|---|---|
| < 99.9 | 10 |
| < 99 | 25 |
| < 95 | 100 |
Azure 产品和服务的 SLA
Azure 产品和服务的 SLA 有三个主要特征：
- 性能目标
- 运行时间和连接性保证
- 服务信用额度
性能目标
SLA 定义了 Azure 产品或服务的性能目标。 SLA 定义的性能目标特定于每个 Azure 产品和服务。 例如，某些 Azure 服务的性能目标以运行时间保证或连接速率表示。
运行时间和连接性保证
典型 SLA 为每个相应的 Azure 产品或服务规定了从 99.9%（“三个九”）到 99.999%（“五个九”）的性能目标承诺。 这些目标可以应用于诸如服务运行时间或响应时间之类的性能标准。
下表列出了各个 SLA 级别在不同持续时间内的潜在累积停机时间：
| SLA % | 每周停机时间 | 每月故障时间 | 每年停机时间 |
|---|---|---|---|
| 99 | 1.68 小时 | 7.2 小时 | 3.65 天 |
| 99.9 | 10.1 分钟 | 43.2 分钟 | 8.76 小时 |
| 99.95 | 5 分钟 | 21.6 分钟 | 4.38 小时 |
| 99.99 | 1.01 分钟 | 4.32 分钟 | 52.56 分钟 |
| 99.999 | 6 秒 | 25.9 秒 | 5.26 分钟 |
例如，Azure Cosmos DB（数据库）服务的 SLA 提供 99.999% 的运行时间，其中包括针对 DB 读取操作少于 10 毫秒的低延迟承诺，以及针对 DB 写入操作少于 10 毫秒的低延迟承诺。
服务信用额度
SLA 还描述了当 Azure 产品或服务无法履行其适用 SLA 的规范时，Microsoft 将如何响应。
例如，客户可能会对其 Azure 帐单应用折扣，作为对 Azure 产品或服务表现不佳的补偿。 下表更详细地解释了此示例。
下表中的第一列显示单实例 Azure 虚拟机的每月运行时间百分比 SLA 目标。 第二列显示当实际运行时间少于该月的指定 SLA 目标时所收到的相应服务信用额。
| 每月运行时间百分比 | 服务信用额度百分比 |
|---|---|
| < 99.9 | 10 |
| < 99 | 25 |
| < 95 | 100 |
跨服务组合 SLA
在跨不同服务产品组合 SLA 时，生成的 SLA 称为“复合 SLA”。 生成的复合 SLA 会根据应用程序体系结构来提供更高或更低的运行时间值。
计算停机时间
假设某个应用服务 Web 应用将数据写入 Azure SQL 数据库。 这些 Azure 服务目前具有以下 SLA：
在此示例中，如果任一服务发生故障，则整个应用程序也会发生故障。 通常，每个服务的个体概率值是独立的。 但是，此应用程序的复合 SLA 值为：
99.95 percent × 99.99 percent = 99.94 percent
备注
对于 SLA 和故障时间计算，请记住，无论何时看到带“百分号”(%) 标签或符号的数字时，该数字都除以 100。 如果在上面输入 SLA 计算，则实际值为 0.9995 * 0.9999 = 0.9994。
这意味着组合故障概率比单个 SLA 值高。 这并不奇怪，因为依赖于多个服务的应用程序具有更多的潜在故障点。
反之，你可以通过创建独立的回退路径来提高复合 SLA。 例如，如果 SQL 数据库不可用，可将事务放入队列供稍后处理。
如果采用这种设计，即使应用程序无法连接到数据库，它也能保持可用性。 但是，如果数据库_和_队列同时发生故障，则应用程序也会发生故障。
同时发生故障的预期时间百分比为 0.0001 × 0.001，因此，此组合路径（数据库_或_队列）的复合 SLA 为：
1.0 − (0.0001 × 0.001) = 99.99999 percent
因此，如果向 Web 应用添加队列，则总复合 SLA 为：
99.95 percent × 99.99999 percent = ~99.95 percent
请注意，我们已经改进了 SLA 行为。 但是，这种方法存在几个缺点：应用程序逻辑更复杂，需要支付更多费用来添加队列支持，并且由于重试行为，可能需要处理数据一致性问题。
Microsoft 分布于全球的区域超过 54 个，比其他任何云提供商都要多。 这样大规模的基础设施能够让你的应用程序更贴近世界各地的用户。 Azure 还具有专用的区域，可供政府使用以及支持需在中国部署的应用程序，因此，无论你有何种业务需求，都可以保证数据的安全性和驻留，并满足客户的合规性和复原要求。
Azure 管理选项
你可以使用各种工具和平台配置和管理 Azure。 有一些工具可用于命令行、特定于语言的软件开发工具包 (SDK)、开发人员工具、迁移工具以及许多其他工具。
通常用于日常管理和交互的工具包括：
- Azure 门户，用于通过图形用户界面 (GUI) 与 Azure 交互
- Azure PowerShell 和 Azure 命令行接口 (CLI)，用于与 Azure 进行基于命令行和自动化的交互
- Azure Cloud Shell，用于基于 Web 的命令行接口
- Azure 移动应用，用于监视和管理移动设备上的资源
Azure 门户
Azure 门户是一个公共网站，可以使用任何 Web 浏览器进行访问。 使用 Azure 帐户登录后，可以创建、管理和监视任何可用的 Azure 服务。 你可以识别正在寻找的服务，获取有关主题的帮助链接，以及部署、管理和删除资源。 它还使用向导和工具提示引导你完成复杂的管理任务。
仪表板视图提供有关 Azure 环境的高级详细信息。 你可以通过移动磁贴和调整磁贴大小来自定义仪表板，并显示你感兴趣的服务。
门户不提供任何自动执行重复性任务的方法。 例如，若要设置多个 VM，需完成每个 VM 的向导，逐个进行创建。 就复杂任务而言，通过门户实现该过程相当耗时且容易出错。
Azure PowerShell
Azure PowerShell 是一个可以为 Windows PowerShell 或 PowerShell Core 安装的模块。它是跨平台版本的 PowerShell，可以在 Windows、Linux 或 macOS 上运行。 Azure PowerShell 让你能够连接 Azure 订阅并管理资源。 Windows PowerShell 和 PowerShell Core 提供 shell 窗口和命令解析等服务。 然后，Azure PowerShell 添加特定于 Azure 的命令。
例如，Azure PowerShell 提供可在 Azure 订阅中创建虚拟机的 New-AzVM 命令。 要使用它，需启动 PowerShell，安装 Azure PowerShell 模块，使用命令 Connect-AzAccount 登录 Azure 帐户，然后发出如下命令：
New-AzVM `
-ResourceGroupName "MyResourceGroup" `
-Name "TestVm" `
-Image "UbuntuLTS" `
...
创建管理脚本和使用自动化工具是一种强大的工作流优化方法。 你可以自动执行重复性任务。 脚本经验证后可一致地运行，这样可以减少错误。 另一个脚本环境是 Azure CLI。
Azure CLI
Azure CLI 是一个跨平台的命令行程序，它连接到 Azure 并对 Azure 资源执行管理命令。 “跨平台”意味着它可以在 Windows、Linux 或 macOS 上运行。 例如，要创建 VM，需打开命令提示符窗口，使用 az login 命令登录 Azure，创建资源组，然后使用如下命令：
az vm create
--resource-group MyResourceGroup
--name TestVm
--image UbuntuLTS
--generate-ssh-keys
...
Azure Cloud Shell
Azure Cloud Shell 是一个可通过浏览器访问的，经过验证的，用于管理 Azure 资源的交互式 shell。 它允许灵活选择最适合自己工作方式的 shell 体验，可选择 Bash 或 PowerShell。
可以在两个 shell 之间切换，两者都支持 Azure CLI 和 Azure PowerShell 模块。 Bash 默认使用 Azure CLI（预先安装了 az 命令），但可以在 Linux 中键入 pwsh 来切换到 PowerShell Core。 PowerShell 环境预先安装了两个 CLI 工具。 除了这些管理工具之外，Cloud Shell 还提供一套开发人员工具、文本编辑器和其他可用工具，包括：
开发人员工具
- .NET Core
- Python
- Java
- Node.js
- Go
编辑器
- 代码（Cloud Shell 编辑器）
- vim
- nano
- emacs
其他工具
- git
- maven
- make
- npm
- 等等...
可以直接从这个基于浏览器的环境创建、生成和部署应用。 它也是持久性的 - 当你访问 Azure Cloud Shell 时，系统会提示创建 Azure 存储帐户。 此存储区域用作 $ HOME 文件夹，放置在此处的任何脚本或数据都会保留在会话中。 每个订阅都有与之关联的唯一存储帐户，因此你可以专门为所管理的每个帐户保留所需数据和工具。
在 Microsoft Learn 中，我们将使用 Cloud Shell 进行许多用于试用 Azure 功能的交互式练习。
Azure 移动应用
Microsoft Azure 移动应用支持从 iOS 或 Android 手机或平板电脑访问、管理和监视所有 Azure 帐户和资源。 安装完成后，可以：
- 检查服务的当前状态和重要指标
- 随时了解有关重要运行状况问题的通知和警报
- 随时随地快速诊断和修复问题
- 查看最新的 Azure 警报
- 启动、停止和重新启动虚拟机或 Web 应用
- 连接到你的虚拟机
- 使用基于角色的访问控制 (RBAC) 管理权限
- 使用 Azure Cloud Shell 运行已保存的脚本或执行临时管理任务
- 等等...
Azure 计算的基本概念
有四种用于在 Azure 中执行计算的常用技术：
- 虚拟机
- 容器
- Azure 应用服务
- 无服务器计算
什么是虚拟机？
虚拟机 (VM) 是物理计算机的软件模拟。 它们包括虚拟处理器、内存、存储和网络资源。 它们托管一个操作系统 (OS)，用户可以像使用物理计算机一样安装和运行软件。 使用远程桌面客户端可以像坐在终端前面一样使用和控制虚拟机。
什么是容器？
容器是用于运行应用程序的虚拟化环境。 与虚拟机一样，容器也在主机操作系统上运行。 但与 VM 不同，容器不包含在容器内部运行的应用的操作系统。 相反，容器将捆绑运行应用程序所需的库和组件，并使用运行该容器的现有主机操作系统。 例如，如果有五个容器在具有特定 Linux 内核的服务器上运行，则所有五个容器以及其中的应用都共享同一 Linux 内核。
什么是 Azure 应用服务？
Azure 应用服务是 Azure 中的平台即服务 (PaaS) 产品/服务，为托管面向 Web 的企业级应用程序而设计。 在使用完全托管的平台执行基础结构维护的同时，可以满足严苛的性能、可伸缩性、安全性和合规性要求。
什么是无服务器计算？
无服务器计算是一个云托管执行环境，可运行代码，但是将基础托管环境完全抽象化。 创建该服务的实例以及添加代码，无需甚至不允许配置或维护基础结构。