架构师的 Azure 指南第三版（一）

原文：annas-archive.org/md5/0b3cfce43ce7ffb62c4f01cafdc66996

译者：飞龙

协议：CC BY-NC-SA 4.0

序言

关于本书

本节简要介绍了作者、书籍的覆盖内容、开始时所需的技术技能以及使用 Azure 架构解决方案所需的硬件和软件要求。

关于《Azure for Architects》第三版

由于其对高可用性、可扩展性、安全性、性能和灾难恢复的支持，Azure 已广泛应用于轻松创建和部署各种类型的应用程序。更新了最新发展的《Azure for Architects》第三版帮助你掌握设计无服务器架构的核心概念，包括容器、Kubernetes 部署和大数据解决方案。你将学习如何架构诸如无服务器功能等解决方案，发现容器和 Kubernetes 的部署模式，并探索使用 Spark 和 Databricks 进行大规模大数据处理。随着深入，你将使用 Azure DevOps 实现 DevOps，利用 Azure Cognitive Services 工作智能解决方案，并将安全性、高可用性和可扩展性集成到每个解决方案中。最后，你将深入了解 Azure 安全概念，如 OAuth、OpenConnect 和托管身份。

到本书结束时，你将有信心基于容器和无服务器功能设计智能的 Azure 解决方案。

作者简介

Ritesh Modi 是微软前高级技术布道者。他因对微软产品、服务和社区的贡献被认定为微软区域总监。他是一位云架构师、出版作者、演讲者和领导者，因其在数据中心、Azure、Kubernetes、区块链、认知服务、DevOps、人工智能和自动化方面的贡献而广受欢迎。他是八本书的作者。

Ritesh 曾在众多国内外会议上发表演讲，并且是 MSDN 杂志的出版作者。他在为客户构建和部署企业解决方案方面有超过十年的经验，并且拥有超过 25 项技术认证。他的爱好包括写书、和女儿玩耍、看电影以及学习新技术。他目前居住在印度海得拉巴。你可以在 Twitter 上关注他，账号是 @automationnext。

Jack Lee 是一位高级 Azure 认证顾问和 Azure 实践负责人，对软件开发、云计算和 DevOps 创新充满热情。Jack 因其对技术社区的贡献而被评为微软 MVP。他曾在多个用户组和会议上发表演讲，包括微软加拿大的全球 Azure 启动营。Jack 是一位经验丰富的导师和黑客松评审员，同时也是一个专注于 Azure、DevOps 和软件开发的用户组的主席。他是《Cloud Analytics with Microsoft Azure》一书的合著者，出版方为 Packt Publishing。你可以在 Twitter 上关注 Jack，账号是 @jlee_consulting。

Rithin Skaria 是一名开源倡导者，拥有超过 7 年的在 Azure、AWS 和 OpenStack 上管理开源工作负载的经验。他目前在微软工作，并参与了微软内多项开源社区活动。他是微软认证培训师、Linux 基金会认证工程师和管理员、Kubernetes 应用开发者和管理员，以及认证 OpenStack 管理员。在 Azure 方面，他拥有四项认证（解决方案架构、Azure 管理、DevOps 和安全），同时他也获得了 Office 365 管理认证。他在多个开源部署中扮演了重要角色，并负责这些工作负载向云平台的管理和迁移。他还是Linux Administration on Azure一书的合著者，书籍由 Packt 出版。通过 LinkedIn 可以联系他，账号为**@rithin-skaria**。

审稿人简介

Melony Qin 是一位从事 STEM 领域的女性。目前，她在微软担任项目经理，并且是计算机协会（ACM）和项目管理协会（PMI）的成员。她曾在微软 Azure 平台上贡献于无服务器计算、大数据处理、DevOps、人工智能、机器学习和物联网（IoT）等领域。她拥有所有 Azure 认证（包括应用与基础设施轨道和数据与 AI 轨道），以及认证 Kubernetes 管理员（CKA）和认证 Kubernetes 应用开发者（CKAD）证书，目前主要专注于在社区中为开源软件（OSS）、DevOps、Kubernetes、无服务器、大数据分析和物联网等领域做出贡献。她是两本书的作者和合著者，分别是Microsoft Azure Infrastructure和The Kubernetes Workshop，这两本书均由 Packt 出版。她可以通过 Twitter 与人联系，账号为**@MelonyQ**。

Sanjeev Kumar 是微软 Azure 上 SAP 云解决方案架构师。他目前居住在瑞士苏黎世，拥有超过 19 年的 SAP 技术经验。在过去的 8 年里，他一直在公共云技术领域工作，其中最近 2 年专注于微软 Azure。

在担任 SAP on Azure 云架构顾问的角色时，Sanjeev Kumar 与许多世界顶级的金融服务和制造公司合作。他的关注领域包括云架构和设计，帮助客户将 SAP 系统迁移到 Azure，并采用 Azure 最佳实践进行 SAP 部署，特别是在实施基础设施即代码（Infrastructure as Code）和 DevOps 方面。他还在使用 Docker 和 Azure Kubernetes Service 进行容器化和微服务、使用 Apache Kafka 进行流数据处理以及使用 Node.js 进行全栈应用开发等方面有丰富经验。他参与了涉及 IaaS、PaaS 和 SaaS 的各种产品开发工作。他还对人工智能、机器学习以及大规模数据处理和分析等新兴领域感兴趣。他在 LinkedIn 上撰写有关 SAP on Azure、DevOps 和基础设施即代码的文章，你可以在**@sanjeevkumarprofile**找到他。

学习目标

在本书结束时，你将能够：

• 了解 Azure 云平台的组件

• 使用云设计模式

• 使用企业安全指南进行 Azure 部署

• 设计并实现无服务器和集成解决方案

• 在 Azure 上构建高效的数据解决方案

• 了解 Azure 上的容器服务

目标读者

如果你是云架构师、DevOps 工程师或开发人员，想要了解 Azure 云平台的关键架构方面，本书适合你。对 Azure 云平台的基本理解将帮助你更有效地掌握本书中的概念。

方法

本书通过逐步讲解关键概念、实际示例和自我评估问题，涵盖了每个主题。通过理论和实际操作经验的平衡，本书将帮助你理解架构师在现实世界中的工作方式。

硬件要求

为了获得最佳体验，我们建议以下配置：

• 最少 4GB RAM

• 最少 32GB 的空闲内存

软件要求

• Visual Studio 2019

• Docker for Windows 最新版本

• AZ PowerShell 模块 1.7 及以上版本

• Azure CLI 最新版本

• Azure 订阅

• Windows Server 2016/2019

• Windows 10 最新版本 - 64 位

约定

文本中的代码字、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟 URL 和用户输入如下所示：

DSC 配置仍未被 Azure Automation 识别。它在某些本地机器上可用，应该上传到 Azure Automation DSC 配置中。Azure Automation 提供了Import-AzureRMAutomationDscConfiguration cmdlet 用于将配置导入到 Azure Automation：

Import-AzureRmAutomationDscConfiguration -SourcePath "C:\DSC\AA\DSCfiles\ConfigureSiteOnIIS.ps1" -ResourceGroupName "omsauto" -AutomationAccountName "datacenterautomation" -Published -Verbose

下载资源

本书的代码包也托管在 GitHub 上，地址为：github.com/PacktPublishing/Azure-for-Architects-Third-Edition。

我们还有其他代码包，来自我们丰富的书籍和视频目录，您可以在github.com/PacktPublishing找到。快去看看吧！

第一章：1. 开始使用 Azure

每隔几年，就会出现一种技术创新，它会永久性地改变整个周围的格局和生态系统。如果我们追溯历史，1970 年代和 1980 年代是大型主机的时代。这些大型主机体积庞大，通常占据整间房间，几乎承担了所有计算工作。由于技术难以采购且使用繁琐，许多企业曾经需要提前一个月下订单，才能确保安装好可用的大型主机。

然后，1990 年代初期见证了个人计算和互联网需求的激增。因此，计算机变得更小，且相对容易为大众采购。个人计算和互联网领域的不断创新最终改变了整个计算机行业。许多人拥有能够运行多个程序并连接互联网的台式计算机。互联网的崛起也推动了客户端-服务器部署模式的兴起。现在可以有集中式服务器托管应用程序，任何有互联网连接的人都可以访问这些服务，世界任何地方的人都可以实现这一点。这也是服务器技术获得重要地位的时期；Windows NT 就是在这个时期发布的，随后是 Windows 2000 和 Windows 2003，它们分别出现在世纪之交。

2000 年代最显著的创新是便携设备的崛起和普及，尤其是智能手机，随之而来的是大量的应用程序。应用程序可以连接到互联网上的集中式服务器，并照常开展业务。用户不再依赖浏览器来完成这项工作；所有的服务器要么是自托管的，要么是通过服务提供商托管的，例如互联网服务提供商（ISP）。

用户对其服务器的控制权有限。多个客户及其部署共用同一台服务器，甚至客户并不知情。

然而，在 2000 年代初期和中期发生了另一件事，那就是云计算的崛起，它再次重塑了整个 IT 行业的格局。最初，云计算的采用速度较慢，人们对其持谨慎态度，原因要么是云计算处于初期阶段，还需要成熟，要么是人们对其存在各种负面看法。

为了更好地理解这种颠覆性技术，我们将在本章中介绍以下主题：

• 云计算

• 基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）

• 理解 Azure

• Azure 资源管理器（ARM）

• 虚拟化、容器与 Docker

• 与智能云互动

云计算

今天，云计算是最有前景的技术之一，无论大小企业都在将其作为其 IT 战略的一部分。如今，很难进行任何有意义的 IT 战略讨论而不将云计算纳入整体解决方案讨论。

云计算，通俗来说就是“云”，指的是互联网资源的可用性。这些资源作为服务通过互联网提供给用户。例如，存储可以通过互联网按需提供，供用户存储文件、文档等。在这里，存储是由云服务提供商提供的一种服务。

云服务提供商是提供云服务给其他企业和消费者的公司或公司联盟。它们代表用户托管和管理这些服务，负责启用和维护服务的健康运行。全球各地的多个大型数据中心已经由云服务提供商开设，以满足用户的 IT 需求。

云资源包括按需基础设施的托管服务，如计算基础设施、网络和存储设施。这种云类型被称为 IaaS。

云计算的优势

云计算的采用率达到了历史最高水平，并且因以下几个优势而不断增长：

• 按需付费模式：客户无需购买硬件和软件来使用云资源。使用云资源不需要资本支出；客户只需为使用或预留资源的时间付费。

• 全球访问：云资源通过互联网在全球范围内可用。客户可以随时随地按需访问他们的资源。

• 无限资源：云技术的扩展能力是无限的；客户可以根据需要配置任何数量的资源，且没有任何限制。这也被称为无限扩展性。

• 托管服务：云服务提供商提供许多由他们为客户管理的服务。这可以减轻客户的技术和财务负担。

为什么选择云计算？

为了理解云计算的必要性，我们必须理解行业的视角。

灵活性和敏捷性

今天，应用程序并不是采用“大爆炸”式的部署方法创建的庞大单体应用，而是通过微服务范式由较小的服务组成。微服务帮助以独立和自主的方式创建服务，可以在隔离的状态下演化，而不会导致整个应用程序崩溃。它们在将变更快速而更好的带入生产过程中提供了极大的灵活性和敏捷性。许多微服务共同构成一个应用程序，并为客户提供集成的解决方案。这些微服务应当是可发现的，并具有明确的集成端点。与传统单体应用程序相比，微服务方法的集成数量非常高。这些集成在应用程序的开发和部署中增加了复杂性。

速度、标准化和一致性

因此，部署的方法论也应当进行调整，以适应这些服务的需求，也就是说，频繁的变更和频繁的部署。对于频繁的变更和部署，使用有助于以可预测且一致的方式进行这些变更的流程非常重要。应当使用自动化的敏捷流程，使得较小的变更可以被隔离地部署和测试。

保持相关性

最后，部署目标应当重新定义。部署目标不仅应当能够在几秒钟内轻松创建，而且构建的环境应该在各个版本间保持一致，具备适当的二进制文件、运行时、框架和配置。单体应用使用虚拟机，但微服务需要比虚拟机更具敏捷性、灵活性和更轻量化的选项。容器技术是这些服务的首选部署目标机制，我们将在本章稍后讨论更多相关内容。

可扩展性

使用微服务的一些重要原则是它们在隔离状态下具有无限的扩展能力、全球高可用性、近乎零恢复点的灾难恢复能力和时间目标。微服务的这些特性需要可以无限扩展的基础设施。不应有任何资源限制。虽然如此，组织在未使用资源时，也不应提前支付资源费用。

成本效益

按照使用的资源付费，并通过自动增加或减少资源数量和容量来优化使用，是云计算的基本原则。这些新兴的应用需求要求云作为首选平台，能够轻松扩展，具有高可用性，抗灾能力强，能够轻松引入变更，并以成本效益高的方式实现可预测和一致的自动化部署。

Azure 中的部署范式

在 Azure 中有三种不同的部署模式，具体如下：

• IaaS

• PaaS

• SaaS

这三种部署模式之间的区别在于客户通过 Azure 行使控制的级别。图 1.1 显示了每种部署模式中不同的控制级别：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_1.1.jpg

图 1.1：云服务——IaaS、PaaS 和 SaaS

从图 1.1可以明显看出，使用 IaaS 部署时，客户拥有更多的控制权，而随着从 PaaS 到 SaaS 部署的推进，控制级别逐渐降低。

IaaS

IaaS 是一种部署模型，允许客户在 Azure 上配置自己的基础设施。Azure 提供了多种基础设施资源，客户可以按需配置它们。客户负责维护和管理自己的基础设施。Azure 会确保托管这些虚拟基础设施资源的物理基础设施得到维护。在这种模式下，客户需要在 Azure 环境中进行积极的管理和操作。

PaaS

PaaS 将基础设施部署和控制权从客户手中移除。相较于 IaaS，这是一种更高级的抽象模式。在这种方式中，客户将自己的应用、代码和数据引入并部署到 Azure 提供的平台上。这些平台由 Azure 管理和治理，客户仅对其应用程序负责。客户只需进行与应用部署相关的活动。相比于 IaaS，这种模式为应用的部署提供了更快速、更便捷的选项。

SaaS

SaaS 是一种相较于 PaaS 更高级的抽象模式。在这种方式中，软件及其服务可以供客户使用。客户只需将数据引入这些服务中——他们无法控制这些服务。现在我们已经对 Azure 中的服务类型有了基本了解，接下来让我们深入了解 Azure，从基础开始理解它。

理解 Azure

Azure 提供了云的所有好处，同时保持开放和灵活。Azure 支持多种操作系统、编程语言、工具、平台、实用程序和框架。例如，它支持 Linux 和 Windows、SQL Server、MySQL 和 PostgreSQL。它支持大多数编程语言，包括 C#、Python、Java、Node.js 和 Bash。它支持 NoSQL 数据库，如 MongoDB 和 Cosmos DB，并且还支持持续集成工具，如 Jenkins 和 Azure DevOps Services（前身是Visual Studio Team Services（VSTS））。这个生态系统的核心思想是使客户能够自由选择自己的语言、平台、操作系统、数据库、存储以及工具和实用程序。客户不应该受到技术方面的限制；相反，他们应该能够构建并专注于他们的业务解决方案，而 Azure 为他们提供了一个世界级的技术栈供其使用。

Azure 与客户选择的技术栈高度兼容。例如，Azure 支持所有流行的（开源和商业）数据库环境。Azure 提供 Azure SQL、MySQL 和 Postgres 的 PaaS 服务。它提供了 Hadoop 生态系统，并提供基于 100% Apache Hadoop 的 PaaS 服务 HDInsight。它还为那些更倾向于 IaaS 方法的客户提供了基于 Linux 的 Hadoop 虚拟机（VM）实现。Azure 还提供 Redis 缓存服务，并支持其他流行的数据库环境，如 Cassandra、Couchbase 和 Oracle，作为 IaaS 实现。

Azure 上的服务数量日益增加，最新的服务列表可以在 azure.microsoft.com/services 找到。

Azure 还提供了一种独特的云计算范式——混合云。混合云指的是一种部署策略，其中一部分服务部署在公共云上，而其他服务则部署在本地私有云或数据中心。公共云和私有云之间通过虚拟专用网络（VPN）连接。Azure 为客户提供了将工作负载划分并同时部署在公共云和本地数据中心的灵活性。

Azure 在全球范围内拥有数据中心，并将这些数据中心组合成区域。每个区域都有多个数据中心，以确保灾难恢复迅速高效。到目前为止，全球已有 58 个区域。这为客户提供了在选择的位置部署服务的灵活性。客户还可以结合这些区域，部署灾难恢复能力强且靠近客户群的解决方案。

注意

在中国和德国，Azure 云服务在普通使用和政府使用方面是分开的。这意味着云服务在不同的数据中心进行维护。

Azure 作为智能云

Azure 提供基础设施和服务，利用超大规模处理技术处理数十亿的事务。它为数据提供了 PB 级的存储，并提供了大量互联的服务，可以在它们之间传递数据。凭借这样的能力，数据可以被处理以生成有意义的知识和见解。通过数据分析可以生成多种类型的见解，具体如下：

• 描述性：这种类型的分析提供关于正在发生或过去发生的事情的详细信息。

• 预测性：这种类型的分析提供有关未来将要发生的事情的详细信息。

• 规范性：这种类型的分析提供有关应采取什么措施来增强或防止当前或未来事件的详细信息。

• 认知性：这种类型的分析实际上执行由规范性分析确定的自动化操作。

尽管从数据中提取见解非常重要，但同样重要的是根据这些见解采取行动。Azure 提供了一个强大的平台，用于摄取大量数据、处理和转换数据、存储并生成见解，并将其显示在实时仪表板上。还可以根据这些见解自动采取行动。这些服务面向所有 Azure 客户提供，形成了一个丰富的生态系统，客户可以在其中创建解决方案。由于 Azure 提供的智能服务的易得性，企业正在创建大量的应用程序和服务，完全颠覆了行业，这些服务结合起来为最终客户创造了有意义的价值。Azure 确保那些对中小型公司来说商业上不可行的服务，现在可以轻松消费并在几分钟内部署。

Azure 资源管理器

Azure 资源管理器 (ARM) 是微软的技术平台和编排服务，将之前讨论的所有组件结合起来。它将 Azure 的资源提供者、资源和资源组结合起来，形成一个统一的云平台。它使 Azure 服务以订阅的形式提供，资源类型以资源组的形式提供，并使资源和资源 API 可供门户和其他客户端访问，同时进行身份验证以访问这些资源。它还启用了如标签、身份验证、基于角色的访问控制 (RBAC)、资源锁定和策略执行等功能，用于订阅及其资源组的管理。它还通过 Azure 门户、Azure PowerShell 和 命令行接口 (CLI) 工具提供部署和管理功能。

ARM 架构

ARM 架构及其组件如图 1.2所示。如我们所见，Azure 订阅由多个资源组组成。每个资源组包含从资源提供者中可用的资源类型创建的资源实例：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_1.2.jpg

图 1.2：ARM 架构

为什么选择 ARM？

在 ARM 之前，Azure 使用的框架被称为Azure 服务管理器（ASM）。了解 ASM 的一些基本情况非常重要，这样我们才能清楚地理解 ARM 的出现，以及 ASM 的逐步弃用过程。

ASM 的限制

ASM 存在固有的限制。例如，ASM 部署较慢且会被阻塞——如果前一个操作正在进行，后续操作将会被阻塞。ASM 的一些限制如下：

• 并行性：并行性在 ASM 中是一个挑战。无法成功地并行执行多个事务。ASM 中的操作是线性的，依次执行。如果同时执行多个事务，将会出现并行操作错误或事务被阻塞。

• 资源：ASM 中的资源是相互独立地进行配置和管理的；ASM 资源之间没有关系。无法将服务和资源进行分组或一起配置。

• 云服务：云服务是 ASM 中的部署单元。它们依赖于亲和性组，并且由于设计和架构的原因，无法进行扩展。

无法为 ASM 中的资源分配细粒度和独立的角色和权限。客户要么是服务管理员，要么是订阅中的共同管理员。客户要么对资源拥有完全控制权限，要么根本无法访问这些资源。ASM 不提供部署支持。要么需要手动进行部署，要么需要编写.NET 或 PowerShell 脚本进行自动化。ASM 的 API 在不同资源之间并不一致。

ARM 的优势

ARM 相比于 ASM 提供了明显的优势，具体如下：

• 分组：ARM 允许将资源逻辑上分组到一个容器中。这些资源可以一起管理，并作为一个整体经历共同的生命周期。这样更容易识别相关和依赖的资源。

• 共同生命周期：分组中的资源具有相同的生命周期。这些资源可以一起发展并作为一个单位进行管理。

• RBAC：可以为资源分配细粒度的角色和权限，从而为客户提供独立的访问权限。客户也只能拥有分配给他们的那些权限。

• 部署支持：ARM 通过模板提供部署支持，支持 DevOps 和基础设施即代码（IaC）。这些部署速度更快、一致且可预测。

• 更优的技术：资源的成本和计费可以作为一个单位进行管理。每个资源组可以提供其使用情况和成本信息。

• 可管理性：ARM 提供了高级功能，如安全性、监控、审计和标记，以便更好地管理资源。可以根据标签查询资源。标签还提供了类似标签资源的成本和计费信息。

• 迁移：在资源组内部和跨资源组迁移和更新资源变得更容易。

ARM 概念

使用 ARM，Azure 中的一切都是资源。资源的例子包括虚拟机（VM）、网络接口、公有 IP 地址、存储帐户和虚拟网络。ARM 基于与资源提供者和资源消费者相关的概念。Azure 通过多个资源提供者提供资源和服务，这些资源和服务在组内被消费和部署。

资源提供者

这些是通过 ARM 提供资源类型的服务。ARM 中的顶级概念是资源提供者。资源提供者是资源类型的容器。资源类型被分组到资源提供者中。它们负责部署和管理资源。例如，虚拟机资源类型由名为 Microsoft.Compute/virtualMachines 的资源提供者提供。表述性状态传输（REST）API 操作已版本化，以便区分它们。版本命名基于它们由 Microsoft 发布的日期。为部署资源，相关的资源提供者必须在订阅中可用。并非所有资源提供者在默认情况下都可用。如果某个资源在订阅中不可用，我们需要检查所需的资源提供者是否在每个区域中可用。如果可用，客户可以明确地为该订阅注册。

资源类型

资源类型是定义资源公共 API 接口和实现的实际资源规范。它们实现资源所支持的工作和操作。与资源提供者类似，资源类型在其内部实现方面也会随着时间的推移而发展，并且有多个版本的架构和公共 API 接口。版本名称基于它们由 Microsoft 作为预览或正式发布（GA）的日期。资源类型在资源提供者注册之后作为订阅可用。此外，并非每个资源类型都在每个 Azure 区域中可用。资源的可用性取决于资源提供者在 Azure 区域的可用性和注册情况，并且必须支持为其提供所需的 API 版本。

资源组

资源组是 ARM 中的部署单元。它们是将多个资源实例组合在一起的容器，并具有安全性和管理边界。资源组在一个订阅中具有唯一名称。资源可以部署在不同的 Azure 区域，但仍然属于同一个资源组。资源组为其中的所有资源提供附加服务。资源组提供元数据服务，例如标签功能，用于对资源进行分类；基于策略的资源管理；RBAC（基于角色的访问控制）；保护资源免受意外删除或更新等。如前所述，资源组具有安全边界，无法访问资源组的用户也无法访问其中包含的资源。每个资源实例都需要属于一个资源组，否则无法进行部署。

资源和资源实例

资源是由资源类型创建的，是资源类型的实例。一个实例可以在全球范围内唯一，或者在资源组级别唯一。唯一性由资源的名称和类型共同定义。如果将其与面向对象编程结构进行比较，资源实例可以视为对象，而资源类型则可以视为类。服务通过资源实例所支持和实现的操作进行消费。资源类型定义了属性，每个实例在实例配置时应配置强制性的属性。有些是强制性的属性，而其他则是可选的。资源实例继承其父资源组的安全性和访问配置。这些继承的权限和角色分配可以被覆盖到每个资源。可以以某种方式锁定资源，从而阻止某些操作，使其即使对角色、用户和组具有访问权限，也无法使用。资源可以被标记，以便于发现和管理。

ARM 特性

下面是 ARM 提供的一些主要功能：

• RBAC：Azure Active Directory（Azure AD）认证用户以提供对订阅、资源组和资源的访问。ARM 在平台中实现 OAuth 和 RBAC，基于分配给用户或组的角色，启用对资源、资源组和订阅的授权和访问控制。权限定义了对资源操作的访问。这些权限可以允许或拒绝对资源的访问。角色定义是这些权限的集合。角色将 Azure AD 用户和组映射到特定权限。角色随后被分配到某个范围；这个范围可以是单个用户、一组资源、资源组或订阅。添加到角色中的 Azure AD 身份（用户、组和服务主体）根据角色中定义的权限访问资源。ARM 提供多个开箱即用的角色，包括系统角色，如所有者、贡献者和阅读者。它还提供基于资源的角色，如 SQL 数据库贡献者和虚拟机贡献者。ARM 还允许创建自定义角色。

• 标签：标签是名称-值对，向资源添加额外的信息和元数据。资源和资源组都可以使用多个标签。标签有助于资源的分类，从而提升可发现性和可管理性。资源可以快速搜索并轻松识别。还可以获取具有相同标签的资源的计费和成本信息。尽管此功能由 ARM 提供，但 IT 管理员会根据资源和资源组定义其使用和分类。分类和标签可以与部门、资源使用、位置、项目或从成本、使用、计费或搜索角度来看被认为合适的其他标准相关。这些标签随后可以应用于资源。在资源组级别定义的标签不会被其资源继承。

• 策略：ARM 提供的另一项安全功能是自定义策略。可以创建自定义策略来控制对资源的访问。策略被定义为约定和规则，在与资源和资源组交互时必须遵守这些规则。策略定义明确禁止对资源的操作或访问。默认情况下，所有未在策略定义中提及的访问都会被允许。这些策略定义被分配到资源、资源组和订阅范围内。需要注意的是，这些策略并不是 RBAC 的替代品或替换品。实际上，它们与 RBAC 互补并协同工作。策略会在用户通过 Azure AD 进行身份验证并通过 RBAC 服务授权后进行评估。ARM 提供了一种基于 JSON 的策略定义语言来定义策略。一些策略定义的示例包括：必须对每个已配置的资源进行标签，并且资源只能在特定的 Azure 区域进行配置。

• 锁定：可以对订阅、资源组和资源进行锁定，以防止经过身份验证的用户意外删除或更新。应用于更高层级的锁定会向下流向子资源。或者，应用于订阅级别的锁定会锁定每个资源组及其中的资源。

• 多区域：Azure 提供多个区域来配置和托管资源。ARM 允许在不同位置配置资源，同时仍然位于同一个资源组内。一个资源组可以包含来自不同区域的资源。

• 幂等：此功能通过确保每次部署都能导致资源和配置处于相同的状态，无论执行多少次，从而确保资源部署的可预测性、标准化和一致性。

• 可扩展：ARM 提供了一个可扩展的架构，允许在平台上创建和插入新的资源提供程序和资源类型。

虚拟化

虚拟化是一项突破性的创新，它彻底改变了对物理服务器的看法。它是将物理对象抽象为逻辑对象的过程。

物理服务器的虚拟化导致了被称为虚拟机（VM）的虚拟服务器。这些虚拟机共享并使用托管它们的物理服务器的 CPU、内存、存储和其他硬件。这使得按需提供应用环境变得更快、更容易，提供了高可用性和可扩展性，并且降低了成本。一个物理服务器就足以托管多个虚拟机，每个虚拟机都有自己的操作系统并在其上托管服务。

不再需要购买额外的物理服务器来部署新的应用程序和服务。现有的物理服务器足以托管更多的虚拟机。此外，通过虚拟化的帮助，许多物理服务器被整合为少数几台，以实现合理化。

每个虚拟机都包含整个操作系统，并且每个虚拟机与其他虚拟机完全隔离，包括物理主机。虽然虚拟机使用宿主物理服务器提供的硬件，但它对其分配的资源和环境拥有完全控制权。这些虚拟机可以托管在如物理服务器等网络上，并拥有自己的身份。

Azure 可以在几分钟内创建 Linux 和 Windows 虚拟机。微软提供了自己的镜像，以及来自其合作伙伴和社区的镜像；用户也可以提供自己的镜像。虚拟机使用这些镜像进行创建。

容器

容器也是一种虚拟化技术；然而，它们并不虚拟化服务器。相反，容器是操作系统级别的虚拟化。这意味着容器共享宿主操作系统内核（由宿主提供）以及宿主之间的内核。运行在宿主（物理或虚拟）上的多个容器共享宿主操作系统内核。容器确保它们复用宿主内核，而不是每个容器都有自己的独立内核。

容器与其宿主或运行在宿主上的其他容器完全隔离。Windows 容器使用 Windows 存储过滤驱动程序和会话隔离来隔离操作系统服务，如文件系统、注册表、进程和网络。即使在 Linux 宿主上运行的 Linux 容器也是如此。Linux 容器使用 Linux 命名空间、控制组和联合文件系统来虚拟化宿主操作系统。

容器看起来仿佛拥有一个全新且未被触及的操作系统和资源。这种安排带来了许多好处，诸如以下几点：

• 容器的快速配置时间远远少于虚拟机。容器中的大多数操作系统服务由宿主操作系统提供。

• 容器比虚拟机更轻量，所需的计算资源也更少。使用容器时，不再需要操作系统资源开销。

• 容器比虚拟机小得多。

• 容器能够以直观、自动化和简便的方式帮助解决与管理多个应用程序依赖关系相关的问题。

• 容器提供了基础设施，用于在一个地方定义所有应用程序的依赖关系。

容器是 Windows Server 2016 和 Windows 10 的固有特性；然而，它们是通过 Docker 客户端和 Docker 守护进程进行管理和访问的。可以在 Azure 上使用 Windows Server 2016 SKU 作为镜像来创建容器。每个容器都有一个必须保持运行的主进程，以确保容器的存在。当该进程结束时，容器将停止。此外，容器可以在交互模式下运行，也可以像服务一样在分离模式下运行：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_1.3.jpg

图 1.3：容器架构

图 1.3 展示了启用容器的所有技术层。最底层提供了核心基础设施，包括网络、存储、负载均衡器和网络卡。在基础设施的顶部是计算层，由物理服务器或物理服务器上方的虚拟和物理服务器组成。此层包含能够托管容器的操作系统。操作系统提供了执行驱动程序，上层使用该驱动程序调用内核代码和对象来执行容器。微软为管理和创建容器而创建了 Host Container System Shim（HCSShim），并使用 Windows 存储过滤驱动程序进行镜像和文件管理。

容器环境隔离已在 Windows 会话中启用。Windows Server 2016 和 Nano Server 提供操作系统，启用容器功能，并执行用户级的 Docker 客户端和 Docker 引擎。Docker 引擎使用 HCSShim、存储过滤驱动程序和会话服务，在服务器上生成多个容器，每个容器中包含一个服务、应用程序或数据库。

Docker

Docker 为 Windows 容器提供管理功能。它包括以下两个可执行文件：

• Docker 守护进程

• Docker 客户端

Docker 守护进程是管理容器的核心工具。它是一个 Windows 服务，负责管理主机上与容器相关的所有活动。Docker 客户端与 Docker 守护进程进行交互，负责捕获输入并将其发送到 Docker 守护进程。Docker 守护进程提供运行时、库、图形驱动程序和引擎，用于创建、管理和监控主机服务器上的容器和镜像。它还能够创建用于构建和交付应用程序到多个环境的自定义镜像。

与智能云交互

Azure 提供多种连接、自动化和与智能云交互的方式。所有这些方法都需要用户在使用前通过有效凭据进行身份验证。连接 Azure 的不同方式如下：

• Azure 门户

• PowerShell

• Azure CLI

• Azure REST API

Azure 门户

Azure 门户是一个很好的入门平台。通过 Azure 门户，用户可以登录并开始手动创建和管理 Azure 资源。该门户通过浏览器提供直观、易于使用的用户界面。Azure 门户提供了一种便捷的方式，通过 blade 来导航资源。Blade 显示资源的所有属性，包括日志、费用、与其他资源的关系、标签、安全选项等。整个云部署都可以通过门户进行管理。

PowerShell

PowerShell 是一个基于对象的命令行外壳和脚本语言，用于基础设施和环境的管理、配置和控制。它建立在 .NET 框架之上，提供自动化功能。PowerShell 已真正成为 IT 管理员和自动化开发人员在管理和控制 Windows 环境中的第一选择。如今，几乎每个 Windows 环境和许多 Linux 环境都可以通过 PowerShell 进行管理。事实上，几乎每个 Azure 的方面也可以通过 PowerShell 管理。Azure 提供了对 PowerShell 的丰富支持，针对每个资源提供商都提供了 PowerShell 模块，其中包含数百个 cmdlet。用户可以在脚本中使用这些 cmdlet 来自动化与 Azure 的交互。Azure PowerShell 模块可以通过 Web 平台安装程序以及通过 PowerShellGet 模块快速、轻松地从 PowerShell Gallery 下载和安装 PowerShell 模块。PowerShellGet 模块提供了 Install-Module cmdlet 用于在系统上下载和安装模块。

安装模块是一个简单的复制模块文件到定义好的模块位置的过程，具体操作如下：

Import-module PowerShellGet
Install-Module -Name az -verbose

Import-module 命令将模块及其相关功能导入当前执行范围，Install-Module 帮助安装模块。

Azure CLI

Azure 还提供了 Azure CLI 2.0，可以在 Linux、Windows 和 macOS 操作系统上部署。Azure CLI 2.0 是 Azure 的新命令行工具，用于管理 Azure 资源。Azure CLI 2.0 针对通过命令行管理和管理 Azure 资源进行了优化，适用于构建与 ARM 交互的自动化脚本。CLI 可以使用 Bash shell 或 Windows 命令行执行命令。Azure CLI 在非 Windows 用户中非常受欢迎，因为它允许在 Linux 和 macOS 上与 Azure 进行交互。Azure CLI 2.0 的安装步骤可以参考 docs.microsoft.com/cli/azure/install-azure-cli?view=azure-cli-latest。

Azure REST API

所有 Azure 资源都通过 REST 端点暴露给用户。REST API 是服务端点，通过提供 创建、检索、更新 或 删除（CRUD）访问来实现 HTTP 操作（或方法）。用户可以使用这些 API 来创建和管理资源。实际上，CLI 和 PowerShell 机制内部使用这些 REST API 与 Azure 上的资源进行交互。

ARM 模板

在前面的部分中，我们讨论了 ARM 提供的部署特性，例如多服务、多区域、可扩展和幂等性等。ARM 模板是 ARM 中资源配置的主要方式，ARM 模板为 ARM 的部署特性提供了实现支持。

ARM 模板通过声明性模型来指定资源、其配置、脚本和扩展。ARM 模板基于 JavaScript 对象表示法（JSON）格式。它们使用 JSON 语法和约定来声明和配置资源。JSON 文件是基于文本的，用户友好且易于阅读的文件。

它们可以存储在源代码库中，并进行版本控制。它们也是表示基础设施即代码（IaC）的一种方式，可以反复、可预测且一致地用于在 Azure 资源组中配置资源。模板需要一个资源组来进行部署。它只能部署到资源组，并且资源组应在执行模板部署之前存在。模板无法创建资源组。

模板提供了在设计和实现中保持通用性和模块化的灵活性。模板允许接受用户输入的参数，声明内部变量，定义资源之间的依赖关系，链接同一资源组或不同资源组中的资源，并执行其他模板。它们还提供脚本语言类型的表达式和函数，使得模板在运行时具有动态性和可定制性。

部署

PowerShell 支持以下两种模板部署模式：

• 增量：增量部署会将模板中声明但在资源组中不存在的资源添加到资源组，将资源组中不属于模板定义的资源保持不变，并保持模板和资源组中都存在的资源（且配置状态相同）不变。

• 完整：完整部署模式则将模板中声明的资源添加到资源组中，从资源组中删除模板中不存在的资源，并保持在资源组和模板中都存在的资源（且配置状态相同）不变。

摘要

云计算是一个相对较新的范式，仍处于初期阶段。随着时间的推移，很多创新和功能将会加入其中。Azure 是目前领先的云服务提供商之一，它通过 IaaS、PaaS、SaaS 和混合部署提供了丰富的功能。事实上，Azure Stack 是微软推出的私有云实现，预计很快就会发布。这将具备与公有云相同的功能，实际上它们会无缝且透明地连接并协同工作。

开始使用 Azure 非常简单，但如果开发人员和架构师没有适当设计和架构他们的解决方案，也很容易陷入困境。本书尝试为架构解决方案提供指导和方向，帮助以正确的方式使用合适的服务和资源。Azure 上的每个服务都是一种资源。理解这些资源如何在 Azure 中组织和管理是非常重要的。本章介绍了 ARM 和资源组——这两个核心框架为资源提供了基础构件。ARM 为资源提供了一套服务，帮助在管理它们时实现统一性、标准化和一致性。诸如 RBAC、标签、策略和锁等服务，适用于每个资源提供者和资源。Azure 还提供了丰富的自动化功能，可以自动化并与资源交互。工具如 PowerShell、ARM 模板和 Azure CLI 可以作为发布流水线、持续部署和交付的一部分进行集成。用户可以通过这些自动化工具从异构环境连接到 Azure。

下一章将讨论一些重要的架构问题，这些问题有助于解决常见的基于云的部署问题，并确保应用程序在长期内是安全的、可用的、可扩展的和可维护的。

第二章：2. Azure 解决方案的可用性、可扩展性和监控

架构上的关注点，如高可用性和可扩展性，是任何架构师最高优先级的任务之一。这在许多项目和解决方案中都很常见。然而，在将应用程序部署到云端时，这些问题变得尤为重要，因为云端的复杂性。在大多数情况下，复杂性并不是来自应用程序本身，而是来自云中类似资源的多样性。云端带来的另一个复杂问题是新功能的不断涌现。这些新功能几乎使得架构师的决策在回顾时完全显得多余。

在本章中，我们将从架构师的角度，探讨如何在 Azure 上部署高度可用和可扩展的应用程序。

Azure 是一个成熟的平台，提供了多个级别的高可用性和可扩展性的实现选项。架构师必须了解这些选项，包括它们之间的差异、所涉及的成本，并最终能够选择一个符合最佳需求的解决方案。没有一个适合所有场景的解决方案，但每个项目都有一个合适的方案。

对于组织来说，能够随时向用户提供可用的应用程序和系统，是最重要的优先事项之一。它们希望自己的应用程序能够持续运行且具备功能，即使在发生一些不利事件时，仍能继续为客户提供服务。高可用性是本章的主要主题。保持系统运行 是高可用性的常用比喻。实现应用程序的高可用性并非易事，组织必须投入大量的时间、精力、资源和金钱。此外，仍然存在组织的实施方案无法达到预期结果的风险。Azure 为虚拟机（VMs）和平台即服务（PaaS）服务提供了许多高可用性功能。本章将介绍 Azure 提供的架构和设计功能，以确保正在运行的应用程序和服务的高可用性。

在本章中，我们将涵盖以下主题：

• 高可用性

• Azure 高可用性

• 高可用性的架构考虑因素

• 可扩展性

• 升级和维护

高可用性

高可用性是任何业务关键服务及其部署的核心非功能性技术要求之一。高可用性是指一个服务或应用程序保持持续运行的特性；它通过满足或超越其承诺的服务级别协议（SLA）来实现这一点。用户根据服务类型会被承诺一定的 SLA。服务应该根据其 SLA 可供用户使用。例如，SLA 可以定义一个应用程序在一年内的可用性为 99%。这意味着它应该可以供用户使用 361.35 天。如果它未能在此期间保持可用，则构成违反 SLA。大多数关键任务应用程序将它们的高可用性 SLA 定义为 99.999%（每年）。这意味着该应用程序应该全年都能保持运行并可供使用，但它的停机时间不能超过 5.2 小时。如果停机时间超过这一限度，您将有资格获得信用，信用金额将根据总的正常运行时间百分比来计算。

需要注意的是，高可用性是根据时间来定义的（可以是按年、按月、按周，或这些的组合）。

一个服务或应用程序由多个组件组成，这些组件部署在不同的层级和层次上。此外，服务或应用程序部署在操作系统（OS）上，并托管在物理机器或虚拟机（VM）上。它消耗网络和存储服务来满足各种需求，甚至可能依赖于外部系统。为了确保这些服务或应用程序具备高可用性，网络、存储、操作系统、虚拟机或物理机器以及应用程序的每个组件都必须考虑 SLA 和高可用性。为了确保高可用性，从应用程序规划开始直到投入运营，都需要采用明确的应用程序生命周期流程。这也涉及到冗余的引入。冗余资源应该包括在整个应用程序和部署架构中，以确保如果一个资源出现故障，另一个资源能够接管并继续为客户提供服务。

影响应用程序高可用性的一些主要因素如下：

• 计划性维护

• 非计划性维护

• 应用程序部署架构

我们将在接下来的章节中详细探讨这些因素。让我们仔细看看 Azure 如何确保部署的高可用性。

Azure 高可用性

实现高可用性并满足高 SLA 要求是非常困难的。Azure 提供了许多功能，能够为应用程序实现高可用性，从主机和来宾操作系统到使用其 PaaS 的应用程序。架构师可以通过这些功能，通过配置来实现应用程序的高可用性，而不必从头开始构建这些功能或依赖第三方工具。

在本节中，我们将探讨 Azure 提供的使应用程序高可用的功能和能力。在深入架构和配置细节之前，理解与 Azure 高可用性相关的概念非常重要。

概念

Azure 提供的实现高可用性的基本概念如下：

• 可用性集

• 故障域

• 更新域

• 可用性区域

如你所知，设计高可用性解决方案非常重要。工作负载可能是关键任务，并且需要高可用架构。我们现在将仔细查看 Azure 中高可用性的每个概念。我们从可用性集开始。

可用性集

Azure 中的高可用性主要通过冗余来实现。冗余意味着有多个相同类型的资源实例，在主资源发生故障时接管控制。然而，仅仅拥有更多相似的资源并不能使它们具备高可用性。例如，在一个订阅中可能会配置多个虚拟机，但仅仅有多个虚拟机并不意味着它们具备高可用性。Azure 提供了一个名为可用性集的资源，将多个虚拟机与其关联可以使它们具备高可用性。为了实现高可用性，至少应将两台虚拟机托管在可用性集中。由于所有虚拟机都被放置在 Azure 数据中心的不同物理机架上，它们都会具备高可用性。在更新时，这些虚拟机会逐一更新，而不是同时更新。可用性集提供了故障域和更新域来实现这一点，我们将在下一部分详细讨论。简而言之，可用性集在数据中心级别提供冗余，类似于本地冗余存储。

需要注意的是，可用性集仅在数据中心内部提供高可用性。如果整个数据中心发生故障，应用程序的可用性将受到影响。为了确保在数据中心故障时应用程序仍然可用，Azure 引入了一个名为可用性区域的新特性，我们将在稍后学习。

如果你回顾基本概念列表，接下来是故障域。故障域通常用缩写 FD 表示。在下一部分中，我们将讨论故障域是什么，以及它在设计高可用性解决方案时的相关性。

故障域

故障域（FDs）表示一组共享相同电源和网络交换机的虚拟机（VM）。当一台 VM 被配置并分配到可用性集时，它将被托管在一个故障域中。每个可用性集默认有两个或三个故障域，这取决于 Azure 区域。有些区域提供两个故障域，而其他区域则提供三个故障域。故障域无法由用户配置。

当多个虚拟机被创建时，它们会被放置在不同的 FDs 上。如果虚拟机的数量超过了 FDs 的数量，多余的虚拟机会被放置在现有的 FDs 上。例如，如果有五个虚拟机，则这些虚拟机会托管在多个虚拟机上。

FDs 与 Azure 数据中心中的物理机架相关。FDs 在由于硬件、电力和网络故障导致的计划外停机情况下提供高可用性。由于每个虚拟机（VM）都被放置在不同的机架上，具有不同的硬件、不同的电源和不同的网络，因此如果某个机架出现故障，其他虚拟机将继续运行。

列表中的下一个是更新域。

更新域

FD 处理计划外停机，而更新域（update domain）则处理来自计划维护的停机。每个虚拟机也会被分配一个更新域，该更新域中的所有虚拟机将一起重启。一个可用性集最多可以有 20 个更新域。更新域是用户无法配置的。当多个虚拟机被创建时，它们会被放置在不同的更新域中。如果在一个可用性集中配置了超过 20 个虚拟机，它们将以轮询方式分布到这些更新域中。更新域处理计划维护。通过 Azure 门户中的服务健康，你可以查看计划维护的详细信息并设置警报。

在接下来的部分中，我们将介绍可用性区域（availability zones）。

可用性区域

这是 Azure 引入的一个相对较新的概念，与存储帐户的区域冗余非常相似。可用性区域通过将虚拟机实例放置在区域内不同的数据中心中，提供区域内的高可用性。可用性区域适用于 Azure 中的许多资源，包括虚拟机、托管磁盘、虚拟机规模集和负载均衡器。支持可用性区域的资源的完整列表可以在 docs.microsoft.com/azure/availability-zones/az-overview#services-that-support-availability-zones 中找到。长时间以来，无法跨区域配置可用性是 Azure 的一个缺口，直到引入可用性区域后才得以解决。

每个 Azure 区域由多个配备独立电力、冷却和网络设施的数据中心组成。一些区域的数据中心较多，而另一些区域的数据中心较少。该区域内的数据中心被称为区域。在所有启用的区域中，至少有三个独立的区域以确保弹性。将虚拟机部署在可用性区域中，确保这些虚拟机位于不同的数据中心，并且位于不同的机架和网络上。这些区域内的数据中心之间具有高速网络，这些虚拟机之间的通信不会出现延迟。图 2.1 显示了在区域中如何设置可用性区域：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_01.jpg

图 2.1：区域中的可用性区域

您可以在docs.microsoft.com/azure/availability-zones/az-overview找到有关可用性区域的更多信息。

区域冗余服务将您的应用程序和数据复制到可用性区域，以防止单点故障。

如果应用程序需要更高的可用性，并且您希望确保即使整个 Azure 区域宕机，也可用，可用性的下一个层次是 Traffic Manager 功能，这将在本章后面讨论。现在让我们继续了解 Azure VM 负载平衡的工作原理。

负载均衡

负载均衡，顾名思义，是指在 VM 和应用程序之间平衡负载的过程。如果只有一个 VM，则无需负载均衡器，因为整个负载位于单个 VM 上，没有其他 VM 可以共享负载。然而，通过包含相同应用程序和服务的多个 VM，可以通过负载均衡器在它们之间分发负载。Azure 提供了几种资源来实现负载均衡：

• 负载均衡器：Azure 负载均衡器有助于设计具有高可用性的解决方案。在传输控制协议（TCP）堆栈内，它是第 4 层传输级别的负载均衡器。这是一个第 4 层负载均衡器，将传入的流量分发到负载平衡集中定义的健康服务实例之间。第 4 层负载均衡器在传输级别工作，并具有网络级别的信息，如 IP 地址和端口，以决定传入请求的目标。负载均衡器将在本章后面详细讨论。

• 应用程序网关：Azure 应用程序网关为您的应用程序提供高可用性。它们是第 7 层负载均衡器，将传入的流量分发到服务的健康实例之间。第 7 层负载均衡器可以在应用程序级别工作，并具有应用程序级别的信息，如 cookie、HTTP、HTTPS 和会话等。应用程序网关将在本章后面详细讨论。在部署 Azure Kubernetes 服务时，特别是需要将来自互联网的入口流量路由到集群中的 Kubernetes 服务的场景中，也会使用应用程序网关。

• Azure Front Door：Azure Front Door 与应用程序网关非常相似；但是，它不在区域或数据中心级别工作。相反，它在全球范围内帮助路由请求。它具有与应用程序网关相同的功能集，但是在全局级别提供。它还提供网页应用程序防火墙以过滤请求并提供其他安全相关的保护。它提供会话亲和性、TLS 终止和基于 URL 的路由作为其部分功能。

• 流量管理器：流量管理器帮助根据区域端点的健康状况和可用性，在多个区域之间对请求进行全局路由。它支持通过 DNS 重定向条目来实现这一点。它具有高度的弹性，并且在区域故障期间不会影响服务。

由于我们已经探讨了可以用于实现负载均衡的方法和服务，接下来我们将讨论如何使虚拟机具备高可用性。

虚拟机高可用性

虚拟机提供计算能力。它们为应用程序和服务提供处理能力和托管支持。如果应用程序部署在单个虚拟机上，而该虚拟机出现故障，则应用程序将无法使用。如果应用程序由多个层组成，并且每个层都部署在各自的单个虚拟机实例上，那么即使是单个虚拟机实例的停机也可能导致整个应用程序不可用。Azure 尝试使单个虚拟机实例的可用性达到 99.9%，特别是当这些单实例虚拟机使用高级存储作为磁盘时。对于那些在可用性集中分组在一起的虚拟机，Azure 提供了更高的服务级别协议（SLA）。对于包含两个或更多虚拟机的可用性集，提供 99.95% 的 SLA。如果虚拟机部署在可用性区域中，SLA 可达 99.99%。在下一节中，我们将讨论计算资源的高可用性。

计算高可用性

需要高可用性的应用程序应部署在同一可用性集中的多个虚拟机（VM）上。如果应用程序由多个层组成，那么每个层应有一组虚拟机，部署在其专用的可用性集中。简而言之，如果一个应用程序有三个层，那么应有三个可用性集，并且至少需要六个虚拟机（每个可用性集两个虚拟机），以确保整个应用程序具有高可用性。

那么，Azure 是如何通过在每个可用性集中部署多个虚拟机来提供服务级别协议（SLA）和高可用性的呢？这个问题可能会浮现在你的脑海中。

在这里，我们之前考虑的概念起到了关键作用——即故障域（FD）和更新域。当 Azure 发现可用性集中有多个虚拟机时，它会将这些虚拟机放置在不同的故障域中。换句话说，这些虚拟机会被放置在不同的物理机架上，而不是同一个机架上。这确保了即使发生电源、硬件或机架故障，至少有一台虚拟机可以继续使用。一个可用性集中有两个或三个故障域，并且根据可用性集中的虚拟机数量，这些虚拟机会被放置在不同的故障域中，或者以循环方式重复放置。这确保了即使机架发生故障，高可用性也不会受到影响。

Azure 还将这些虚拟机放置在不同的更新域中。换句话说，Azure 内部为这些虚拟机打上标签，使得这些虚拟机按照顺序进行修补和更新，以确保在某个更新域中的任何重启都不会影响应用程序的可用性。这确保了虚拟机和主机维护不会影响高可用性。需要注意的是，Azure 不负责操作系统级别和应用程序的维护。

通过将虚拟机放置在不同的故障域和更新域中，Azure 确保所有虚拟机不会同时宕机，并且即使它们正在进行维护或面临物理停机问题，也能保持在线并能够处理请求：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_02.jpg

图 2.2：虚拟机在故障域和更新域中的分布

图 2.2 显示了四个虚拟机（其中两个安装了Internet 信息服务（IIS），另两个安装了 SQL Server）。IIS 和 SQL 虚拟机都属于可用性集的一部分。IIS 和 SQL 虚拟机位于数据中心的不同故障域（FD）和机架中，并且它们也处于不同的更新域中。

图 2.3 显示了故障域和更新域之间的关系：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_03.jpg

图 2.3：可用性集中更新域和故障域的布局

到目前为止，我们讨论了如何实现计算资源的高可用性。在接下来的章节中，您将学习如何为 PaaS 实现高可用性。

高可用性平台

Azure 提供了许多新功能，以确保 PaaS 的高可用性。以下是其中的一些功能：

• 应用服务中的容器

• Azure 容器实例组

• Azure Kubernetes 服务

• 其他容器协调器，如 DC/OS 和 Swarm

另一个提供高可用性的重要平台是Service Fabric。Service Fabric 和包含 Kubernetes 的容器协调器都能确保在环境中始终有所需数量的应用实例在运行。这意味着即使环境中的某个实例宕机，协调器也能通过主动监控得知，并会在另一个节点上启动新的实例，从而保持理想的应用实例数量。它这样做不需要管理员的手动或自动干预。

虽然 Service Fabric 允许任何类型的应用程序实现高可用性，但 Kubernetes、DC/OS 和 Swarm 等协调器特定于容器。同时，需要理解的是，这些平台提供的功能有助于进行滚动更新，而不是可能影响应用程序可用性的整体更新。

当我们讨论虚拟机的高可用性时，我们简要介绍了负载均衡的概念。让我们进一步深入了解，以便更好地理解它在 Azure 中是如何工作的。

Azure 中的负载均衡器

Azure 提供了两种具有负载均衡器功能的资源。它提供了一个 4 层负载均衡器，在 TCP OSI 协议栈的传输层工作；以及一个 7 层负载均衡器（应用程序网关），它在应用层和会话层工作。

虽然应用程序网关和负载均衡器都提供负载均衡的基本功能，但它们的用途不同。在许多使用场景中，部署应用程序网关比负载均衡器更合适。

应用程序网关提供以下 Azure 负载均衡器所不具备的功能：

• Web 应用防火墙：这是操作系统防火墙之上的一个附加防火墙，它能深入查看传入的消息。这有助于识别和防止常见的基于 Web 的攻击，如 SQL 注入、跨站脚本攻击和会话劫持。

• 基于 Cookie 的会话保持：负载均衡器将传入流量分配给健康且相对空闲的服务实例。一个请求可以由任何服务实例处理。然而，一些应用程序需要更高级的功能，要求所有后续请求都由同一服务实例处理。这被称为基于 Cookie 的会话保持。应用程序网关通过使用 Cookie 提供基于 Cookie 的会话保持，从而将用户会话保持在同一服务实例上。

• 安全套接字层（SSL）卸载：请求和响应数据的加密与解密由 SSL 执行，这通常是一个昂贵的操作。Web 服务器理应将其资源用于处理和响应请求，而不是加密和解密流量。SSL 卸载有助于将这一加密过程从 Web 服务器转移到负载均衡器，从而为处理用户请求的 Web 服务器提供更多资源。用户的请求经过加密后，在应用程序网关处解密，而不是在 Web 服务器处解密。来自应用程序网关到 Web 服务器的请求则保持未加密。

• 端到端 SSL：虽然 SSL 卸载是某些应用程序的一个不错功能，但有些关键任务的安全应用程序仍然需要完全的 SSL 加密和解密，即使流量经过负载均衡器。应用程序网关也可以配置为进行端到端 SSL 加密。

• 基于 URL 的内容路由：应用程序网关对于根据传入请求的 URL 内容将流量重定向到不同的服务器也很有用。这有助于在托管多个服务和其他应用程序时进行流量管理。

Azure 负载均衡器

Azure 负载均衡器根据可用的传输层信息分配传入的流量。它依赖于以下特性：

• 源 IP 地址

• 目标 IP 地址

• 源端口号

• 目标端口号

• 一种协议类型——TCP 或 HTTP

Azure 负载均衡器可以是私有负载均衡器或公共负载均衡器。私有负载均衡器可用于在内部网络中分配流量。由于这是内部使用，因此不会分配公共 IP 地址，并且不能通过互联网访问。公共负载均衡器具有附加的外部公共 IP 地址，可以通过互联网访问。在图 2.4中，您可以看到如何将内部（私有）和公共负载均衡器集成到一个解决方案中，分别处理内部和外部流量：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_04.jpg

图 2.4：使用 Azure 负载均衡器分配流量

在图 2.4中，您可以看到外部用户通过公共负载均衡器访问虚拟机（VM），然后来自虚拟机的流量通过内部负载均衡器分配到另一组虚拟机。

我们已经对 Azure 负载均衡器与应用程序网关的区别进行了比较。在下一节中，我们将更详细地讨论应用程序网关。

Azure 应用程序网关

Azure 负载均衡器帮助我们在基础设施层面启用解决方案。然而，有时使用负载均衡器需要高级服务和功能。这些高级服务包括 SSL 终止、粘性会话、高级安全性等。Azure 应用程序网关提供了这些附加功能；Azure 应用程序网关是一个第七层负载均衡器，能够处理应用程序和会话负载，在 TCP OSI 堆栈中运行。

与 Azure 负载均衡器相比，应用程序网关拥有更多的信息，用于在服务器之间做出请求路由和负载均衡的决策。应用程序网关由 Azure 管理，并具有高可用性。

如图 2.5所示，应用程序网关位于用户和虚拟机之间：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_05.jpg

图 2.5：Azure 应用程序网关

应用程序网关是一种托管服务。它们使用应用程序请求路由（ARR）将请求路由到不同的服务和端点。创建应用程序网关需要一个私有或公共 IP 地址。然后，应用程序网关将 HTTP/HTTPS 流量路由到配置的端点。

从配置的角度来看，应用程序网关与 Azure 负载均衡器相似，但具有额外的结构和功能。应用程序网关可以配置前端 IP 地址、证书、端口配置、后端池、会话亲和性和协议信息。

我们在讨论虚拟机高可用性时提到了另一个服务——Azure 流量管理器。让我们在下一节中进一步了解该服务。

Azure 流量管理器

在充分了解 Azure 负载均衡器和应用程序网关之后，是时候深入了解 Traffic Manager 了。Azure 负载均衡器和应用程序网关是数据中心或区域内高可用性所需的资源；然而，要实现跨区域和跨数据中心的高可用性，还需要另一种资源，而 Traffic Manager 就在这方面为我们提供了帮助。

Traffic Manager 帮助我们创建跨多个地理位置、区域和数据中心的高可用解决方案。Traffic Manager 不同于负载均衡器。它使用域名服务（DNS）将请求重定向到由端点的健康状况和配置决定的适当端点。Traffic Manager 不是代理或网关，它无法看到客户端与服务之间传递的流量。它仅根据最合适的端点重定向请求。

Azure Traffic Manager 有助于控制分配到应用程序端点的流量。端点可以被定义为任何面向互联网的服务，无论是在 Azure 内部还是外部托管。

端点是面向互联网的、可访问的公共 URL。应用程序被部署在多个地理位置和 Azure 区域。部署到每个区域的应用程序有一个唯一的端点，通过.trafficmanager.net的 URL 扩展来引用。

当请求到达 Traffic Manager 的 URL 时，它会在列表中找到最合适的端点，并将请求重定向到该端点。简而言之，Azure Traffic Manager 充当全球 DNS 来识别将处理请求的区域。

然而，Traffic Manager 如何知道使用哪些端点并将客户端请求重定向到它们呢？Traffic Manager 考虑两个方面来确定最合适的端点和区域。

首先，Traffic Manager 会积极监控所有端点的健康状况。它可以监控虚拟机、云服务和应用服务的健康状况。如果它确定部署在某个区域的应用程序健康状况不适合重定向流量，它会将请求重定向到健康的端点。

其次，Traffic Manager 可以配置路由信息。Traffic Manager 提供了六种流量路由方法，具体如下：

• 优先级：当所有流量应发送到默认端点，并且当主端点不可用时需要备份端点时，应使用此选项。

• 加权：当需要在端点之间均匀分配流量，或根据定义的权重分配流量时，应使用此选项。

• 性能：当端点位于不同区域时，应使用此选项，并根据用户的位置将其重定向到最接近的端点。这直接影响网络延迟。

• 地理：这应当用于根据最近的地理位置将用户重定向到一个端点（Azure、外部或嵌套）。这有助于遵守与数据保护、地域化和基于区域的流量收集相关的合规要求。

• 子网：这是一种新的路由方法，帮助根据客户端的 IP 地址提供不同的端点。在此方法中，每个端点会分配一系列 IP 地址。这些 IP 地址范围与客户端的 IP 地址映射，以确定合适的返回端点。通过这种路由方法，可以根据用户的源 IP 地址向不同的人提供不同的内容。

• 多值：这也是 Azure 中新增的一种方法。在这种方法中，多个端点会返回给客户端，客户端可以使用其中任何一个端点。这确保了如果一个端点不可用，其他端点可以作为替代使用，从而提升了解决方案的整体可用性。

需要注意的是，在流量管理器确定有效且健康的端点后，客户端将直接连接到应用程序。接下来，让我们继续了解 Azure 在全球范围内路由用户请求的能力。

在接下来的部分，我们将讨论另一项服务，叫做 Azure Front Door。该服务类似于 Azure 应用程序网关；然而，它有一个小的区别，使得该服务与众不同。让我们继续深入了解 Azure Front Door。

Azure Front Door

Azure Front Door 是 Azure 提供的最新服务，它帮助将请求路由到全球服务，而不是像 Azure 应用程序网关和负载均衡器那样将请求路由到本地区域或数据中心级别。Azure Front Door 类似于应用程序网关，不同之处在于它的范围。它是一个第七层负载均衡器，帮助将请求路由到在多个区域中部署的最近的、性能最优的服务端点。它提供诸如 TLS 终止、会话亲和性、基于 URL 的路由和多站点托管等功能，并带有 Web 应用防火墙。它与流量管理器相似，默认情况下对整个区域的故障具有弹性，并提供路由能力。它还定期进行端点健康探测，确保请求仅路由到健康的端点。

它提供了四种不同的路由方法：

• 延迟：请求将路由到具有最小端到端延迟的端点。

• 优先级：请求将路由到主端点，如果主端点失败，则路由到备用端点。

• 加权：请求将根据分配给端点的权重进行路由。

• 会话亲和性：会话中的请求将始终指向相同的端点，以便利用先前请求的会话数据。原始请求可以指向任何可用的端点。

寻求全球级别弹性的部署应在其架构中包括 Azure Front Door，并结合应用程序网关和负载均衡器。在接下来的章节中，你将看到在设计高可用解决方案时应考虑的一些架构要点。

高可用性的架构考虑因素

Azure 通过多种方式和不同级别提供高可用性。高可用性可以在数据中心级别、区域级别，甚至跨 Azure 实现。在本节中，我们将介绍一些高可用性的架构。

Azure 区域内的高可用性

如图 2.6所示，该架构展示了在单一 Azure 区域内的高可用性部署。高可用性在单个资源级别进行设计。在该架构中，每一层都有多个虚拟机（VM），这些虚拟机通过应用程序网关或负载均衡器连接，并且它们都属于一个可用性集。每一层都与一个可用性集关联。这些虚拟机被放置在不同的故障和更新域上。虽然 Web 服务器连接到应用程序网关，但其他层次（如应用程序层和数据库层）使用内部负载均衡器：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_06.jpg

图 2.6：在一个区域内设计高可用性

现在你已经知道如何在同一区域内设计高度可用的解决方案，接下来我们来讨论如何设计一个类似的架构，且跨多个 Azure 区域进行部署。

跨 Azure 区域的高可用性

该架构展示了在两个不同 Azure 区域中的类似部署。如图 2.7所示，两个区域都部署了相同的资源。高可用性在这些区域内的单个资源级别进行设计。每一层都有多个虚拟机，虚拟机通过负载均衡器连接，并且它们属于一个可用性集。这些虚拟机被放置在不同的故障和更新域上。Web 服务器连接到外部负载均衡器，而其他层次（如应用程序层和数据库层）则使用内部负载均衡器。需要注意的是，如果需要高级服务（如会话保持、SSL 终止、使用Web 应用防火墙（WAF）的高级安全性以及基于路径的路由），则可以使用应用程序负载均衡器来替代 Azure 负载均衡器，部署在 Web 服务器和应用程序层。两个区域中的数据库通过虚拟网络对等连接和网关互相连接。这对于配置日志传输、SQL Server Always On 和其他数据同步技术非常有用。

来自两个区域的负载均衡器端点用于配置流量管理器端点，流量根据优先级负载均衡方法进行路由。流量管理器帮助将所有请求路由到东美国区域，在故障转移的情况下，如果第一个区域不可用，则路由到西欧区域：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_07.jpg

图 2.7：跨 Azure 区域设计高可用性

在接下来的部分中，我们将探讨可扩展性，这是云计算的另一个优势。

可扩展性

运行对用户开放的应用程序和系统对于任何业务关键应用程序的架构师来说都非常重要。然而，另一个同样重要的应用程序特性，也是架构师的首要任务之一，就是应用程序的可扩展性。

想象一种情况，应用程序已经部署，并且在少量用户下能够获得良好的性能和可用性，但随着用户数量的增加，可用性和性能都会下降。应用程序在正常负载下表现良好，但在用户数量增加时性能下降。这可能发生在用户数量突然增加且环境未针对如此大量用户进行构建时。

为了应对用户数量的激增，您可能会为应对高峰期配置硬件和带宽。问题在于，额外的容量在大部分年份都未被使用，因此无法提供投资回报。它仅为假期或促销期间使用。我希望到现在为止，您已经开始熟悉架构师正在努力解决的问题。所有这些问题都与容量配置和应用程序的可扩展性相关。本章的重点是将可扩展性视为架构上的一个问题，并了解 Azure 提供的用于实现可扩展性的服务。

容量规划和资源配置是架构师及其应用程序和服务的几个首要任务。架构师必须在购买和配置过多资源与购买和配置过少资源之间找到平衡。资源过少会导致无法满足所有用户需求，从而导致他们转向竞争对手。另一方面，资源过多则会损害预算和投资回报率，因为大多数资源大部分时间处于未使用状态。此外，问题会因需求水平在不同时间的波动而加剧。几乎不可能预测一天内的应用用户数，更别说一年的用户数了。然而，通过过去的信息和持续的监控，找到一个大致的数字是可能的。

可扩展性指的是处理日益增长的用户数量，并为他们提供与较少用户时相同水平的性能，即使在应用程序部署、进程和技术使用资源时。可扩展性可能意味着在性能不下降的情况下处理更多请求，或者意味着处理更大、更耗时的工作而不损失性能，在这两种情况下都是如此。

容量规划和大小调整练习应由架构师在项目初期和规划阶段进行，以便为应用程序提供可扩展性。

一些应用程序具有稳定的需求模式，而另一些应用程序则难以预测需求。对于稳定需求的应用程序，可扩展性要求是已知的，而对于需求变化较大的应用程序，识别其需求可能是一个更复杂的过程。自动扩展是我们在下一节将要讨论的概念，应该应用于那些无法预测需求的应用程序。

人们常常把可扩展性和性能混为一谈。在接下来的章节中，你将看到这两个术语的简要对比。

可扩展性与性能

在架构问题上，很多人容易将可扩展性与性能混淆，因为可扩展性完全是为了确保无论有多少用户使用应用程序，所有用户都能获得预定的性能水平。

性能与确保应用程序满足预定义的响应时间和吞吐量相关。可扩展性指的是在需要时提供更多资源，以容纳更多用户而不牺牲性能。

通过类比来理解这一点会更好：火车的速度与铁路网络的性能直接相关。然而，增加更多的火车以平行运行在相同或更高的速度下，代表着铁路网络的可扩展性。

现在你已经知道了可扩展性与性能之间的区别，接下来我们来讨论 Azure 如何提供可扩展性。

Azure 可扩展性

在这一节中，我们将探讨 Azure 提供的功能和能力，以使应用程序具备高可用性。在深入了解架构和配置细节之前，理解 Azure 的高可用性概念，即可扩展性，是非常重要的。

扩展指的是增加或减少用于处理用户请求的资源量。扩展可以是自动的，也可以是手动的。手动扩展需要管理员手动启动扩展过程，而自动扩展指的是根据环境和生态系统中可用的事件（如内存和 CPU 可用性）自动增加或减少资源。资源可以向上或向下扩展，也可以向外或向内扩展，这将在本节后面解释。

除了滚动更新，Azure 提供的实现高可用性的基本构造如下：

• 扩展上下调节

• 向外扩展与向内收缩

• 自动伸缩

向上扩展

对虚拟机或服务进行向上扩展意味着向现有服务器添加更多资源，如 CPU、内存和磁盘。其目的是增加现有物理硬件和资源的容量。

向下扩展

对虚拟机或服务进行向下扩展意味着从现有服务器中移除资源，如 CPU、内存和磁盘。其目的是减少现有物理和虚拟硬件及资源的容量。

向外扩展

向外扩展意味着添加更多硬件，如额外的服务器和容量。这通常包括新增服务器、分配 IP 地址、在其上部署应用程序，并将其纳入现有的负载均衡器，以便流量可以路由到这些服务器。向外扩展既可以是自动的，也可以是手动的。然而，为了获得更好的效果，应该使用自动化：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_08.jpg

图 2.8：向外扩展

向内扩展

向内扩展指的是移除现有硬件的过程，具体来说就是现有的服务器和容量。这通常包括移除现有服务器，取消分配它们的 IP 地址，并将它们从现有的负载均衡器配置中移除，以确保流量不能路由到它们。像向外扩展一样，向内扩展也可以是自动的或手动的。

自动伸缩

自动伸缩指的是根据应用程序需求动态地进行向上/向下或向外/向内扩展的过程，并且这一过程是通过自动化实现的。自动伸缩非常有用，因为它确保部署始终由理想数量的服务器实例组成。自动伸缩有助于构建具有容错性的应用程序。它不仅支持可伸缩性，还使应用程序具有高可用性。最后，它提供了最佳的成本管理。自动伸缩使得根据需求配置服务器实例的最优配置成为可能。它帮助避免过度配置服务器，以免服务器最终被闲置，并且能够在向外扩展后移除不再需要的服务器。

到目前为止，我们已经讨论了 Azure 中的可伸缩性。Azure 为其大多数服务提供了可伸缩性选项。接下来，我们将探索 Azure 中 PaaS 的可伸缩性。

PaaS 可伸缩性

Azure 提供了 App Service 来托管托管应用程序。App Service 是 Azure 的 PaaS 服务。它为 Web 和移动平台提供服务。在这些 Web 和移动平台背后，有一套由 Azure 代表用户管理的托管基础设施。用户无需查看或管理任何基础设施；然而，他们可以扩展平台并在其上部署应用程序。通过这种方式，架构师和开发人员可以专注于他们的业务问题，而无需担心基础平台和基础设施的配置、部署和故障排除。开发人员可以灵活选择任何语言、操作系统和框架来开发应用程序。App Service 提供了多个计划，用户可以根据选择的计划享受不同程度的可扩展性。App Service 提供以下五种计划：

• 免费：此计划使用共享基础设施。这意味着多个应用程序将部署在相同的基础设施上，可以是来自同一租户或多个租户。它提供 1 GB 的免费存储。然而，此计划不支持扩展功能。

• 共享：此计划也使用共享基础设施，并提供 1 GB 的免费存储。此外，还提供定制域名作为额外功能。然而，此计划不支持扩展功能。

• 基础：该计划有三个不同的库存单位（SKU）：B1、B2 和 B3。它们在 CPU 和内存方面有逐渐增加的资源配置。简而言之，它们提供了更好的虚拟机配置，以支持这些服务。此外，还提供存储、定制域名和 SSL 支持。基础计划提供了手动扩展的基本功能。此计划不支持自动扩展。最多可以使用三个实例来扩展应用程序。

• 标准：该计划也有三个不同的 SKU：S1、S2 和 S3。它们在 CPU 和内存方面有逐渐增加的资源配置。简而言之，它们提供了更好的虚拟机配置，以支持这些服务。此外，它们还提供类似基础计划的存储、定制域名和 SSL 支持。该计划还提供一个 Traffic Manager 实例、预发布插槽和每天一次的备份，作为基础计划的额外功能。标准计划提供了自动扩展功能。最多可以使用 10 个实例来扩展应用程序。

• 高级：这也有三个不同的 SKU：P1、P2 和 P3。它们分别提供更多的 CPU 和内存资源。简而言之，它们提供了更好的虚拟机配置，支撑这些服务。此外，它们还提供与基础计划类似的存储、自定义域和 SSL 支持。该计划还提供了一个流量管理器实例、暂存槽和 50 个每日备份，作为基础计划的附加功能。标准计划提供自动扩展功能。最多可以使用 20 个实例来扩展应用。

我们已经探讨了 PaaS 服务的可扩展性层级。现在，让我们来看一下如何在应用服务计划中进行扩展。

PaaS – 扩展和缩减

托管在应用服务中的服务的扩展和缩减是非常简单的。Azure 应用服务的“扩展”菜单会打开一个新面板，列出所有计划和它们的 SKU。选择一个计划和 SKU 将会扩展或缩减服务，如图 2.9所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_09.jpg

图 2.9：不同计划及其 SKU

PaaS – 扩展和缩减

在应用服务中扩展和缩减服务也非常简单。Azure 应用服务的“扩展”菜单项会打开一个新面板，提供扩展配置选项。

默认情况下，自动扩展对高级和标准计划是禁用的。可以通过扩展菜单项并点击启用自动扩展按钮来启用，如图 2.10所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_10.jpg

图 2.10：启用自动扩展选项

手动扩展不需要配置，但自动扩展有助于通过以下属性进行配置：

• 扩展模式：基于性能指标，如 CPU 或内存使用情况，或者用户可以简单指定要扩展的实例数量。

• 何时扩展：可以添加多个规则来确定何时扩展和缩减。每个规则可以确定诸如 CPU 或内存消耗、是否增加或减少实例数量，以及每次增加或减少多少实例等标准。至少应该配置一个扩展规则和一个缩减规则。阈值定义有助于定义触发自动扩展的上限和下限——通过增加或减少实例数量来实现。

• 如何扩展：这指定了在每次扩展或缩减操作中要创建或移除多少个实例：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_11.jpg

图 2.11：设置实例限制

这是在任何部署中都非常好的功能。然而，您应该同时启用扩展和缩减，以确保在扩展后环境能够恢复到正常容量。

由于我们已经覆盖了 PaaS 的可扩展性，现在让我们继续讨论 IaaS 的可扩展性。

IaaS 可扩展性

有些用户希望对其基础架构、平台和应用程序拥有完全的控制权。他们更倾向于使用 IaaS 解决方案，而非 PaaS 解决方案。当这类客户创建虚拟机时，他们还需要负责容量规划和扩展。对于虚拟机的手动扩展或自动扩展，Azure 并没有现成的配置。这些客户需要编写自己的自动化脚本、触发器和规则来实现自动扩展。使用虚拟机也意味着需要负责维护它们。虚拟机的补丁管理、更新和升级由所有者负责。架构师应考虑计划内和计划外的维护。必须考虑虚拟机如何打补丁、顺序、分组以及其他因素，以确保不会影响应用程序的可扩展性和可用性。为了解决这些问题，Azure 提供了 虚拟机规模集（VMSS）作为解决方案，我们接下来会讨论这一点。

虚拟机规模集

VMSS 是 Azure 计算资源，您可以用它来部署和管理一组相同的虚拟机。所有虚拟机都以相同的方式配置，规模集旨在支持真正的自动扩展，并且不需要预先配置虚拟机。它有助于配置多个通过虚拟网络和子网互联的相同虚拟机。

VMSS（虚拟机规模集）由多个虚拟机组成，但它们是在 VMSS 层级上进行管理的。所有虚拟机都是该单元的一部分，任何所做的更改都会应用于该单元，从而通过预定算法应用于正在使用这些虚拟机的 VM：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_12.jpg

图 2.12：一个虚拟机规模集

这使得这些虚拟机能够使用 Azure 负载均衡器或应用程序网关进行负载均衡。虚拟机可以是 Windows 或 Linux 虚拟机。它们可以使用 PowerShell 扩展运行自动化脚本，并可以通过状态配置进行集中管理。它们可以作为一个单元进行监控，或通过日志分析分别进行监控。

VMSS 可以通过 Azure 门户、Azure CLI、Azure 资源管理器模板、REST API 和 PowerShell cmdlet 进行配置。可以从任何平台、环境或操作系统以及任何语言中调用 REST API 和 Azure CLI。

许多 Azure 服务已经将 VMSS 用作其底层架构。包括 Azure Batch、Azure Service Fabric 和 Azure 容器服务。Azure 容器服务又在这些 VMSS 上部署 Kubernetes 和 DC/OS。

VMSS 架构

当使用平台镜像时，VMSS 最多允许在一个规模集内创建 1,000 个虚拟机，使用自定义镜像时则为 100 个虚拟机。如果规模集中的虚拟机数量少于 100 个，它们将被放置在一个可用性集中；如果虚拟机数量大于 100 个，则会创建多个可用性集（称为放置组），并将虚拟机分布在这些可用性集中。我们从第一章，开始使用 Azure中了解到，可用性集中的虚拟机会被放置在不同的故障域和更新域中。与 VMSS 相关的可用性集默认有五个故障域和更新域。VMSS 提供了一个模型，用于保存整个集的元数据。更改此模型并应用更改会影响所有虚拟机实例。此信息包括虚拟机实例的最大和最小数量、操作系统 SKU 和版本、当前虚拟机数量、故障域和更新域等。这在图 2.13中有演示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_13.jpg

图 2.13：可用性集中的虚拟机

VMSS 缩放

缩放是指增加或减少计算和存储资源。VMSS 是一个功能丰富的资源，使缩放变得简单高效。它提供自动缩放功能，帮助基于外部事件和数据（如 CPU 和内存使用率）进行向上或向下的缩放。以下是 VMSS 缩放的一些功能。

横向与纵向缩放

缩放可以是横向或纵向的，或者两者兼有。横向缩放是扩展和收缩的另一种说法，而纵向缩放则指的是向上或向下缩放。

容量

VMSS 具有一个capacity属性，用于确定规模集中的虚拟机数量。可以将capacity属性设置为零来部署 VMSS，这样不会创建任何虚拟机；然而，如果为capacity属性提供一个数字，则会创建相应数量的虚拟机。

自动缩放

VMSS 中的虚拟机自动缩放是指根据配置的环境增加或移除虚拟机实例，以满足应用程序的性能和可扩展性需求。通常，在没有 VMSS 的情况下，这通过自动化脚本和运行手册来实现。

VMSS 通过支持配置帮助实现这一自动化过程。与其编写脚本，不如配置 VMSS 进行自动向上或向下缩放。

自动缩放使用多个集成组件来实现其最终目标。自动缩放涉及持续监控虚拟机并收集其遥测数据。这些数据被存储、合并，然后根据一组规则进行评估，以确定是否触发自动缩放。触发条件可能是扩展或收缩，也可能是向上或向下缩放。

自动缩放机制使用诊断日志收集来自虚拟机的遥测数据。这些日志作为诊断指标存储在存储帐户中。自动缩放机制还使用应用程序洞察监控服务，读取这些指标，将它们组合在一起并存储在存储帐户中。

背景自动缩放任务会持续运行，读取应用程序洞察存储数据，基于配置的所有自动缩放规则进行评估，并且，如果满足任何规则或规则组合，执行自动缩放过程。规则可以考虑来自来宾虚拟机和主机服务器的指标。

使用属性描述定义的规则可以在 docs.microsoft.com/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-autoscale-overview 获取。

VMSS 自动缩放架构如 图 2.14 所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_14.jpg

图 2.14：VMSS 自动缩放架构

自动缩放可以为比环境中一般可用指标更复杂的场景进行配置。例如，缩放可以基于以下任一项：

• 特定日期

• 循环的时间表，例如周末

• 工作日与周末的对比

• 假期和一次性事件

• 多个资源指标

这些可以使用应用程序洞察资源的 schedule 属性进行配置，帮助注册规则。

建筑师应确保至少配置两种操作——扩展和缩减。仅仅扩展或缩减配置无法实现 VMSS 提供的扩展优势。

总结来说，我们已经涵盖了 Azure 中的可扩展性选项，以及 IaaS 和 PaaS 的详细缩放功能，以满足您的业务需求。如果您记得共享责任模型，您会记得平台升级和维护应由云提供商负责。在这种情况下，微软负责平台相关的升级和维护。让我们在下一部分中看看这是如何实现的。

升级和维护

在部署 VMSS 和应用程序后，它们需要进行积极的维护。应定期进行计划性维护，确保从安全性和韧性角度来看，环境和应用程序都能更新到最新功能。

升级可以与应用程序、来宾虚拟机实例或镜像本身关联。升级可能相当复杂，因为它们应该在不影响环境和应用程序的可用性、可扩展性和性能的情况下进行。为了确保更新可以通过滚动升级方法逐个实例进行，VMSS 必须支持并提供这些高级场景所需的功能。

Azure 团队提供了一个用于管理 VMSS 更新的工具。这是一个基于 Python 的工具，可以从 github.com/gbowerman/vmssdashboard 下载。它通过 REST API 调用 Azure 来管理扩展集。这个工具可以用来启动、停止、升级和重新镜像在故障域（FD）或虚拟机组中的虚拟机，如 图 2.15 所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_15.jpg

图 2.15：用于管理 VMSS 更新的工具

既然你已经对升级和维护有了基本的了解，那么我们来看看应用程序更新是如何在 VMSS 中进行的。

应用程序更新

VMSS 中的应用程序更新不应手动执行。它们必须作为发布管理和自动化管道的一部分运行。此外，更新应该一次处理一个应用程序实例，且不应影响应用程序的整体可用性和可扩展性。应部署配置管理工具，如 期望状态配置 (DSC)，来管理应用程序更新。DSC 拉取服务器可以配置为包含最新版本的应用程序配置，并应以滚动方式应用到每个实例。

在下一节中，我们将重点介绍如何在客户操作系统上进行更新。

客户更新

虚拟机的更新由管理员负责。Azure 不负责修补客户虚拟机。客户更新目前处于预览模式，用户应手动控制修补或使用自定义自动化方法，如运行簿和脚本。然而，滚动补丁升级也处于预览模式，并且可以通过升级策略在 Azure 资源管理器模板中进行配置，如下所示：

"upgradePolicy": {"mode": "Rolling","automaticOSUpgrade": "true" or "false",  "rollingUpgradePolicy": {    "batchInstancePercent": 20,    "maxUnhealthyUpgradedInstanceCount": 0,    "pauseTimeBetweenBatches": "PT0S"  }}

现在我们已经了解了 Azure 如何管理客户更新，接下来看看镜像更新是如何完成的。

镜像更新

VMSS 可以在没有任何停机的情况下更新操作系统版本。操作系统更新涉及更改操作系统的版本或 SKU，或更改自定义镜像的 URI。无停机更新意味着一次更新一个虚拟机或一组虚拟机（例如，一次更新一个故障域），而不是一次性更新所有虚拟机。通过这种方式，未被升级的虚拟机可以继续运行。

到目前为止，我们讨论了更新和维护。现在让我们来看看 VMSS 的扩展最佳实践是什么。

VMSS 扩展的最佳实践

在本节中，我们将介绍一些应用程序应当实施的最佳实践，以便充分利用 VMSS 提供的扩展能力。

偏好扩展操作

扩展横向（Scaling out）是比纵向扩展（Scaling up）更好的扩展方案。纵向扩展或缩减意味着调整虚拟机实例的大小。当虚拟机调整大小时，通常需要重新启动，这有其自身的缺点。首先，机器会有停机时间。其次，如果有活动用户连接到该实例上的应用程序，他们可能会面临应用程序不可用，甚至可能丧失事务。扩展横向不会影响现有虚拟机，而是配置新的机器并将其添加到组中。

新实例与休眠实例

扩展新实例可以采取两种广泛的方法：从头开始创建新实例，这需要安装应用程序、配置和测试它们；或者在由于其他服务器的可扩展性压力而需要时启动休眠的实例。

适当配置最大和最小实例数量

如果将最小实例数和最大实例数都设置为 2，且当前实例数为 2，则无法进行扩展操作。最大实例数和最小实例数之间应有足够的差距，这两个值是包含在内的。自动扩展总是在这些限制之间进行。

并发

应用程序应该设计为专注于并发以实现可扩展性。应用程序应使用异步模式，确保当资源忙于处理其他请求时，客户端请求不会无限期等待获取资源。在代码中实现异步模式可以确保线程不会因等待资源而阻塞，从而避免系统耗尽所有可用线程。如果预期有间歇性的故障，应用程序应该实现超时概念。

设计无状态应用程序

应用程序和服务应该设计为无状态的。具有状态的服务可能会导致可扩展性成为挑战，而无状态服务则容易扩展。有状态就意味着需要额外的组件和实现，例如复制、集中式或分布式存储库、维护和粘性会话。所有这些都是可扩展性道路上的障碍。试想一个服务在本地服务器上维护一个活动状态。无论整体应用程序或单个服务器上的请求数量如何，后续请求必须由相同的服务器处理，其他服务器无法处理这些请求。这使得可扩展性的实现变得具有挑战性。

缓存和内容分发网络（CDN）

应用程序和服务应利用缓存技术。缓存有助于消除多次对数据库或文件系统的后续调用。这有助于使资源可用并为空间腾出更多请求。CDN 是另一种用于缓存静态文件（如图片和 JavaScript 库）的机制。这些文件在全球范围内的服务器上可用，也使资源可用并为空间腾出更多客户端请求——这使得应用程序具有高度可扩展性。

N+1 设计

N+1 设计 指的是在每个组件的整体部署中构建冗余。这意味着即使在没有要求的情况下，也要规划一定的冗余。这可能意味着额外的虚拟机、存储和网络接口。

在设计使用 VMSS 的工作负载时，考虑上述最佳实践将提高应用程序的可扩展性。在下一部分中，我们将探讨监控。

监控

监控是一个重要的架构问题，应该是任何解决方案的一部分，无论是大型还是小型、关键任务还是非关键任务、基于云的还是非基于云的——它不应被忽视。

监控指的是跟踪解决方案并捕获各种遥测信息的过程，处理这些信息，基于规则识别符合警报条件的信息，并触发警报。通常，环境中会部署一个代理进行监控，收集遥测信息并发送到集中服务器，在那里进行警报生成和通知相关人员的处理。

监控采取了主动和被动的措施来应对解决方案的挑战。它也是审计解决方案的第一步。如果没有监控日志记录的能力，从多个角度（如安全性、性能和可用性）审计系统是困难的。

监控有助于我们在问题发生之前识别可用性、性能和可扩展性问题。硬件故障、软件配置错误和补丁更新问题可以在影响用户之前通过监控发现，性能下降也可以在发生前得到修复。

被动监控通过日志记录标出导致问题的特定区域和位置，识别问题并加速修复过程。

团队可以通过监控遥测信息识别问题的模式，并通过创新新的解决方案和功能来消除它们。

Azure 是一个丰富的云环境，提供了多种丰富的监控功能和资源，不仅可以监控基于云的部署，还可以监控本地部署。

Azure 监控

首要问题是，“我们必须监控什么？” 对于部署在云上的解决方案来说，这个问题变得更加重要，因为我们对其控制有限。

有一些重要的组件需要被监控。它们包括以下内容：

• 自定义应用程序

• Azure 资源

• 客户操作系统（虚拟机）

• 主机操作系统（Azure 物理服务器）

• Azure 基础设施

针对这些组件，Azure 提供了不同的日志记录和监控服务，以下章节将讨论这些服务。

Azure 活动日志

以前被称为审计日志和操作日志，活动日志是 Azure 平台上的控制平面事件。它们提供了在订阅级别而非单个资源级别的信息和遥测数据。活动日志跟踪在订阅级别发生的所有更改的信息，例如使用Azure 资源管理器（ARM）创建、删除和更新资源。活动日志帮助我们发现资源的身份（如服务主体、用户或组），以及执行对资源的操作（如写入或更新）（例如，存储、虚拟机或 SQL 数据库）。它们提供有关资源的配置信息变更，而不是资源的内部工作和执行。例如，您可以查看启动虚拟机、调整虚拟机大小或停止虚拟机的日志。

接下来我们要讨论的主题是诊断日志。

Azure 诊断日志

来源于 Azure 资源内部工作的信息被记录在所谓的诊断日志中。它们提供关于资源操作的遥测信息，这些操作是资源固有的。并不是所有资源都提供诊断日志，而且提供自己内容日志的资源与其他资源完全不同。诊断日志是为每个资源单独配置的。诊断日志的示例包括在存储帐户中的容器中存储文件。

接下来我们将讨论的日志类型是应用程序日志。

Azure 应用程序日志

应用程序日志可以通过应用程序洞察资源捕获，并且可以集中管理。它们获取自定义应用程序的内部工作信息，如性能指标和可用性，用户可以从中获得见解，以便更好地管理它们。

最后，我们将讨论来宾操作系统和主机操作系统日志。让我们理解一下它们是什么。

来宾操作系统和主机操作系统日志

使用 Azure Monitor，用户可以获得来宾操作系统和主机操作系统的日志。这些日志提供了主机和来宾操作系统的状态信息：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_16.jpg

图 2.16：Azure 中的日志记录

重要的 Azure 监控相关资源包括 Azure Monitor、Azure Application Insights 和 Log Analytics，后者以前称为操作洞察。

还有一些工具，如系统中心操作管理器（SCOM），它们不是云功能的一部分，但可以部署在基于 IaaS 的虚拟机上，监控 Azure 或本地数据中心中的任何工作负载。让我们在接下来的章节中讨论三种监控资源。

Azure Monitor

Azure Monitor 是一个核心工具和资源，提供完整的管理功能，使你能够监控 Azure 订阅。它为活动日志、诊断日志、指标、Application Insights 和 Log Analytics 提供管理功能。应将其视为所有其他监控功能的仪表板和管理资源。

我们的下一个主题是 Azure Application Insights。

Azure Application Insights

Azure Application Insights 提供集中式的 Azure 规模监控、日志和指标功能，供自定义应用程序使用。自定义应用程序可以将指标、日志和其他遥测信息发送到 Azure Application Insights。它还提供丰富的报告、仪表板和分析功能，帮助从传入数据中获取洞察并采取行动。

现在我们已经讨论了 Application Insights，让我们来看看另一个类似的服务——Azure Log Analytics。

Azure Log Analytics

Azure Log Analytics 使日志的集中处理成为可能，并从中生成洞察和警报。活动日志、诊断日志、应用程序日志、事件日志，甚至自定义日志都可以将信息发送到 Log Analytics，后者可以进一步提供丰富的报告、仪表板和分析功能，帮助从传入数据中获取洞察并采取行动。

现在我们已经了解了 Log Analytics 的目的，让我们讨论一下日志是如何存储在 Log Analytics 工作区中的，以及如何查询这些日志。

日志

Log Analytics 工作区提供搜索功能，可以搜索特定的日志条目，将所有遥测数据导出到 Excel 和/或 Power BI，并搜索一种名为 Kusto 查询语言（KQL）的查询语言，该语言与 SQL 类似。

日志搜索 屏幕如下所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_17.jpg

图 2.17：Log Analytics 工作区中的日志搜索

在下一节中，我们将讨论 Log Analytics 解决方案，它们就像是 Log Analytics 工作区中的附加功能。

解决方案

Log Analytics 中的解决方案是可以添加到工作区的附加功能，用于捕获默认情况下未捕获的其他遥测数据。当这些解决方案添加到工作区时，适当的管理包会发送到连接到该工作区的所有代理，以便它们可以自我配置，从虚拟机和容器捕获特定于解决方案的数据，并将其发送到 Log Analytics 工作区。来自 Microsoft 和合作伙伴的监控解决方案可以通过 Azure Marketplace 获取。

Azure 提供了许多 Log Analytics 解决方案，用于跟踪和监控环境和应用程序的不同方面。至少应该向工作区添加一组通用的解决方案，适用于几乎所有环境：

• 容量与性能

• 代理健康

• 变更跟踪

• 容器

• 安全与审计

• 更新管理

• 网络性能监控

监控的另一个关键方面是警报。警报有助于在任何监控事件发生时通知相关人员。接下来的部分，我们将介绍警报的相关内容。

警报

Log Analytics 允许我们生成与摄取数据相关的警报。它通过运行一个预定义的查询来做到这一点，查询由对输入数据的条件组成。如果查询结果中有任何记录符合条件，它就会生成一个警报。Log Analytics 提供了一个高度可配置的环境，用于确定生成警报的条件、查询应返回记录的时间窗口、查询应执行的时间窗口以及当查询返回警报时采取的行动：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_18.jpg

图 2.18：通过 Log Analytics 配置警报

让我们逐步了解如何通过 Log Analytics 配置警报：

1. 配置警报的第一步是通过 Azure 门户或从 Log Analytics 资源的警报菜单中使用自动化添加新的警报规则。

2. 配置警报的第一步是通过 Azure 门户或从 Log Analytics 资源的警报菜单中使用自动化添加新的警报规则。

3. 从结果面板中，选择警报规则的范围。范围决定了应监控哪个资源以触发警报——它可以是资源实例，如 Azure 存储账户，也可以是资源类型，如 Azure 虚拟机，资源组或订阅：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_19.jpg

   图 2.19：为警报选择资源

4. 在选择资源之后，必须为警报设置条件。条件决定了评估所选资源上的日志和指标的规则，只有在条件为真时，警报才会被触发。有许多可用的指标和日志可以用来生成条件。在以下示例中，创建了一个静态阈值为 80% 的CPU 使用率百分比（平均值）的警报，并且数据每五分钟收集一次，每分钟评估一次：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_02_20.jpg

   图 2.20：为 CPU 使用率百分比（平均值）创建警报

   警报还支持动态阈值，它使用机器学习来学习指标的历史行为，并检测可能表示服务问题的不正常现象。

5. 最后，创建一个操作组或重用现有的组，该组确定向利益相关者发送与警报相关的通知。操作组部分允许你配置警报后需要执行的内容。通常，应该有一个补救和/或通知动作。Log Analytics 提供了八种不同的方式来创建一个新操作。这些操作可以按任何你喜欢的方式组合。一个警报会执行以下任何或所有配置的操作：

   • 电子邮件/SMS/推送/语音通知：这将向配置的收件人发送电子邮件/SMS/推送/语音通知。

   • Webhook：Webhook 使用 HTTP POST 机制运行任意外部进程。例如，可以执行 REST API，或调用 Service Manager/ServiceNow API 来创建工单。

   • Azure 函数：此操作运行一个 Azure 函数，传递必要的负载并运行负载中包含的逻辑。

   • 逻辑应用程序：此操作执行自定义逻辑应用程序工作流。

   • 电子邮件 Azure 资源管理器角色：此操作向 Azure 资源管理器角色的持有者发送电子邮件，例如所有者、贡献者或读取者。

   • 安全 Webhook：Webhook 使用 HTTP POST 机制运行任意外部进程。Webhook 使用身份提供者进行保护，例如 Azure Active Directory。

   • 自动化运行书：此操作执行 Azure 自动化运行书。

   • ITSM：在使用此选项之前，应该先配置 ITSM 解决方案。它有助于将信息连接并发送到 ITSM 系统。

6. 完成所有配置后，你需要提供 名称、描述 和 严重性 值，以便生成警报规则。

正如本节开头提到的，警报在监控中起着至关重要的作用，它帮助授权人员根据触发的警报采取必要的行动。

摘要

高可用性和可扩展性是至关重要的架构问题。几乎每个应用程序和每个架构师都尝试实现高可用性。Azure 是一个成熟的平台，理解应用程序中这些架构需求的重要性，并提供资源以在多个层次上实现这些需求。这些架构问题不是事后考虑的，它们应该是应用程序开发生命周期的一部分，从规划阶段开始。

监控是任何解决方案的重要架构方面。它也是能够正确审计应用程序的第一步。它使运维团队能够对解决方案进行管理，既可以被动响应，也可以主动预防。它提供了处理平台和应用程序可能出现问题所需的记录。Azure 提供了许多与监控实施相关的资源，适用于 Azure、其他云和本地数据中心。Application Insights 和 Log Analytics 是其中最重要的两个资源。不用说，监控是通过基于监控数据的洞察力创新来改进解决方案和产品的必要条件。

本章纯粹讲解了解决方案的可用性、可扩展性和监控；下一章将介绍与虚拟网络、存储帐户、区域、可用性区域和可用性集相关的设计模式。在云中设计解决方案时，这些原则在构建具有成本效益、提高生产力和可用性的解决方案中至关重要。

第三章：3. 设计模式 – 网络、存储、消息传递和事件

在上一章中，你概览了 Azure 云并了解了一些相关的重要概念。本章讲解的是与虚拟网络、存储帐户、区域、可用性区域和可用性集相关的 Azure 云设计模式。这些是影响最终架构的重要构建块，直接关系到成本、效率和整体生产力。本章还简要讨论了帮助我们实现架构可扩展性和性能的云设计模式。

本章将涵盖以下主题：

• Azure 虚拟网络设计

• Azure 存储设计

• Azure 可用性区域、区域和可用性集

• 与消息传递、性能和可扩展性相关的 Azure 设计模式

Azure 可用性区域和区域

Azure 由大型数据中心支持，这些数据中心通过一个庞大的网络互联。数据中心根据其物理位置的接近性，分组为 Azure 区域。例如，西欧的数据中心对西欧区域的 Azure 用户可用。用户无法选择其偏好的数据中心，他们只能选择 Azure 区域，Azure 会分配一个合适的数据中心。

选择合适的区域是一个重要的架构决策，因为它会影响：

• 资源的可用性

• 数据和隐私合规性

• 应用程序的性能

• 运行应用程序的成本

让我们详细讨论一下这些要点。

资源的可用性

并非所有资源都在每个 Azure 区域中可用。如果你的应用架构要求的资源在某个区域不可用，那么选择该区域是没有帮助的。相反，应该根据应用程序所需资源的可用性来选择区域。可能在开发应用程序架构时该资源不可用，但它可能在 Azure 的发展路线图中，后续会使其可用。

例如，Log Analytics 并非在所有区域都可用。如果你的数据源位于区域 A，而 Log Analytics 工作区位于区域 B，你需要支付带宽费用，即从区域 A 到 B 的数据出口费用。类似地，一些服务只能与位于同一区域的资源一起使用。例如，如果你希望加密部署在区域 A 的虚拟机磁盘，你需要在区域 A 部署 Azure Key Vault 来存储加密密钥。在部署任何服务之前，你需要检查你的依赖服务是否在该区域内可用。查看 Azure 产品在各个区域的可用性的一个好途径是这个产品页面：azure.microsoft.com/global-infrastructure/services。

数据和隐私合规性

每个国家都有自己的数据和隐私合规性规定。有些国家对于将其公民的数据存储在本国领土内有非常明确的要求。因此，在设计每个应用程序的架构时，必须考虑到这些法律要求。

应用程序性能

应用程序的性能取决于请求和响应到达目标并返回时所经过的网络路由。地理上更接近的区域不一定是延迟最低的区域。我们可以按公里或英里来计算距离，但延迟是基于数据包所经过的路径。例如，部署在西欧的面向东南亚用户的应用程序，其性能可能不如部署在东亚区域面向该地区用户的应用程序。因此，确保在离您最近的区域架构解决方案至关重要，以提供最低的延迟和最佳的性能。

运行应用程序的成本

Azure 服务的费用因区域而异。应选择整体成本较低的区域。本书中有完整的一章讲解成本管理（第六章，Azure 解决方案的成本管理），可以参考其中的详细信息。

到目前为止，我们已经讨论了如何选择合适的区域来架构我们的解决方案。现在我们已经确定了适合解决方案的区域，接下来我们将讨论如何在 Azure 中设计我们的虚拟网络。

虚拟网络

虚拟网络应该像物理办公室或家庭局域网一样考虑。从概念上讲，它们是相同的，尽管Azure 虚拟网络（VNet）作为一种软件定义网络，通过庞大的物理网络基础设施实现。

VNet 是托管虚拟机所必需的。它提供了 Azure 资源之间的安全通信机制，使得它们能够相互连接。VNet 为资源提供内部 IP 地址，便于访问和连接其他资源（包括同一虚拟网络上的虚拟机），路由请求，并提供与其他网络的连接。

虚拟网络包含在一个资源组中，并托管在某个区域内，例如西欧。它不能跨多个区域，但可以跨该区域内的所有数据中心，这意味着我们可以跨区域的多个可用性区域构建虚拟网络。对于跨区域的连接，虚拟网络可以通过 VNet 对 VNet 连接实现互联。

虚拟网络还提供与本地数据中心的连接，支持混合云架构。可以使用多种 VPN 技术将本地数据中心扩展到云端，例如站点对站点 VPN 和点对站点 VPN。还可以通过使用 ExpressRoute，在 Azure VNet 与本地网络之间建立专用连接。

虚拟网络是免费的。每个订阅可以在所有区域内创建最多 50 个虚拟网络。然而，如果需要增加此数量，可以联系 Azure 支持团队。如果数据不离开部署区域，将不会收费。截止撰写本文时，来自同一地区的可用性区域之间的进出数据传输不会产生费用；但是，从 2020 年 7 月 1 日起，将开始计费。

有关网络限制的信息可以在 Microsoft 文档中找到，网址为 docs.microsoft.com/azure/azure-resource-manager/management/azure-subscription-service-limits。

虚拟网络的架构考虑因素

虚拟网络与其他资源一样，可以通过 ARM 模板、REST API、PowerShell 和 CLI 进行配置。在开发生命周期的早期尽可能规划网络拓扑非常重要，以避免后续出现问题。这是因为一旦网络被配置并且资源开始使用它，就很难在没有停机的情况下进行更改。例如，将虚拟机从一个网络移动到另一个网络时，需要先关闭虚拟机。

让我们看看在设计虚拟网络时的一些关键架构考虑因素。

区域

VNet 是 Azure 的一项资源，并且在某个区域内进行配置，例如西欧。跨多个区域的应用程序需要分别为每个区域配置虚拟网络，并且还需要通过 VNet-to-VNet 连接进行连接。VNet-to-VNet 连接会产生进出流量的费用。对于传入（入口）数据没有费用，但传出数据会产生费用。

专用 DNS

VNet 默认使用 Azure 的 DNS 来解析虚拟网络中的名称，并且也支持互联网名称解析。如果应用程序需要专用的名称解析服务或希望连接到本地数据中心，它应该配置自己的 DNS 服务器，并且该服务器应在虚拟网络内配置以确保名称解析成功。此外，你可以将公共域名托管在 Azure 中，并通过 Azure 门户完全管理记录，而无需管理额外的 DNS 服务器。

虚拟网络数量

虚拟网络的数量受区域数量、服务的带宽使用、跨区域连接和安全性的影响。比起多个较小的 VNet，拥有较少但更大的 VNet 可以消除管理负担。

每个虚拟网络中的子网数量

子网提供虚拟网络内的隔离。它们还可以提供安全边界。网络安全组（NSG）可以与子网关联，从而限制或允许对 IP 地址和端口的特定访问。具有独立安全性和可访问性要求的应用组件应放置在独立的子网中。

网络和子网的 IP 范围

每个子网都有一个 IP 范围。IP 范围不应过大，以免 IP 地址未得到充分利用，但也不应过小，以免由于缺乏 IP 地址而使子网变得无法使用。部署的未来 IP 地址需求应考虑在内。

应为 Azure 网络、子网和本地数据中心的 IP 地址和范围进行规划。为了确保无缝连接性和可访问性，应该避免重叠。

监控

监控是一个重要的架构方面，必须包含在整体部署中。Azure 网络监视器提供了日志记录和诊断功能，能够洞察网络性能和健康状况。Azure 网络监视器的一些功能包括：

• 诊断虚拟机的网络流量过滤问题

• 理解用户定义路由的下一跳

• 查看虚拟网络中的资源及其关系

• 监控虚拟机与终端之间的通信

• 捕获来自虚拟机的流量

• NSG 流量日志，用于记录与通过 NSG 的流量相关的信息。这些数据将存储在 Azure 存储中，以供进一步分析。

它还提供了资源组中所有网络资源的诊断日志。

网络性能可以通过日志分析进行监控。网络性能监视器管理解决方案提供了网络监控功能。它监控网络的健康状况、可用性和可达性。它还用于监控公共云和本地子网之间的连接性，这些子网承载多层应用的不同层。

安全性考虑事项

虚拟网络是 Azure 上任何资源访问的首要组件。安全性在允许或拒绝访问资源中起着重要作用。NSG 是启用虚拟网络安全性的主要手段。它们可以附加到虚拟网络子网上，每个进出流量都受到其约束、过滤和允许。

用户定义的路由（UDR）和 IP 转发也有助于过滤和路由请求到 Azure 上的资源。你可以在 docs.microsoft.com/azure/virtual-network/virtual-networks-udr-overview 阅读更多关于 UDR 和强制隧道的信息。

Azure 防火墙是 Azure 提供的完全托管的防火墙即服务。它可以帮助你保护虚拟网络中的资源。Azure 防火墙可以用于传入和传出的流量包过滤等操作。此外，Azure 防火墙的威胁情报功能可以用于提醒并拒绝来自或去往恶意域名或 IP 地址的流量。IP 地址和域名的数据来源是 Microsoft 的威胁情报数据流。

还可以通过部署网络设备（azure.microsoft.com/solutions/network-appliances）来保护资源，这些设备包括 Barracuda、F5 和其他第三方组件。

部署

虚拟网络应部署在各自独立的资源组中。网络管理员应获得所有者的许可才能使用该资源组，而开发人员或团队成员应拥有贡献者权限，以便他们可以在其他资源组中创建使用虚拟网络服务的其他 Azure 资源。

将具有静态 IP 地址的资源部署在专用子网中是一个好的实践，而与动态 IP 地址相关的资源可以部署在另一个子网中。

策略不仅应创建，以确保只有网络管理员可以删除虚拟网络，还应对其进行标签标记，以便用于计费目的。

连接性

虚拟网络中同一地区的资源可以无缝地互相通信。即使是虚拟网络中其他子网的资源，也可以在没有任何明确配置的情况下相互通信。不同地区的资源无法使用相同的虚拟网络。虚拟网络的边界是在一个地区内。要实现跨区域的资源通信，我们需要在两端部署专用网关以促进通信。

话虽如此，如果你希望在不同地区的两个网络之间建立私有连接，你可以使用全球 VNet 对等互联。使用全球 VNet 对等互联时，通信通过 Microsoft 的骨干网进行，这意味着在通信过程中不需要公共互联网、网关或加密。如果你的虚拟网络位于同一区域但使用不同的地址空间，那么一个网络中的资源将无法与另一个网络中的资源通信。由于它们位于同一区域，我们可以使用虚拟网络对等互联，这类似于全球 VNet 对等互联；唯一的区别是源虚拟网络和目标虚拟网络部署在同一区域内。

由于许多组织采用了混合云，Azure 资源有时需要与本地数据中心进行通信或连接，反之亦然。Azure 虚拟网络可以使用 VPN 技术和 ExpressRoute 连接到本地数据中心。实际上，一个虚拟网络能够同时连接多个本地数据中心和其他 Azure 区域。作为最佳实践，每个连接应位于虚拟网络内的专用子网中。

现在我们已经探讨了虚拟网络的多个方面，接下来让我们讨论虚拟网络的好处。

虚拟网络的好处

虚拟网络是部署任何有意义的 IaaS 解决方案所必需的。没有虚拟网络，无法配置虚拟机。除了在 IaaS 解决方案中几乎是一个强制性组件外，它们还提供了巨大的架构优势，其中一些在此列出：

• 隔离性：大多数应用组件有独立的安全性和带宽要求，并且生命周期管理不同。虚拟网络帮助为这些组件创建隔离的区域，可以借助虚拟网络和子网独立管理这些组件，而不影响其他组件。

• 安全性：过滤和跟踪访问资源的用户是虚拟网络提供的重要功能。它们可以阻止对恶意 IP 地址和端口的访问。

• 可扩展性：虚拟网络就像云上的私人局域网。通过连接全球的其他虚拟网络，它们还可以扩展为广域网（WAN），并且可以作为本地数据中心的扩展。

我们已经探讨了虚拟网络的好处。现在的问题是我们如何利用这些好处并设计一个虚拟网络来托管我们的解决方案。在接下来的部分，我们将讨论虚拟网络的设计。

虚拟网络设计

在本节中，我们将考虑一些流行的虚拟网络设计和用例场景。

虚拟网络有多种用途。可以在每个虚拟网络端点部署网关，以启用安全性并传输完整性和保密性的数据包。在连接到本地网络时，必须使用网关；然而，在使用 Azure VNet 对等连接时，网关是可选的。此外，您还可以利用网关传输功能，简化扩展本地数据中心的过程，而无需部署多个网关。网关传输功能允许您与所有对等虚拟网络共享 ExpressRoute 或 VPN 网关。这将使管理变得更加容易，并减少部署多个网关的成本。

在上一节中，我们提到了对等连接，并提到我们不使用网关或公共互联网来建立对等网络之间的通信。接下来我们将进一步探讨对等连接的设计方面，以及在特定场景下需要使用哪些对等连接。

连接同一区域和订阅内的资源

同一区域和订阅内的多个虚拟网络可以相互连接。在 VNet 对等连接的帮助下，两个网络可以连接，并使用 Azure 私有网络骨干网互相传输数据包。这些网络上的虚拟机和服务可以相互通信，但受限于网络流量的约束。在下图中，VNet1 和 VNet2 都部署在美国西部区域。然而，VNet1 的地址空间是 172.16.0.0/16，而 VNet2 的地址空间是 10.0.0.0/16。默认情况下，VNet1 中的资源无法与 VNet2 中的资源通信。由于我们已经在两者之间建立了 VNet 对等连接，因此这些资源将能够通过 Microsoft 骨干网络相互通信：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/3.1.jpg

图 3.1：相同订阅内资源的 VNet 对等连接

连接到另一个订阅内同一区域的资源

这个场景与前一个场景非常相似，唯一不同的是虚拟网络托管在两个不同的订阅中。这些订阅可以属于同一个租户，也可以来自多个租户。如果两个资源属于同一个订阅并且位于同一区域，则适用前一个场景。这个场景可以通过两种方式实现：使用网关或使用虚拟网络对等连接。

如果我们在这个场景中使用网关，我们需要在两端部署网关以促进通信。以下是使用网关连接两个不同订阅资源的架构表示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_3.2.jpg

图 3.2：使用网关进行不同订阅资源的 VNet 对等连接

然而，部署网关会产生一些费用。我们将讨论 VNet 对等连接，之后我们会比较这两种实现方式，看看哪种方式最适合我们的解决方案。

在使用对等连接时，我们不会部署任何网关。图 3.3 展示了如何进行对等连接：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_3.3.jpg

图 3.3：跨订阅的 VNet 对等连接

VNet 对等连接提供了低延迟、高带宽的连接，如图所示，我们没有部署任何网关来实现通信。这对于数据复制或故障转移等场景非常有用。如前所述，对等连接使用 Microsoft 骨干网络，消除了对公共互联网的需求。

网关用于需要加密且带宽不是问题的场景，因为这将是一个带宽有限的连接。然而，这并不意味着带宽有约束。此方法适用于对延迟不太敏感的客户。

到目前为止，我们已经查看了跨订阅的同一区域资源。在下一节中，我们将探讨如何在两个不同区域的虚拟网络之间建立连接。

连接到另一个订阅中不同区域的资源

在这种场景中，我们有两个实现方式，一个使用网关，另一个使用全球 VNet 对等连接。

流量将通过公共网络传输，我们将在两端部署网关以便建立加密连接。图 3.4 说明了实现方法：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_3.4.jpg

图 3.4：使用不同订阅连接不同区域的资源

我们将采用类似的方式使用全球 VNet 对等连接。图 3.5 显示了如何使用全球 VNet 对等连接：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_3.5.jpg

图 3.5：使用全球 VNet 对等连接连接不同区域的资源

选择网关或对等连接的考虑因素已在之前讨论过，这些考虑因素在本场景中同样适用。到目前为止，我们已经讨论了跨区域和订阅连接虚拟网络；但我们还没有讨论如何将本地数据中心连接到云。接下来的部分将讨论实现这一目标的方法。

连接到本地数据中心

虚拟网络可以连接到本地数据中心，从而使 Azure 和本地数据中心成为一个单一的广域网（WAN）。需要在网络的两侧部署网关和 VPN。为此，有三种不同的技术可供选择。

站点到站点 VPN

当 Azure 网络和本地数据中心连接以形成一个广域网（WAN），且两个网络中的任何资源都可以访问网络中的任何其他资源，无论它们是部署在 Azure 还是本地数据中心时，应使用此方法。为了安全起见，需要在两端的网络上部署 VPN 网关。此外，Azure 网关应部署在与本地数据中心连接的虚拟网络的子网中。本地网关必须分配公共 IP 地址，以便 Azure 通过公共网络连接到它们：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_3.6.jpg

图 3.6：站点到站点 VPN 架构

点对站点 VPN

这类似于站点到站点的 VPN 连接，但有一个单一的服务器或计算机连接到本地数据中心。当需要从远程位置安全地连接到 Azure 且只有少数用户或客户端时，应使用此方式。此外，在这种情况下，无需在本地侧配置公共 IP 和网关：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_3.7.jpg

图 3.7：点对站点 VPN 架构

ExpressRoute

无论是站点到站点（site-to-site）还是点对站点（point-to-site）VPN，均使用公共互联网工作。它们通过 VPN 和证书技术对网络流量进行加密。然而，一些应用程序希望使用混合技术进行部署——一部分组件部署在 Azure，另一部分部署在本地数据中心——同时又不希望使用公共互联网连接 Azure 和本地数据中心。对于这些需求，Azure ExpressRoute 是最佳解决方案，尽管它比另外两种连接方式成本更高。它也是最安全和可靠的提供商，速度更快，延迟更低，因为流量不会经过公共互联网。Azure ExpressRoute 可以通过连接提供商通过专用私有连接将本地网络扩展到 Azure。如果你的解决方案是网络密集型的，例如事务性企业应用程序（如 SAP），强烈建议使用 ExpressRoute。

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_3.8.jpg

图 3.8：ExpressRoute 网络架构

图 3.9 显示了三种混合网络类型：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_3.9.jpg

图 3.9：不同类型的混合网络

从安全性和隔离的角度来看，虚拟网络为每个逻辑组件创建单独的子网并进行独立部署是一种良好的实践。

我们在 Azure 部署的所有资源都需要某种方式的网络支持，因此在架构设计 Azure 解决方案时，需要深入理解网络知识。另一个关键要素是存储。在接下来的章节中，你将进一步了解存储。

存储

Azure 通过存储服务提供了一个持久、高可用且可扩展的存储解决方案。

存储用于持久化数据，以满足长期需求。Azure 存储可以通过互联网为几乎所有编程语言提供服务。

存储类别

存储有两类存储账户：

• 一种标准存储性能层，允许你存储表格、队列、文件、Blob 和 Azure 虚拟机磁盘。

• 一种支持 Azure 虚拟机磁盘的高级存储性能层，写作时，Premium 存储比标准通用存储提供更高的性能和 IOPS。Premium 存储当前作为虚拟机的数据磁盘，使用 SSD 作为支持。

根据存储的数据类型，存储可以分为不同的类型。让我们来看一下存储类型，并深入了解它们。

存储类型

Azure 提供四种常见的存储服务：

• Azure Blob 存储： 这种存储类型最适合非结构化数据，如文档、图片和其他类型的文件。Blob 存储可以分为热存储、冷存储和归档存储。热存储适用于需要非常频繁访问的数据。冷存储适用于访问频率低于热存储的数据，并且数据的存储时间为 30 天。最后，归档存储适用于归档目的，访问频率非常低。

• Azure 表格存储： 这是一个 NoSQL 键值数据存储，适用于结构化数据。数据以实体的形式存储。

• Azure 队列存储： 这提供了可靠的消息存储，用于存储大量消息。这些消息可以通过 HTTP 或 HTTPS 调用从任何地方访问。队列消息的最大大小为 64 KB。

• Azure 文件： 这是基于 SMB 协议的共享存储，通常用于存储和共享文件。它也存储非结构化数据，但其主要区别在于它可以通过 SMB 协议进行共享。

• Azure 磁盘： 这是 Azure 虚拟机的块级存储。

这五种存储类型满足不同的架构需求，涵盖几乎所有类型的数据存储设施。

存储功能

Azure 存储是弹性的，这意味着您可以存储从几兆字节到几拍字节的数据。您无需预先设置存储容量，它会自动增长和收缩。用户只需为实际使用的存储付费。以下是使用 Azure 存储的一些主要好处：

• Azure 存储是安全的，只能通过 SSL 协议访问。此外，访问必须经过身份验证。

• Azure 存储提供了生成帐户级安全访问签名（SAS）令牌的功能，存储客户端可以使用该令牌进行身份验证。还可以为 Blob、队列、表格和文件生成单独的服务级 SAS 令牌。

• 存储在 Azure 存储中的数据可以被加密，这被称为静态数据加密。

• Azure 磁盘加密用于加密 IaaS 虚拟机中的操作系统和数据磁盘。客户端加密（CSE）和存储服务加密（SSE）都用于加密 Azure 存储中的数据。SSE 是 Azure 存储的一个设置，确保在数据写入存储时加密，并在存储引擎读取数据时解密。这确保了启用 SSE 不需要任何应用程序更改。在 CSE 中，客户端应用程序可以使用存储 SDK 在数据发送并写入 Azure 存储之前对数据进行加密。客户端应用程序可以在读取数据时再解密这些数据。这为数据传输中的数据和静态数据提供了安全性。CSE 依赖于 Azure 密钥保管库中的密钥。

• Azure 存储具有高度的可用性和持久性。这意味着 Azure 始终保持多个 Azure 账户的副本。副本的地点和数量取决于复制配置。

Azure 提供以下复制设置和数据冗余选项：

• 本地冗余存储（LRS）：在主区域的单一物理位置内，将同步存储三份数据副本。从计费的角度来看，这是最便宜的选项；然而，它不推荐用于需要高可用性的解决方案。LRS 提供在给定一年内对象的 99.999999999% 的持久性级别。

• 区域冗余存储（ZRS）：在 LRS 的情况下，副本存储在同一物理位置。而在 ZRS 的情况下，数据将同步复制到主区域内的可用区。由于这些可用区都是主区域内的独立物理位置，ZRS 提供比 LRS 更好的持久性和更高的可用性。

• 地理冗余存储（GRS）：GRS 通过使用 LRS 在单一主区域内同步复制三份数据副本，从而提高高可用性。它还将数据复制到次要区域的单一物理位置。

• 地理区域冗余存储（GZRS）：这与 GRS 非常相似，但不同之处在于，GZRS 不是在主区域内单一物理位置复制数据，而是跨三个可用区同步复制数据。正如我们在 ZRS 的案例中所讨论的，由于可用区是主区域内独立的物理位置，GZRS 提供了更好的持久性，并且可以包含在高可用设计中。

• 读取访问地理冗余存储（RA-GRS）和读取访问地理区域冗余存储：通过 GZRS 或 GRS 复制到次要区域的数据无法进行读写。这些数据将在主数据中心发生故障转移时由次要区域使用。RA-GRS 和 RA-GZRS 遵循与 GRS 和 GZRS 相同的复制模式；唯一的区别是通过 RA-GRS 或 RA-GZRS 复制到次要区域的数据可以进行读取。

现在我们已经了解了 Azure 上各种存储和连接选项，接下来让我们了解该技术的底层架构。

存储帐户的架构考虑事项

存储帐户应在与其他应用程序组件相同的区域中进行配置。这意味着使用相同的数据中心网络骨干，避免产生任何网络费用。

Azure 存储服务具有与每个服务相关的容量、事务速率和带宽的可扩展性目标。一个通用的存储帐户允许存储 500 TB 的数据。如果需要存储超过 500 TB 的数据，则应创建多个存储帐户或使用高级存储。

通用存储的最大性能为 20,000 IOPS 或每秒 60 MB 的数据。如果需要更高的 IOPS 或每秒管理的数据量，则会受到限制。如果从性能角度来看，这些不足以满足应用程序的需求，那么应使用高级存储或多个存储帐户。对于一个帐户，访问表格的可扩展性限制为最多 20,000（每个 1 KB）条目。插入、更新、删除或扫描的实体数量将计入目标。单个队列每秒可处理大约 2,000 条消息（每条 1 KB），每个 AddMessage、GetMessage 和 DeleteMessage 的计数将被视为一条消息。如果这些值不足以满足你的应用程序需求，你应该将消息分布到多个队列中。

虚拟机的大小决定了可用数据磁盘的大小和容量。虽然较大的虚拟机具有更高 IOPS 容量的数据磁盘，但最大容量仍将限制为 20,000 IOPS 和每秒 60 MB。需要注意的是，这些是最大值，因此在最终确定存储架构时，应考虑较低的值。

截至目前，GRS 帐户在美国的入站带宽目标为 10 Gbps，如果启用了 RA-GRS/GRS，则为 20 Gbps。对于 LRS 帐户，限制相对较高，入站带宽为 20 Gbps，出站带宽为 30 Gbps。在美国以外，带宽目标较低：入站带宽为 10 Gbps，出站带宽为 5 Gbps。如果需要更高的带宽，可以联系 Azure 支持团队，他们将帮助你获取更多的选项。

存储帐户应启用使用 SAS 令牌进行身份验证。它们不应允许匿名访问。此外，对于 Blob 存储，应根据不同类型和类别的客户端创建不同的容器，并为每个容器生成独立的 SAS 令牌。这些 SAS 令牌应定期重新生成，以确保密钥不会被破解或猜测。你将会在第八章，构建 Azure 上的安全应用程序中了解更多关于 SAS 令牌和其他安全选项的内容。

通常，从 Blob 存储帐户获取的 Blob 应该进行缓存。我们可以通过将其最后修改属性与重新获取的最新 Blob 进行比较，来判断缓存是否过时。

存储帐户提供并发功能，以确保同一文件和数据不会被多个用户同时修改。它们提供以下功能：

• 乐观并发：这允许多个用户同时修改数据，但在写入时，它会检查文件或数据是否已经更改。如果有更改，它会提示用户重新获取数据并再次执行更新操作。这是表格的默认并发方式。

• 悲观并发：当一个应用尝试更新文件时，它会加锁，明确拒绝其他用户对文件的任何更新。这是通过 SMB 协议访问文件时的默认并发模式。

• 最后写者获胜：更新没有限制，最后一个用户会更新文件，而不管最初读取的内容是什么。这是队列、Blob 和文件（通过 REST 访问时）的默认并发模式。

到目前为止，你应该已经知道了不同的存储服务是什么，以及如何在你的解决方案中利用它们。在接下来的章节中，我们将讨论设计模式，并看看它们如何与架构设计相关。

云设计模式

设计模式是针对已知设计问题的成熟解决方案。它们是可重用的解决方案，可以应用于问题中。它们不是可以直接嵌入到解决方案中的可重用代码或设计，而是解决问题的文档化描述和指导。一个问题可能在不同的上下文中表现出来，设计模式可以帮助解决这些问题。Azure 提供了大量的服务，每个服务都提供特定的功能和能力。使用这些服务很简单，但将多个服务结合起来创建解决方案可能会有挑战。而且，为解决方案实现高可用性、超高可扩展性、可靠性、性能和安全性并非易事。

Azure 设计模式提供了可以根据具体问题定制的现成解决方案。它们帮助我们在 Azure 上构建高可用、可扩展、可靠、安全和以性能为中心的解决方案。尽管有许多模式，并且一些模式将在后续章节中详细讨论，但本章提到了其中的一些消息传递、性能和可扩展性模式。同时，还提供了这些模式的详细描述链接。这些设计模式本身值得一本完整的书来讨论。它们在这里被提及，旨在让你意识到它们的存在，并为进一步了解提供参考。

消息传递模式

消息传递模式有助于以松耦合的方式连接服务。这意味着服务之间从不直接通信。相反，服务会生成并将消息发送到一个代理（通常是队列），任何对该消息感兴趣的服务都可以取出并处理它。发送方和接收方服务之间没有直接通信。这种解耦不仅使服务和整个应用程序更可靠，还使其更强健和容错。接收方可以根据自己的速度接收和读取消息。

消息传递有助于创建异步模式。消息传递涉及从一个实体向另一个实体发送消息。这些消息由发送方创建并转发，存储在持久存储中，最后被接收方消费。

消息传递模式解决的主要架构问题如下：

• 耐久性：消息被存储在持久化存储中，应用程序可以在故障转移后读取已接收到的消息。

• 可靠性：消息通过持久化存储在磁盘上，确保不会丢失，从而实现可靠性。

• 消息的可用性：在恢复连接并在停机之前，消息可以供应用程序消费。

Azure 提供了服务总线队列和主题来实现应用程序内的消息传递模式。Azure 队列存储也可以用于相同的目的。

在选择 Azure 服务总线队列与队列存储时，需要考虑消息存储的时间、消息大小、延迟和成本等因素。Azure 服务总线支持 256 KB 的消息，而队列存储支持 64 KB 的消息。Azure 服务总线可以存储消息无限期，而队列存储则只能存储 7 天。服务总线队列的成本和延迟较高。

根据应用程序的需求和要求，在决定最佳队列之前，应考虑上述因素。在下一部分中，我们将讨论不同类型的消息传递模式。

竞争消费者模式

如果应用程序没有实现异步读取消息的逻辑，单一消费者将以同步方式处理消息。竞争消费者模式则提供了一种解决方案，其中多个消费者准备好处理传入的消息，并竞争处理每一条消息。这种方式可以实现高可用性和可扩展的解决方案。此模式可扩展，因为通过多个消费者，可以在较短的时间内处理更多的消息。它具有高可用性，因为即使部分消费者崩溃，仍然会有至少一个消费者可以处理消息。

当每条消息独立于其他消息时，应使用此模式。消息本身包含了消费者完成任务所需的所有信息。如果消息之间存在依赖关系，则不应使用此模式。消费者应能够在隔离的情况下完成任务。此外，如果服务需求波动，则此模式适用。可以根据需求增加或删除消费者。

实现竞争消费者模式需要一个消息队列。在这里，来自多个来源的模式通过一个单一的队列传递，队列的另一端连接着多个消费者。这些消费者在读取每条消息后应删除该消息，以防止它们被重新处理：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_3.10.jpg

图 3.10：竞争消费者模式

请参阅 Microsoft 文档 docs.microsoft.com/azure/architecture/patterns/competing-consumers 以了解有关此模式的更多信息。

优先队列模式

经常需要优先处理某些消息。这个模式对那些为消费者提供不同服务级别协议（SLA）的应用程序非常重要，这些应用程序根据不同的计划和订阅提供服务。

队列遵循先进先出（FIFO）模式。消息按顺序处理。然而，在优先级队列模式的帮助下，可以根据消息的优先级加速某些消息的处理。实现这一点有多种方法。如果队列允许你分配优先级并根据优先级重新排序消息，那么即使是单一队列也足以实现这一模式：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_3.11.jpg

图 3.11：单一优先级队列模式

然而，如果队列无法重新排序消息，可以为不同的优先级创建独立的队列，并且每个队列可以有与之关联的独立消费者：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_3.12.jpg

图 3.12：使用独立消息队列处理不同优先级

事实上，该模式可以使用竞争消费者模式（Competing Consumer pattern）来加速使用多个消费者处理每个队列中的消息。有关优先级队列模式的更多信息，请参阅微软文档 docs.microsoft.com/azure/architecture/patterns/priority-queue。

基于队列的负载均衡模式

基于队列的负载均衡模式减少了需求峰值对任务和服务的可用性和警觉性的影响。在任务和服务之间，队列将充当缓冲区。它可以在发生突发负载时被调用，避免服务中断或超时。该模式有助于解决性能和可靠性问题。为了防止服务超载，我们将引入一个队列，直到服务取出消息。服务将以一致的方式从队列中取出并处理消息。

图 3.13 展示了基于队列的负载均衡模式的工作原理：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_3.13.jpg

图 3.13：基于队列的负载均衡模式

尽管该模式有助于处理意外需求的激增，但在构建低延迟服务时，它不是最佳选择。说到延迟，它是一个性能指标，下一节我们将专注于性能和可扩展性模式。

性能和可扩展性模式

性能和可扩展性是相辅相成的。性能是衡量系统在给定时间间隔内如何快速、有效地执行操作的指标。另一方面，可扩展性是指系统在不影响性能的情况下处理意外负载的能力，或者系统如何利用现有资源迅速扩展。在本节中，将介绍与性能和可扩展性相关的几个设计模式。

命令与查询职责分离（CQRS）模式

CQRS 不是一个特定于 Azure 的模式，而是一个可以应用于任何应用程序的一般模式。它可以提高应用程序的整体性能和响应能力。

CQRS 是一种将读取数据（查询）操作与更新数据（命令）操作隔离开来的模式，通过使用不同的接口。这意味着用于查询和更新的数据模型是不同的。然后，这些模型可以像图 3.14中所示那样隔离，尽管这不是强制要求。

当在更新和检索数据时，涉及大量复杂的业务规则时，应该使用该模式。此外，这种模式在某些情况下非常适用，其中一个开发团队可以专注于写模型中复杂的领域模型，另一个团队可以专注于读模型和用户界面。当读写比例失衡时，使用该模式也是明智的。数据读取的性能应该与数据写入的性能分开调优。

CQRS 不仅可以提高应用程序的性能，还能帮助多团队的设计和实现。由于其使用不同模型的特性，如果你使用模型和脚手架生成工具，CQRS 就不太适用：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_3.14.jpg

图 3.14：CQRS 模式

请参考 Microsoft 文档 docs.microsoft.com/azure/architecture/patterns/cqrs，了解有关该模式的更多信息。

事件溯源模式

由于大多数应用程序都涉及数据操作，并且用户也在操作数据，因此应用程序的经典方法是维护和更新数据的当前状态。从源头读取数据，修改数据，然后用修改后的值更新当前状态是典型的数据处理方法。然而，这种方法有一些局限性：

• 由于更新操作直接作用于数据存储，这会降低整体的性能和响应能力。

• 如果有多个用户在操作和更新数据，可能会出现冲突，并且一些相关的更新可能会失败。

解决方案是实现事件溯源（Event Sourcing）模式，其中变更将被记录在仅追加的存储中。应用程序代码会将一系列事件推送到事件存储中，并在那里持久化。这些持久化的事件充当当前数据状态的系统记录。消费者将在事件发布后收到通知，并在需要时处理这些事件。

事件溯源模式如图 3.15所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_3.15.jpg

图 3.15：事件溯源模式

更多关于此模式的信息，请访问 docs.microsoft.com/azure/architecture/patterns/event-sourcing。

限流模式

有些应用程序对性能和可扩展性有非常严格的 SLA（服务级别协议）要求，无论用户数量如何。在这种情况下，实施限流模式非常重要，因为它可以限制允许执行的请求数量。在所有情况下，无法准确预测应用程序的负载。当应用程序的负载激增时，限流通过控制资源消耗来减少服务器和服务的压力。Azure 基础设施是该模式的一个很好的示例。

当满足 SLA 是应用程序的优先事项时，应该使用此模式，以防止某些用户消耗超过分配的资源，优化需求的峰值和波动，并在成本方面优化资源消耗。这些是为部署在云上的应用程序设计的有效场景。

在应用程序中处理限流可以采用多种策略。限流策略可以在超过阈值后拒绝新的请求，或者可以让用户知道请求已在队列中，并且在请求数量减少后会有机会执行。

图 3.16展示了在多租户系统中实施限流模式的情况，其中每个租户都有固定的资源使用限制。一旦超过此限制，任何额外的资源需求都会受到限制，从而为其他租户保留足够的资源：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_3.16.jpg

图 3.16：限流模式

阅读更多关于此模式的信息，请访问 docs.microsoft.com/azure/architecture/patterns/throttling。

重试模式

重试模式是一个非常重要的模式，使应用程序和服务能够更好地应对瞬时故障。假设你正在尝试连接并使用一个服务，但该服务由于某种原因无法使用。如果该服务很快就会恢复，继续尝试建立连接是有意义的。这将使应用程序更加健壮、容错和稳定。在 Azure 中，大多数组件都运行在互联网环境下，而互联网连接可能会间歇性地产生瞬时故障。由于这些故障可以在几秒钟内修复，因此应用程序不应该崩溃。应用程序应该设计为在失败的情况下反复尝试使用服务，并在成功或最终确定存在需要时间修复的故障时停止重试。

当应用程序与远程服务交互或访问远程资源时可能会遇到瞬时故障时，应该实现此模式。这些故障预计会是短暂的，重复以前失败的请求可能在后续尝试中成功。

重试模式可以根据错误的性质和应用程序的需求采用不同的重试策略。

• 重试固定次数：这意味着应用程序在确定发生失败并引发异常之前，会尝试与服务通信固定的次数。例如，它会重试三次连接到另一个服务。如果在这三次尝试内成功连接，整个操作将成功；否则，它将引发异常。

• 基于计划的重试：这意味着应用程序将在固定的秒数或分钟数内反复尝试与服务通信，并在重试前等待固定的秒数或分钟数。例如，应用程序将在 60 秒内每三秒尝试连接一次服务。如果在此期间成功连接，整个操作将成功；否则，它将引发异常。

• 滑动和延迟重试：这意味着应用程序将根据计划反复尝试与服务通信，并在随后的尝试中逐渐增加延迟。例如，在总计 60 秒内，第一次重试发生在一秒后，第二次重试发生在上一次重试后两秒，第三次重试发生在上一次重试后四秒，以此类推。这减少了重试的总次数。

图 3.17 演示了重试模式。第一次请求得到 HTTP 500 响应，第二次重试仍然得到 HTTP 500 响应，最后请求成功并得到 HTTP 200 响应：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_3.17.jpg

图 3.17：重试模式

请参考此 Microsoft 文档docs.microsoft.com/azure/architecture/patterns/retry，了解更多关于此模式的信息。

电路断路器模式

这是一个非常有用的模式。再想象一下，当您尝试连接并使用某个服务，而该服务因某种原因不可用。如果该服务在短期内无法恢复，那么继续重试连接毫无意义。此外，在重试时占用其他资源会浪费大量本可以在其他地方使用的资源。

电路断路器模式有助于消除资源浪费。它可以防止应用程序重复尝试连接和使用一个不可用的服务。它还帮助应用程序检测服务是否已恢复运行，并允许应用程序连接到它。

要实现电路断路器模式，所有对服务的请求都应通过一个充当原始服务代理的服务。这个代理服务的目的是维护一个状态机，并充当原始服务的网关。它维持三种状态。根据应用程序的需求，可能会包含更多的状态。

实现此模式所需的最小状态如下：

• 打开：这表示服务不可用，应用程序会立即显示为异常，而不是允许它重试或等待超时。当服务恢复后，状态会过渡到半打开。

• 关闭：该状态表示服务正常，应用程序可以继续连接到它。通常，会显示一个计数器，显示在过渡到打开状态之前的失败次数。

• 半打开：在某个时刻，当服务恢复运行时，该状态允许有限数量的请求通过。这个状态是一个试金石，用来检查通过的请求是否成功。如果请求成功，状态将从半打开过渡到关闭。此状态还可以实现一个计数器，允许一定数量的请求成功后，再过渡到关闭状态。

图 3.18 中展示了三种状态及其过渡：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_3.18.jpg

图 3.18：电路断路器模式

在 Microsoft 文档中阅读更多关于此模式的信息：docs.microsoft.com/azure/architecture/patterns/circuit-breaker。

在本节中，我们讨论了可以用于构建可靠、可扩展且安全的云应用程序的设计模式。然而，还有其他模式，您可以在docs.microsoft.com/azure/architecture/patterns上进行探索。

总结

Azure 提供了众多服务，大多数可以组合起来创建真正的解决方案。本章解释了 Azure 提供的三个最重要的服务——区域、存储和网络。它们构成了部署在任何云上的大多数解决方案的基础。本章详细介绍了这些服务及其配置和预配如何影响设计决策。

本章详细介绍了存储和网络的重要考虑因素。网络和存储都提供了许多选择，根据您的需求选择合适的配置至关重要。

最后，介绍了与消息相关的一些重要设计模式，例如竞争消费者、优先队列和负载平衡。还详细说明了诸如 CQRS 和节流等模式，并讨论了其他模式，如重试和断路器。在部署解决方案时，我们将把这些模式作为基准。

在下一章中，我们将讨论如何自动化我们打算设计的解决方案。随着自动化技术的发展，每个组织都希望消除逐一创建资源的开销，这是非常具有挑战性的。由于自动化是解决这一问题的方法，下一章将更深入地探讨这个话题。

第四章：4. 在 Azure 上自动化架构

每个组织都希望减少手动工作和错误，自动化在提高可预测性、标准化和一致性方面发挥着重要作用，不仅在产品开发中，也在运营中。自动化一直是几乎每个首席信息官（CIO）和数字化官员的关注重点，以确保他们的系统具备高可用性、可扩展性、可靠性，并能够满足客户的需求。

随着云计算的到来，自动化变得更加突出，因为新的资源可以随时配置，无需采购硬件资源。因此，云公司希望在几乎所有活动中都能实现自动化，以减少滥用、错误、治理、维护和管理。

本章将评估 Azure 自动化作为一项主要的自动化服务，以及它与其他看似相似的服务相比的差异化能力。本章将涵盖以下内容：

• Azure 自动化生态

• Azure 自动化服务

• Azure 自动化服务的资源

• 编写 Azure 自动化运行书

• Webhooks

• 混合工作者

让我们开始使用 Azure 自动化，这是一个用于过程自动化的云服务。

自动化

自动化是组织内部 IT 资源的配置、操作、管理和拆除的必要手段。图 4.1 给你展示了每个用例的详细信息：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_04_01.jpg

图 4.1：自动化用例

在云计算到来之前，IT 资源主要是在本地，并且这些活动通常依赖手动过程。然而，随着云的采用增加，自动化得到了更多的关注。主要原因是，云技术的敏捷性和灵活性为实时配置、拆除和管理这些资源提供了机会，而这一过程比以前要快得多。随着这种灵活性和敏捷性而来的，是对云计算要求更加可预测和一致，因为组织现在能够轻松创建资源。

微软提供了一个非常棒的 IT 自动化工具——System Center Orchestrator。它是一个适用于本地和云环境的自动化工具，但它是一个产品，而不是服务。它需要许可并部署在服务器上，然后可以执行运行书，以对云和本地环境进行更改。

微软意识到，需要一种自动化解决方案，可以作为服务提供给客户，而不是作为产品购买和部署。于是，Azure 自动化应运而生。

Azure 自动化

Azure 提供了一项名为 Azure 自动化 的服务，这是一项用于自动化流程、活动和任务的核心服务，不仅适用于 Azure，还可以应用于本地环境。通过 Azure 自动化，组织可以自动化与处理、拆除、运营及管理其跨云、IT 环境、平台和语言资源相关的流程和任务。在图 4.2中，我们可以看到 Azure 自动化的一些功能：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_04_02.jpg

图 4.2：Azure 自动化功能

Azure 自动化架构

Azure 自动化由多个组件组成，这些组件之间完全解耦。大部分集成发生在数据存储级别，且没有组件直接进行通信。

当在 Azure 上创建一个自动化账户时，它由一个管理服务进行管理。该管理服务是所有 Azure 自动化活动的单一联络点。来自门户的所有请求，包括保存、发布、创建运行簿，执行、停止、暂停、启动和测试，都会发送到自动化管理服务，服务将请求数据写入其数据存储。它还会在数据存储中创建一个作业记录，并根据运行簿工作者的状态，将作业分配给一个工作者。

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.3.jpg

图 4.3：Azure 自动化架构

工作者不断轮询数据库，查找分配给它的新作业。一旦找到作业分配，它会提取作业信息并使用其执行引擎开始执行该作业。结果会写回数据库，由管理服务读取，并显示在 Azure 门户上。

本章后面我们将要了解的混合工作者也是运行簿工作者，尽管它们未在图 4.3中显示。

开始使用 Azure 自动化的第一步是创建一个新账户。账户创建后，所有其他组件都将在该账户内创建。

账户作为主要的顶级资源，可以通过 Azure 资源组及其自身的控制平面进行管理。

账户应当在某个区域内创建，且该账户中的所有自动化操作都将在该区域的服务器上执行。

选择区域时要谨慎，最好选择靠近其他与自动化账户集成或管理的 Azure 资源的区域，以减少区域之间的网络流量和延迟。

自动化帐户还支持几个Run As帐户，可以从自动化帐户中创建。由于这些 Run As 帐户类似于服务帐户，我们通常创建它们以执行操作。尽管我们通常称其为 Run As 帐户，但实际上有两种类型的 Run As 帐户：一种叫做 Azure 经典 Run As 帐户，另一种则简称为 Run As 帐户，二者都用于连接到 Azure 订阅。Azure 经典 Run As 帐户用于通过Azure 服务管理API 连接到 Azure，而 Run As 帐户则用于通过Azure 资源管理（ARM）API 连接到 Azure。

这两个帐户使用证书进行身份验证以连接到 Azure。这些帐户可以在创建自动化帐户时创建，也可以选择稍后从 Azure 门户创建。

建议在稍后创建这些 Run As 帐户，而不是在创建自动化帐户时同时创建，因为如果在设置自动化帐户时创建，它们会在后台使用默认配置生成证书和服务主体。如果需要更多的控制和自定义配置（例如使用现有的证书或服务主体），则应在创建自动化帐户后再创建 Run As 帐户。

一旦创建了自动化帐户，它会提供一个仪表板，通过该仪表板可以启用多个自动化场景。

使用自动化帐户可以启用的一些重要场景包括：

• 流程自动化

• 配置管理

• 更新管理

自动化的目标是编写可重用且通用的脚本，以便它们可以在多个场景中重复使用。例如，一个自动化脚本应该足够通用，可以在任何资源组、任何订阅和管理组中启动和停止任何虚拟机（VM）。如果将虚拟机服务器信息与资源组、订阅和管理组的名称硬编码到脚本中，就会创建多个类似的脚本，并且任何一个脚本的更改都无可避免地会导致所有脚本的更改。为了避免这种情况，最好通过使用脚本参数和变量来创建一个通用的脚本，并确保执行者为这些脚本提供相应的值。

让我们更仔细地看一下前面提到的每个场景。

流程自动化

流程自动化指的是开发反映现实世界流程的脚本。流程自动化包括多个活动，每个活动执行一个独立的任务。所有这些活动共同组成一个完整的流程。活动的执行可能取决于前一个活动是否成功执行。

任何流程自动化都需要其执行所依赖的基础设施满足一些要求。以下是其中的一些要求：

• 创建工作流的能力

• 能够执行长时间运行的任务

• 能够在工作流未完成时保存执行状态，这也被称为检查点和水合作用

• 能够从最后保存的状态恢复，而不是从头开始

接下来我们要探讨的场景是配置管理。

配置管理

配置管理是指在整个生命周期内管理系统配置的过程。Azure 自动化状态配置是 Azure 的配置管理服务，允许用户为云节点和本地数据中心编写、管理和编译 PowerShell DSC 配置。

Azure 自动化状态配置让我们能够管理 Azure 虚拟机、Azure 经典虚拟机以及本地的物理机器或虚拟机（Windows/Linux），并且还支持其他云服务提供商的虚拟机。

Azure 自动化状态配置的最大优势之一是它提供了可扩展性。我们可以通过单一的中央管理界面管理成千上万台机器。我们可以轻松地将配置分配给机器，并验证它们是否符合预期的配置。

另一个优势是 Azure 自动化可以作为存储 所需状态配置（DSC）配置的仓库，且在需要时可以使用这些配置。

在下一节中，我们将讨论更新管理。

更新管理

正如你已经知道的那样，更新管理是客户在 IaaS 环境中负责管理更新和补丁的任务。Azure 自动化的更新管理功能可以用来自动化或管理 Azure 虚拟机的更新和补丁。有多种方式可以启用 Azure 虚拟机的更新管理：

• 从你的自动化帐户

• 通过浏览 Azure 门户

• 通过运行簿

• 从 Azure 虚拟机

从 Azure 虚拟机启用是最简单的方法。然而，如果你有大量虚拟机并且需要启用更新管理，那么你必须考虑一个可扩展的解决方案，例如运行簿或从自动化帐户进行操作。

既然你已经了解了相关场景，我们现在来探讨与 Azure 自动化相关的概念。

与 Azure 自动化相关的概念

现在你已经知道 Azure 自动化需要一个帐户，称为 Azure 自动化帐户。在我们深入探讨之前，让我们先了解与 Azure 自动化相关的概念。理解这些术语的含义非常重要，因为我们将在本章中贯穿使用这些术语。我们从运行簿开始。

运行簿

Azure 自动化运行簿是表示过程自动化中单个步骤或完整过程自动化的一组脚本语句。可以从父级运行簿调用其他运行簿，并且这些运行簿可以用多种脚本语言编写。支持编写运行簿的语言如下：

• PowerShell

• Python 2（截至目前）

• PowerShell 工作流

• 图形化 PowerShell

• 图形化 PowerShell 工作流

创建自动化账户非常简单，可以通过 Azure 门户完成。在所有服务面板中，你可以找到自动化账户，或者你可以在 Azure 门户中搜索它。如前所述，在创建过程中你将有机会创建一个 Run As 账户。图 4.4展示了创建自动化账户所需的输入信息：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.4.jpg

图 4.4：创建自动化账户

Run As 账户

默认情况下，Azure 自动化账户无法访问任何包含在 Azure 订阅中的资源，包括托管它们的订阅。账户需要访问 Azure 订阅及其资源，才能进行管理。Run As 账户是一种为订阅及其中的资源提供访问权限的方式。

这是一个可选练习。每个经典和资源管理器类型的订阅最多只能有一个 Run As 账户；然而，一个自动化账户可能需要连接到多个订阅。在这种情况下，建议为每个订阅创建共享资源并在 runbook 中使用。

创建自动化账户后，导航到门户中的Run As 账户视图，你将看到可以创建两种类型的账户。在图 4.5中，你可以看到Azure Run As 账户和Azure Classic Run As 账户的创建选项可用：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.5.jpg

图 4.5：Azure Run As 账户选项

这些 Run As 账户可以通过 Azure 门户、PowerShell 和 CLI 创建。有关通过 PowerShell 创建这些账户的信息，请访问docs.microsoft.com/azure/automation/manage-runas-account。

对于 ARM Run As 账户，该脚本会创建一个新的 Azure AD 服务主体和一个新的证书，并为新创建的服务主体提供在订阅上的贡献者 RBAC 权限。

作业

提交工作请求与执行工作请求并没有直接的关联，这是因为 Azure 自动化采用了松耦合架构。它们之间的联系是间接的，通过数据存储来实现。当自动化接收到执行 runbook 的请求时，它会在数据库中创建一条包含所有相关信息的新记录。Azure 中还运行着一个名为混合 Runbook Worker 的服务，它分布在多个服务器上，负责查找任何新添加到数据库中的记录，并执行 runbook。一旦它发现新记录，它会锁定该记录，以防其他服务读取，然后执行 runbook。

资源

Azure 自动化资产指的是可以在运行书之间共享并使用的工件。它们显示在图 4.6中：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.6.jpg

图 4.6：Azure 自动化中的共享工件

凭证

凭证指的是用于连接到需要身份验证的其他集成服务的机密信息，如用户名/密码组合。这些凭证可以在运行书中使用 Get-AutomationPSCredential PowerShell cmdlet 和其相关名称：

$myCredential = Get-AutomationPSCredential -Name 'MyCredential'

Python 语法要求我们导入 automationassets 模块，并使用 get_automation_credential 函数及其相关凭证名称：

import automationassets
cred = automationassets.get_automation_credential("credtest")

证书

证书指的是可以从证书颁发机构购买或自签的 X.509 证书。证书用于 Azure 自动化中的身份验证。每个证书都有一对密钥，称为私钥/公钥。私钥用于在 Azure 自动化中创建证书资产，公钥应在目标服务中可用。通过使用私钥，自动化账户可以创建数字签名，并将其附加到请求中，然后将请求发送到目标服务。目标服务可以使用已存在的公钥从数字签名中提取详细信息（哈希），从而确认请求发送者的身份。

证书资产存储 Azure 自动化中的证书信息和密钥。这些证书可以在运行书中直接使用，并且也被连接的资产所使用。下一节展示了如何在连接资产中使用证书。Azure 服务主体连接资产使用证书指纹来识别它想要使用的证书，而其他类型的连接则使用证书资产的名称来访问证书。

可以通过提供名称和上传证书来创建证书资产。可以上传公钥证书（.cer 文件）以及私钥证书（.pfx 文件）。证书的私钥部分也有一个密码，在访问证书之前需要使用该密码。

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.7.jpg

图 4.7：向 Azure 自动化添加证书

创建证书需要提供名称和描述，上传证书，提供密码（对于 .pfx 文件），并告知用户证书是否可以导出。

在创建此证书资产之前，必须有一个可用的证书。可以从证书颁发机构购买证书，也可以生成证书。生成的证书称为自签名证书。在生产环境等重要环境中，使用证书颁发机构的证书始终是最佳实践。用于开发目的时，使用自签名证书是可以的。

使用 PowerShell 生成自签名证书，请使用以下命令：

$cert = New-SelfSignedCertificate -CertStoreLocation "Cert:\CurrentUser\my" -KeySpec KeyExchange -Subject "cn=azureforarchitects"

这将在当前用户的个人文件夹中的证书存储中创建一个新证书。由于该证书还需要上传到 Azure 自动化证书资产，因此应将其导出到本地文件系统，如图 4.8所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.8.jpg

图 4.8：导出证书

导出证书时，还应导出私钥，因此应该选择是，导出私钥。

选择个人信息交换选项，其他值应保持默认。

提供密码和文件名C:\azureforarchitects.pfx，并且导出应该成功。

连接到 Azure 有多种方式。然而，最安全的方式是通过证书进行。服务主体是在 Azure 上使用证书创建的，可以使用证书进行身份验证。证书的私钥由用户持有，公钥部分由 Azure 持有。在下一节中，将使用本节中创建的证书来创建服务主体。

使用证书凭证创建服务主体

可以通过 Azure 门户、Azure CLI 或 Azure PowerShell 创建服务主体。使用 Azure PowerShell 创建服务主体的脚本在本节中提供。

登录 Azure 后，将上一节中创建的证书转换为 base64 编码。创建一个新的服务主体azureforarchitects，并将证书凭证与新创建的服务主体关联。最后，为新服务主体提供基于角色的访问控制权限，以便访问该订阅：

Login-AzAccount
$certKey = [system.Convert]::ToBase64String($cert.GetRawCertData())
$sp =  New-AzADServicePrincipal -DisplayName "azureforarchitects"
New-AzADSpCredential -ObjectId $sp.Id -CertValue $certKey -StartDate $cert.NotBefore -EndDate $cert.NotAfter
New-AzRoleAssignment -RoleDefinitionName contributor -ServicePrincipalName $sp.ApplicationId 
Get-AzADServicePrincipal -ObjectId $sp.Id
$cert.Thumbprint
Get-AzSubscription  

要创建连接资产，可以使用Get-AzADServicePrincipal cmdlet 获取应用程序 ID，结果如图 4.9所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.9.jpg

图 4.9：检查服务主体

可以使用证书引用和SubscriptionId来获取证书指纹，SubscriptionId可以通过Get-AzSubscription cmdlet 获取。

连接

连接资产用于创建与外部服务的连接信息。在这方面，Azure 也被视为外部服务。连接资产包含成功连接到服务所需的所有必要信息。Azure 自动化提供了三种默认的连接类型：

• Azure

• Azure 经典证书

• Azure 服务主体

使用 Azure 服务主体连接到 Azure 资源管理器资源，并使用 Azure 经典证书连接到 Azure 经典资源是一种良好的实践。需要注意的是，Azure 自动化不提供任何使用用户名和密码等凭据连接到 Azure 的连接类型。

Azure 和 Azure 经典证书本质上是相似的。它们都帮助我们连接到基于 Azure 服务管理 API 的资源。实际上，Azure 自动化在创建经典 Run As 帐户时，会创建一个 Azure 经典证书连接。

Azure 服务主体由 Run As 帐户内部使用，用于连接到基于 Azure 资源管理器的资源。

图 4.10 中显示了一个新的类型为 AzureServicePrincipal 的连接资产。它需要：

• 连接的名称。提供名称是必需的。

• 连接的描述。这个值是可选的。

• 在本章中，选择适当的 AzureServicePrincipal 用于创建连接资产。

• clientid 是在创建服务主体时生成的应用程序 ID。下一部分将展示如何使用 Azure PowerShell 创建服务主体的过程。提供应用程序 ID 是必需的。

• Get-AzSubscription cmdlet。提供租户标识符是必需的。

• CertificateThumbprint 是证书标识符。该证书应已通过证书资产上传到 Azure 自动化。提供证书指纹是必需的。

• SubscriptionId 是订阅的标识符。提供订阅 ID 是必需的。

您可以使用自动化帐户中的连接面板添加新连接，如图 4.10所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.10.jpg

图 4.10：将新连接添加到自动化帐户

Runbook 编写和执行

Azure 自动化允许创建称为 Runbook 的自动化脚本。可以通过 Azure 门户或 PowerShell ISE 创建多个 Runbook。它们也可以从Runbook 库导入。可以搜索特定功能，整个代码将在 Runbook 中显示。

Runbook 可以接受参数值，就像普通的 PowerShell 脚本一样。下一个示例接受一个名为 connectionName 的参数，类型为 string。在执行该 Runbook 时，必须为此参数提供值：

param(
    [parameter(mandatory=$true)]
    [string] $connectionName
)
$connection = Get-AutomationConnection  -name $connectionName  
$subscriptionid = $connection.subscriptionid
$tenantid = $connection.tenantid
$applicationid = $connection.applicationid
$cretThumbprint = $connection.CertificateThumbprint
Login-AzureRMAccount -CertificateThumbprint $cretThumbprint -ApplicationId $applicationid -ServicePrincipal -Tenant $tenantid  
Get-AzureRMVM

runbook 使用 Get-AutomationConnection cmdlet 引用共享连接资产。资产的名称包含在参数值中。引用连接资产后，连接引用中的值会填充到 $connection 变量中，并随后分配给多个其他变量。

Login-AzureRMAccount cmdlet 用于与 Azure 进行身份验证，并提供从连接对象中获得的值。它使用本章前面创建的服务主体进行身份验证。

最后，runbook 调用 Get-AzureRMVm cmdlet 来列出订阅中的所有虚拟机。

默认情况下，Azure Automation 仍提供用于与 Azure 一起工作的 AzureRM 模块。默认情况下，它不会安装 Az 模块。稍后我们将在 Azure Automation 帐户中手动安装 Az 模块，并在 runbook 中使用 cmdlet。

父级和子级 runbook

Runbook 具有生命周期，从编写到执行。这些生命周期可以分为编写状态和执行状态。

编写生命周期如图 4.11所示。

当新创建一个 runbook 时，它的状态为 New，当进行多次编辑和保存后，状态变为 In edit，最终，当它被发布时，状态更改为 Published。已发布的 runbook 也可以进行编辑，在这种情况下，状态会返回为 In edit。

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.11.jpg

图 4.11：编写生命周期

接下来将描述执行生命周期。

生命周期从 runbook 执行请求开始。runbook 可以通过多种方式执行：

• 通过 Azure 门户手动启动

• 通过将父级 runbook 作为子级 runbook 使用

• 通过 webhook 方式

无论 runbook 是如何启动的，生命周期都是相同的。执行 runbook 的请求会被自动化引擎接收，自动化引擎会创建一个作业并将其分配给 runbook worker。目前，runbook 的状态为 Queued。

有多个 runbook worker，选定的 worker 会接收作业请求并将状态更改为 Starting。此时，如果脚本中存在任何脚本编写或解析问题，状态会变为 Failed，执行将被中止。

一旦 runbook 执行被 worker 启动，状态将变为 Running。runbook 在运行时可能会有多种不同的状态。

如果执行过程中没有未处理的终止异常，runbook 的状态会变为 Completed。

运行中的 runbook 可以由用户手动停止，状态将变为 Stopped。

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.12.jpg

图 4.12：runbook 的执行生命周期

用户还可以暂停和恢复 runbook 的执行。

创建一个运行簿

可以通过访问 Azure 门户中的左侧导航面板中的运行簿菜单项来创建运行簿。一个运行簿具有名称和类型。类型决定了用于创建运行簿的脚本语言。我们已经讨论了可能的语言，本章中将主要使用 PowerShell 进行所有示例。

创建 PowerShell 运行簿与创建 PowerShell 脚本完全相同。它可以声明并接受多个参数—这些参数可以具有数据类型等属性，其中一些是必填的（就像任何 PowerShell 参数属性一样）。它可以调用已加载和声明的 PowerShell cmdlet 模块，也可以调用函数并返回输出。

运行簿还可以调用另一个运行簿。它可以在原始流程和上下文内调用子运行簿，或者在单独的流程和上下文中调用。

内联调用运行簿类似于调用 PowerShell 脚本。下一个示例使用内联方法调用子运行簿：

.\ConnectAzure.ps1 -connectionName "azureforarchitectsconnection"
Get-AzSqlServer

在前面的代码中，我们看到ConnectAzure运行簿如何接受一个名为connectionName的参数，并向其提供适当的值。此运行簿在通过服务主体进行身份验证后创建与 Azure 的连接。请查看调用子运行簿的语法，它与调用一般 PowerShell 脚本并传递参数非常相似。

下一行代码Get-AzVm从 Azure 获取相关信息并列出虚拟机的详细信息。你会注意到，尽管身份验证是在子运行簿中进行的，但Get-AzVm cmdlet 成功执行，并列出了订阅中的所有虚拟机，因为子运行簿在与父运行簿相同的作业中执行，它们共享上下文。

另外，可以使用 Azure 自动化提供的Start-AzurermAutomationRunbook cmdlet 来调用子运行簿。此 cmdlet 接受自动化帐户的名称、资源组名称以及运行簿的名称和参数，详情如下：

$params = @{"connectionName"="azureforarchitectsconnection"}
$job = Start-AzurermAutomationRunbook '
    –AutomationAccountName 'bookaccount' '
    –Name 'ConnectAzure' '
    -ResourceGroupName 'automationrg' -parameters $params
if($job -ne $null) {
    Start-Sleep -s 100
    $job = Get-AzureAutomationJob -Id $job.Id -AutomationAccountName 'bookaccount'
    if ($job.Status -match "Completed") {
        $jobout = Get-AzureAutomationJobOutput '
                                    -Id $job.Id '
                                    -AutomationAccountName 'bookaccount' '
                                    -Stream Output
                    if ($jobout) {Write-Output $jobout.Text}
    }
}

使用这种方法会创建一个新的作业，它与父作业不同，并且在不同的上下文中运行。

使用 Az 模块

到目前为止，所有示例都使用了AzureRM模块。之前展示的运行簿将重新编写，改为使用Az模块中的 cmdlet。

如前所述，Az模块默认并未安装。可以通过 Azure 自动化中的模块库菜单项来安装它们。

在库中搜索Az，结果会显示与之相关的多个模块。如果选择导入并安装Az模块，系统会抛出一个错误，表示其依赖的模块未安装，并且需要先安装这些模块才能安装当前模块。该模块可以在Az上找到，如图 4.13所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.13.jpg

图 4.13：在模块库面板中查找 Az 模块

不选择Az模块，而是选择Az.Accounts并按照向导导入该模块，如图 4.14所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.14.jpg

图 4.14：导入 Az.Accounts 模块

安装Az.Accounts后，可以导入Az.Resources模块。与 Azure 虚拟机相关的 cmdlet 位于Az.Compute模块中，可以使用与导入Az.Accounts相同的方法导入它。

导入这些模块后，runbook 可以使用这些模块提供的 cmdlet。之前展示的ConnectAzure runbook 已被修改为使用Az模块：

param(
    [parameter(mandatory=$true)]
    [string] $connectionName
)
$connection = Get-AutomationConnection  -name $connectionName  
$subscriptionid = $connection.subscriptionid
$tenantid = $connection.tenantid
$applicationid = $connection.applicationid
$cretThumbprint = $connection.CertificateThumbprint
Login-AzAccount -CertificateThumbprint $cretThumbprint -ApplicationId $applicationid -ServicePrincipal -Tenant $tenantid  -SubscriptionId  $subscriptionid 
Get-AzVm

代码的最后两行很重要。它们使用的是Az cmdlet，而不是AzureRM cmdlet。

执行此 runbook 将得到类似以下的结果：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.15.jpg

图 4.15：Az.Accounts 模块成功导入

在下一节中，我们将使用 Webhook。

Webhooks

Webhook 在 REST 端点和 JSON 数据负载出现后变得流行。Webhook 是任何应用程序可扩展性中的一个重要概念和架构决策。Webhook 是应用程序中特殊区域中的占位符，用户可以用包含自定义逻辑的端点 URL 填充这些占位符。应用程序将调用端点 URL，自动传递必要的参数，并执行其中的登录操作。

Azure Automation 的 runbook 可以通过 Azure 门户手动调用。它们也可以使用 PowerShell cmdlet 和 Azure CLI 调用。还有多种语言的 SDK 可用于调用 runbook。

Webhook 是调用 runbook 的最强大方式之一。需要注意的是，包含主要逻辑的 runbook 不应直接暴露为 Webhook。它们应该通过父级 runbook 来调用，且父级 runbook 应暴露为 Webhook。父级 runbook 应确保在调用子级 runbook 之前进行适当的检查。

创建 Webhook 的第一步是正常编写 runbook，如之前所做的。编写完 runbook 后，它将作为 Webhook 暴露。

创建了一个新的基于 PowerShell 的 runbook，名为exposedrunbook。此 runbook 接受一个名为$WebhookData的单一参数，类型为对象。它应命名为verbatim。该对象由 Azure Automation 运行时创建，并传递给 runbook。Azure Automation 运行时在获取 HTTP 请求头值和正文内容后构建该对象，并填充此对象的RequestHeader和RequestBody属性：

param(
    [parameter(mandatory=$true)]
    [object] $WebhookData
)
$webhookname = $WebhookData.WebhookName
$headers = $WebhookData.RequestHeader
$body = $WebhookData.RequestBody
Write-output "webhook header data"
Write-Output $webhookname
Write-output $headers.message
Write-output $headers.subject
 $connectionname = (ConvertFrom-Json -InputObject $body)
./connectAzure.ps1 -connectionName  $connectionname[0].name

该对象的三个重要属性是WebhookName、RequestHeader和RequestBody。这些属性的值将被检索，并由 runbook 发送到输出流。

头部和正文内容可以是用户在触发 webhook 时提供的任何内容。这些值会填充到相应的属性中，并在 runbook 中使用。在前面的示例中，调用者设置了两个头部，分别是 message 和 status 头部。调用者还将提供要作为正文内容一部分使用的共享连接名称。

在创建 runbook 后，必须先发布它，才能创建 webhook。发布 runbook 后，点击顶部的 Webhook 菜单，开始为该 runbook 创建一个新的 webhook，如 图 4.16 所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.16.jpg

图 4.16：创建 webhook

应为 webhook 提供一个名称。此值可以在 runbook 中通过 WebhookData 参数与 WebhookName 属性名称进行访问。

webhook 可以处于 enabled 或 disabled 状态，并且可以在指定的日期和时间过期。它还会生成一个唯一的 URL，适用于此 webhook 和 runbook。此 URL 应提供给任何希望触发 webhook 的人。

触发 webhook

Webhook 是通过使用 POST 方法的 HTTP 请求来触发的。当触发 webhook 时，HTTP 请求会传递到 Azure Automation，以启动一个 runbook。它会创建 WebHookData 对象，填充传入的 HTTP 头部和正文数据，并创建一个任务，由 runbook 工作者处理。此调用使用在前一步中生成的 webhook URL。

webhook 可以通过 Postman 或任何能够使用 POST 方法调用 REST 端点的代码来触发。在下一个示例中，将使用 PowerShell 来触发 webhook：

$uri = "https://s16events.azure-automation.net/webhooks?token=rp0w93L60fAPYZQ4vryxl%2baN%2bS1Hz4F3qVdUaKUDzgM%3d"
$connection  = @(
            @{  name="azureforarchitectsconnection"}

        )
$body = ConvertTo-Json -InputObject $ connection  
$header = @{ subject="VMS specific to Ritesh";message="Get all virtual machine details"}

$response = Invoke-WebRequest -Method Post -Uri $uri -Body $body -Headers $header
$jobid = (ConvertFrom-Json ($response.Content)).jobids[0] 

PowerShell 代码声明了 webhook 的 URL，并以 JSON 格式构建正文，name 设置为 azureforarchitectsconnection，并设置了两个头部名称-值对：subject 和 message。头部和正文数据都可以通过 WebhookData 参数在 runbook 中获取。

invoke-webrequest cmdlet 使用 POST 方法在前面提到的端点上发起请求，提供头部和正文。

请求是异步的，返回的是任务标识符，而不是实际的 runbook 输出，并且该标识符也可以在响应内容中获取。任务显示在 图 4.17 中：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.17.jpg

图 4.17：检查任务

点击 WEBHOOKDATA 会显示通过 HTTP 请求到达 runbook 自动化服务的值：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.18.jpg

图 4.18：验证输出

点击输出菜单会显示订阅中虚拟机和 SQL 服务器的列表。

Azure 自动化中的下一个重要概念是 Azure Monitor 和混合工作者，接下来的章节将详细解释这些概念。

从 Azure Monitor 中调用运行书

Azure 自动化运行书可以作为响应来调用，响应 Azure 中生成的警报。Azure Monitor 是一个集中式服务，用于管理订阅中资源和资源组的日志与指标。您可以使用 Azure Monitor 创建新的警报规则和定义，触发时可以执行 Azure 自动化运行书。它们可以以默认形式调用 Azure 自动化运行书，或者调用一个 Webhook，Webhook 进一步执行其关联的运行书。Azure Monitor 与运行书的调用能力之间的集成为自动修正环境、上下调计算资源或在无需人工干预的情况下进行纠正操作提供了无数的自动化机会。

可以在单个资源和资源级别创建和配置 Azure 警报，但最佳实践是将警报定义集中管理，便于维护和管理。

让我们一步步讲解如何将运行书与警报关联，并在警报触发时调用运行书。

第一步是创建一个新的警报，如图 4.19所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.19.jpg

图 4.19：创建警报规则

选择一个应被监控并评估以生成警报的资源。已经从列表中选择了一个资源组，它会自动启用资源组内的所有资源。也可以从资源组中移除资源选择：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.20.jpg

图 4.20：选择警报的范围

配置应评估的条件和规则。在选择活动日志作为信号类型后，选择关闭虚拟机信号名称：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.21.jpg

图 4.21：选择信号类型

结果窗口将允许您为成功配置严重级别：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.22.jpg

图 4.22：设置警报逻辑

在确定警报条件之后，最重要的配置就是配置通过调用运行书响应警报。我们可以使用操作组来配置警报的响应。它提供了多种选项，可以调用 Azure 函数、Webhook 或 Azure 自动化运行书，还可以发送电子邮件和短信。

创建一个操作组，提供名称、简短名称、托管订阅、资源组，并将操作类型设置为自动化运行书：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.23.jpg

图 4.23 配置操作组

选择一个自动化运行簿将打开另一个面板，用于选择适当的 Azure 自动化帐户和运行簿。系统提供了多个预设的运行簿，本文中使用了其中一个：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.24.jpg

图 4.24 创建运行簿

最后，提供一个名称和托管资源组来创建一个新的警报。

如果虚拟机被手动取消分配，警报条件将被满足，并会触发警报：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.25.jpg

图 4.25 测试警报

如果你在几秒钟后检查虚拟机的详细信息，你应该会看到虚拟机正在被删除：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.26.jpg

图 4.26 验证结果

混合工作者

到目前为止，所有的运行簿执行主要是在 Azure 提供的基础设施上进行的。运行簿工作者是由 Azure 提供的计算资源，在其中部署了适当的模块和资源。任何运行簿的执行都发生在这些计算资源上。然而，用户也可以提供自己的计算资源，并在用户提供的计算资源上执行运行簿，而不是在默认的 Azure 计算资源上。

这有多个优点。首先，整个执行过程及其日志由用户拥有，Azure 无法查看这些内容。其次，用户提供的计算资源可以位于任何云环境中，甚至可以是本地部署的。

添加混合工作者涉及多个步骤

• 首先，必须在用户提供的计算资源上安装一个代理。微软提供了一个脚本，可以自动下载并配置代理。此脚本可以从www.powershellgallery.com/packages/New-OnPremiseHybridWorker/1.6获取。

  脚本也可以通过 PowerShell ISE 以管理员身份在应成为混合工作者一部分的服务器上执行，使用以下命令：

  Install-Script -Name New-OnPremiseHybridWorker -verbose
  

• 脚本安装后，可以与相关的 Azure 自动化帐户详细信息一起执行。同时还为混合工作者提供了一个名称。如果该名称不存在，将会创建；如果已存在，服务器将被添加到现有的混合工作者中。一个混合工作者中可以包含多个服务器，同时也可以有多个混合工作者：

  New-OnPremiseHybridWorker.ps1 -AutomationAccountName bookaccount -AAResourceGroupName automationrg '
  -HybridGroupName "localrunbookexecutionengine" '
  -SubscriptionID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  
  

• 执行完成后，返回到门户将显示混合工作者的条目，如图 4.27所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.27.jpg

图 4.27：检查用户的混合工作者组

• 如果此时执行一个依赖于Az模块和已上传到证书资产的自定义证书的 Azure 运行簿，它将由于找不到Az模块和证书而失败，并显示相关错误：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.28.jpg

图 4.28：检查错误

• 使用以下命令在服务器上安装Az模块：

  Install-module -name Az -AllowClobber -verbose
  

  此外，在此服务器上还必须有.pfx证书。之前导出的证书应复制到服务器并手动安装。

• 安装Az模块和证书后，在 Hybrid Worker 上重新执行运行簿，如图 4.29所示，应该会显示订阅中的虚拟机列表：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.29.jpg

图 4.29：在 Hybrid Worker 上设置运行簿

当我们讨论不同的场景时，我们谈到了配置管理。在下一节中，我们将更详细地讨论 Azure Automation 中的配置管理。

Azure Automation 状态配置

Azure Automation 为每个 Azure Automation 帐户提供期望状态配置（DSC）拉取服务器。拉取服务器可以保存配置脚本，供跨云和本地的服务器拉取。这意味着 Azure Automation 可以用于配置世界上任何地方托管的服务器。

DSC 需要在这些服务器上安装本地代理，也叫本地配置管理器（LCM）。它应该与 Azure Automation DSC 拉取服务器进行配置，以便能够下载所需的配置并自动配置服务器。

自动配置可以设置为周期性（默认情况下为半小时），如果代理发现服务器配置与 DSC 脚本中提供的配置有任何偏差，它将自动纠正并使服务器恢复到期望的状态。

在本节中，我们将配置一个托管在 Azure 上的服务器，无论该服务器是位于云端还是本地，整个过程将保持一致。

第一步是创建 DSC 配置。这里展示了一个示例配置，复杂的配置可以类似地编写：

configuration ensureiis {
import-dscresource -modulename psdesiredstateconfiguration

node localhost {        
        WindowsFeature iis {
            Name = "web-server"
            Ensure = "Present"

        }
    }
}

配置非常简单。它导入了PSDesiredStateConfiguration基础 DSC 模块，并声明了一个单节点配置。此配置不与任何特定节点关联，可以用于配置任何服务器。该配置旨在配置 IIS web 服务器，并确保其在应用到的任何服务器上存在。

此配置尚未在 Azure 自动化 DSC 拉取服务器上可用，因此第一步是将配置导入到拉取服务器。这可以通过使用自动化帐户的 Import-AzAutomationDscConfiguration cmdlet 来完成，如下所示：

Import-AzAutomationDscConfiguration -SourcePath "C:\Ritesh\ensureiis.ps1" -AutomationAccountName bookaccount -ResourceGroupName automationrg -Force -Published

这里有几个重要事项需要注意。配置名称应与文件名匹配，且只能包含字母数字字符和下划线。一个好的命名约定是使用动词/名词组合。cmdlet 需要配置文件的路径和 Azure 自动化帐户的详细信息来导入配置脚本。

此时，配置在门户中可见：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.30.jpg

图 4.30：添加配置

一旦配置脚本被导入，它会使用 Start-AzAutomationDscCompilationJob cmdlet 在 DSC 拉取服务器上进行编译并存储，如下所示：

Start-AzAutomationDscCompilationJob -ConfigurationName 'ensureiis' -ResourceGroupName 'automationrg' -AutomationAccountName 'bookaccount'

配置的名称应与最近上传的名称匹配，且已编译的配置现在应该可以在 已编译配置 标签页中找到，如 图 4.31 所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.31.jpg

图 4.31：列出已编译的配置

需要注意的是，0 表示存在一个名为 ensureiss.localhost 的节点配置，但尚未分配给任何节点。下一步是将配置分配给该节点。

到目前为止，我们在 DSC 拉取服务器上有了一个已编译的 DSC 配置，但没有节点可以管理。下一步是将虚拟机加入并与 DSC 拉取服务器关联。这是通过使用 Register-AzAutomationDscNode cmdlet 完成的：

Register-AzAutomationDscNode -ResourceGroupName 'automationrg' -AutomationAccountName 'bookaccount' -AzureVMLocation "west Europe" -AzureVMResourceGroup 'spark' -AzureVMName 'spark' -ConfigurationModeFrequencyMins 30 -ConfigurationMode 'ApplyAndAutoCorrect' 

此 cmdlet 需要提供虚拟机和 Azure 自动化帐户的资源组名称。它还配置了虚拟机本地配置管理器的配置模式和configurationModeFrequencyMins属性。此配置每 30 分钟检查并自动修正任何偏离已应用配置的情况。

如果未指定 VMresourcegroup，cmdlet 会尝试在与 Azure 自动化帐户相同的资源组中查找虚拟机，如果未提供虚拟机位置值，它会尝试在 Azure 自动化区域中查找虚拟机。最好为它们提供值。请注意，此命令仅适用于 Azure 虚拟机，因为它明确要求提供 AzureVMname。对于其他云和本地服务器，请使用 Get-AzAutomationDscOnboardingMetaconfig cmdlet。

现在，新的节点配置条目也可以在门户中找到，如 图 4.32 所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.32.jpg

图 4.32：验证节点状态

可以通过以下方式获取节点信息：

$node = Get-AzAutomationDscNode -ResourceGroupName 'automationrg' -AutomationAccountName 'bookaccount' -Name 'spark' 

可以将配置分配给节点：

Set-AzAutomationDscNode -ResourceGroupName 'automationrg' -AutomationAccountName 'bookaccount' -NodeConfigurationName 'ensureiis.localhost' -NodeId $node.Id 

一旦编译完成，就可以将其分配给节点。初始状态为待处理，如图 4.33所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.33.jpg

图 4.33：验证节点状态

几分钟后，配置应用到节点，节点变为合规，状态变为已完成：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.34.jpg

图 4.34：验证节点是否合规

稍后，通过登录到服务器并检查 Web 服务器（IIS）是否已安装，确认它已经安装，正如你在图 4.35中看到的：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Figure_4.35.jpg

图 4.35：检查是否已达到预期状态

下一节将讨论 Azure Automation 定价。

Azure Automation 定价

如果 Azure Automation 上没有执行任何 runbook，则不收取费用。Azure Automation 的费用按 runbook 任务执行的分钟数计费。这意味着，如果总的 runbook 执行分钟数为 10,000，则 Azure Automation 的费用为每分钟 0.002 美元，乘以 9,500，因为前 500 分钟是免费的。

在 Azure Automation 中，涉及其他费用，这取决于使用的功能。例如，DSC 拉取服务器在 Azure Automation 中是免费的；将 Azure 虚拟机添加到拉取服务器也不收费。然而，如果将非 Azure 服务器加入，通常是来自其他云或本地部署的服务器，那么前五台服务器是免费的，超出部分的费用是每台服务器每月 6 美元（在西美地区）。

定价可能会因地区而异，通常最好通过官方定价页面确认定价：azure.microsoft.com/pricing/details/automation。

你可能会问，既然我们可以通过 Azure Functions 部署无服务器应用，为什么还需要 Automation 账户？在下一节中，我们将探讨 Azure Automation 与无服务器自动化之间的关键区别。

与无服务器自动化的比较

Azure Automation 和 Azure 无服务器技术，尤其是 Azure Functions，在功能上非常相似并有所重叠。然而，这些是不同的服务，具有不同的功能和定价。

重要的是要理解，Azure Automation 是一个完整的流程自动化和配置管理套件，而 Azure Functions 是用于实现业务功能的服务。

Azure 自动化用于自动化基础设施的供应、撤销、管理和操作过程，以及随后的配置管理。另一方面，Azure Functions 旨在创建服务，实现可以作为微服务和其他 API 一部分的功能。

Azure 自动化并不适用于无限扩展，负载预计为中等，而 Azure Functions 可以处理无限流量并自动扩展。

在 Azure 自动化中，有许多共享资产，如连接、变量和模块，可以在运行簿之间重用；然而，Azure Functions 中没有现成的共享概念。

Azure 自动化通过检查点管理中间状态，并能够从最后保存的状态继续，而 Azure Functions 通常是无状态的，不维护任何状态。

总结

Azure 自动化是 Azure 中一项重要服务，也是唯一用于流程自动化和配置管理的服务。本章涵盖了与 Azure 自动化和流程自动化相关的许多重要概念，包括共享资产，如连接、证书和模块。

本章介绍了运行簿的创建，包括以不同方式调用运行簿，如父子关系、Webhook 和使用门户。还讨论了运行簿的架构和生命周期。

我们还研究了混合工作者的使用，并在本章结尾探讨了使用 DSC 拉取服务器和本地配置管理器进行配置管理。最后，我们与其他技术（如 Azure Functions）进行了比较。

在下一章中，我们将探讨为 Azure 部署设计策略、锁定和标签。

第五章：5. 设计 Azure 部署的策略、锁定和标签

Azure 是一个多功能的云平台。客户不仅可以创建和部署他们的应用程序，还可以积极管理和治理他们的环境。云计算通常遵循按需付费的模式，客户可以订阅并将几乎任何东西部署到云端。它可以是一个简单的虚拟机，也可以是数千个具有更高库存单位（SKU）的虚拟机。Azure 不会阻止任何客户配置他们希望配置的资源。在一个组织内，可能有很多人可以访问该组织的 Azure 订阅。需要建立一个治理模型，以确保只有具有创建权限的人才能配置必要的资源。Azure 提供了资源管理功能，如Azure 基于角色的访问控制（RBAC）、Azure 策略、管理组、蓝图和资源锁定，用于管理和提供资源治理。

治理的其他主要方面包括成本、使用情况和信息管理。组织的管理团队总是希望实时了解云计算消耗和成本情况。他们希望能够识别出哪些团队、部门或单位使用了多少比例的总成本。简而言之，他们希望能够基于不同的消费和成本维度生成报告。Azure 提供了一种标签功能，可以帮助实时提供这类信息。

在本章中，我们将涵盖以下主题：

• Azure 管理组

• Azure 标签

• Azure 策略

• Azure 锁定

• Azure RBAC

• Azure 蓝图

• 实施 Azure 治理功能

Azure 管理组

我们从 Azure 管理组开始，因为在接下来的章节中，我们会引用或提到管理组。管理组充当作用域级别，使你能够有效地分配或管理角色和策略。如果你有多个订阅，管理组非常有用。

管理组充当组织订阅的占位符。你也可以拥有嵌套的管理组。如果在管理组层级应用策略或访问权限，它将被下层的管理组和订阅继承。从订阅层级开始，这些策略或访问权限将被资源组继承，最终被资源继承。

管理组的层次结构如下所示：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_05_01.jpg

图 5.1：Azure 管理组的层次结构

在图 5.1 中，我们使用管理组将不同部门的操作分开，如市场营销、IT 和人力资源。在每个部门内部，有嵌套的管理组和订阅，这有助于将资源组织成层次结构，以便进行政策和访问管理。稍后，您将看到管理组如何作为治理、政策管理和访问管理的范围。

在下一部分，我们将讨论 Azure 标签，它在资源的逻辑分组中发挥着另一个重要作用。

Azure 标签

Azure 允许通过名称-值对对资源组和资源进行标签标记。标签帮助对资源进行逻辑组织和分类。Azure 还允许对资源组及其资源标记最多 50 个名称-值对。尽管资源组充当资源的容器或占位符，但标记资源组并不意味着标记其组成资源。资源组和资源应根据其使用情况进行标记，本节稍后将解释这一点。标签绑定到订阅、资源组或资源。Azure 接受任何名称-值对，因此组织需要定义名称及其可能的值。

那么，为什么标签很重要呢？换句话说，标签能解决哪些问题？标签具有以下优点：

• 资源分类：一个 Azure 订阅可以被组织内的多个部门使用。管理团队需要识别任何资源的所有者。标签有助于为资源分配标识符，这些标识符可以代表部门或角色。

• Azure 资源的信息管理：同样，Azure 资源可以由任何有权限访问订阅的人进行配置。为了符合信息管理政策，组织通常希望对资源进行适当的分类。这些政策可以基于应用程序生命周期管理，如开发、测试和生产环境的管理。它们还可以基于使用情况或任何其他优先事项。每个组织都有自己定义信息类别的方式，Azure 通过标签满足这一需求。

• 成本管理：在 Azure 中使用标签可以根据资源的分类帮助识别资源。例如，可以针对 Azure 执行查询，以识别每个类别的成本。例如，Azure 中为财务部门和市场部门开发环境的资源成本可以轻松确定。此外，Azure 还提供基于标签的计费信息，这有助于识别团队、部门或小组的消耗率。

然而，Azure 中的标签确实存在一些限制：

• Azure 允许最多 50 个标签名称-值对与资源组关联。

• 标签是不可继承的。应用于资源组的标签不会应用于其中的单个资源。然而，在为资源配置时，容易忘记为资源添加标签。Azure 策略提供了一种机制，确保在配置时为资源添加适当的标签值。我们将在本章稍后讨论这类策略的详细信息。

可以使用 PowerShell、Azure CLI 2.0、Azure 资源管理器模板、Azure 门户和 Azure 资源管理器 REST API 来为资源和资源组分配标签。

这里展示了使用 Azure 标签进行信息管理分类的示例：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_05_02.jpg

图 5.2：使用 Azure 标签进行信息管理分类

在这个示例中，Department、Project、Environment、Owner、Approver、Maintainer、Start Date、Retire Date 和 Patched Date 等名称-值对用于为资源添加标签。使用 PowerShell、Azure CLI 或 REST API，非常容易查找具有特定标签或标签组合的所有资源。下一节将讨论如何使用 PowerShell 为资源分配标签。

使用 PowerShell 的标签

可以使用 PowerShell、Azure 资源管理器模板、Azure 门户和 REST API 来管理标签。在本节中，将使用 PowerShell 来创建和应用标签。PowerShell 提供了一个 cmdlet 用于检索并附加标签到资源组和资源：

• 要使用 PowerShell 检索与资源关联的标签，可以使用 Get-AzResource cmdlet：

  (Get-AzResource -Tag @{ "Environment"="Production"}).Name 
  

• 要使用 PowerShell 检索与资源组关联的标签，可以使用以下命令：

  Get-AzResourceGroup -Tag @{"Environment"="Production"} 
  

• 要为资源组设置标签，可以使用 Update-AzTag cmdlet：

  $tags = @{"Dept"="IT"; "Environment"="Production"}
  $resourceGroup = Get-AzResourceGroup -Name demoGroup
  New-AzTag -ResourceId $resourceGroup.ResourceId -Tag $tags
  

• 要为资源设置标签，可以使用相同的 Update-AzTag cmdlet：

  $tags = @{"Dept"="Finance"; "Status"="Normal"}
  $resource = Get-AzResource -Name demoStorage -ResourceGroup demoGroup 
  New-AzTag -ResourceId $resource.id -Tag $tags
  

• 你可以使用 Update-AzTag 命令更新现有标签；但是，你需要指定操作为 Merge 或 Replace。Merge 将把你传入的新标签附加到现有标签中；而 Replace 操作将替换掉所有旧标签，使用新标签。下面是一个不替换现有标签的资源组标签更新示例：

  $tags = @{"Dept"="IT"; "Environment"="Production"}
  $resourceGroup = Get-AzResourceGroup -Name demoGroup
  Update-AzTag -ResourceId $resourceGroup.ResourceId -Tag $tags  -Operation Merge
  

现在让我们来看一下使用 Azure 资源管理器模板的标签。

使用 Azure 资源管理器模板的标签

Azure 资源管理器模板也有助于为每个资源定义标签。可以使用它们为每个资源分配多个标签，如下所示：

{ 
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", 
    "contentVersion": "1.0.0.0", 
    "resources": [ 
    { 
      "apiVersion": "2019-06-01", 
      "type": "Microsoft.Storage/storageAccounts", 
      "name": "[concat('storage', uniqueString(resourceGroup().id))]", 
      "location": "[resourceGroup().location]", 
      "tags": { 
        "Dept": "Finance", 
        "Environment": "Production" 
      }, 
      "sku": { 
        "name": "Standard_LRS" 
      }, 
      "kind": "Storage", 
      "properties": { } 
    } 
    ] 
}

在前面的示例中，使用 Azure 资源管理器模板为存储帐户资源添加了两个标签，Dept 和 Environment。

资源组标签与资源标签的区别

架构师必须决定 Azure 资源和资源组的分类法和信息架构。他们应根据查询要求识别资源的分类标准。然而，他们还必须确定标签应该附加到单个资源上，还是附加到资源组上。

如果资源组内的所有资源都需要相同的标签，那么最好给资源组打标签，尽管标签不会继承到资源组中的资源。如果您的组织要求将标签传递到所有底层资源，可以考虑编写 PowerShell 脚本，从资源组获取标签，并更新资源组中资源的标签。在决定是否在资源级别或资源组级别应用标签之前，重要的是考虑对标签的查询。如果查询涉及跨订阅和跨资源组的单个资源类型，那么为单个资源分配标签更为合理。然而，如果仅通过识别资源组就能有效地进行查询，那么标签应仅应用于资源组。如果您将资源从一个资源组移动到另一个资源组，资源组级别应用的标签将丢失。如果您要移动资源，请考虑重新添加标签。

Azure 策略

在上一节中，我们讨论了如何为 Azure 部署应用标签。标签在组织资源方面非常有用；然而，还有一件事没有讨论：组织如何确保每次部署都应用了标签？应该对 Azure 标签进行自动化强制执行，确保资源和资源组都应用标签。Azure 本身没有检查机制来确保资源和资源组上应用了适当的标签。这不仅仅是标签的问题——这适用于 Azure 上任何资源的配置。例如，您可能希望限制资源的地理位置（例如，仅限于美国东部地区）。

你可能已经猜到，这一节主要是讲述如何在 Azure 上制定治理模型。治理是 Azure 中的重要元素，因为它确保每个访问 Azure 环境的人都能了解组织的优先事项和流程。它还有助于控制成本，并帮助定义管理资源的组织惯例。

每个策略可以通过多个规则构建，多个策略可以应用到订阅或资源组。根据规则是否满足，策略可以执行各种操作。操作可以是拒绝正在进行的交易、审计交易（即写入日志并允许其完成），或者如果发现缺少元数据，则将元数据附加到交易中。

策略可能与资源的命名约定、资源的标签、可配置的资源类型、资源的位置或这些的任意组合相关。

Azure 提供了众多内置策略，并且可以创建自定义策略。可以使用基于 JSON 的策略语言来定义自定义策略。

现在你已经了解了 Azure 策略的目的和使用场景，让我们继续讨论内置策略、策略语言和自定义策略。

内置策略

Azure 提供了一个用于创建自定义策略的服务；然而，它也提供了一些现成的策略，这些策略可以用于治理。这些策略涉及允许的位置、允许的资源类型和标签。有关这些内置策略的更多信息，请访问docs.microsoft.com/azure/azure-resource-manager/resource-manager-policy。

策略语言

Azure 中的策略使用 JSON 来定义和描述策略。政策采用有两个步骤：首先定义策略，然后应用和分配它。策略具有作用域，可以在管理组、订阅或资源组级别应用。

策略是使用if...then块定义的，类似于任何流行编程语言。if块会执行以评估条件，基于这些条件的结果，then块将会执行：

{ 
  "if": { 
    <condition> | <logical operator> 
  }, 
  "then": { 
    "effect": "deny | audit | append" 
  } 
} 

策略不仅允许简单的if条件，还允许将多个if条件逻辑地连接起来，创建复杂的规则。这些条件可以通过AND、OR和NOT运算符连接：

• AND语法要求所有条件都为真。

• OR语法要求至少有一个条件为真。

• NOT语法反转条件的结果。

接下来是AND语法，它由allOf关键字表示：

"if": { 
  "allOf": [ 
    { 
       "field": "tags", 
        "containsKey": "application" 
    }, 
    { 
      "field": "type", 
      "equals": "Microsoft.Storage/storageAccounts" 
    } 
  ] 
}, 

接下来是OR语法，它由anyOf关键字表示：

"if": { 
  "anyOf": [ 
    { 
       "field": "tags", 
        "containsKey": "application" 
    }, 
    { 
      "field": "type", 
      "equals": "Microsoft.Storage/storageAccounts" 
    } 
  ] 
}, 

接下来是NOT语法，它由not关键字表示：

"if": { 
  "not": [ 
    { 
       "field": "tags", 
        "containsKey": "application" 
    }, 
    { 
      "field": "type", 
      "equals": "Microsoft.Storage/storageAccounts" 
    } 
  ] 
}, 

事实上，这些逻辑运算符可以组合在一起，如下所示：

"if": { 
  "allOf": [ 
    { 
      "not": { 
        "field": "tags", 
        "containsKey": "application" 
      } 
    }, 
    { 
      "field": "type", 
      "equals": "Microsoft.Storage/storageAccounts" 
    } 
  ] 
},

这与在流行编程语言（如 C#和 Node.js）中使用if条件非常相似：

If ("type" == "Microsoft.Storage/storageAccounts") { 
      Deny 
}

需要注意的是，虽然有Deny操作，但没有allow操作。这意味着策略规则应考虑到可能的拒绝，规则应评估条件并在满足条件时Deny该操作。

允许的字段

在定义策略时，允许的条件字段如下：

• Name：应用策略的资源名称。这是非常具体的，并且适用于资源的使用。

• Type：资源类型，例如Microsoft.Compute/VirtualMachines。这将把策略应用于所有虚拟机实例。

• Location：资源的位置（即 Azure 区域）。

• 标签：与资源关联的标签。

• 属性别名：特定资源的属性。这些属性对于不同的资源是不同的。

在下一节中，你将学习更多关于如何保护生产环境中的资源的信息。

Azure 锁定

锁定是一种停止对资源执行某些操作的机制。RBAC（基于角色的访问控制）为用户、组和应用程序提供在特定范围内的权限。有现成的 RBAC 角色，例如所有者、贡献者和读取者。使用贡献者角色，可以删除或修改资源。那么，即便用户拥有贡献者角色，如何避免这些操作呢？答案是：使用 Azure 锁定。

Azure 锁定可以提供以下两种帮助：

• 它们可以锁定资源，使其即便拥有所有者权限，也无法删除。

• 锁定可以以这样的方式保护资源，使它们既不能被删除，也不能修改其配置。

锁定通常对生产环境中的资源非常有帮助，这些资源不应被意外修改或删除。

锁定可以应用于订阅、资源组、管理组以及单个资源的级别。锁定可以在订阅、资源组和资源之间继承。对父级应用锁定将确保子级资源也继承该锁定。后续添加到子范围的资源也默认继承该锁定配置。在资源级别应用锁定还会阻止包含该资源的资源组被删除。

锁定仅应用于帮助管理资源的操作，而不涉及资源内部的操作。用户需要拥有 Microsoft.Authorization/* 或 Microsoft.Authorization/locks/* 的 RBAC 权限才能创建和修改锁定。

锁定可以通过 Azure 门户、Azure PowerShell、Azure CLI、Azure 资源管理器模板以及 REST API 创建和应用。

使用 Azure 资源管理器模板创建锁定的方法如下：

{ 
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#", 
  "contentVersion": "1.0.0.0", 
  "parameters": { 
    "lockedResource": { 
      "type": "string" 
    } 
  }, 
  "resources": [ 
    { 
      "name": "[concat(parameters('lockedResource'), '/Microsoft.Authorization/myLock')]", 
      "type": "Microsoft.Storage/storageAccounts/providers/locks", 
      "apiVersion": "2019-06-01", 
      "properties": { 
        "level": "CannotDelete" 
      } 
    } 
  ] 
}

Azure 资源管理器模板代码中的 resources 部分包含了所有在 Azure 中将要配置或更新的资源列表。这里有一个存储账户资源，并且存储账户中包含一个锁定资源。锁定的名称是通过动态字符串拼接提供的，所应用的锁定是 CannotDelete 类型，这意味着该存储账户被锁定，无法删除。只有在移除锁定后，存储账户才能被删除。

使用 PowerShell 创建并应用锁定到资源的方法如下：

New-AzResourceLock -LockLevel CanNotDelete -LockName LockSite '
  -ResourceName examplesite -ResourceType Microsoft.Web/sites '
  -ResourceGroupName exampleresourcegroup

使用 PowerShell 创建并应用锁定到资源组的方法如下：

New-AzResourceLock -LockName LockGroup -LockLevel CanNotDelete '
  -ResourceGroupName exampleresourcegroup

使用 Azure CLI 创建并应用锁定到资源的方法如下：

az lock create --name LockSite --lock-type CanNotDelete \
  --resource-group exampleresourcegroup --resource-name examplesite \
  --resource-type Microsoft.Web/sites

使用 Azure CLI 创建并应用锁定到资源组的方法如下：

az lock create --name LockGroup --lock-type CanNotDelete \ --resource-group exampleresourcegroup

要创建或删除资源锁定，用户应当具有对 Microsoft.Authorization/* 或 Microsoft.Authorization/locks/* 操作的访问权限。你还可以进一步授予更细粒度的权限。拥有者和用户访问管理员默认将具有创建或删除锁定的权限。

如果你想知道 Microsoft.Authorization/* 和 Microsoft.Authorization/locks/* 关键字是什么，下一节你会了解更多相关内容。

现在我们来看一下 Azure RBAC。

Azure RBAC

Azure 使用 Azure Active Directory 进行资源的身份验证。身份验证完成后，应该确定该身份可以访问哪些资源。这就是授权。授权评估已赋予身份的权限。任何拥有 Azure 订阅访问权限的人应该仅被赋予足够的权限来执行他们的特定工作，其他的权限不需要提供。

授权也常被称为 RBAC。Azure 中的 RBAC 是指在某个范围内为身份分配权限。该范围可以是管理组、订阅、资源组或单个资源。

RBAC 帮助创建和分配不同的权限给不同的身份。这有助于在团队内部分配职责，而不是每个人都有所有的权限。RBAC 帮助让每个人只对自己的工作负责，因为其他人可能没有执行该工作的必要访问权限。需要注意的是，在更大范围内提供权限会自动确保子资源继承这些权限。例如，给一个身份提供对资源组的读取权限意味着该身份也会对该组内的所有资源拥有读取权限。

Azure 提供了三种通用的内建角色，具体如下：

• 拥有者角色，具有对所有资源的完全访问权限

• 贡献者角色，具有读取/写入资源的权限

• 读者角色，具有只读资源权限

Azure 提供了更多的角色，但它们是特定于资源的，如网络贡献者和安全管理员角色。

要获取 Azure 为所有资源提供的所有角色，请在 PowerShell 控制台中执行 Get-AzRoleDefinition 命令。

每个角色定义都有特定的允许和不允许的操作。例如，拥有者角色允许所有操作；没有任何操作是禁止的：

PS C:\Users\riskaria> Get-AzRoleDefinition -Name "Owner"
Name             : Owner
Id               : 8e3af657-a8ff-443c-a75c-2fe8c4bcb635
IsCustom         : False
Description      : Lets you manage everything, including access to resources.
Actions          : {*}
NotActions       : {}
DataActions      : {}
NotDataActions   : {}
AssignableScopes : {/}

每个角色由多个权限组成。每个资源提供一组操作。可以通过 Get-AzProviderOperation cmdlet 获取某个资源支持的操作。此 cmdlet 需要提供提供者和资源的名称来检索操作：

PS C:\Users\riskaria> Get-AzProviderOperation -OperationSearchString "Microsoft.Insights/*" | select Operation

这将导致以下输出：

PS C:\Users\riskaria> Get-AzProviderOperation -OperationSearchString "Microsoft.Insights/*" | select Operation
Operation                                                                                 
---------                                                                                 
Microsoft.Insights/Metrics/Action                                                         
Microsoft.Insights/Register/Action                                                        
Microsoft.Insights/Unregister/Action                                                      
Microsoft.Insights/ListMigrationDate/Action                                               
Microsoft.Insights/MigrateToNewpricingModel/Action                                        
Microsoft.Insights/RollbackToLegacyPricingModel/Action  
.
.
.
.
.
.
.
.
Microsoft.Insights/PrivateLinkScopes/PrivateEndpointConnectionProxies/Read                
Microsoft.Insights/PrivateLinkScopes/PrivateEndpointConnectionProxies/Write               
Microsoft.Insights/PrivateLinkScopes/PrivateEndpointConnectionProxies/Delete              
Microsoft.Insights/PrivateLinkScopeOperationStatuses/Read                                 
Microsoft.Insights/DiagnosticSettingsCategories/Read

这里显示的输出提供了 Microsoft.Insights 资源提供程序中所有可用的操作，包括其关联的资源。资源包括 Metrics、Register 等，而操作包括 Read、Write 等。

现在我们来看看自定义角色。

自定义角色

Azure 提供了许多现成的通用角色，如所有者、贡献者和阅读者，以及专门的资源特定角色，如虚拟机贡献者。当为用户/组或服务主体分配阅读者角色时，意味着会将阅读者权限分配给某个范围。这个范围可以是资源、资源组或订阅。同样，贡献者能够读取并修改分配的范围。而虚拟机贡献者则只能修改虚拟机的设置，而不能修改其他资源的设置。然而，有时现有的角色可能不符合我们的需求。在这种情况下，Azure 允许创建自定义角色。它们可以分配给用户、组和服务主体，并且适用于资源、资源组和订阅。

自定义角色是通过组合多个权限来创建的。例如，一个自定义角色可以由多个资源的操作组成。在下一个代码块中，正在创建一个新的角色定义，但不是手动设置所有属性，而是获取其中一个现有的“虚拟机贡献者”角色，因为它几乎与新自定义角色的配置匹配。避免使用与内置角色相同的名称，因为这会导致冲突。然后，将 ID 属性置为空，提供一个新的名称和描述。代码还清除了所有操作，添加了一些操作，在清除现有范围后添加了新范围，最后创建了一个新的自定义角色：

$role = Get-AzRoleDefinition "Virtual Machine Contributor" 
$role.Id = $null 
$role.Name = "Virtual Machine Operator" 
$role.Description = "Can monitor and restart virtual machines." 
$role.Actions.Clear()
$role.Actions.Add("Microsoft.Storage/*/read") 
$role.Actions.Add("Microsoft.Network/*/read") 
$role.Actions.Add("Microsoft.Compute/*/read") 
$role.Actions.Add("Microsoft.Compute/virtualMachines/start/action") 
$role.Actions.Add("Microsoft.Compute/virtualMachines/restart/action")
$role.Actions.Add("Microsoft.Authorization/*/read") 
$role.Actions.Add("Microsoft.Resources/subscriptions/resourceGroups/read") 
$role.Actions.Add("Microsoft.Insights/alertRules/*") 
$role.Actions.Add("Microsoft.Support/*") 
$role.AssignableScopes.Clear() 
$role.AssignableScopes.Add("/subscriptions/548f7d26-b5b1-468e-ad45-6ee12accf7e7") 
New-AzRoleDefinition -Role $role

在 Azure 门户中，有一个预览功能，可以让你直接在门户中创建自定义 RBAC 角色。你可以选择从头开始创建角色、克隆现有角色或直接编写 JSON 清单。图 5.3 显示了创建自定义角色窗格，它位于 IAM > +添加 部分：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_05_03.jpg

图 5.3：从 Azure 门户创建自定义角色

这使得创建自定义角色的过程变得轻松无忧。

锁与 RBAC 有什么不同？

锁与 RBAC 不同。RBAC 帮助允许或拒绝对资源的权限。这些权限与执行操作相关，如对资源进行读取、写入和更新等操作。而锁则与禁止配置或删除资源的权限有关。

在接下来的章节中，我们将讨论 Azure 蓝图，它有助于我们组织已经讨论过的工件，如角色分配、策略分配等。

Azure 蓝图

你将会熟悉“蓝图”这个词，它指的是建筑师用来设计解决方案的计划或图纸。同样，在 Azure 中，云架构师可以利用 Azure Blueprints 来定义一组可重复的 Azure 资源，符合组织的标准、流程和模式。

Blueprints 允许我们编排各种资源和其他工件的部署，例如：

• 角色分配

• 策略分配

• Azure 资源管理器模板

• 资源组

Azure 蓝图对象会复制到多个区域，并由 Azure Cosmos DB 提供支持。复制有助于提供一致的资源访问，并保持组织标准，无论你将资源部署到哪个区域。

Azure Blueprints 包含了各种工件，你可以在这里找到支持的工件列表：docs.microsoft.com/azure/governance/blueprints/overview#blueprint-definition。

可以通过 Azure 门户、Azure PowerShell、Azure CLI、REST API 或 ARM 模板创建蓝图。

在下一节中，我们将看到一个实施 Azure 治理功能的示例。示例中将使用 RBAC、Azure 策略和 Azure 资源锁等服务和功能。

实施 Azure 治理功能的示例

在本节中，我们将介绍一个示例架构实施，针对一个虚构的组织，该组织希望实现 Azure 治理和成本管理功能。

背景

公司 Inc 是一家全球性公司，正在 Azure IaaS 平台上实现社交媒体解决方案。他们使用部署在 Azure 虚拟机和网络上的 Web 服务器和应用服务器。Azure SQL Server 作为后台数据库。

Company Inc 的 RBAC

第一个任务是确保适当的团队和应用程序所有者能够访问他们的资源。需要注意的是，每个团队有不同的需求。为了清晰起见，Azure SQL 被部署在与 Azure IaaS 工件不同的资源组中。

管理员为订阅分配以下角色：

https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/Table_5.1.jpg

表 5.1：不同角色及访问详情

Azure 策略

该公司应该实施 Azure 策略，以确保其用户始终按照公司指南配置资源。

Azure 中的策略治理与资源部署相关的各个方面。策略还将治理初始部署后的更新。以下部分列出了应实施的一些策略。

部署到特定位置

Azure 资源和部署只能在选定的位置执行。无法在政策以外的区域部署资源。例如，允许的区域是西欧和东美。应该无法在其他任何区域部署资源。

资源和资源组的标签

Azure 中的每一个资源，包括资源组，都必须强制分配标签。标签至少应包括有关部门、环境、创建日期和项目名称的详细信息。

所有资源的诊断日志和应用程序洞察

在 Azure 上部署的每个资源都应该在可能的情况下启用诊断日志和应用程序日志。

Azure 锁定

企业应实施 Azure 锁定，确保重要资源不会被意外删除。所有对解决方案功能至关重要的资源都需要锁定。这意味着即使是 Azure 上运行服务的管理员也没有权限删除这些资源；删除资源的唯一方法是先移除锁定。

你还需要注意：

除了开发和测试环境外，所有生产和预生产环境将会被锁定，禁止删除。

所有具有单实例的开发和测试环境也将被锁定，禁止删除。

所有与 Web 应用相关的资源将在所有生产环境中被锁定，禁止删除。

所有共享资源无论环境如何，都将被锁定，禁止删除。

总结

在本章中，你了解到治理和成本管理是企业迁移到云端时的首要任务之一。拥有一个按需付费的 Azure 订阅可能会对公司预算造成影响，因为任何拥有访问权限的人都可以根据需要创建资源。某些资源是免费的，但其他资源则非常昂贵。

你还了解到，组织保持云端成本控制非常重要。标签有助于生成计费报告，这些报告可以基于部门、项目、所有者或任何其他标准。虽然成本很重要，但治理同样重要。Azure 提供了锁定、策略和 RBAC 来实施适当的治理。策略确保可以拒绝或审计资源操作，锁定确保资源无法被修改或删除，RBAC 确保员工具有执行工作所需的权限。通过这些功能，企业可以实现对 Azure 部署的良好治理和成本控制。

在下一章中，我们将讨论 Azure 中的成本管理。我们将讲解不同的优化方法、成本管理和计费 API。