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

admin•2025-09-17 08:41:58•网站建设•阅读12

原文：annas-archivemd50b3cfce43ce7ffb62c4f01cafdc66996 译者：飞龙协议：CC BY-NC-SA 4.0 第六章&

原文：annas-archive/md5/0b3cfce43ce7ffb62c4f01cafdc66996

译者：飞龙

协议：CC BY-NC-SA 4.0

第六章：6. Azure 解决方案的成本管理

在上一章中，我们讨论了标签、策略和锁，以及如何从合规性的角度利用它们。标签允许我们为资源添加元数据，它们还帮助我们在资源的逻辑管理中发挥作用。在 Azure 门户中，我们可以根据标签来筛选资源。如果假设有大量资源（这在企业中非常常见），筛选将帮助我们更轻松地管理资源。标签的另一个好处是它们可以用于根据标签来筛选我们的账单报告或使用报告。在本章中，我们将探讨 Azure 解决方案的成本管理。

企业迁移到云端的主要原因是节省成本。订阅 Azure 不需要前期费用。Azure 提供了按需付费的订阅方式，计费是基于实际消耗的。Azure 会测量资源使用情况并提供每月账单。Azure 消耗没有上限。作为一个公共云，Azure（像任何其他服务提供商一样）对可以部署的资源数量设定了硬性和软性限制。软性限制可以通过与 Azure 支持团队合作来增加。有些资源有硬性限制。服务限制可以在 docs.microsoft/azure/azure-resource-manager/management/azure-subscription-service-limits 查看，默认限制取决于您所拥有的订阅类型。

对于公司来说，密切关注 Azure 的消耗和使用情况非常重要。尽管他们可以创建策略来设定组织标准和惯例，但同样需要跟踪账单和消耗数据。此外，他们还应该采用最佳实践来消耗 Azure 资源，以最大化回报。为此，架构师需要了解 Azure 资源和功能，它们相应的费用，以及功能和解决方案的成本/效益分析。

在本章中，我们将讨论以下内容：

Azure 服务详情
计费
开具发票
使用情况和配额
使用情况和计费 API
Azure 定价计算器
成本优化的最佳实践

让我们继续讨论每个要点。

Azure 服务详情

Azure 提供了不同的服务套餐可以购买。到目前为止，我们已经讨论了按需付费，但还有其他服务套餐，例如 企业协议（EAs）、Azure 赞助和 CSP 中的 Azure。我们将逐一讨论这些内容，因为它们对计费非常重要：

按需付费：这是一种常见的服务方式，客户根据实际使用情况支付费用，相关的费率可以在 Azure 的公开文档中查看。客户每月都会收到来自微软的使用账单，并可以通过信用卡或账单支付方式付款。
EA：EA 代表与 Microsoft 的货币承诺，意味着组织与 Microsoft 签署协议，并承诺使用一定数量的 Azure 资源。如果使用量超过约定的额度，客户将收到超额费用账单。客户可以在 EA 下创建多个帐户，并在这些帐户中拥有多个订阅。EA 有两种类型：直接 EA 和间接 EA。直接 EA 客户与 Microsoft 之间有直接的账单关系；而在间接 EA 中，账单由合作伙伴管理。EA 客户因与 Microsoft 的承诺而获得更好的优惠和折扣。EA 通过名为 EA 门户的门户管理（ea.azure），您需要拥有注册权限才能访问此门户。
Azure 在 CSP 中：Azure 在 CSP 中是指客户联系 云解决方案提供商（CSP）合作伙伴，由该合作伙伴为客户提供订阅。账单将完全由合作伙伴管理；客户与 Microsoft 不会有直接的账单关系。Microsoft 向合作伙伴开具账单，合作伙伴再向客户开具账单，并加上其利润。
Azure 赞助：Microsoft 向初创公司、非政府组织（NGO）和其他非营利组织提供赞助，以使用 Azure。赞助是有固定期限和固定额度的信用。如果期限到期或信用用尽，订阅将转换为按需计费订阅。如果组织希望续订其赞助资格，必须与 Microsoft 合作。

我们刚刚概述了 Azure 的部分产品。完整列表请参见 azure.microsoft/support/legal/offer-details，其中包括其他产品，如 Azure 学生计划、Azure Pass 和 Dev/Test 订阅。

接下来，我们来讨论 Azure 中的账单。

理解账单

Azure 是一项具有以下特点的服务工具：

无需预付费用
无解约费用
根据资源类型按秒、按分钟或按小时计费
按实际消费进行付费

在这种情况下，很难估算使用 Azure 资源的预付成本。Azure 中的每种资源都有自己的成本模型，并根据存储、使用情况和时间跨度收费。对于管理、行政和财务部门来说，跟踪使用情况和成本非常重要。Azure 提供使用和账单报告功能，帮助高级管理人员和管理员根据多种标准生成成本和使用报告。

Azure 门户通过 成本管理 + 账单 功能提供详细的账单和使用信息，该功能可以从主导航窗格访问，如 图 6.1 所示：

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

图 6.1：Azure 门户中的成本管理 + 账单服务

请注意，如果你的计费由 CSP 管理，你将无法访问此功能。CSP 客户可以在将其 CSP 传统订阅转换为 Azure 计划后，按需查看其成本。我们将在本章后续部分讨论 Azure 计划和现代商务平台。

成本管理 + 计费显示所有你有权限访问的订阅和计费范围，如图 6.2所示：

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

图 6.2：用户订阅的计费概述

成本管理部分有几个页面，例如：

成本分析用于分析某个范围内的使用情况。
预算用于设置预算。
成本警报用于在使用超过某个阈值时通知管理员。
Advisor 推荐用于获取如何实现潜在节省的建议。我们将在本章最后一部分讨论 Azure Advisor。
导出用于将使用数据自动导出到 Azure 存储。
Cloudyn 是 CSP 合作伙伴用来分析成本的工具，因为他们无法访问成本管理。
AWS 连接器用于将你的 AWS 消耗数据连接到 Azure 成本管理。

在 Azure 成本管理中提供的不同选项如图 6.3所示：

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

图 6.3：成本管理概述

点击此页面上的 成本分析 菜单，可以获得一个全面的交互式仪表盘，使用它可以通过不同的维度和度量分析成本：

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

图 6.4：通过成本分析选项分析订阅成本

该仪表盘不仅显示当前成本，还预测成本，并根据多个维度进行拆分。默认提供服务名称、位置和资源组名称，但也可以更改为其他维度。每个视图始终会与一个范围相关联。可用的一些范围包括计费账户、管理组、订阅和资源组。你可以根据需要分析的层级切换范围。

左侧的预算菜单允许我们设置预算以更好地管理成本，并提供在实际成本即将超出预算估算时的警报功能：

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

图 6.5：创建预算

成本管理还允许我们在当前的仪表盘中获取来自其他云（如 AWS）的成本数据，从而在单一的仪表盘和页面中管理多个云的成本。然而，在写作时，此功能仍处于预览阶段。此连接器将于 2020 年 8 月 25 日之后开始收费。

您需要填写您的 AWS 角色详细信息及其他信息，以便提取成本信息，如图 6.5所示。如果您不确定如何在 AWS 中创建策略和角色，请参考docs.microsoft/azure/cost-management-billing/costs/aws-integration-set-up-configure#create-a-role-and-policy-in-aws:

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

图 6.6：在成本管理中创建 AWS 连接器

成本报告还可以根据计划定期导出到存储帐户中。

部分成本分析也可以在订阅面板中查看。在概览部分，您可以看到资源及其成本。此外，还有另一张图表，您可以查看当前花费、预测花费以及余额信用（如果您使用的是基于信用的订阅）。

图 6.7显示了成本信息：

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

图 6.7：订阅的成本分析

点击图 6.7中的任何一个成本项将会将您重定向到成本管理 – 成本分析部分。成本管理中有许多维度，您可以根据这些维度对数据进行分组分析。可用的维度将根据您选择的范围而有所不同。以下是一些常用的维度：

资源类型
资源组
标签
资源位置
资源 ID
计量类别
计量子类别
服务

在本章开始时，我们提到过标签可以用于成本管理。例如，假设您有一个名为“部门”的标签，值为 IT、HR 和财务。正确地为资源打上标签将帮助您了解每个部门产生的成本。您还可以通过下载按钮将成本报告下载为 CSV、Excel 或 PNG 文件。

此外，成本管理支持多种视图。您可以创建自己的仪表板并保存它。EA 客户还可以额外享受成本管理连接器或 Power BI 的优势。通过连接器，用户可以将使用统计数据拉取到 Power BI 并创建可视化。

到目前为止，我们一直在讨论如何使用成本管理来跟踪我们的使用情况。在接下来的部分，我们将探讨我们所使用的服务的计费方式。

开票

Azure 的计费系统还提供有关每月生成的发票的信息。

根据优惠类型，计费方式可能会有所不同。对于按需付费用户，发票将每月发送给帐户管理员。然而，对于 EA 客户，发票将发送给注册时的联系人。

点击发票菜单将显示所有生成的发票列表，点击任何一张发票将提供该发票的详细信息。图 6.8显示了如何在 Azure 门户中查看发票：

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

图 6.8：发票及其详细信息列表

发票有两种类型：一种是针对 Azure 服务，如 SQL、虚拟机和网络的发票；另一种是针对 Azure 市场和预订的发票。Azure 市场提供来自不同供应商的合作伙伴服务供客户选择。稍后我们将讨论 Azure 预订。

默认情况下，对于按需付费订阅，账户管理员可以访问发票。如果需要，他们可以通过选择图 6.8中的访问发票选项，将访问权限委托给其他用户，例如组织的财务团队。此外，账户管理员还可以选择希望将发票副本发送到的电子邮件地址。

电子邮件发票选项目前不适用于支持计划。您可以访问账户门户并下载发票。微软正在逐步淘汰该门户，大部分功能正在被集成到 Azure 门户中。

到目前为止，我们已经讨论了订阅和发票处理的方式。微软推出的一个新概念是现代商务。通过这一新的商务体验，购买流程和体验得到了简化。让我们仔细看看现代商务，并了解它与我们迄今讨论的传统平台有何不同。

现代商务体验

如果您的组织已经与微软合作，您会知道每个报价都有多个协议，例如 Web Direct、EA、CSP、微软服务与产品协议（MSPA）、服务器云注册（SCE）等。除此之外，每个协议都有自己的门户；例如，EA 有 EA 门户，CSP 有合作伙伴中心门户，Volume Licensing 也有自己的门户。

每个报价都有不同的条款和条件，客户在每次购买时都需要了解这些条款和条件。从一个报价转换到另一个报价并不容易，因为每个报价的条款和条件各不相同。假设您已经有了 EA 订阅，并希望将其转换为 CSP 订阅；您可能需要删除一些合作伙伴服务，因为这些服务在 CSP 中不被支持。对于每个产品，每个报价都有不同的规则。从客户的角度来看，理解哪些支持哪些内容以及规则如何不同是非常困难的。

为了解决这个问题，微软最近发布了一项新的协议，称为微软客户协议（MCA）。该协议将作为基本条款和条件。每当您注册新项目时，您可以根据需要对其进行修改。

对于 Azure，将有三个市场推广（GTM）计划：

以客户为主导：客户将直接与微软账户团队互动，发票将由微软直接管理。最终，这将取代 EA。
合作伙伴主导：这相当于 Azure-in-CSP 项目，其中合作伙伴管理你的账单。全球有不同的合作伙伴，快速搜索一下即可找到周围的合作伙伴。这个项目将取代 Azure-in-CSP 项目。作为现代商务的第一步，合作伙伴将与微软签署 微软合作伙伴协议（MPA），并通过让他们的客户签署 MCA 来转换他们现有的客户。在撰写本书时，许多合作伙伴已经将他们的客户转移到现代商务，新商业体验已在 139 个国家/地区提供。
自助服务：这将取代 Web Direct。它不需要合作伙伴或微软账户团队的任何参与。客户可以直接从 microsoft 购买，并且在购买时签署 MCA。

在 Azure 中，账单将根据 Azure 计划进行，并且账单总是与日历月份对齐。购买 Azure 计划与购买其他订阅非常相似。不同之处在于，在过程中会签署 MCA。

Azure 计划可以托管多个订阅，并将作为根级容器。所有的使用情况都与单一的 Azure 计划相关联。Azure 计划中的所有订阅将作为容器来托管服务，如虚拟机、SQL 数据库和网络服务。

我们可以观察到在现代商务引入后的一些变化和进展如下：

最终，门户网站将被弃用。例如，之前的 EA 客户只能从 EA 门户下载注册使用信息。现在，微软已经将其集成到 Azure 成本管理中，提供比 EA 门户更丰富的体验。
定价将以美元（USD）进行，并以当地货币计费。如果你的货币不是美元，则将应用外汇（FX）汇率，并会显示在发票中。微软使用来自 Thomson Reuters 的外汇汇率，这些汇率将在每个月的第一天进行分配。这个汇率在整个一个月内保持一致，无论市场汇率如何变化。
转到新 Azure 计划的 CSP 客户将能够使用成本管理。访问成本管理打开了一个全新的成本跟踪世界，因为它提供了所有原生的成本管理功能。

到目前为止我们讨论的所有订阅最终都将迁移到 Azure 计划，这是 Azure 的未来。现在你已经理解了现代商务的基础，接下来让我们讨论一个在架构解决方案时起着非常重要作用的话题。大多数服务默认都有限制；其中一些限制可以增加，而有些是硬性限制。当我们在设计解决方案时，需要确保有足够的配额。容量规划是架构设计中的一个至关重要的部分。在下一节，你将了解更多有关订阅限制的信息。

使用情况和配额

如前所述，容量规划需要成为我们设计解决方案时的首要步骤之一。我们需要验证订阅是否有足够的配额来容纳我们设计的新资源。如果没有，在部署过程中可能会遇到问题。

每个订阅对每种资源类型都有有限的配额。例如，使用 MSDN Microsoft 帐户时，最多可以分配 10 个公共 IP 地址。类似地，所有资源对每种资源类型都有一个最大默认限制。通过联系 Azure 支持或在订阅页面的使用情况 + 配额窗格中点击请求增加按钮，可以增加这些资源类型的配额。

考虑到每个区域的资源数量，要浏览整个列表将是一个挑战。门户提供了筛选数据集并查找所需项的选项。在图 6.9中，您可以看到如果我们将位置筛选为美国中部并将资源提供者设置为Microsoft.Storage，我们可以确认存储帐户的可用配额：

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

图 6.9：给定位置和资源提供者的使用情况和配额

在图 6.9中，您可以清楚地看到我们在美国中部尚未创建任何存储帐户，这使得我们拥有 250 个帐户的配额。如果我们构建的解决方案需要超过 250 个帐户，则需要点击请求增加，这将联系 Azure 支持。

此窗格使我们能够在部署前进行容量规划。

在筛选报告时，我们使用了资源提供者一词并选择了Microsoft.Storage。在下一节中，我们将更详细地了解这个术语的含义。

资源提供者和资源类型

无论您是与 Azure 门户交互，筛选服务，还是筛选账单使用报告，您可能需要与资源提供者和资源类型打交道。例如，当您创建虚拟机时，您正在与Microsoft.Compute资源提供者和virtualMachines资源类型交互。其格式为{resource-provider}/{resource-type}。因此，虚拟机的资源类型是Microsoft.Compute/virtualMachines。简而言之，资源提供者帮助创建资源类型。

资源提供者需要在 Azure 订阅中注册。如果资源提供者没有注册，则资源类型将在订阅中不可用。默认情况下，大多数提供者会自动注册；不过，也会有一些情况需要我们手动注册。

要获取可用的提供商列表，包括已注册和未注册的提供商，并注册未注册的提供商或反之，可以使用 图 6.10 所示的仪表板。进行此操作时，您需要拥有必要的角色——Owner 或 Contributor 角色即可。图 6.10 显示了仪表板的样子：

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

图 6.10：已注册和未注册的资源提供商列表

在前一部分中，我们讨论了如何下载发票和使用信息。如果您需要通过编程方式下载数据并保存，您可以使用 API。下一部分将全面介绍 Azure 计费 API。

使用情况和计费 API

尽管门户是手动查找使用、计费和发票信息的好方法，但 Azure 还提供了以下 API，以便通过编程方式检索详细信息并创建定制的仪表板和报告。这些 API 会根据您使用的订阅类型有所不同。由于 API 很多，我们将分享每个 API 的 Microsoft 文档，以便您可以逐一探索它们。

Azure 企业计费 API

EA 客户有一组专门的 API 可供他们处理计费数据。以下 API 使用来自 EA 门户的 API 密钥进行身份验证；来自 Azure Active Directory 的令牌无法与它们一起使用：

余额和摘要 API：如前所述，EA 依赖于货币承诺，因此跟踪余额、超额费用、信用调整和 Azure Marketplace 费用非常重要。使用此 API，客户可以提取计费期间的余额和摘要。
使用详情 API：使用详情 API 将帮助您获取关于注册的每日使用信息，精确到实例级别。此 API 的响应将类似于可以从 EA 门户下载的使用报告。
Marketplace 商店费用 API：这是一个专门的 API，用于提取 Marketplace 购买的费用。
价格表 API：每个注册都会有一个特殊的价格表，折扣因客户而异。价格表 API 可以拉取价格列表。
预留实例详情 API：到目前为止我们还没有讨论 Azure 预留实例，但本章末会进行讨论。使用此 API，您可以获取有关预留实例的使用信息以及注册中的预留实例列表。

这是 EA API 文档的链接：docs.microsoft/azure/cost-management-billing/manage/enterprise-api。

现在让我们来看一下 Azure 消费 API。

Azure 消费 API

Azure 消耗 API 可以与 EA 和 Web Direct（有些例外）订阅一起使用。此 API 需要一个令牌，该令牌需要通过 Azure Active Directory 认证生成。由于这些 API 也支持 EA，请不要将此令牌与之前提到的 EA API 密钥混淆。以下是一些显而易见的关键 API：

使用详情 API
市场费用 API
预订推荐 API
预订详情和总结 API

EA 客户支持以下额外的 API：

价格表
预算
余额

文档可以在此处查看：docs.microsoft/azure/cost-management-billing/manage/consumption-api-overview。

此外，还有一组仅可供 Web Direct 客户使用的 API：

Azure 资源使用 API：此 API 可以与 EA 或按需订阅一起使用，用于下载使用数据。
Azure 资源价格表 API：仅适用于 Web Direct，不支持 EA。Web Direct 客户可以使用此 API 下载价格表。
Azure 发票下载 API：仅适用于 Web Direct 客户。用于通过编程下载发票。

这些 API 的名称可能看起来很熟悉，区别仅在于我们调用的端点。对于 Azure 企业计费 API，URL 以 https://consumption.azure 开头；对于 Azure 消耗 API，URL 以 https://management.azure 开头。这样你就可以区分它们。在接下来的部分，你将看到一组专门供成本管理使用的 API。

Azure 成本管理 API

随着 Azure 成本管理的引入，客户可以使用一组新的 API。这些 API 是成本管理的核心，我们之前在 Azure 门户中使用过。主要的 API 如下：

查询使用 API：这是 Azure 门户中的成本分析使用的同一 API。我们可以通过负载自定义响应内容。当我们需要定制报告时，这个 API 非常有用。日期范围不能超过 365 天。
预算 API：预算是 Azure 成本管理的另一项功能，使用此 API 可以通过编程与预算进行交互。
预测 API：此 API 可用于获取范围的预测。预测 API 目前仅适用于 EA 客户。
维度 API：之前在讨论成本管理时，我们提到过成本管理支持基于范围的多维度。如果你想根据特定的范围获取支持的维度列表，可以使用此 API。
导出 API：成本管理的另一个功能是我们可以自动将报告导出到存储帐户。导出 API 可用于与导出配置进行交互，如存储帐户的名称、定制化、频率等。

查看官方文档：docs.microsoft/rest/api/cost-management。

由于现代商务正在扩展 MCA，这里有一组全新的 API 可供探索：docs.microsoft/rest/api/billing。

你可能注意到我们在这些场景中没有提到 CSP。在 CSP 中，客户无法访问账单，因为它由合作伙伴管理，因此 API 不对外开放。然而，迁移到 Azure 计划将允许 CSP 客户使用 Azure 成本管理 API 查看零售价格。

任何编程或脚本语言都可以用于调用这些 API，并将它们组合在一起，创建完整的综合账单解决方案。在下一部分中，我们将重点介绍 Azure 定价计算器，帮助客户或架构师了解部署成本。

Azure 定价计算器

Azure 提供了一个成本计算器，供用户和客户估算他们的成本和使用情况。该计算器可通过 azure.microsoft/pricing/calculator 访问：

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

图 6.11：Azure 定价计算器

用户可以从左侧菜单中选择多个资源，它们将被添加到计算器中。在以下示例中，添加了一个虚拟机。接下来，需要提供有关虚拟机区域、操作系统、类型、层级、实例大小、小时数和数量的更多配置，以便计算成本：

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

图 6.12：提供配置详情以计算资源成本

同样，Azure Functions 的成本与虚拟机内存大小、执行时间和每秒执行次数相关，见 图 6.13：

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

图 6.13：计算 Azure Functions 的成本

Azure 提供不同的级别和支持计划：

默认支持：免费
开发者支持：每月 $29
标准支持：每月 $300
专业版直达：每月 $1,000

要查看支持计划的完整对比，请参考：azure.microsoft/support/plans。

你可以根据自己的需求选择所需的支持计划。最后，系统将显示总体估算成本：

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

图 6.14：所选支持计划的成本估算

架构师了解他们架构和解决方案中使用的每个 Azure 功能非常重要。Azure 计算器的成功取决于所选择的资源及其配置。任何错误的表示都会导致偏颇和不准确的估算，且与实际账单不同。

我们已经进入本章的最后一部分。我们已经涵盖了计费的基础知识，现在是时候学习最佳实践了。遵循最佳实践将帮助你实现成本优化。

最佳实践

架构师需要了解他们的架构和所使用的 Azure 组件。基于主动监控、审计和使用情况，他们应该确定微软在 SKU、大小和功能方面的最佳选择。本节将详细介绍一些从成本优化角度应采纳的最佳实践。

Azure 治理

Azure 治理可以定义为一套可以利用的过程或机制，用于保持对在 Azure 中部署的资源的完全控制。以下是一些关键要点：

为所有资源类型和资源组设置命名规范。确保命名规范在所有资源和资源组中始终如一、全面地遵循。这可以通过建立 Azure 策略来实现。
通过为资源、资源组和订阅应用标签，设置逻辑组织和多个分类法。标签对资源进行分类，还能帮助从不同角度评估成本。这可以通过建立 Azure 策略来实现，多个策略可以组合成计划。应用这些计划后，所有的策略将用于合规性检查和报告。
使用 Azure 蓝图，而不是直接使用 ARM 模板。这将确保新的环境、资源和资源组的部署可以按照企业标准进行标准化，包括命名规范和标签的使用。

计算最佳实践

计算指的是帮助执行服务的服务。Azure 架构师应遵循的一些最佳计算实践，以实现资源的最佳利用和成本效益，如下所示：

利用 Azure Advisor 查看节省虚拟机成本的可用选项，并找出虚拟机是否被低效使用。Advisor 使用机器学习模式和人工智能分析你的使用情况，并提供建议。这些建议在成本优化中起着重要作用。
使用 Azure 预留实例 (RI)。预留实例通过提前支付虚拟机费用（按月或一次性支付）为计算成本提供潜在节省。预留实例的期限可以是一年或三年。如果购买了预留实例，就可以降低计算成本，之后只需支付虚拟机的磁盘、网络和许可费用（如果有）。如果你有五个虚拟机，可以选择购买五个预留实例，从而完全压缩计算成本。预留实例会自动寻找与虚拟机匹配的 SKU 并附加到它上面。潜在节省可能会根据虚拟机的大小有所不同，通常在 20% 到 40% 之间。
使用 Azure Hybrid Benefit（AHUB），您可以使用自己的 Windows Server 或 SQL 许可证来降低许可证费用。结合 RIs 和 AHUB 可以带来巨大的节省。
选择最适合您的计算服务的区域，例如虚拟机。选择一个所有 Azure 功能都在同一区域的地点，这样可以避免外部流量。
为虚拟机选择最佳的大小。大型虚拟机比小型虚拟机更贵，而且有时候大型虚拟机根本不需要。
在需求高峰期间调整虚拟机大小，并在需求下降时缩小其规模。Azure 会频繁发布新的 SKU。如果新的大小更适合您的需求，就必须使用它。
在非工作时间或不需要时关闭计算服务。这适用于非生产环境。
取消分配虚拟机，而不是关闭它们。这将释放所有资源，并停止计量它们的消耗。
使用开发/测试实验室进行开发和测试。它们提供策略、自动关机和自动启动功能。
使用虚拟机规模集，从少量虚拟机开始，需求增加时再进行扩展。
为应用网关选择正确的大小（小型、中型或大型）。它们由虚拟机支持，可以帮助降低成本。
如果不需要 Web 应用防火墙，则选择基本层应用网关。
选择正确的 VPN 网关层级（基本 VPN、标准、高性能和超高性能）。
减少 Azure 区域之间的网络流量。
使用带有公共 IP 的负载均衡器来访问多个虚拟机，而不是为每个虚拟机分配公共 IP。
监控虚拟机并计算性能和使用指标。根据这些计算，确定是否需要扩展或缩小虚拟机。这可能会导致缩小规模并减少虚拟机数量。

在架构时考虑这些最佳实践将不可避免地带来成本节省。现在我们已经覆盖了计算部分，让我们采用类似的方法来处理存储。

存储最佳实践

由于我们在云中托管应用程序，Azure 存储将用于存储与这些应用程序相关的数据。如果不遵循正确的实践，可能会导致问题。以下是一些存储的最佳实践：

选择适当的存储冗余类型（GRS、LRS、RA-GRS）。GRS 比 LRS 更贵。
将存储数据归档到冷存储或归档存取层。将经常访问的数据保存在热存储层。
删除不需要的 Blob。
删除虚拟机后，如果不再需要操作系统磁盘，请显式删除它们。
存储账户应根据其大小、写入、读取、列出和容器操作进行计量。
优先选择标准磁盘而非高级磁盘；只有在业务需求时才使用高级磁盘。
使用 CDN 和缓存来处理静态文件，而不是每次都从存储中获取。
Azure 提供预留容量，以节省 Blob 数据的成本。

随时掌握这些最佳实践有助于你架构出具有成本效益的存储解决方案。在接下来的章节中，我们将讨论部署 PaaS 服务时的最佳实践。

PaaS 最佳实践

Azure 提供了许多 PaaS 服务，如果这些服务配置不当，可能会导致账单中出现意外费用。为了避免这种情况，你可以利用以下最佳实践：

选择合适的 Azure SQL 层级（基本版、标准版、Premium RS 或 Premium）和合适的性能等级。
在单一数据库和弹性数据库之间做出合适选择。如果数据库数量较多，使用弹性数据库比单一数据库更具成本效益。
将你的解决方案重新架构为使用 PaaS（无服务器或容器化的微服务）解决方案，而不是 IaaS 解决方案。这些 PaaS 解决方案可以消除维护成本，并且按每分钟消费计费。如果你不使用这些服务，即便你的代码和服务全天候可用，也不会产生费用。

针对特定资源有成本优化，但无法在一个章节中涵盖所有内容。建议你阅读与每个功能相关的成本和使用文档。

一般最佳实践

到目前为止，我们已经看过了服务特定的最佳实践，接下来我们将总结一些通用的指导原则：

资源的成本在不同地区有所不同。尝试选择另一个区域，前提是它不会造成性能或延迟问题。
企业协议（EA）提供的折扣优于其他优惠。你可以联系微软账户团队，了解签署 EA 后你可以获得哪些优惠。
如果 Azure 成本可以预付，那么所有类型的订阅都可以享受折扣。
删除或移除未使用的资源。找出那些使用率低的资源并减少它们的 SKU 或大小。如果不需要，删除它们。
使用 Azure Advisor，并认真对待其建议。

如前所述，这些是一些通用的指导原则，随着你架构更多的解决方案，你将能够为自己制定一套最佳实践。但一开始，你可以考虑这些建议。尽管如此，Azure 中的每个组件都有其自身的最佳实践，架构设计时参考文档有助于你创建具有成本效益的解决方案。

总结

在本章中，我们学习了在云环境中工作时，成本管理和管理的重要性。我们还讨论了各种 Azure 定价选项和 Azure 提供的各种价格优化功能。管理项目的成本至关重要，主要是因为每月的费用可能非常低，但如果没有定期监控资源，费用可能会增加。云架构师应该以成本效益的方式设计他们的应用程序。他们应该使用适当的 Azure 资源、适当的 SKU、层级和大小，并且知道何时启动、停止、向上扩展、向外扩展、向下扩展、向内扩展、转移数据等。正确的成本管理将确保实际费用符合预算费用。

在下一章，我们将介绍与数据服务相关的各种 Azure 功能，例如 Azure SQL、Cosmos DB 和分片。

第七章：7. Azure OLTP 解决方案

Azure 提供了基础设施即服务（IaaS）和平台即服务（PaaS）服务。这些服务为组织提供了不同层次的存储、计算和网络控制。存储是处理数据存储和传输时使用的资源。Azure 提供了多种存储数据的选项，如 Azure Blob 存储、表存储、Cosmos DB、Azure SQL 数据库、Azure 数据湖等。虽然其中一些选项适用于大数据存储、分析和呈现，但也有一些是针对处理事务的应用程序。Azure SQL 是 Azure 中与事务数据配合使用的主要资源。

本章将重点讨论使用事务数据存储的各个方面，如 Azure SQL 数据库以及其他通常用于在线事务处理（OLTP）系统的开源数据库，并将涵盖以下主题：

OLTP 应用程序
关系型数据库
部署模型
Azure SQL 数据库
单一实例
弹性池
托管实例
Cosmos DB

我们将从了解 OLTP 应用程序是什么开始，并列出 Azure 的 OLTP 服务及其用例。

OLTP 应用程序

如前所述，OLTP 应用程序是帮助处理和管理事务的应用程序。一些最常见的 OLTP 实现可以在零售销售、金融交易系统和订单输入中找到。这些应用程序执行数据捕获、数据处理、数据检索、数据修改和数据存储。然而，OLTP 应用程序不仅限于此。OLTP 应用程序将这些数据任务视为事务。事务具有一些重要的特性，OLTP 应用程序需要考虑这些特性。这些特性被归纳为ACID，让我们详细讨论这些特性：

原子性：该特性表示一个事务必须由多个语句组成，且这些语句要么都执行成功，要么都不执行。如果多个语句被组合在一起，它们就形成了一个事务。原子性意味着每个事务被视为最小的执行单元，要么成功完成，要么失败。
一致性：该特性关注数据库中数据的状态。它规定任何状态的变化应当是完整的，并基于数据库的规则和约束，且不允许部分更新。
隔离性：该特性表示系统上可以同时执行多个并发事务，并且每个事务应当在隔离状态下执行。一个事务不应了解或干扰任何其他事务。如果事务按顺序执行，那么最终的数据状态应与执行前相同。
持久性：此属性表明，一旦数据提交到数据库，它应该被持久化并可用，即使发生故障。已提交的事务变为事实。

现在你已经了解了什么是 OLTP 应用程序，让我们来讨论关系型数据库在 OLTP 应用程序中的作用。

关系型数据库

OLTP 应用程序通常依赖关系型数据库进行事务管理和处理。关系型数据库通常以表格格式呈现，由行和列组成。数据模型被转换为多个表，每个表通过关系与另一个表相连接（基于规则）。这个过程也称为规范化。

Azure 中有多个支持 OLTP 应用程序和关系型数据库部署的服务。在接下来的部分中，我们将查看与 OLTP 应用程序相关的 Azure 服务。

Azure 云服务

在 Azure 门户中搜索sql会提供多个结果。我已经标记出其中一些，显示可以直接用于 OLTP 应用程序的资源：

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

图 7.1：Azure SQL 服务列表

图 7.1展示了在 Azure 上创建基于 SQL Server 的数据库时可用的各种功能和选项。

再次，在 Azure 门户中快速搜索数据库会提供多个资源，图7.2中标记的部分可以用于 OLTP 应用程序：

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

图 7.2：用于 OLTP 应用程序的 Azure 服务列表

图 7.2展示了 Azure 提供的可以承载数据的资源，这些资源支持多种数据库，包括以下内容：

MySQL 数据库
MariaDB 数据库
PostgreSQL 数据库
Cosmos DB

接下来，让我们讨论部署模型。

部署模型

Azure 中的部署模型是根据管理或控制的级别来分类的。用户可以根据个人偏好选择管理或控制的级别；他们可以选择通过使用虚拟机等服务来获得完全控制，或者使用由 Azure 为其管理的托管服务。

在 Azure 上部署数据库有两种部署模型：

在 Azure 虚拟机上托管数据库（IaaS）
托管为托管服务（PaaS）的数据库

现在，我们将尝试了解在 Azure 虚拟机和托管实例上的部署区别。让我们从虚拟机开始。

在 Azure 虚拟机上托管的数据库

Azure 提供了多个 库存单位 (SKUs) 用于虚拟机。除了通用虚拟机外，还提供了高计算、高吞吐量（IOPS）虚拟机。与其在本地服务器上托管 SQL Server、MySQL 或其他数据库，不如将这些数据库部署在这些虚拟机上。这些数据库的部署和配置与本地部署没有区别。唯一的区别是数据库托管在云端，而不是使用本地服务器。管理员需要执行与本地部署相同的活动和步骤。尽管当客户希望完全控制其部署时，这个选项是一个不错的选择，但与此选项相比，还有一些模型可能在成本效益、可扩展性和高可用性方面更具优势，本章稍后将讨论这些模型。

在 Azure 虚拟机上部署任何数据库的步骤如下：

创建一个适应应用程序性能需求的虚拟机。
在其上部署数据库。
配置虚拟机和数据库配置。

该选项不提供任何现成的高可用性，除非配置多个服务器。它也不提供任何自动扩展功能，除非有自定义自动化来支持它。

灾难恢复仍然是客户的责任。服务器应部署在多个区域，并通过全球对等、VPN 网关、ExpressRoute 或 Virtual WAN 等服务进行连接。这些虚拟机可以通过站点对站点的 VPN 或 ExpressRoute 连接到本地数据中心，而无需暴露到外部网络。

这些数据库也被称为 非托管数据库。另一方面，托管在 Azure 上的数据库（除了虚拟机之外）由 Azure 管理，并称为 托管服务。在下一节中，我们将详细介绍这些内容。

托管服务中的数据库

托管服务意味着 Azure 提供数据库的管理服务。这些托管服务包括数据库的托管、确保主机的高可用性、确保数据在灾难恢复期间进行内部复制以提高可用性、确保在所选 SKU 的约束下实现可扩展性、监控主机和数据库并生成通知警报或执行操作、提供日志和审计服务以便于故障排除，并负责性能管理和安全警报。

简而言之，客户在使用 Azure 托管服务时，能够立刻获得大量服务，并且不需要对这些数据库进行主动管理。在本章中，我们将深入探讨 Azure SQL 数据库，并提供关于其他数据库的信息，如 MySQL 和 Postgres。同时，我们还将介绍非关系型数据库，如 Cosmos DB，它是一个 NoSQL 数据库。

Azure SQL 数据库

Azure SQL 服务器提供了作为 PaaS 托管的关系型数据库。客户可以配置此服务，带入自己的数据库架构和数据，并将应用程序连接到它。它提供了在虚拟机上部署 SQL Server 时的所有功能。这些服务不提供用于创建表格及其架构的用户界面，也不直接提供查询功能。应使用 SQL Server 管理工作室和 SQL CLI 工具连接到这些服务并直接操作。

Azure SQL 数据库提供三种不同的部署模型：

单实例： 在这种部署模型中，单个数据库被部署在一个逻辑服务器上。这涉及到在 Azure 上创建两个资源：一个 SQL 逻辑服务器和一个 SQL 数据库。
弹性池： 在这种部署模式下，多个数据库会被部署在一个逻辑服务器上。再次强调，这涉及到在 Azure 上创建两个资源：一个 SQL 逻辑服务器和一个 SQL 弹性数据库池——它包含所有的数据库。
托管实例： 这是 Azure SQL 团队推出的一种相对较新的部署模型。这种部署模式反映了在逻辑服务器上的一组数据库，提供对系统数据库资源的完全控制。通常，在其他部署模型中，系统数据库是不可见的，但在该模型中可以访问。该模型与 SQL Server 本地部署非常接近：

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

图 7.3：Azure SQL 数据库的部署模型

如果你在疑惑什么时候使用哪种服务，你应该查看 SQL 数据库与 SQL 托管实例之间的功能对比。完整的功能对比可以在docs.microsoft/azure/azure-sql/database/features-comparison找到。

接下来，我们将介绍 SQL 数据库的一些特性。让我们从应用程序功能开始。

应用程序特性

Azure SQL 数据库提供了多种面向应用程序的特性，以满足 OLTP 系统的不同需求：

列式存储： 该特性允许数据以列的格式而不是行的格式存储。
内存中 OLTP： 通常，数据存储在 SQL 的后端文件中，并在应用程序需要时从中提取数据。与此相反，内存中 OLTP 将所有数据存储在内存中，读取存储的数据时没有延迟。将内存中 OLTP 数据存储在 SSD 上为 Azure SQL 提供了最佳性能。
所有本地 SQL Server 的功能。

接下来我们要讨论的功能是高可用性。

高可用性

默认情况下，Azure SQL 的高可用性为 99.99%。它根据 SKU 具有两种不同的架构来保持高可用性。对于基础、标准和通用 SKU，整个架构被划分为以下两层。

计算层
存储层

这两个层次都有冗余设计，以提供高可用性：

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

图 7.4：标准 SKU 中的计算和存储层

对于高级和业务关键型 SKU，计算和存储都在同一层。高可用性通过在四节点集群中复制计算和存储来实现，使用类似于 SQL Server Always On 可用性组的技术：

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

图 7.5：四节点集群部署

现在你了解了高可用性是如何处理的，接下来我们讨论下一个功能：备份。

备份

Azure SQL 数据库还提供了自动备份数据库并将其存储在存储账户中的功能。这个功能在数据库损坏或用户不小心删除表时尤其重要。此功能在服务器级别可用，如图 7.6所示：

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

图 7.6：在 Azure 中备份数据库

架构师应准备备份策略，以便在需要时可以使用备份。在配置备份时，确保备份频率既不太少也不太频繁。根据业务需求，可以配置每周备份，甚至每日备份，或根据需要配置更频繁的备份。这些备份可用于恢复目的。

备份将有助于业务连续性和数据恢复。您还可以使用地理复制来恢复区域故障时的数据。在下一部分，我们将介绍地理复制。

地理复制

Azure SQL 数据库还提供了将数据库复制到不同区域（也称为次级区域）的功能；这完全取决于您选择的计划。次级区域中的数据库可以被应用程序读取。Azure SQL 数据库允许可读的次级数据库。这是一个很好的业务连续性解决方案，因为任何时刻都可以使用可读数据库。通过地理复制，可以在不同区域或相同区域最多拥有四个次级数据库。通过地理复制，也可以在发生灾难时故障转移到次级数据库。地理复制在数据库级别进行配置，如图 7.7所示：

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

图 7.7：Azure 中的地理复制

如果你在这个屏幕上向下滚动，将列出可以作为副本的区域，如图 7.8所示：

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

图 7.8：可用于地理复制的副本列表

在设计涉及地理复制的解决方案之前，我们需要验证数据驻留和合规性法规。如果由于合规原因不允许将客户数据存储在区域外，我们就不应该将其复制到其他区域。

在下一节中，我们将探讨可扩展性选项。

可扩展性

Azure SQL 数据库通过增加更多资源（如计算、内存和 IOPS）提供垂直可扩展性。这可以通过增加数据库吞吐量单位（DTU）或在vCore模型中增加计算和存储资源来实现：

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

图 7.9：Azure SQL 数据库中的可扩展性

我们在本章后面介绍了基于 DTU 模型和基于 vCore 模型之间的区别。

在下一节中，我们将介绍安全性，帮助你理解如何在 Azure 中构建安全的数据解决方案。

安全性

安全性是任何数据库解决方案和服务的重要因素。Azure SQL 为 Azure SQL 提供了企业级的安全性，本节将列出一些 Azure SQL 中的重要安全功能。

防火墙

默认情况下，Azure SQL 数据库不提供任何请求的访问权限。必须显式接受源 IP 地址才能访问 SQL 服务器。也可以选择允许所有基于 Azure 的服务访问 SQL 数据库。此选项包括托管在 Azure 上的虚拟机。

防火墙可以在服务器级别进行配置，而不是在数据库级别进行配置。允许访问 Azure 服务选项允许所有服务，包括虚拟机，访问托管在逻辑服务器上的数据库。

默认情况下，由于安全原因，此功能将被禁用；启用此功能将允许所有 Azure 服务访问：

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

图 7.10：在 Azure 中配置服务器级别的防火墙

Azure SQL 服务器专用网络

尽管 SQL 服务器通常可以通过互联网访问，但也可以将 SQL 服务器的访问限制为来自虚拟网络的请求。这是 Azure 中一个相对较新的功能。它帮助通过虚拟网络中的另一台服务器上的应用程序访问 SQL 服务器中的数据，而不通过互联网发出请求。

为此，应该在虚拟网络中添加一个Microsoft.Sql类型的服务端点，并且虚拟网络应与 Azure SQL 数据库所在的区域相同：

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

图 7.11：添加 Microsoft.Sql 服务端点

应选择虚拟网络中的一个合适的子网：

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

图 7.12：为 Microsoft.Sql 服务选择子网

最后，在 Azure SQL Server 配置面板中，应添加一个已启用Microsoft.Sql服务终结点的现有虚拟网络：

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

图 7.13：添加具有 Microsoft.Sql 服务终结点的虚拟网络

静态时加密的数据库

数据库在静态时应以加密形式存在。这里的静态意味着数据处于数据库的存储位置。尽管你可能无法访问 SQL Server 及其数据库，但最好还是加密数据库存储。

文件系统上的数据库可以使用密钥进行加密。这些密钥必须存储在 Azure 密钥保管库中，并且该保管库必须与 Azure SQL 服务器位于同一地区。可以通过 SQL Server 配置面板中的透明数据加密菜单项，并选择是来启用使用您自己的密钥来加密文件系统。

密钥是一个 RSA 2048 密钥，必须存在于保管库中。SQL Server 在需要读取数据并将其发送给调用方时，会在页面级别解密数据；然后，它会在写入数据库后对其进行加密。应用程序无需任何更改，并且这对它们是完全透明的：

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

图 7.14：SQL Server 中的透明数据加密

动态数据屏蔽

SQL Server 还提供了一种功能，能够屏蔽包含敏感数据的单个列，这样除了特权用户之外，其他人无法通过 SQL Server Management Studio 查询来查看实际数据。数据将保持屏蔽状态，只有当经过授权的应用程序或用户查询表时，数据才会被解屏蔽。架构师应确保像信用卡信息、社会安全号码、电话号码、电子邮件地址和其他财务信息等敏感数据被屏蔽。

可以在表中的列上定义屏蔽规则。有四种主要的屏蔽类型—你可以在这里查看它们：docs.microsoft/sql/relational-databases/security/dynamic-data-masking?view=sql-server-ver15#defining-a-dynamic-data-mask。

图 7.15 显示了如何添加数据屏蔽：

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

图 7.15：SQL 数据库中的动态数据屏蔽

Azure Active Directory 集成

另一个重要的 Azure SQL 安全特性是，它可以与 Azure Active Directory（AD）集成，用于身份验证。如果没有与 Azure AD 集成，SQL Server 唯一的身份验证机制是通过用户名和密码进行身份验证，即 SQL 身份验证。无法使用集成的 Windows 身份验证。SQL 身份验证的连接字符串包括明文的用户名和密码，这并不安全。与 Azure AD 集成可以启用 Windows 身份验证、服务主体名称或基于令牌的身份验证，从而对应用程序进行身份验证。将 Azure SQL 数据库与 Azure AD 集成是一个好做法。

还有其他安全功能，如高级威胁防护、环境审计和监控，应该在任何企业级的 Azure SQL 数据库部署中启用。

到此，我们已经结束了对 Azure SQL 数据库功能的介绍，现在可以继续讨论 SQL 数据库的类型。

单实例

单实例数据库作为单个数据库托管在单个逻辑服务器上。这些数据库无法访问 SQL Server 提供的所有完整功能。每个数据库都是隔离的且可移植的。单实例支持我们之前讨论的 vCPU 和 DTU 购买模型。

单数据库的另一个优势是成本效益。如果您使用 vCore 模型，可以选择较低的计算和存储资源来优化成本。如果需要更多的计算或存储能力，您可以随时进行扩展。动态可扩展性是单实例的一个突出特性，可以根据业务需求动态地扩展资源。单实例使现有的 SQL Server 客户能够将本地应用程序迁移到云端。

其他功能包括可用性、监控和安全性。

当我们开始介绍 Azure SQL 数据库时，我们也提到过弹性池。您还可以将单一数据库转换为弹性池，以便共享资源。如果您在疑惑什么是资源共享和弹性池，下一节我们将详细介绍这一点。

弹性池

弹性池是一个逻辑容器，可以在单个逻辑服务器上托管多个数据库。弹性池适用于 vCore 模型和 DTU 模型的购买方式。vCPU 购买模型是默认且推荐的部署方式，您可以根据业务负载选择计算和存储资源。如图 7.16所示，您可以选择需要的核心数和存储量：

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

图 7.16：在 vCore 模型中设置弹性池

此外，在前面的图表顶部，你可以看到一个选项，上面写着 Looking for basic, standard, premium? 如果选择此项，模型将切换为 DTU 模型。

DTU 基础模型中可用于弹性池的 SKU 如下：

基本
标准
高级

图 7.17 显示了每个 SKU 可提供的最大 DTU 数量：

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

图 7.17：弹性池每个 SKU 的 DTU 数量

针对 Azure SQL 单实例讨论的所有功能同样适用于弹性池；然而，水平可扩展性是一个额外功能，支持分片。分片指的是数据的垂直或水平分区，并将数据存储在不同的数据库中。还可以通过消耗比实际分配的 DTU 更多的 DTU 来实现弹性池中各个数据库的自动扩展。

弹性池还在成本方面提供了另一项优势。你将在后续部分看到，Azure SQL 数据库是按 DTU 定价的，且 DTU 在 SQL Server 服务配置完成后立即分配。无论是否使用这些 DTU，都会对其收费。如果有多个数据库，可以将这些数据库放入弹性池中，并在它们之间共享 DTU。

实现使用 Azure SQL 弹性池分片的所有信息可以在 docs.microsoft/azure/sql-database/sql-database-elastic-scale-introduction 找到。

接下来，我们将讨论托管实例部署选项，它是一种可扩展、智能、基于云的完全托管数据库。

托管实例

托管实例是一项独特的服务，提供类似于本地服务器上可用的托管 SQL 服务器。用户可以访问主数据库、模型数据库和其他系统数据库。托管实例非常适合多个数据库和客户将其实例迁移到 Azure。托管实例由多个数据库组成。

Azure SQL 数据库提供了一种新的部署模型，即 Azure SQL 数据库托管实例，它与 SQL Server 企业版数据库引擎几乎 100% 兼容。该模型提供了本地虚拟网络实现，解决了常见的安全问题，是本地 SQL Server 客户非常推荐的业务模型。托管实例允许现有的 SQL Server 客户将其本地应用程序迁移到云端，几乎不需要对应用程序和数据库进行更改，同时保留所有 PaaS 能力。这些 PaaS 能力大大减少了管理开销和总拥有成本，如 图 7.18 所示：

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

图 7.18：Azure SQL 数据库托管实例

Azure SQL 数据库、Azure SQL 托管实例和在 Azure 虚拟机上的 SQL Server 之间的完整比较可在此查看：docs.microsoft/azure/azure-sql/azure-sql-iaas-vs-paas-what-is-overview#comparison-table。

托管实例的关键功能显示在图 7.19中：

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

图 7.19：SQL 数据库托管实例功能

我们在本章中提到过 vCPU 定价模型和 DTU 定价模型。现在是时候更仔细地了解这些定价模型了。

SQL 数据库定价

Azure SQL 之前只有一种定价模型——基于 DTU 的模型——但现在也推出了基于 vCPU 的替代定价模型。定价模型根据客户的需求进行选择。当客户希望使用简单且预配置的资源选项时，选择基于 DTU 的模型；而基于 vCore 的模型则提供选择计算和存储资源的灵活性，同时也提供更多的控制和透明度。

让我们更仔细地看看这些模型。

基于 DTU 的定价

DTU 是 Azure SQL 数据库性能衡量的最小单位。每个 DTU 对应一定量的资源。这些资源包括存储、CPU 周期、IOPS 和网络带宽。例如，一个 DTU 可能提供三个 IOPS、少量 CPU 周期，以及 5 毫秒的读操作延迟和 10 毫秒的写操作延迟。

Azure SQL 数据库提供多种 SKU 用于创建数据库，每种 SKU 都有定义的 DTU 最大限制。例如，Basic SKU 只提供5个 DTU 和最大2 GB的数据，如图 7.20所示：

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

图 7.20：不同 SKU 的 DTU

另一方面，标准 SKU 提供从10个 DTU 到300个 DTU 之间的任何数量，最大数据量为250 GB。如你所见，每个 DTU 的费用大约为 991 卢比，或大约$1.40：

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

图 7.21：标准 SKU 中选择数量的 DTU 费用总结

Microsoft 提供了这些 SKU 在性能和资源方面的比较，并显示在图 7.22中：

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

图 7.22：Azure 中的 SKU 比较

一旦你配置了特定数量的 DTU，后端资源（CPU、IOPS 和内存）就会被分配，并且无论是否使用，都需要为其付费。如果采购的 DTU 数量超过实际需要，就会造成浪费；而如果配置的 DTU 数量不足，则会导致性能瓶颈。

正因如此，Azure 提供了弹性池。如您所知，弹性池中有多个数据库，DTU 是分配给弹性池的，而不是单个数据库。池内的所有数据库可以共享 DTU。这意味着，如果某个数据库的使用量较低，仅消耗了 5 个 DTU，则会有其他数据库消耗 25 个 DTU 来进行补偿。

需要注意的是，总体上，DTU 的消耗不能超过为弹性池分配的 DTU 数量。此外，弹性池内的每个数据库应分配最小的 DTU 数量，这个最小的 DTU 数量是预分配给数据库的。

弹性池有自己的 SKU：

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

图 7.23：弹性池中的 SKU

此外，单个弹性池中可以创建的数据库数量有限。完整的限制可以在此查看：docs.microsoft/azure/azure-sql/database/resource-limits-dtu-elastic-pools。

基于 vCPU 的定价

这是 Azure SQL 的新定价模型。此定价模型提供了根据服务器分配的虚拟 CPU（vCPU）数量来采购，而不是为应用设置所需的 DTU 数量的选项。vCPU 是附带硬件的逻辑 CPU，例如存储、内存和 CPU 核心。

在此模型中，有三个 SKU：通用型、超大规模和业务关键型，每个 SKU 提供不同数量的 vCPU 和资源。此定价适用于所有 SQL 部署模型：

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

图 7.24：通用 SKU 的 vCPU 定价

如何选择合适的定价模型

架构师应能够为 Azure SQL 数据库选择合适的定价模型。DTU 是一种很好的定价机制，适用于有适用和可用使用模式的数据库。由于 DTU 方案中的资源可用性是线性的，如下图所示，数据库的使用可能更多的是内存密集型而非 CPU 密集型。在这种情况下，可以为数据库选择不同级别的 CPU、内存和存储。

在 DTU 模型中，资源是打包在一起的，无法对这些资源进行细粒度配置。而在 vCPU 模型中，可以为不同的数据库选择不同级别的内存和 CPU。如果已知某应用的使用模式，使用 vCPU 定价模型可能比 DTU 模型更合适。事实上，vCPU 模型还为已拥有本地 SQL Server 许可证的组织提供了混合许可证的好处。这些 SQL Server 实例可获得最高 30% 的折扣。

在图 7.25中，你可以从左侧的图表看到，随着 DTU 数量的增加，资源可用性也线性增长；然而，在右侧的 vCPU 定价图表中，你可以为每个数据库选择独立的配置：

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

图 7.25：DTU 和 vCore 模式的存储计算图

有了这些内容，我们可以结束对 Azure SQL 数据库的介绍。我们讨论了与 Azure SQL 数据库相关的不同部署方法、功能、定价和计划。在接下来的章节中，我们将介绍 Cosmos DB，它是一个 NoSQL 数据库服务。

Azure Cosmos DB

Cosmos DB 是 Azure 真实的跨区域、高可用、分布式、多模型数据库服务。如果你希望你的解决方案具有高度响应性并且始终可用，那么 Cosmos DB 适合你。由于这是一个跨区域的多模型数据库，我们可以将应用程序部署在离用户位置更近的地方，从而实现低延迟和高可用性。

只需点击按钮，就可以在任意数量的 Azure 区域之间扩展吞吐量和存储。为了涵盖几乎所有非关系型数据库的需求，提供了几种不同的数据库模型，包括：

SQL（文档）
MongoDB
Cassandra
表
Gremlin 图

Cosmos DB 中的对象层次结构从 Cosmos DB 账户开始。一个账户可以拥有多个数据库，每个数据库可以拥有多个容器。根据数据库的类型，容器可能包含文档（例如 SQL 的情况）；在 Table 存储中包含半结构化的键值数据；或者如果使用 Gremlin 和 Cassandra 存储 NoSQL 数据，则包含实体及其之间的关系。

Cosmos DB 可用于存储 OLTP 数据。它在事务数据方面符合 ACID 原则，但有一些例外情况。

Cosmos DB 在单个文档级别提供 ACID 要求。这意味着文档中的数据在更新、删除或插入时，其原子性、一致性、隔离性和持久性将得到维护。然而，在文档之外，一致性和原子性需要由开发者自己管理。

Cosmos DB 的定价可以在这里找到：azure.microsoft/pricing/details/cosmos-db。

图 7.26 展示了 Azure Cosmos DB 的一些特性：

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

图 7.26：Azure Cosmos DB 概览

在接下来的章节中，我们将介绍 Azure Cosmos DB 的一些关键特性。

特性

Azure Cosmos DB 的一些主要优点包括：

全球分布：可以使用 Azure Cosmos DB 构建全球范围内的高度响应和高可用应用程序。在复制的帮助下，数据副本可以存储在接近用户的 Azure 区域，从而提供更低的延迟和全球分布。
**复制：**你可以随时选择是否将数据复制到某个地区。假设你的数据在东部美国地区有一个副本，而你的组织计划在东部美国停用该服务并迁移到英国南部。只需几次点击，你就可以移除东部美国并将英国南部添加到账户中进行复制。
始终在线：Cosmos DB 提供 99.999% 的高可用性，支持读取和写入。通过 Azure 门户或编程方式，可以触发 Cosmos DB 账户的区域故障切换到其他地区。这确保了应用在发生区域故障时的业务连续性和灾难恢复计划。
可扩展性：Cosmos DB 提供无与伦比的全球弹性可扩展性，支持读取和写入。其扩展响应非常强大，意味着你可以通过一次 API 调用将请求量从数千增加到数亿次每秒。值得注意的是，这一切是在全球范围内完成的，但你只需要为吞吐量和存储付费。这种可扩展性非常适合应对意外的流量高峰。
低延迟：如前所述，将数据副本复制到离用户更近的地方可以显著减少延迟，这意味着用户可以在毫秒级别访问数据。Cosmos DB 保证全球范围内的读取和写入延迟低于 10 毫秒。
TCO 节省：由于 Cosmos DB 是完全托管的服务，客户需要的管理程度较低。此外，客户无需在全球范围内设置数据中心来支持其他地区的用户。
SLA：它提供 99.999% 的高可用性 SLA。
对开源软件（OSS） API的支持：Cosmos DB 还支持开源软件 API，另一个额外的优势。Cosmos DB 实现了 Cassandra、Mongo DB、Gremlin 和 Azure 表存储的 API。

使用案例场景

如果你的应用涉及全球范围的大规模数据读写，那么 Cosmos DB 是理想的选择。这类应用通常包括网页应用、移动应用、游戏和物联网应用。这些应用将从 Cosmos DB 的高可用性、低延迟和全球覆盖中获益。

此外，Cosmos DB 提供的响应时间接近实时。你可以利用 Cosmos DB SDK 开发基于 Xamarin 框架的 iOS 和 Android 应用。

一些使用 Cosmos DB 的热门游戏包括行尸走肉：无人之地（由 Next Games 开发）和光环 5：守护者。

完整的使用案例和示例列表可以在此找到：docs.microsoft/azure/cosmos-db/use-cases。

Cosmos DB 是 Azure 中用于存储半结构化数据的首选服务，尤其适用于 OLTP 应用程序。我可以单独写一本书来讲解 Cosmos DB 的功能和特性；本节的目的是为你介绍 Cosmos DB 以及它在处理 OLTP 应用程序中的作用。

总结

在本章中，你学习到 Azure SQL 数据库是 Azure 的旗舰服务之一。今天，众多客户正在使用此服务，它提供了构建任务关键型数据库管理系统所需的所有企业级功能。

你发现 Azure SQL 数据库有多种部署类型，如单实例、托管实例和弹性池。架构师应该全面评估他们的需求并选择合适的部署模型。选择部署模型后，他们还需要在 DTU 和 vCPU 之间选择定价策略。除此之外，他们还应该配置 Azure SQL 数据库中所有与数据相关的安全性、可用性、灾难恢复、监控、性能和可扩展性需求。

在下一章，我们将讨论如何在 Azure 中构建安全的应用程序。我们将涵盖大多数服务的安全实践和功能。

第八章：8. 在 Azure 上构建安全应用的架构

在上一章中，我们讨论了 Azure 数据服务。由于我们正在处理敏感数据，安全性成为一个大问题。毫无疑问，安全性是架构师必须实现的最重要的非功能性需求。企业非常重视正确实施其安全策略。实际上，安全性是几乎所有利益相关者在应用的开发、部署和管理过程中关注的重点之一。当应用被构建并部署到云时，安全性变得更加重要。

为了帮助你了解如何根据部署的性质保护在 Azure 上的应用，本章将涵盖以下内容：

了解 Azure 中的安全性
基础设施层的安全性
应用层的安全性
Azure 应用中的认证与授权
使用 OAuth、Azure Active Directory 和其他通过联合身份验证的方法，包括第三方身份提供商如 Facebook
了解托管身份并使用它们访问资源

安全性

如前所述，安全性是任何软件或服务的重要元素。应实施适当的安全措施，使得应用仅能被允许访问的人使用，且用户不应执行他们无权操作的功能。同样，整个请求-响应机制应该使用确保只有目标方能够理解消息的方法构建，并确保能够轻松检测消息是否已被篡改。

以下原因使得 Azure 中的安全性变得尤为重要。首先，部署应用的组织无法完全控制底层硬件和网络。其次，安全性必须在每一层中构建，包括硬件、网络、操作系统、平台和应用。任何疏漏或配置错误都可能导致应用暴露于入侵者的攻击之下。例如，你可能听说过最近影响 Zoom 会议的漏洞，该漏洞允许黑客即使在会议主持人禁用与会者录音功能时，仍能录制会议。有消息称，数百万个 Zoom 账户已被销售到暗网。公司已经采取了必要的措施来解决这个漏洞。

安全性是当前一个重要的问题，尤其是在云环境中托管应用时，如果处理不当可能会导致严重后果。因此，理解保护工作负载的最佳实践非常必要。随着 DevOps 领域的进展，开发和运维团队借助工具和实践进行有效协作，安全性也成为一个重要关注点。

为了将安全原则和实践作为 DevOps 的重要组成部分，而不影响整体生产力和效率，已经引入了一种新的文化，称为DevSecOps。DevSecOps 帮助我们在开发阶段及早识别安全问题，而不是在发布后再进行缓解。在一个将安全作为每个阶段关键原则的开发过程中，DevSecOps 减少了后期雇佣安全专业人员来查找软件安全漏洞的成本。

保护应用程序意味着未知和未经授权的实体无法访问它。这也意味着与应用程序的通信是安全的且未被篡改。包括以下安全措施：

身份验证：身份验证检查用户的身份，并确保给定的身份可以访问应用程序或服务。在 Azure 中，身份验证使用基于 OAuth 2.0 构建的身份验证协议 OpenID Connect 来执行。
授权：授权允许并确定身份在应用程序或服务内能够执行的权限。授权在 Azure 中使用 OAuth 来执行。
机密性：机密性确保用户与应用程序之间的通信保持安全。实体之间的有效载荷交换是加密的，只有发送方和接收方能够理解，而其他人无法解读。消息的机密性通过对称加密和非对称加密来保障。证书用于实现加密，即消息的加密和解密。

对称加密使用一个共享的密钥，发送方和接收方都使用这个密钥，而非对称加密则使用一对私钥和公钥进行加密，提供更高的安全性。Linux 中的 SSH 密钥对，作为身份验证的工具，就是非对称加密的一个很好的例子。
完整性：完整性确保发送方和接收方之间的有效载荷和消息交换不会被篡改。接收方收到的消息与发送方发送的消息完全相同。数字签名和哈希是检查传入消息完整性的实现机制。

安全性是服务提供者与服务消费者之间的合作。双方对部署堆栈有不同的控制级别，每方都应实施安全最佳实践，以确保所有威胁被识别并得到缓解。从第一章，开始使用 Azure中，我们已经知道云计算大致提供三种模式——IaaS、PaaS 和 SaaS——每种模式在部署堆栈的协作控制上有所不同。每方应对其控制和范围内的组件实施安全实践。若在任何层面或任何一方未实施安全性，整个部署和应用将容易受到攻击。每个组织都需要有一个安全生命周期模型，就像对待任何其他流程一样。这确保了安全实践不断改进，以避免任何安全漏洞。在下一节中，我们将讨论安全生命周期及其如何使用。

安全生命周期

安全性通常被视为解决方案的非功能性需求。然而，随着网络攻击数量的增加，现在它被视为每个解决方案的功能性需求。

每个组织都会遵循某种形式的应用生命周期管理。当安全性被视为功能性需求时，它应该遵循与应用开发相同的流程。安全性不应是事后考虑的问题；它应从一开始就成为应用的一部分。在应用的整体规划阶段，安全性也应该进行规划。根据应用的性质，应识别不同类型和类别的威胁，并根据这些识别，应该在范围和应对措施方面进行文档化。应进行威胁建模演练，以说明每个组件可能面临的威胁。这将有助于为应用设计安全标准和政策。这通常是安全设计阶段。下一阶段称为威胁缓解或构建阶段。在这一阶段，实施安全性的代码和配置，以缓解安全威胁和风险。

系统在未经测试之前无法被认为是安全的。应执行适当的渗透测试和其他安全测试，以识别未实施或被忽视的潜在威胁缓解措施。通过测试发现的漏洞将得到修复，生命周期将在应用的整个过程中持续进行。这种应用生命周期管理过程，如图 8.1所示，应遵循安全性：

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

图 8.1：安全生命周期

规划、威胁建模、识别、缓解、测试和修复是一个迭代的过程，即使在应用程序或服务投入使用后，这些过程仍然会继续。应该积极监控整个环境和应用程序，以便主动识别威胁并进行缓解。监控还应启用警报和审计日志，以帮助进行反应性诊断、故障排除以及消除威胁和漏洞。

任何应用程序的安全生命周期从规划阶段开始，最终进入设计阶段。在设计阶段，应用程序的架构被分解成细化的组件，并具有独立的通信和托管边界。威胁是基于它们与其他组件之间的交互以及跨托管边界的交互来识别的。在整体架构中，通过实施适当的安全特性来缓解威胁，一旦缓解措施到位，进一步的测试会验证威胁是否仍然存在。应用程序部署到生产环境并投入使用后，将对其进行安全监控，以检测任何安全漏洞和风险，并采取主动或被动的修复措施。

如前所述，不同的组织有不同的流程和方法来实施安全生命周期；同样，微软提供了有关安全生命周期的完整指导和信息，详细信息请访问www.microsoft/securityengineering/sdl/practices。通过微软分享的实践，每个组织都可以专注于构建更加安全的解决方案。在云计算时代的进步以及企业和客户数据迁移到云端的过程中，学习如何保护这些数据至关重要。在接下来的部分，我们将探讨 Azure 安全性以及不同级别的安全性，这将帮助我们在 Azure 中构建安全的解决方案。

Azure 安全性

Azure 通过多个 Azure 区域的数据中心提供所有服务。这些数据中心在区域内部以及区域之间互联。Azure 了解它为客户托管着关键任务应用程序、服务和数据，因此必须确保数据中心和区域的安全性是至关重要的。

客户将应用程序部署到云端，是基于他们相信 Azure 会保护他们的应用程序和数据免受漏洞和泄露的威胁。如果这种信任被打破，客户将不会迁移到云端，因此 Azure 在所有层次上实施安全措施，如图 8.2所示，从数据中心的物理边界到逻辑软件组件。每一层都有保护措施，甚至 Azure 数据中心团队也无法访问它们：

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

图 8.2：Azure 数据中心不同层次的安全特性

安全对微软和 Azure 至关重要。微软通过确保客户的部署、解决方案和数据在物理和虚拟层面上都得到完全的保护，从而建立起客户的信任。如果一个云平台不安全，无论是物理还是数字层面的，用户是不会使用它的。

为了确保客户对 Azure 的信任，Azure 开发中的每个活动都从安全角度进行规划、记录、审计和监控。物理 Azure 数据中心受到防止入侵和未经授权访问的保护。事实上，甚至微软的员工和运营团队也无法访问客户的解决方案和数据。以下是 Azure 提供的一些开箱即用的安全功能：

安全用户访问：只有客户可以访问自己的部署、解决方案和数据。即使是 Azure 数据中心的人员也无法访问客户的资料。客户可以允许其他人访问，但这是由客户自行决定的。
静态数据加密：Azure 对所有管理数据进行加密，包括各种企业级存储解决方案，以满足不同的需求。微软还为像 Azure SQL 数据库、Azure Cosmos DB 和 Azure Data Lake 等托管服务提供加密。由于数据是静态加密的，因此无法被任何人读取。它还为客户提供此功能，客户可以加密自己的静态数据。
传输加密：Azure 对所有从其网络传输的数据进行加密，同时确保其网络主干不会受到未经授权的访问。
主动监控和审计：Azure 会持续主动监控所有数据中心，及时识别任何违反规定、威胁或风险，并加以缓解。

Azure 符合各国、地方、国际及行业特定的合规标准。你可以在www.microsoft/trustcenter/compliance/complianceofferings上查阅微软合规性服务的完整清单。在部署符合合规要求的解决方案时，务必将其作为参考。现在我们已经了解了 Azure 的主要安全功能，接下来让我们深入探讨 IaaS 安全。在接下来的部分中，我们将探索客户如何利用 Azure 提供的 IaaS 安全功能。

IaaS 安全

Azure 是一个成熟的 IaaS 解决方案部署平台。许多 Azure 用户希望完全控制他们的部署，这些用户通常会使用 IaaS 来处理他们的解决方案。确保这些部署和解决方案的安全性是至关重要的，无论是默认的还是设计时的。Azure 提供了丰富的安全功能来保护 IaaS 解决方案。在本部分中，我们将介绍一些主要的安全功能。

网络安全组

IaaS 部署的最基本组成包括虚拟机和虚拟网络。虚拟机可能通过将公共 IP 分配给其网络接口暴露到互联网，或者仅对内部资源可用。其中一些内部资源可能会反过来暴露到互联网。无论如何，虚拟机应当确保其安全，以便未经授权的请求根本无法到达它们。虚拟机应通过能够过滤网络本身请求的机制进行安全保护，而不是让请求到达虚拟机后再采取行动。

隔离机制（Ring-fencing）是虚拟机使用的安全机制之一。此防护墙可以根据协议、源 IP、目标 IP、源端口和目标端口允许或拒绝请求。此功能通过 Azure 网络安全组（NSGs）资源进行部署。NSGs 由规则组成，评估传入和传出的请求。根据这些规则的执行和评估，决定是否允许或拒绝访问请求。

NSGs 灵活且可以应用于虚拟网络子网或单个网络接口。当应用于子网时，安全规则会应用到该子网上托管的所有虚拟机。另一方面，应用于网络接口时，只影响与该网络接口关联的特定虚拟机的请求。也可以同时将 NSGs 应用到网络子网和网络接口。通常，应该使用这种设计在网络子网级别应用通用安全规则，在网络接口级别应用独特的安全规则。这有助于设计模块化的安全规则。

评估 NSGs 的流程如图 8.3所示：

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

图 8.3：表示评估 NSGs 的流程图

当请求到达 Azure 主机时，根据请求是传入请求还是传出请求，适当的规则会加载并应用到请求/响应上。如果规则与请求/响应匹配，则请求/响应被允许或拒绝。规则匹配由重要的请求/响应信息组成，如源 IP 地址、目标 IP 地址、源端口、目标端口和使用的协议。此外，NSGs 支持服务标签。服务标签表示来自特定 Azure 服务的一组 IP 地址前缀。微软管理这些地址前缀并自动更新，从而消除了每次地址前缀变更时需要更新安全规则的麻烦。

可用于的服务标签集可以在docs.microsoft/azure/virtual-network/service-tags-overview#available-service-tags中找到。服务标签可以与 NSG 一起使用，也可以与 Azure 防火墙一起使用。现在你已经了解了 NSG 的工作原理，我们来看看 NSG 设计，这将帮助你在创建 NSG 规则以提高安全性时，确定应该考虑的主要点。

NSG 设计

设计 NSG 的第一步是确定资源的安全需求。应确定或考虑以下内容：

该资源仅从互联网可访问吗？
该资源是否同时可以从内部资源和互联网访问？
该资源仅能从内部资源访问吗？
根据正在部署的解决方案架构，确定所依赖的资源、负载均衡器、网关和虚拟机。
配置虚拟网络及其子网。

根据这些调查结果，应创建合适的 NSG 设计。理想情况下，每个工作负载和资源类型应该有多个网络子网。建议不要在同一子网上部署负载均衡器和虚拟机。

根据项目需求，应确定适用于不同虚拟机工作负载和子网的通用规则。例如，对于 SharePoint 部署，前端应用程序和 SQL 服务器部署在不同的子网中，因此应该为每个子网确定规则。

在识别常见的子网级规则后，应识别单个资源的规则，并将这些规则应用于网络接口级别。需要理解的是，如果某个规则允许某个端口的入站请求，那么该端口也可以用于发出的请求，而无需额外配置。

如果资源可以通过互联网访问，应尽可能使用特定的 IP 范围和端口创建规则，而不是允许来自所有 IP 范围的流量（通常表示为 0.0.0.0/0）。应执行仔细的功能和安全性测试，以确保打开和关闭了足够且最佳的 NSG 规则。

防火墙

NSG 提供请求的外部安全边界。然而，这并不意味着虚拟机不需要实施额外的安全措施。最好同时在内部和外部实施安全性。无论是 Linux 还是 Windows 虚拟机，都提供一种机制来在操作系统级别过滤请求。这在 Windows 和 Linux 中都称为防火墙。

建议为操作系统实现防火墙。它们帮助建立一个虚拟安全墙，只允许那些被认为可信的请求。任何不可信的请求都会被拒绝访问。虽然也有物理防火墙设备，但在云端，通常使用操作系统防火墙。图 8.4展示了 Windows 操作系统的防火墙配置：

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

图 8.4：防火墙配置

防火墙过滤网络数据包，并识别传入的端口和 IP 地址。利用这些数据包中的信息，防火墙评估规则并决定是否允许或拒绝访问。

就 Linux 而言，有多种防火墙解决方案可供选择。某些防火墙方案非常特定于所使用的发行版；例如，SUSE 使用 SuSefirewall2，Ubuntu 使用 ufw。最广泛使用的实现是 firewalld 和 iptables，这些在每个发行版中都可以找到。

防火墙设计

作为最佳实践，应该评估每个操作系统的防火墙。每个虚拟机在整体部署和解决方案中都有独特的责任。应该明确这些责任的规则，并根据情况适当地打开和关闭防火墙。

在评估防火墙规则时，重要的是要考虑子网和单个网络接口级别的 NSG 规则。如果没有正确处理，可能会出现规则在 NSG 级别被拒绝，但在防火墙级别保持开放，反之亦然。如果请求在 NSG 级别被允许但在防火墙级别被拒绝，应用程序将无法按预期工作；而如果请求在 NSG 级别被拒绝但在防火墙级别被允许，则安全风险将增加。

防火墙帮助你建立多个通过其安全规则隔离的网络。应该进行仔细的功能性和安全性测试，确保适当且优化的防火墙规则被正确地开启和关闭。

使用 Azure 防火墙最为合理，它是建立在 NSG 之上的云端网络服务。它非常容易设置，提供中央管理功能，并且无需维护。结合 Azure 防火墙和 NSG 可以为虚拟机、虚拟网络，甚至不同的 Azure 订阅之间提供安全性。话虽如此，如果一个解决方案需要额外的安全级别，我们可以考虑实现操作系统级别的防火墙。我们将在接下来的章节中更深入地讨论Azure 防火墙。

应用程序安全组

NSG（网络安全组）可以应用于虚拟网络子网级别或直接应用于单个网络接口。虽然在子网级别应用 NSG 已经足够，但有时这还不够。在同一个子网内有不同类型的工作负载，每个工作负载需要不同的安全组。可以将安全组分配给虚拟机的单个网络接口卡（NICs），但如果虚拟机数量很大，这种做法容易变成维护的噩梦。

Azure 有一个相对较新的功能，叫做应用安全组。我们可以创建应用安全组，并将其直接分配给多个 NIC，即使这些 NIC 属于不同子网和资源组中的虚拟机。应用安全组的功能类似于 NSG，只是它提供了一种替代方法，将组分配给网络资源，并在跨资源组和子网分配时提供更多的灵活性。应用安全组可以简化 NSG；然而，它有一个主要的限制。我们可以在安全规则的源和目标中使用一个应用安全组，但当前不支持在源或目标中使用多个应用安全组。

创建规则的最佳实践之一是尽量减少所需的安全规则数量，以避免维护显式规则。在前一节中，我们讨论了如何使用服务标签与 NSG 配合，消除维护每个服务的单独 IP 地址前缀的麻烦。同样，使用应用安全组时，我们可以减少显式 IP 地址和多个规则的复杂性。推荐在可能的情况下使用这种做法。如果你的解决方案要求使用单独的 IP 地址或 IP 地址范围的显式规则，那么才应该选择这种方式。

Azure 防火墙

在前一节中，我们讨论了如何在 Windows/Linux 操作系统中使用 Azure 防火墙来允许或拒绝通过特定端口和服务的请求与响应。虽然操作系统防火墙在安全方面起着重要作用，并且必须在任何企业部署中实施，但 Azure 提供了一种名为 Azure 防火墙的安全资源，它具有类似的功能，可以基于规则过滤请求并确定是否应允许或拒绝该请求。

使用 Azure 防火墙的优点是，它会在请求到达操作系统之前进行评估。Azure 防火墙是一个网络资源，是一项独立服务，保护虚拟网络级别的资源。任何与虚拟网络直接关联的资源，包括虚拟机和负载均衡器，都可以通过 Azure 防火墙进行保护。

Azure 防火墙是一项高可用、可扩展的服务，不仅能保护基于 HTTP 的请求，还能保护从虚拟网络进出任何类型的请求，包括 FTP、SSH 和 RDP。Azure 防火墙还可以在部署期间跨多个可用性区域，提供更高的可用性。

强烈建议在 Azure 上部署 Azure 防火墙，以保护关键任务工作负载，并结合其他安全措施一起使用。还需注意，即使使用其他服务，如 Azure 应用程序网关和 Azure Front Door，仍应使用 Azure 防火墙，因为这些工具具有不同的作用范围和功能。此外，Azure 防火墙还支持服务标签和威胁情报。在前面的部分中，我们讨论了使用服务标签的优势。威胁情报可以用于在流量来自或去往已知恶意 IP 地址和域时生成警报，这些地址和域记录在微软的威胁情报数据流中。

减少攻击面

NSG 和防火墙有助于管理授权请求进入环境。然而，环境不应过度暴露于攻击。系统的表面区域应充分启用以实现其功能，但应禁用足够的部分，以便攻击者无法找到漏洞并访问那些没有预期用途或没有足够安全保护的开放区域。安全性应充分加固，使任何攻击者都难以入侵系统。

应该完成的一些配置包括以下内容：

从操作系统中移除所有不必要的用户和组。
确定所有用户的组成员身份。
使用目录服务实施组策略。
阻止脚本执行，除非它是由受信任的机构签名的。
记录并审计所有活动。
安装恶意软件和防病毒软件，定期进行扫描，并频繁更新定义。
禁用或关闭不需要的服务。
锁定文件系统，只允许授权访问。
锁定对注册表的更改。
必须根据要求配置防火墙。
PowerShell 脚本执行应设置为Set-ExecutionPolicy -ExecutionPolicy Restricted或Set-ExecutionPolicy -ExecutionPolicy RemoteSigned PowerShell 命令。
通过 Internet Explorer 启用增强保护。
限制创建新用户和组的权限。
移除互联网访问权限，并为 RDP 实施跳板服务器。
禁止通过互联网使用 RDP 登录到服务器。相反，应该使用站点到站点 VPN、点对站点 VPN 或 ExpressRoute 通过网络内部远程登录到远程计算机。
定期部署所有安全更新。
在环境中运行安全合规性管理工具，并实施其所有建议。
使用安全中心和操作管理套件主动监控环境。
部署虚拟网络设备，将流量路由到内部代理和反向代理。
所有敏感数据，如配置、连接字符串和凭据，应该进行加密。

上述内容是从安全角度应该考虑的一些关键点。这个列表将不断扩展，我们需要不断改进安全性，以防止任何形式的安全漏洞。

实现跳板服务器

从虚拟机中移除互联网访问是一个好主意。限制远程桌面服务从互联网访问虚拟机也是一种良好的做法，但那么如何访问虚拟机呢？一种可行的方法是仅允许内部资源通过 Azure VPN 选项进行 RDP 访问虚拟机。然而，还有另一种方法——使用跳板服务器。

跳板服务器是部署在隔离区（DMZ）中的服务器。这意味着它不在托管核心解决方案和应用程序的网络上，而是位于一个单独的网络或子网中。跳板服务器的主要目的是接受用户的 RDP 请求，并帮助他们登录。通过这个跳板服务器，用户可以进一步通过 RDP 连接到其他虚拟机。它可以访问两个或多个网络：一个是与外部世界连接的网络，另一个是与解决方案内部网络连接的网络。跳板服务器实施所有安全限制，并提供一个安全客户端来连接到其他服务器。通常，跳板服务器会禁用访问电子邮件和互联网。

使用 Azure 资源管理器模板部署带有虚拟机规模集（VMSS）的跳板服务器示例，请访问 azure.microsoft/resources/templates/201-vmss-windows-jumpbox。

Azure Bastion

在上一节中，我们讨论了实现跳板服务器。Azure Bastion 是一个完全托管的服务，可以在虚拟网络中进行配置，以便通过 TLS 在 Azure 门户中直接为您的虚拟机提供 RDP/SSH 访问。Bastion 主机将充当跳板服务器，消除了为虚拟机配置公共 IP 地址的需求。使用 Bastion 的概念与实现跳板服务器相同；然而，由于这是一个托管服务，因此完全由 Azure 管理。

由于 Bastion 是 Azure 提供的完全托管服务，并且内部已经进行了加固，因此我们无需在 Bastion 子网中应用额外的 NSG（网络安全组）。另外，由于我们没有为虚拟机附加任何公共 IP，它们就可以防止端口扫描。

应用安全

Web 应用可以在基于 IaaS 的解决方案中托管，这些解决方案建立在虚拟机之上，也可以在 Azure 提供的托管服务中托管，例如应用服务（App Service）。应用服务是 PaaS 部署模式的一部分，我们将在下一节中详细介绍。在这一节中，我们将探讨应用层安全性。

SSL/TLS

安全套接层（SSL）现在已经被弃用，取而代之的是传输层安全性（TLS）。TLS 通过加密提供端到端的安全性。它提供了两种类型的加密：

对称加密：发送者和接收者都可以使用相同的密钥，该密钥用于加密和解密消息。
非对称加密：每个利益相关者都有两把密钥——一把私钥和一把公钥。私钥保留在服务器上或用户手中并保持机密，而公钥可以自由分发给所有人。公钥持有者使用它来加密信息，而该信息只能通过对应的私钥解密。由于私钥保留在所有者手中，只有他们才能解密信息。Rivest–Shamir–Adleman（RSA）是用于生成这些公私密钥对的算法之一。
这些密钥也可以通过证书的形式提供，这些证书通常被称为 X.509 证书，尽管证书除了包含密钥外，还有更多的详细信息，并且通常由受信任的证书颁发机构签发。

Web 应用程序应该使用 TLS 来确保用户与服务器之间的消息交换是安全和机密的，并且身份得到保护。这些证书应该从受信任的证书颁发机构购买，而不是自签名证书。

托管身份

在我们了解托管身份之前，了解没有托管身份时应用程序是如何构建的非常重要。

传统的应用程序开发方式是在配置文件中使用机密，例如用户名、密码或 SQL 连接字符串。将这些机密放入配置文件使得对这些机密的应用程序更改变得容易且灵活，而无需修改代码。它帮助我们遵循“对扩展开放，对修改封闭”的原则。然而，从安全角度来看，这种方法有一个缺点。任何能够访问配置文件的人都可以查看这些机密，因为通常这些机密以明文列在其中。虽然有一些方法可以加密它们，但它们并非万无一失。

在应用程序中使用密钥和凭证的更好方法是将其存储在像 Azure Key Vault 这样的机密库中。Azure Key Vault 提供了通过硬件安全模块（HSM）的完全安全性，并且机密以加密方式存储，并通过存储在独立硬件中的密钥进行按需解密。机密可以存储在 Key Vault 中，每个机密都有一个显示名称和密钥。密钥以 URI 的形式存在，应用程序可以使用它来引用机密，如图 8.5所示：

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

图 8.5：将机密存储在密钥库中

在应用程序配置文件中，我们可以使用名称或密钥来引用机密。然而，现在又有一个新挑战。应用程序如何连接到并验证密钥保管库？

密钥保管库有访问策略，定义了用户或组在密钥保管库中访问密钥和凭证的权限。可以提供访问权限的用户、组或服务应用程序都在Azure Active Directory（Azure AD）中配置和托管。尽管可以通过密钥保管库的访问策略为单个用户账户提供访问权限，但更好的做法是使用服务主体来访问密钥保管库。服务主体有一个标识符，也称为应用程序 ID 或客户端 ID，以及一个密码。可以使用客户端 ID 和密码来验证 Azure 密钥保管库。这种服务主体可以被授权访问机密。Azure 密钥保管库的访问策略在密钥保管库的访问策略窗格中授予。在图 8.6中，您可以看到服务主体—https://keyvault.book—已获得访问名为 keyvaultbook 的密钥保管库的权限：

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

图 8.6：授予服务主体访问密钥保管库的权限

这引出了另一个挑战：要访问密钥保管库，我们需要在配置文件中使用客户端 ID 和密钥来连接到密钥保管库，获取密钥，并检索其值。这几乎相当于在配置文件中使用用户名、密码和 SQL 连接字符串。

这就是托管身份可以发挥作用的地方。Azure 推出了托管服务身份，并随后将其更名为托管身份。托管身份是由 Azure 管理的身份。在后台，托管身份还会创建一个服务主体，并附带一个密码。通过托管身份，您无需将凭证放入配置文件中。

托管身份只能用于与支持 Azure AD 作为身份提供者的服务进行身份验证。托管身份仅用于身份验证。如果目标服务没有为该身份提供基于角色的访问控制（RBAC）权限，则该身份可能无法在目标服务上执行其预期的操作。

托管身份有两种类型：

系统分配的托管身份
用户分配的托管身份

系统分配的身份由服务本身生成。例如，如果应用服务想要连接到 Azure SQL 数据库，它可以在其配置选项中生成系统分配的托管身份。这些托管身份在父资源或服务删除时也会被删除。如图 8.7所示，系统分配的身份可以由应用服务用于连接 Azure SQL 数据库：

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

图 8.7：为应用服务启用系统分配的托管标识

用户分配的托管标识是作为独立的单独标识创建的，之后将其分配给 Azure 服务。由于其生命周期不依赖于它们所分配的资源，它们可以应用并在多个 Azure 服务中重复使用。

一旦托管标识被创建并且通过 RBAC 或访问权限赋予目标资源，它就可以在应用程序中用于访问目标资源和服务。

Azure 提供了一个 SDK 和一个 REST API，用于与 Azure AD 交互并获取托管标识的访问令牌，然后使用该令牌访问和消费目标资源。

SDK 是 Microsoft.Azure.Services.AppAuthentication NuGet 包的一部分，适用于 C#。一旦访问令牌可用，它就可以用来消费目标资源。

获取访问令牌所需的代码如下：

var tokenProvider = new AzureServiceTokenProvider();
string token = await tokenProvider.GetAccessTokenAsync("https://vault.azure");

或者，使用此方法：

string token = await tokenProvider.GetAccessTokenAsync("https://database.windows");

应该注意，应用程序代码需要在应用服务或函数应用的上下文中运行，因为标识是附加在它们上的，只有在从这些上下文中运行时，代码才能访问标识。

上面的代码有两个不同的使用场景。访问密钥库和 Azure SQL 数据库的代码是一起展示的。

需要注意的是，应用程序不会在代码中提供任何与托管标识相关的信息，所有这些信息都通过配置进行完全管理。开发人员、单个应用程序管理员和操作员不会接触到任何与托管标识相关的凭证，而且在代码中也没有提到它们。凭证轮换完全由托管 Azure 服务的资源提供者进行管理。默认情况下，每 46 天会进行一次轮换。如果需要，资源提供者可以要求新的凭证，因此提供者可能会等超过 46 天才请求新的凭证。

在下一节中，我们将讨论一个云原生的安全信息和事件管理器（SIEM）：Azure Sentinel。

Azure Sentinel

Azure 提供了一个 SIEM 和安全编排自动响应（SOAR）作为一个独立服务，可以与任何自定义部署的 Azure 服务集成。图 8.8 显示了 Azure Sentinel 的一些关键功能：

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

图 8.8：Azure Sentinel 的关键功能

Azure Sentinel 收集来自部署和资源的信息日志，并进行分析，以找出与各种安全问题相关的模式和趋势，这些问题从数据源中提取。

应该对环境进行主动监控，收集日志，并从这些日志中提取信息，作为与代码实现分离的单独活动。这时，SIEM 服务发挥了作用。Azure Sentinel 可以使用许多连接器；这些连接器将用于向 Azure Sentinel 添加数据源。Azure Sentinel 提供了与 Microsoft 服务（如 Office 365、Azure AD 和 Azure 威胁保护）兼容的连接器。收集到的数据将被馈送到日志分析工作区，您可以编写查询来搜索这些日志。

像 Azure Sentinel 这样的 SIEM 工具可以在 Azure 上启用，从日志分析和 Azure 安全中心获取所有日志，而这些日志又可以从多个来源、部署和服务中获取。SIEM 然后可以在收集到的数据上运行其智能分析并生成洞察。它可以根据发现的智能生成报告和仪表板供消费使用，但它也可以调查可疑活动和威胁，并对其采取行动。

虽然 Azure Sentinel 在功能上可能与 Azure 安全中心非常相似，但 Azure Sentinel 的功能远超过 Azure 安全中心。它通过使用连接器从其他途径收集日志的能力，使其与 Azure 安全中心有所不同。

PaaS 安全性

Azure 提供了许多 PaaS 服务，每个服务都有自己的安全特性。通常，PaaS 服务可以通过凭据、证书和令牌进行访问。PaaS 服务允许生成短期有效的安全访问令牌。客户端应用程序可以发送这些安全访问令牌来表示受信任的用户。在本节中，我们将介绍一些在几乎所有解决方案中使用的最重要的 PaaS 服务。

Azure Private Link

Azure Private Link 提供通过虚拟网络中的私有端点访问 Azure PaaS 服务以及 Azure 托管的客户拥有/合作伙伴共享服务。在使用 Azure Private Link 时，我们不必将服务暴露到公共互联网，并且我们服务与虚拟网络之间的所有流量都通过微软的骨干网络进行。

Azure Private Endpoint 是一种网络接口，可帮助私密且安全地连接到由 Azure Private Link 提供支持的服务。由于私有端点映射到 PaaS 服务的实例，而不是整个服务，因此用户只能连接到资源。对任何其他服务的连接都会被拒绝，这样可以防止数据泄露。Private Endpoint 还允许您通过 ExpressRoute 或 VPN 隧道从本地安全访问。这消除了设置公共对等连接或通过公共互联网访问服务的需求。

Azure 应用程序网关

Azure 提供了一个称为 Azure 应用网关的 7 层负载均衡器，它不仅可以进行负载均衡，还可以根据 URL 中的值进行路由。它还具有称为 Web 应用程序防火墙的功能。Azure 应用网关支持在网关处终止 TLS，因此后端服务器将收到未加密的流量。这有几个优点，如更好的性能，更好地利用后端服务器以及数据包的智能路由。在前面的部分中，我们讨论了 Azure 防火墙及其如何在网络层保护资源。另一方面，Web 应用程序防火墙则在应用程序层保护部署。

任何部署在互联网上的应用程序都面临着多种安全挑战。以下是一些重要的安全威胁：

跨站脚本攻击
远程代码执行
SQL 注入
拒绝服务 (DoS) 攻击
分布式拒绝服务 (DDoS) 攻击

当然，还有更多的安全威胁。

开发人员可以通过编写防御性代码并遵循最佳实践来解决大量这些攻击；然而，仅仅是代码不应该负责在实时网站上识别这些问题。Web 应用程序防火墙配置规则可以识别此类问题，并拒绝请求，正如前文所述。

建议使用应用网关 Web 应用程序防火墙功能来保护应用程序免受实时安全威胁。Web 应用程序防火墙将根据配置的方式要么允许请求通过，要么阻止它。

Azure 前门

Azure 推出了一个相对较新的服务，称为 Azure 前门。Azure 前门的角色与 Azure 应用网关非常相似；然而，它在范围上有所不同。虽然应用网关在单个区域内工作，但 Azure 前门在全球范围内跨区域和数据中心工作。它也有一个 Web 应用程序防火墙，可以配置以保护部署在多个区域中的应用程序免受各种安全威胁，如 SQL 注入、远程代码执行和跨站脚本攻击。

应用网关可以部署在 Front Door 后面以解决连接排干。此外，将应用网关部署在 Front Door 后面还将有助于负载均衡需求，因为 Front Door 只能在全局层面进行基于路径的负载均衡。在架构中添加应用网关将为虚拟网络中的后端服务器提供进一步的负载均衡。

Azure 应用服务环境

Azure App Service 部署在共享网络中，并且在后台运行。所有 App Service 的 SKU 都使用虚拟网络，这些虚拟网络也可能被其他租户使用。为了更好地控制和确保在 Azure 上安全部署 App Service，可以将服务托管在专用虚拟网络上。可以通过使用 Azure App Service Environment（ASE）实现这一点，它提供完全隔离的环境，以高规模运行你的 App Service。这还通过允许你部署 Azure 防火墙、应用安全组、NSG、应用网关、Web 应用防火墙和 Azure Front Door 提供额外的安全性。所有在 App Service Environment 中创建的 App Service 计划将位于隔离的定价层，且无法选择其他层次。

这个虚拟网络和计算的所有日志可以在 Azure Log Analytics 和 Security Center 中整理，最终与 Azure Sentinel 配合使用。

然后，Azure Sentinel 可以提供洞察并执行工作簿和运行簿，以自动化方式响应安全威胁。安全行动手册可以在 Azure Sentinel 中响应警报时运行。每个安全行动手册包含在警报发生时需要采取的措施。安全行动手册基于 Azure Logic Apps，这使你可以自由使用并自定义与 Logic Apps 一起提供的内置模板。

Log Analytics

Log Analytics 是一个新的分析平台，用于管理云部署、内部数据中心和混合解决方案。

它提供了多个模块化解决方案——一种帮助实现特定功能的功能。例如，安全和审计解决方案帮助获取组织部署的完整安全视图。同样，还有许多其他解决方案，如自动化和变更跟踪，应该从安全角度实施。Log Analytics 的安全和审计服务提供以下五个类别的信息：

安全领域：这些提供了查看安全记录、恶意软件评估、更新评估、网络安全、身份和访问信息，以及具有安全事件的计算机的能力。还可以访问 Azure Security Center 控制面板。
反恶意软件评估：这有助于识别未受到恶意软件保护且存在安全问题的服务器。它提供有关潜在安全问题暴露的信息，并评估任何风险的严重性。用户可以根据这些建议采取主动措施。Azure Security Center 子类别提供由 Azure Security Center 收集的信息。
显著问题：这可以快速识别活动问题并评估其严重性。
检测：此类别处于预览模式。它通过可视化安全警报来识别攻击模式。
威胁情报：通过可视化拥有外发恶意 IP 流量的服务器总数、恶意威胁类型以及显示这些 IP 来源的地图，帮助识别攻击模式。

在门户中查看上述详细信息时，如图 8.9所示：

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

图 8.9：在 Log Analytics 的“安全与审计”面板中显示的信息

现在你已经了解了 PaaS 服务的安全性，接下来让我们探索如何保护存储在 Azure 存储中的数据。

Azure 存储

存储帐户在整体解决方案架构中扮演重要角色。存储帐户可以存储重要信息，如用户的个人可识别信息（PII）数据、商业交易以及其他敏感和机密数据。确保存储帐户安全并仅允许授权用户访问至关重要。存储的数据在传输时会进行加密，并使用安全通道传输。存储本身，以及使用存储帐户及其数据的用户和客户端应用程序，在数据整体安全性中扮演着至关重要的角色。数据应该始终保持加密状态。这也包括连接到数据存储的凭证和连接字符串。

Azure 提供 RBAC 来管理谁可以管理 Azure 存储帐户。这些 RBAC 权限赋予 Azure AD 中的用户和组。然而，当要部署到 Azure 的应用程序创建时，它将拥有不在 Azure AD 中的用户和客户。为了让用户能够访问存储帐户，Azure 存储提供存储访问密钥。存储帐户级别有两种访问密钥——主密钥和辅助密钥。拥有这些密钥的用户可以连接到存储帐户。这些存储访问密钥在访问存储帐户时用于身份验证步骤。应用程序可以使用主密钥或辅助密钥来访问存储帐户。提供两把密钥是为了防止主密钥被泄露时，应用程序可以更新为使用辅助密钥，同时主密钥被重新生成。这有助于最小化应用程序停机时间。此外，它通过移除被泄露的密钥来提高安全性，而不影响应用程序。通过 Azure 门户查看存储密钥详情，如图 8.10所示：

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

图 8.10：存储帐户的访问密钥

Azure 存储提供四种服务——blob、文件、队列和表格——在一个帐户中。每项服务还提供用于其自身安全性的基础设施，采用安全访问令牌。

共享访问签名（SAS）是一个 URI，它授予对 Azure 存储服务（如 Blob、文件、队列和表格）的受限访问权限。这些 SAS 令牌可以与不应信任整个存储账户密钥的客户端共享，从而限制对特定存储账户资源的访问。通过将 SAS URI 分发给这些客户端，可以在指定的时间段内授予资源访问权限。

SAS 令牌存在于存储账户及单个 Blob、文件、表格和队列级别。存储账户级别的签名功能更强大，具有在单个服务级别上允许或拒绝权限的权利。它还可以替代单个资源服务级别使用。

SAS 令牌提供了对资源的精细访问控制，并且可以组合使用。这些令牌包括读取、写入、删除、列出、添加、创建、更新和处理权限。此外，在生成 SAS 令牌时，还可以确定对资源的访问权限。可以单独针对 Blob、表格、队列和文件，也可以对它们的组合进行访问控制。存储账户密钥适用于整个账户，无法针对单个服务进行限制——也无法从权限角度进行限制。创建和撤销 SAS 令牌比存储账户访问密钥要容易得多。SAS 令牌可以为指定时间段创建，过期后自动失效。

需要注意的是，如果存储账户密钥被重新生成，那么基于这些密钥的 SAS 令牌将失效，需要创建新的 SAS 令牌并与客户端共享。在图 8.11中，您可以看到选择范围、权限、开始日期、结束日期、允许的 IP 地址、允许的协议和签名密钥的选项，以创建 SAS 令牌：

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

图 8.11：创建 SAS 令牌

如果我们正在重新生成key1（之前用于签署 SAS 令牌的密钥），那么我们需要使用key2或新的key1创建一个新的 SAS 令牌。

Cookie 偷窃、脚本注入和 DoS 攻击是攻击者常用的破坏环境和窃取数据的手段。浏览器和 HTTP 协议实现了内建机制，确保无法执行这些恶意活动。通常，任何跨域的请求都不被 HTTP 或浏览器允许。一个域中的脚本无法请求另一个域的资源。然而，在某些有效的用例中，应该允许此类请求。HTTP 协议实现了跨域资源共享（CORS）。借助 CORS，可以跨域访问资源并使其工作。Azure 存储为 blob、文件、队列和表资源配置 CORS 规则。Azure 存储允许创建在每个身份验证请求中进行评估的规则。如果规则满足，请求将被允许访问该资源。在图 8.12 中，您可以看到如何为每个存储服务添加 CORS 规则：

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

图 8.12：为存储账户创建 CORS 规则

数据不仅在传输过程中必须得到保护；在静态状态下也应该得到保护。如果静态数据没有加密，任何有权限访问数据中心物理硬盘的人都能读取这些数据。尽管数据泄露的可能性微乎其微，客户仍然应该加密他们的数据。存储服务加密有助于保护静态数据。该服务透明地工作，且用户无需知晓。它在数据保存到存储账户时进行加密，并在数据读取时自动解密。整个过程无需用户进行任何额外操作。

Azure 账户密钥必须定期轮换。这将确保攻击者无法访问存储账户。

重新生成密钥也是一个好主意；然而，必须根据其在现有应用程序中的使用情况进行评估。如果它破坏了现有应用程序，那么这些应用程序应优先考虑变更管理，并且变更应逐步应用。

始终建议为每个服务使用具有有限时间范围的独立 SAS 令牌。此令牌应仅提供给需要访问资源的用户。始终遵循最小权限原则，仅提供必要的权限。

SAS 密钥和存储账户密钥应存储在 Azure 密钥保管库中。这提供了安全的存储和访问方式。应用程序可以在运行时从密钥保管库读取这些密钥，而不是将它们存储在配置文件中。

此外，您还可以使用 Azure AD 来授权对 Blob 和队列存储的请求。我们将使用 RBAC（角色基于访问控制）为服务主体授予必要的权限，一旦我们使用 Azure AD 对服务主体进行身份验证，将生成一个 OAuth 2.0 令牌。该令牌可以添加到 API 调用的授权头中，以授权对 Blob 或队列存储的请求。微软建议在使用 Blob 和队列应用程序时使用 Azure AD 授权，因为 Azure AD 提供了更强的安全性，并且相比于 SAS 令牌更为简便。

在下一节中，我们将评估 Azure SQL 数据库的安全选项。

Azure SQL

SQL Server 在 Azure 上存储关系数据，它是一个托管的关系数据库服务。它也被称为数据库即服务（DBaaS），为数据存储提供了一个高可用、可扩展、注重性能并且安全的平台。它可以从任何地方、使用任何编程语言和平台访问。客户端需要一个包含服务器、数据库和安全信息的连接字符串才能连接到该服务。

SQL Server 提供防火墙设置，默认情况下防止任何人访问。IP 地址和范围应列入白名单才能访问 SQL Server。架构师应仅允许他们信任的、属于客户或合作伙伴的 IP 地址。对于一些在 Azure 上部署的应用程序，可能有很多 IP 地址或这些 IP 地址是未知的，例如部署在 Azure Functions 或 Logic Apps 中的应用程序。为了使此类应用程序能够访问 Azure SQL，Azure SQL 允许将所有 IP 地址列入白名单，以便跨订阅的 Azure 服务能够访问。

需要注意的是，防火墙配置是在服务器级别而不是数据库级别。这意味着在此处进行的任何更改都会影响服务器中的所有数据库。在图 8.13中，您可以看到如何将客户端的 IP 地址添加到防火墙中以授予访问服务器的权限：

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

图 8.13：配置防火墙规则

Azure SQL 还通过加密静态数据提供了增强的安全性。这确保没有人，包括 Azure 数据中心的管理员，能够查看存储在 SQL Server 中的数据。SQL Server 用于加密静态数据的技术被称为透明数据加密（TDE）。实施 TDE 不需要在应用程序级别进行任何更改。SQL Server 会在用户保存和读取数据时透明地加密和解密数据。此功能在数据库级别可用。我们还可以将 TDE 与 Azure Key Vault 集成，使用自带密钥（BYOK）功能。通过使用 BYOK，我们可以在 Azure Key Vault 中使用客户管理的密钥来启用 TDE。

SQL Server 还提供动态数据屏蔽（DDM），这对于屏蔽某些类型的数据（如信用卡详情或用户个人身份信息数据）特别有用。屏蔽与加密不同，屏蔽并不加密数据，而是只将其遮蔽，从而确保数据不以人类可读的格式呈现。用户应在 Azure SQL Server 中屏蔽并加密敏感数据。

SQL Server 还为所有服务器提供审计和威胁检测服务。这些数据库上运行着先进的数据收集和智能服务，用于发现威胁和漏洞，并提醒用户。审计日志由 Azure 保存在存储帐户中，管理员可以查看并采取行动。像 SQL 注入和匿名客户端登录等威胁可以生成警报，管理员可以通过电子邮件接收通知。在图 8.14中，您可以看到如何启用威胁检测：

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

图 8.14：启用威胁保护并选择要检测的威胁类型

数据可以在 Azure SQL 中被屏蔽。这样可以以无法被人类读取的格式存储数据：

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

图 8.15：配置设置以屏蔽数据

Azure SQL 还提供 TDE 来加密静态数据，如图 8.16所示：

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

图 8.16：启用 TDE

要对 SQL Server 进行漏洞评估，您可以利用 SQL 漏洞评估，它是高级 SQL 安全功能统一包“高级数据安全”的一部分。SQL 漏洞评估可供客户主动使用，通过发现、跟踪并帮助修复潜在的数据库漏洞，从而提高数据库的安全性。

在前面的部分中，我们已经多次提到 Azure 密钥库，当时我们讨论了托管身份、SQL 数据库等。现在您已经了解了 Azure 密钥库的用途，在接下来的部分中，我们将探讨一些方法，帮助您保护密钥库的内容。

Azure 密钥库

使用密码、密钥、凭证、证书和唯一标识符来保护资源是任何环境和应用程序从安全角度来看至关重要的一个环节。这些资源需要得到保护，确保它们保持安全且不被泄露是安全架构的重要支柱。管理和操作这些秘密和密钥的安全，同时确保在需要时能够访问它们，是不能忽视的重要方面。通常，这些秘密资源无处不在——在源代码中、配置文件里、纸张上以及其他数字格式中。为了克服这些挑战并将所有秘密资源统一存储在集中式的安全存储中，应使用 Azure Key Vault。

Azure Key Vault 与其他 Azure 服务紧密集成。例如，使用存储在 Azure Key Vault 中的证书并将其部署到 Azure 虚拟机的证书存储中是非常容易的。各种类型的密钥，包括存储密钥、IoT 密钥和事件密钥、连接字符串，都可以作为秘密存储在 Azure Key Vault 中。它们可以被透明地检索并使用，无需任何人查看或临时存储它们。SQL Server 和其他服务的凭证也可以存储在 Azure Key Vault 中。

Azure Key Vault 是基于每个区域运作的。这意味着 Azure Key Vault 资源应部署在与应用程序和服务相同的区域。如果部署涉及多个区域并需要 Azure Key Vault 服务，则应配置多个 Azure Key Vault 实例。

Azure Key Vault 的一个重要特点是，秘密、密钥和证书不会存储在一般存储中。这些敏感数据由 HSM（硬件安全模块）备份。这意味着这些数据存储在 Azure 上的独立硬件中，只有拥有密钥的用户才能解锁。为了提供额外的安全性，您还可以为 Azure Key Vault 实施虚拟网络服务终端。这将限制对密钥库的访问，仅限特定的虚拟网络。您还可以限制对某个 IPv4 地址范围的访问。

在 Azure 存储 部分，我们讨论了使用 Azure AD 来授权对 Blob 和队列的请求。提到我们使用的是从 Azure AD 获取的 OAuth 令牌，用于认证 API 调用。在接下来的部分中，您将学习如何使用 OAuth 进行身份验证和授权。完成下一部分后，您将能够将其与我们在 Azure 存储 部分讨论的内容联系起来。

使用 OAuth 进行身份验证和授权

Azure AD 是一个身份提供者，可以基于租户内已有的用户和服务主体来验证用户。Azure AD 实现了 OAuth 协议，并支持互联网授权。它实现了一个授权服务器和服务，以启用 OAuth 授权流，包括隐式流和客户端凭证流。这些是客户端应用程序、授权端点、用户和受保护资源之间不同的、文档化良好的 OAuth 交互流。

Azure AD 还支持单点登录（SSO），它在登录到注册在 Azure AD 中的应用程序时提供了更高的安全性和便利性。在开发新应用程序时，您可以使用 OpenID Connect、OAuth、SAML、基于密码的方法，或是联动或禁用的 SSO 方法。如果您不确定使用哪种方法，请参考 Microsoft 提供的流程图：docs.microsoft/azure/active-directory/manage-apps/what-is-single-sign-on#choosing-a-single-sign-on-method。

Web 应用程序、基于 JavaScript 的应用程序和本地客户端应用程序（如移动应用和桌面应用）都可以使用 Azure AD 进行身份验证和授权。有一些社交媒体平台，如 Facebook、Twitter 等，也支持 OAuth 协议进行授权。

启用使用 Facebook 进行 Web 应用程序身份验证的最简单方法之一如下所示。还有其他使用安全二进制文件的方法，但这超出了本书的范围。

在本操作步骤中，将配置一个 Azure 应用服务，并配合一个应用服务计划来托管自定义 Web 应用程序。需要一个有效的 Facebook 账户作为前提条件，以便将用户重定向到 Facebook 进行身份验证和授权。

可以使用 Azure 门户创建一个新的资源组，如图 8.17所示：

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

图 8.17：创建新资源组

创建资源组后，可以使用门户创建新的应用服务，如图 8.18所示：

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

图 8.18：创建新应用程序

请注意 Web 应用程序的 URL，因为在配置 Facebook 应用程序时需要使用该 URL。

一旦在 Azure 中配置好 Web 应用程序，下一步是在 Facebook 中创建一个新应用程序。这是为了在 Facebook 中表示您的 Web 应用程序，并生成适当的客户端凭证。通过这种方式，Facebook 才能识别您的 Web 应用程序。

访问 developers.facebook 并使用适当的凭据登录。通过在右上角的 我的应用 下选择 创建应用 选项来创建一个新应用，如图 8.19所示：

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

图 8.19：从 Facebook 开发者门户创建一个新应用

网页会提示你为网页应用提供一个名称，以便在 Facebook 内创建新应用：

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

图 8.20：添加新应用

添加一个新的 Facebook 登录 产品，并点击设置来配置在 Azure 应用服务上托管的自定义网页应用的登录：

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

图 8.21：将 Facebook 登录添加到应用中

设置按钮提供了几种选项，如图 8.22所示，这些选项配置 OAuth 流程，如授权流、隐式流或客户端凭证流。选择Web选项，因为这需要 Facebook 授权：

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

图 8.22：选择平台

提供我们在 Azure 上创建网页应用后记录的网页应用 URL：

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

图 8.23：为应用提供站点 URL

点击 domain name/.auth/login/facebook/callback：

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

图 8.24：添加 OAuth 重定向 URI

从左侧菜单进入基本设置，并记下 应用 ID 和 应用密钥 的值。这些值用于配置 Azure 应用服务的认证/授权：

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

图 8.25：查找应用 ID 和应用密钥

在 Azure 门户中，返回到本节前几步中创建的 Azure 应用服务，并导航到认证/授权面板。开启 应用服务认证，选择 使用 Facebook 登录 进行认证，然后从列表中点击 Facebook 项目：

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

图 8.26：在 App 服务中启用 Facebook 认证

在结果页面上，提供已记录的应用 ID 和应用密钥，并选择作用域。作用域决定 Facebook 与网页应用共享的信息：

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

图 8.27：选择作用域

点击确定然后点击保存按钮以保存身份验证/授权设置。

现在，如果启动一个新的隐身浏览器会话并访问自定义网页应用，请求应该会重定向到 Facebook。如你在其他网站上看到的，当使用 Facebook 登录 时，你将被要求输入凭证：

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

图 8.28：使用 Facebook 登录网站

一旦输入凭证，用户同意对话框将询问是否允许将 Facebook 的数据与网页应用共享：

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

图 8.29：用户同意将信息分享给应用程序

如果同意，网页应用的网页应该会出现：

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

图 8.30：访问登陆页面

可以使用类似的方法通过 Azure AD、Twitter、Microsoft 和 Google 来保护你的网页应用。如果需要，你还可以集成自己的身份提供者。

这里展示的方法只是其中一种通过将凭证存储在其他地方，并授权外部应用访问受保护资源来保护网站的方式。Azure 还提供 JavaScript 库和 .NET 程序集，使用命令式编程方法来调用 Azure AD 和其他社交媒体平台提供的 OAuth 端点。建议使用这种方法，以便在应用程序中对身份验证和授权进行更好的控制和灵活性。

到目前为止，我们讨论了安全特性及其如何实现。建立监控和审计机制也很重要。实施审计解决方案可以帮助你的安全团队审核日志并采取预防措施。在接下来的部分中，我们将讨论 Azure 中的安全监控和审计解决方案。

安全监控和审计

环境中的每一项活动，从电子邮件到更改防火墙，都可以被归类为安全事件。从安全角度来看，必须有一个中央日志系统来监控和跟踪所做的更改。在审计过程中，如果发现可疑活动，您可以发现架构中的漏洞是什么，以及如何修复它。此外，如果发生了数据泄露，日志将帮助安全专业人员理解攻击模式及其执行方式。同时，可以采取必要的预防措施，以避免未来发生类似事件。Azure 提供了以下两个重要的安全资源，用于管理 Azure 订阅、资源组和资源的所有安全方面：

Azure Monitor
Azure Security Center

在这两个安全资源中，我们将首先探讨 Azure Monitor。

Azure Monitor

Azure Monitor 是一个一站式的 Azure 资源监控平台。它提供有关 Azure 资源及其状态的信息。它还提供一个丰富的查询界面，使用可以通过订阅、资源组、单个资源和资源类型级别的数据进行切片和切块。Azure Monitor 收集来自多个数据源的数据，包括 Azure 的指标和日志、客户应用程序以及运行在虚拟机中的代理。其他服务，如 Azure Security Center 和 Network Watcher，也将数据导入 Log Analytics 工作区，可以通过 Azure Monitor 进行分析。您还可以使用 REST API 将自定义数据发送到 Azure Monitor。

可以通过 Azure 门户、PowerShell、CLI 和 REST API 使用 Azure Monitor：

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

图 8.31：查看活动日志

以下是 Azure Monitor 提供的日志：

活动日志：此功能显示对资源执行的所有管理级操作。它提供有关创建时间、创建者、资源类型和资源状态的详细信息。
操作日志（经典）：此功能提供关于在资源组和订阅内对资源执行的所有操作的详细信息。
指标：此功能获取单个资源的性能信息并设置警报。
诊断设置：此功能通过设置 Azure 存储来存储日志、将日志实时流式传输到 Azure Event Hubs，并将其发送到 Log Analytics，帮助我们配置影响日志。
日志搜索：此功能有助于将 Log Analytics 与 Azure Monitor 集成。

Azure Monitor 可以识别与安全相关的事件并采取适当的行动。非常重要的一点是，只有授权人员才能访问 Azure Monitor，因为它可能包含敏感信息。

Azure Security Center

如其名称所示，Azure 安全中心是满足所有安全需求的一站式平台。安全通常涉及两项活动——实施安全措施和监控威胁与漏洞。安全中心主要是为了帮助完成这两项活动而构建的。Azure 安全中心使用户能够定义安全策略，并在 Azure 资源上实现这些策略。基于 Azure 资源的当前状态，Azure 安全中心提供安全建议，以加固解决方案和单个 Azure 资源。这些建议包括几乎所有 Azure 安全最佳实践，涵盖数据和磁盘加密、网络保护、端点保护、访问控制列表、来访请求的白名单以及阻止未经授权的请求等。资源涵盖从基础设施组件，如负载均衡器、网络安全组和虚拟网络，到 PaaS 资源，如 Azure SQL 和存储等。以下是概述面板的摘录，显示了订阅的整体安全评分、资源安全卫生状况等信息：

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

图 8.32：Azure 安全中心概述

Azure 安全中心是一个功能丰富的平台，提供多种服务的推荐，如 图 8.33 所示。此外，这些建议可以导出为 CSV 文件以供参考：

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

图 8.33：Azure 安全中心推荐

正如本节开始时提到的，监控和审计在企业环境中至关重要。Azure Monitor 可以拥有多个数据源，并可用于审计来自这些数据源的日志。Azure 安全中心提供持续的评估和优先级安全建议，以及整体的安全评分。

摘要

安全始终是任何部署或解决方案中的一个重要方面。由于云部署的兴起，安全变得更加重要和相关。此外，网络攻击的威胁也日益增加。在这种情况下，安全已成为组织的焦点。无论是 IaaS、PaaS 还是 SaaS 类型的部署或解决方案，都需要进行安全保障。Azure 数据中心完全安全，且拥有十多个国际安全认证。它们默认情况下是安全的。它们提供 IaaS 安全资源，如 NSG、网络地址转换、安全端点、证书、密钥库、存储、虚拟机加密等，以及为单个 PaaS 资源提供的 PaaS 安全功能。安全有完整的生命周期，应该像其他应用功能一样，进行适当的规划、设计、实施和测试。

我们讨论了操作系统防火墙和 Azure 防火墙，以及如何利用它们来增强解决方案的整体安全性。我们还探索了 Azure 的一些新服务，如 Azure Bastion、Azure Front Door 和 Azure Private Link。

应用程序安全是另一个关键领域，我们讨论了如何使用 OAuth 进行身份验证和授权。我们演示了如何创建一个应用服务并集成 Facebook 登录。Facebook 只是一个例子，你也可以使用 Google、Twitter、Microsoft、Azure AD 或任何自定义身份提供商。

我们还探讨了 Azure SQL 提供的安全选项，Azure SQL 是由 Azure 提供的托管数据库服务。我们讨论了安全功能的实现，最后一节我们通过 Azure Monitor 和 Azure Security Center 来进行监控和审计。安全在你的环境中扮演着至关重要的角色。架构师应始终将安全性作为架构的主要支柱之一进行设计和架构；Azure 提供了许多选项来实现这一目标。

现在你已经了解了如何在 Azure 中保护数据，接下来的章节我们将重点讲解 Hadoop 的大数据解决方案，随后是数据湖存储、数据湖分析和数据工厂。

第九章：9. Azure 大数据解决方案

在上一章中，你学习了可以在 Azure 上实施的各种安全策略。通过安全的应用程序，我们可以管理大量数据。近年来，大数据获得了显著的关注。处理大数据需要专用的工具、软件和存储。有趣的是，几年前这些工具、平台和存储选项还不以服务形式提供。然而，随着新云技术的出现，Azure 提供了众多工具、平台和资源，可以轻松创建大数据解决方案。本章将详细介绍数据的摄取、清理、过滤和可视化的完整架构。

本章将涵盖以下主题：

大数据概览
数据集成
抽取-转换-加载 (ETL)
数据工厂
数据湖存储
像 Spark、Databricks 和 Hadoop 这样的工具生态系统
Databricks

大数据

随着廉价设备的涌入——如物联网设备和手持设备——生成和捕捉的数据量呈指数级增长。几乎每个组织都拥有大量数据，并且如果需要，他们也准备好购买更多。当大量数据以多种格式并以不断增加的速度到达时，我们就可以说我们在处理大数据。简而言之，大数据有三个关键特征：

体量：体量指的是数据的数量，包括大小（例如 GB、TB 和 PB）以及记录的数量（例如在层级数据存储中的百万行、10 万张图片、5 亿个 JSON 文档等）。
速度：速度指的是数据到达或被摄取的速度。如果数据变化不频繁或新数据不常到达，则数据的速度被认为是低的；而如果频繁更新并且有大量新数据持续不断地到达，则数据的速度被认为是高的。
多样性：多样性指的是数据的不同种类和格式。数据可以来自不同来源，且格式各异。数据可以是结构化数据（如逗号分隔文件、JSON 文件或层级数据）、半结构化数据库（如无模式的 NoSQL 文档），或是非结构化数据（如二进制大对象（blobs）、图片、PDF 等）。由于存在如此多的变体，因此必须有一个明确的处理流程来处理接收的数据。

在下一部分，我们将查看大数据的通用处理过程。

大数据处理过程

当数据来自不同来源，格式不同，且速度不同的时候，制定一个存储、整合、过滤和清理数据的过程变得至关重要，这样可以帮助我们更轻松地处理数据，并使数据能够服务于其他流程。必须有一个明确的数据管理流程。大数据的通用处理流程应遵循 图 9.1 所示：

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

图 9.1：大数据处理

大数据处理有四个主要阶段。让我们详细探讨它们：

Ingest：这是将数据引入和摄入到大数据环境中的过程。数据可以来自多个来源，应使用连接器将该数据摄入到大数据平台中。
Store：摄入后，数据应存储在数据池中以进行长期存储。存储应包括历史数据和实时数据，并且必须能够存储结构化、半结构化和非结构化数据。应该有连接器从数据源读取数据，或者数据源应能够将数据推送到存储中。
Analysis：从存储中读取数据后，应对其进行分析，这个过程需要过滤、分组、连接和转换数据以获取洞察。
Visualize：分析结果可以作为报告通过多种通知平台发送，也可以用于生成带有图表和图形的仪表板。

以前，由于涉及昂贵的硬件和大量投资，组织机构无法轻易获得捕获、摄入、存储和分析大数据所需的工具。此外，也没有平台可供处理它们。随着云计算的出现，组织机构现在可以更轻松地使用他们首选的工具和框架捕获、摄入、存储和执行大数据分析。他们可以支付云提供商使用其基础设施，避免任何资本支出。而且，与任何本地解决方案相比，云计算的成本非常便宜。

大数据需要大量的计算、存储和网络资源。通常，所需资源量不适合在单台计算机或服务器上拥有。即使在某种程度上，可以在单台服务器上提供足够的资源，处理整个大数据池所需的时间也相当长，因为每个作业按顺序完成，每个步骤都依赖于前一步骤。需要专门的框架和工具来分布工作到多个服务器，并最终从这些服务器返回结果，并在适当地结合所有服务器的结果后呈现给用户。这些工具是专门的大数据工具，帮助实现可用性、可扩展性和分发，以确保大数据解决方案能够通过内置的稳健性和稳定性快速运行。

显著的 Azure 大数据服务包括 HD Insights 和 Databricks。让我们继续探索大数据领域中提供的各种工具。

大数据工具

大数据空间中有许多工具和服务，我们将在本章中介绍其中一些。

Azure 数据工厂

Azure 数据工厂是 Azure 中的旗舰 ETL 服务。它定义了传入数据（根据其格式和模式），根据业务规则和过滤器转换数据，增强现有数据，并最终将数据传输到目标存储，供其他下游服务轻松消费。它能够在 Azure 上运行管道（包含 ETL 逻辑），以及在自定义基础设施上运行，还可以运行 SQL Server 集成服务包。

Azure 数据湖存储

Azure 数据湖存储是企业级的大数据存储，开箱即用即具备弹性、高可用性和安全性。它与 Hadoop 兼容，能够扩展到 PB 级别的数据存储。它建立在 Azure 存储帐户之上，因此直接获得所有存储帐户的优势。当前版本称为 Gen2，源自 Azure 存储和数据湖存储 Gen1 的能力合并。

Hadoop

Hadoop 由 Apache 软件基金会创建，是一个分布式、可扩展且可靠的框架，用于处理大数据。它将大数据拆分成较小的数据块并将它们分布在集群中。一个 Hadoop 集群由两种类型的服务器组成——主节点和从节点。主节点包含 Hadoop 的管理组件，而从节点是进行数据处理的地方。Hadoop 负责在从节点之间进行逻辑数据分区；从节点执行所有数据转换、收集洞察并将其返回给主节点，主节点将它们整理成最终输出。Hadoop 可以扩展到数千台服务器，每台服务器为作业提供计算和存储服务。Hadoop 也可以通过 Azure 的HDInsight服务作为一种服务提供。

Hadoop 核心系统由三个主要组件组成：

HDFS：Hadoop 分布式文件系统（HDFS）是一个用于存储大数据的文件系统。它是一个分布式框架，通过将大数据文件分解为较小的数据块并将其放置在集群中的不同从节点上来帮助处理数据。HDFS 是一个容错的文件系统。这意味着，尽管不同的数据块分配给集群中的不同从节点，但数据在从节点之间也会进行复制，以确保在某个从节点失败时，数据也能在另一个服务器上可用。它还提供快速高效的数据访问。

MapReduce：MapReduce 是另一个重要的框架，使 Hadoop 能够并行处理数据。该框架负责处理存储在 HDFS 从节点中的数据并将其映射到从节点。在从节点完成处理后，“reduce”部分将来自每个从节点的信息汇总到一起，生成最终输出。通常，HDFS 和 MapReduce 会在同一节点上运行，这样数据就不需要在从节点之间传输，从而提高处理效率。

YARN：Yet Another Resource Negotiator（YARN）是一个重要的 Hadoop 架构组件，帮助在集群内调度与应用程序和资源管理相关的作业。YARN 作为 Hadoop 2.0 的一部分发布，许多人将其视为 MapReduce 的继任者，因为它在批处理和资源分配方面更为高效。

Apache Spark

Apache Spark 是一个分布式、可靠的大规模数据处理分析平台。它提供一个集群，能够并行运行转换和机器学习作业，并将汇总结果返回给客户端。它由主节点和工作节点组成，其中主节点负责在作业内划分和分发操作和数据到工作节点之间，并将所有工作节点的结果汇总并返回给客户端。在使用 Spark 时要记住的一件重要事情是，逻辑或计算应易于并行化，并且数据量太大以至于无法适应一台机器。Spark 在 Azure 中作为 HDInsight 和 Databricks 的服务提供。

Databricks

Databricks 构建在 Apache Spark 之上。它是一个平台即服务，为用户提供管理的 Spark 集群。它提供许多附加功能，如完整的门户管理 Spark 集群及其节点，以及帮助创建笔记本、调度和运行作业，以及为多个用户提供安全性和支持。

现在，是时候学习如何从多个源集成数据并使用我们讨论过的工具共同处理它们了。

数据集成

我们深知集成模式如何用于应用程序；由多个服务组成的应用程序使用各种模式进行集成。然而，还有另一种范例对许多组织来说是关键需求，即被称为数据集成。数据集成的激增主要发生在过去十年间，当时数据的生成和可用性显著增加。数据生成的速度、多样性和数量大幅增加，数据几乎无处不在。

每个组织都有许多不同类型的应用程序，它们都以自己的专有格式生成数据。通常，数据也从市场购买。即使在组织合并和合并期间，也需要迁移和组合数据。

数据集成是指从多个源带入数据并生成新输出的过程，该输出具有更多的意义和可用性。

在以下场景中明确需要数据集成：

从源或一组源迁移数据到目标位置。这是为了让数据以不同的格式对各种利益相关者和消费者可用。
从数据中获取洞察。随着数据的快速增加，组织希望从中获取洞察。它们希望创建提供洞察的解决方案；来自多个源的数据应该被合并、清洗、增强，并存储在数据仓库中。
生成实时仪表盘和报告。
创建分析解决方案。

应用程序集成在用户使用应用程序时具有运行时行为——例如，在信用卡验证和集成的情况下。另一方面，数据集成是在后台执行的，并且不直接与用户活动相关联。

让我们继续了解如何使用 Azure 数据工厂理解 ETL 过程。

ETL

一个非常流行的过程称为 ETL，它有助于构建目标数据源，以存储应用程序可以使用的数据。通常，数据是以原始格式存在的，为了使其可用，数据需要经过以下三个不同的阶段：

提取：在这个阶段，数据从多个地方提取。例如，可能有多个数据源，它们需要连接在一起以便检索数据。提取阶段通常使用包含目标数据源连接信息的数据连接器。它们还可能有临时存储，用于将数据从数据源提取并存储，以便更快地检索。这个阶段负责数据的摄取。
转换：在提取阶段之后的数据可能无法直接被应用程序使用。这可能是由于多种原因；例如，数据可能存在不规则性，可能有缺失的数据，或数据可能存在错误。或者，可能有一些数据根本不需要。或者，数据的格式可能不适合目标应用程序的使用。在所有这些情况下，必须对数据进行转换，使其能够高效地被应用程序使用。
加载：在数据转换后，应该将数据加载到目标数据源中，格式和架构使其能够更快、更容易地提供给应用程序，以提高性能。通常，这包括目标数据源的数据连接器以及将数据加载到其中的过程。

接下来，让我们来了解一下 Azure 数据工厂如何与 ETL 过程相关联。

Azure 数据工厂简介

Azure 数据工厂是一个完全托管、高可用、高可扩展、易于使用的工具，用于创建集成解决方案并实现 ETL 阶段。数据工厂帮助你以拖放方式通过用户界面创建新的管道，而无需编写任何代码；然而，它仍然提供功能，允许你用自己喜欢的编程语言编写代码。

在使用数据工厂服务之前，有一些重要的概念需要了解，我们将在接下来的章节中更详细地探讨这些概念：

活动：活动是能够在数据工厂管道中运行和处理逻辑的单个任务。活动有多种类型，涉及数据移动、数据转换和控制活动。每个活动都有一个策略，可以通过该策略决定重试机制和重试间隔。
管道：数据工厂中的管道由一组活动组成，负责将活动集合在一起。管道是工作流和调度器，能够实现 ETL 阶段的运行。管道允许将活动编织在一起，并允许声明它们之间的依赖关系。通过使用依赖关系，可以使某些任务并行执行，其他任务按顺序执行。
数据集：数据集是数据的来源和目的地。这些可以是 Azure 存储账户、数据湖存储或其他多个来源。
链接服务：这些是包含数据集连接和连接信息的服务，并由各个任务用于连接到它们。
集成运行时：负责运行数据工厂的主要引擎叫做集成运行时。集成运行时有以下三种配置：
Azure：在此配置下，数据工厂运行在 Azure 提供的计算资源上。
自托管：在此配置下，数据工厂在你提供自己的计算资源时运行。这可以通过本地或基于云的虚拟机服务器来实现。
Azure SQL Server 集成服务 (SSIS): 此配置允许运行使用 SQL Server 编写的传统 SSIS 包。
版本：数据工厂有两个不同的版本。需要理解的是，所有新开发将发生在 V2 上，V1 将保持原样，或者在某个时候逐渐淘汰。V2 优先的原因如下：

它提供了运行 SQL Server 集成包的功能。

它相较于 V1 提供了增强的功能。

它提供了 V1 中缺少的增强监控功能。

现在你已经对数据工厂有了较为清晰的理解，让我们来看一下 Azure 上可用的各种存储选项。

Azure 数据湖入门

Azure 数据湖为大数据解决方案提供存储。它专门设计用于存储大数据解决方案中通常需要的大量数据。它是 Azure 提供的托管服务。客户需要将他们的数据带来并存储在数据湖中。

Azure 数据湖存储有两个版本：版本 1（Gen1）和当前版本，版本 2（Gen2）。Gen2 拥有 Gen1 的所有功能，但有一个特别的区别是它建立在 Azure Blob 存储之上。

由于 Azure Blob 存储具有高可用性、可以多次复制、具备灾难恢复能力并且成本较低，这些优势也被继承到 Gen2 Data Lake 中。Data Lake 可以存储任何类型的数据，包括关系型、非关系型、基于文件系统和层次化数据。

创建 Data Lake Gen2 实例与创建新存储账户一样简单。唯一需要做的更改是在存储账户的高级选项卡中启用层次命名空间。需要注意的是，无法直接将通用存储账户迁移或转换为 Azure Data Lake，反之亦然。此外，存储账户用于存储文件，而 Data Lake 则针对读取和摄取大量数据进行了优化。

接下来，我们将探讨处理大数据时的流程和主要阶段。这些是不同的阶段，每个阶段负责数据的不同操作。

将数据从 Azure 存储迁移到 Data Lake 存储 Gen2

在本节中，我们将把数据从 Azure Blob 存储迁移到同一 Azure Blob 存储实例中的另一个 Azure 容器，并且我们还将使用 Azure Data Factory 管道将数据迁移到 Azure Data Lake Gen2 实例。以下各节概述了创建此端到端解决方案所需的步骤。

准备源存储账户

在我们可以创建 Azure Data Factory 管道并将其用于迁移之前，需要创建一个新的存储账户，存储账户由多个容器组成，并上传数据文件。在实际操作中，这些文件和存储连接通常已经准备好。创建新 Azure 存储账户的第一步是创建一个新的资源组，或者在 Azure 订阅内选择一个现有的资源组。

配置新的资源组

Azure 中的每个资源都与一个资源组关联。在我们配置 Azure 存储账户之前，需要创建一个资源组来承载存储账户。创建资源组的步骤如下所示。需要注意的是，在配置 Azure 存储账户时，可以创建一个新的资源组，或者使用现有的资源组：

导航到 Azure 门户，登录并点击 资源组。
从搜索结果中选择 资源组，然后创建一个新的资源组。提供名称并选择合适的位置。请注意，所有资源应该托管在同一资源组和位置，这样删除时会更方便。

在配置资源组之后，我们将在其中配置一个存储账户。

配置存储账户

在本节中，我们将介绍创建新的 Azure 存储账户的步骤。这个存储账户将从中获取数据源，并迁移数据。执行以下步骤来创建存储账户：

点击 存储账户。从搜索结果中选择 存储账户，然后创建一个新的存储账户。
提供名称和位置，然后选择基于之前创建的资源组的订阅。
在帐户类型中选择StorageV2 (通用目的 v2)，在性能中选择标准，在复制中选择本地冗余存储（LRS），如图 9.2所示：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_09_02.jpg

图 9.2：配置存储帐户
现在在存储帐户中创建几个容器。rawdata容器包含将由数据工厂管道提取的文件，并将作为源数据集，而finaldata将包含数据工厂管道将写入数据的文件，并将作为目标数据集：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_09_03.jpg

图 9.3：创建容器
将数据文件（该文件随源代码一起提供）上传到rawdata容器，如图 9.4所示：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_09_04.jpg

图 9.4：上传数据文件

完成这些步骤后，源数据准备工作完成。现在我们可以专注于创建 Data Lake 实例。

配置 Data Lake Gen2 服务

如我们所知，Data Lake Gen2 服务是建立在 Azure 存储帐户之上的。因此，我们将以与之前相同的方式创建一个新的存储帐户——唯一的区别是在新 Azure 存储帐户的高级选项卡中选择启用，以支持层次命名空间。这将创建新的 Data Lake Gen2 服务：

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

图 9.5：创建新存储帐户

在创建数据湖之后，我们将专注于创建一个新的 Data Factory 管道。

配置 Azure Data Factory

现在我们已经配置了资源组和 Azure 存储帐户，是时候创建一个新的 Data Factory 资源了：

通过选择V2并提供名称和位置，以及资源组和订阅选择，创建一个新的 Data Factory 管道。

Data Factory 有三个不同的版本，如图 9.6所示。我们已经讨论了V1和V2：

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

图 9.6：选择数据工厂的版本
创建完数据工厂资源后，点击中央窗格中的Author & Monitor链接。

这将打开另一个窗口，其中包含用于管道设计的 Data Factory 设计器。

管道的代码可以存储在版本控制仓库中，这样可以跟踪代码更改，并促进开发人员之间的协作。如果在这些步骤中错过了仓库设置，可以稍后进行设置。

下一部分将重点介绍与版本控制仓库设置相关的配置，如果你的数据工厂资源在没有配置任何仓库设置的情况下创建，我们将在这里进行相关配置。

仓库设置

在创建任何数据工厂工件（如数据集和管道）之前，最好先设置代码仓库，以托管与数据工厂相关的文件：

在创作页面，点击管理按钮，然后在左侧菜单中选择Git 配置。这将打开另一个面板；在此面板中点击设置代码仓库按钮：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_09_07.jpg

图 9.7：设置 Git 仓库
从结果面板中，选择你希望存储数据工厂代码文件的仓库类型。在本例中，我们选择Azure DevOps Git：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_09_08.jpg

图 9.8：选择合适的 Git 仓库类型
创建一个新的仓库，或从 Azure DevOps 重用现有仓库。你应该已经在 Azure DevOps 中有一个账户。如果没有，可以访问dev.azure，使用与你在 Azure 门户中相同的账户登录，并在其中创建一个新的组织和项目。有关在 Azure DevOps 中创建组织和项目的更多信息，请参考第十三章，集成 Azure DevOps。

现在，我们可以回到数据工厂创作窗口，开始为我们的新管道创建工件。

在下一部分中，我们将准备将在数据工厂管道中使用的数据集。

数据工厂数据集

现在我们可以返回到数据工厂管道。首先，创建一个新的数据集，作为源数据集。它将是我们创建的第一个存储账户，我们将在其中上传示例product.csv文件：

点击AutoResolveIntegrationRuntime用于运行时环境，这意味着 Azure 将在 Azure 托管的计算上提供运行时环境。链接服务提供多种身份验证方法，我们正在使用**共享访问签名（SAS）统一资源定位符（URI）**方法。也可以使用账户密钥、服务主体和托管身份作为身份验证方法：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_09_09.jpg

图 9.9：实现身份验证方法
然后，在结果的下方窗格中的常规选项卡中，点击打开属性链接并为数据集提供一个名称：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_09_10.jpg

图 9.10：为数据集命名
在连接选项卡中，提供有关容器、存储帐户中的 Blob 文件名、行分隔符、列分隔符和其他有助于 Data Factory 正确读取源数据的信息。

配置后的连接选项卡应类似于图 9.11。请注意，路径包括容器的名称和文件的名称：

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

图 9.11：配置连接
此时，如果点击product.csv文件。在ProductID和ProductPrice列上，架构有助于为列提供标识符，并在源数据集和目标数据集之间映射源列到目标列，即使列名不一致。

现在第一个数据集已创建，让我们创建第二个数据集。

创建第二个数据集

以之前相同的方式为目标 Blob 存储帐户创建一个新的数据集和关联服务。请注意，存储帐户与源相同，但容器不同。确保传入的数据也附带有架构信息，如图 9.12所示：

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

图 9.12：创建第二个数据集

接下来，我们将创建第三个数据集。

创建第三个数据集

为 Data Lake Gen2 存储实例创建一个新的数据集，作为目标数据集。为此，选择新数据集，然后选择Azure Data Lake Storage Gen2（预览版）。

给新数据集命名，并在连接选项卡中创建一个新的关联服务。选择使用帐户密钥作为身份验证方法，选择存储帐户名称后，其余配置将自动填充。然后，通过点击测试连接按钮来测试连接。保持其他选项卡的默认配置，如图 9.13所示：

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

图 9.13：连接选项卡中的配置

现在，我们已经连接到源数据，并且连接到源和目标数据存储的连接都已建立，是时候创建包含数据转换逻辑的管道了。

创建管道

创建所有数据集后，我们可以创建一个管道来消费这些数据集。创建管道的步骤如下：

从左侧菜单点击**+ 管道 => 新建管道菜单以创建新管道。然后，将复制数据活动从移动与转换**菜单拖放，如图 9.14所示：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_09_14.jpg

图 9.14：管道菜单
结果的常规标签可以保持不变，但源标签应配置为使用我们之前配置的源数据集：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_09_15.jpg

图 9.15：源标签
接收标签用于配置目标数据存储和数据集，应配置为使用我们之前配置的目标数据集：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_09_16.jpg

图 9.16：接收标签
在映射标签中，将源数据集的列映射到目标数据集的列，如图 9.17所示：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_09_17.jpg

图 9.17：映射标签

添加另一个复制数据活动

在我们的管道中，我们可以添加多个活动，每个活动负责特定的转换任务。本节讨论的任务负责将数据从 Azure 存储帐户复制到 Azure Data Lake Storage：

添加另一个product.csv文件。

接收配置将目标指向 Data Lake Gen2 存储帐户。
对于第二个复制数据活动，其余配置可以保留为默认设置。

在完成管道的编写后，可以将其发布到版本控制库，如 GitHub。

接下来，我们将探讨如何使用 Databricks 和 Spark 创建解决方案。

使用 Databricks 创建解决方案

Databricks 是一个将 Spark 作为服务使用的平台。我们无需在虚拟机上配置主节点和工作节点。相反，Databricks 为我们提供了一个由主节点和工作节点组成的托管环境，并且对其进行管理。我们只需提供数据处理的步骤和逻辑，其余的都由 Databricks 平台负责。

在本节中，我们将通过步骤介绍如何使用 Databricks 创建解决方案。我们将下载示例数据进行分析。

示例 CSV 文件已从ourworldindata/coronavirus-source-data下载，尽管它也可以在本书的代码中找到。前述网址会提供更为最新的数据，但格式可能发生变化，因此建议使用本书代码示例中提供的文件：

创建 Databricks 解决方案的第一步是通过 Azure 门户进行预配。从 Azure 门户中可以选择 14 天评估版 SKU，以及标准和高级版两个其他 SKU。高级版 SKU 在笔记本、集群、作业和表格级别提供 Azure 基于角色的访问控制：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_09_19.jpg

图 9.19：Azure 门户—Databricks 服务
在 Databricks 工作区预配完成后，从概述面板点击 启动工作区 按钮。这将打开一个新的浏览器窗口，并最终将你登录到 Databricks 门户。
从 Databricks 门户中，从左侧菜单选择集群，并创建一个新集群，如 图 9.20 所示：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_09_20.jpg

图 9.20：创建一个新集群
提供名称、Databricks 运行时版本、工作节点类型、虚拟机大小配置以及驱动程序类型服务器配置。
创建集群可能需要几分钟时间。集群创建完成后，点击主页，从其上下文菜单中选择一个用户，并创建一个新的笔记本：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_09_21.jpg

图 9.21：选择一个新笔记本
为笔记本提供一个名称，如下所示：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_09_22.jpg

图 9.22：创建笔记本
创建一个新的存储账户，如下所示。这将作为存储原始 COVID 数据的 CSV 格式存储：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_09_23.jpg

图 9.23：创建一个新的存储账户
为存储 CSV 文件创建一个容器，如下所示：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_09_24.jpg

图 9.24：创建一个容器
将 owid-covid-data.csv 文件上传到此容器中。

完成上述步骤后，下一步是加载数据。

加载数据

第二个主要步骤是将 COVID 数据加载到 Databricks 工作区。这可以通过两种主要方式完成：

在 Databricks 中挂载 Azure 存储容器，然后加载挂载中的文件。
从存储账户直接加载数据。以下示例使用了这种方法。

以下步骤应执行以使用 Databricks 加载和分析数据：

第一步是连接并访问存储帐户。需要存储帐户的密钥，该密钥存储在 Spark 配置中。注意，这里的密钥是"fs.azure.account.key.coronadatastorage.blob.core.windows"，其值是关联的密钥：
```
spark.conf.set("fs.azure.account.key.coronadatastorage.blob.core.windows","xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx==")
```
Azure 存储帐户的密钥可以通过导航到设置并使用wasbs://{{container}}@{{storage account name}}.blob.core.windows/{{filename}}来获取。
SparkSession对象的read方法提供了读取文件的方法。要读取 CSV 文件，应该使用csv方法，并传递其所需的参数，例如 CSV 文件的路径。还可以提供额外的可选参数来定制数据文件的读取过程。Spark 支持多种文件格式，如 JSON、优化行列格式（ORC）和 Parquet，以及关系型数据库如 SQL Server 和 MySQL、NoSQL 数据存储如 Cassandra 和 MongoDB，以及大数据平台如 Apache Hive。让我们通过以下命令了解 Spark DataFrame 的实现：
```
coviddata = spark.read.format("csv").option("inferSchema", "true").option("header", "true").load("wasbs://coviddata@coronadatastorage.blob.core.windows/owid-covid-data.csv")
```
使用此命令会在 Spark 中创建一个新的 DataFrame 类型对象。Spark 提供弹性分布式数据集（RDD）对象来操作和处理数据。RDD 是低级对象，任何针对它们编写的代码可能不会经过优化。DataFrame 是 RDD 之上的高级构造，提供了优化访问和处理 RDD 的功能。与 RDD 一起工作时，最好使用 DataFrame。

DataFrame 以行列格式提供数据，这使得可视化和处理数据变得更容易。Spark 的 DataFrame 类似于 pandas 的 DataFrame，区别在于它们是不同的实现。
以下命令显示了 DataFrame 中的数据，展示了 DataFrame 中所有可用的行和列：
```
coviddata.show()
```
你应该得到类似于图 9.25中所看到的输出：

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

图 9.25：DataFrame 中的原始数据
加载数据的模式由 Spark 推断，可以使用以下命令检查：
```
coviddata.printSchema()
```
这应该会给你类似于以下的输出：

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

图 9.26：获取 DataFrame 每列的模式
要计算 CSV 文件中的行数，可以使用以下命令，输出显示文件中有 19,288 行：
```
coviddata.count()
```
https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_09_27.jpg

图 9.27：查找 DataFrame 中的记录数量
原始的 DataFrame 有超过 30 列。我们也可以选择其中的一部分列并直接使用，如下所示：
```
CovidDataSmallSet = coviddata.select("location","date", "new_cases", "new_deaths")
CovidDataSmallSet.show()
```
代码的输出将如下所示，正如图 9.28所示：

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

图 9.28：从所有列中选择几个列

也可以使用 filter 方法过滤数据，如下所示：

CovidDataSmallSet.filter(" location == 'United States' ").show()

还可以使用 AND（&）或 OR（|）运算符将多个条件组合在一起：

CovidDataSmallSet.filter((CovidDataSmallSet.location == 'United States') | (CovidDataSmallSet.location == 'Aruba')).show()

要找出行数及其他统计细节，如均值、最大值、最小值和标准差，可以使用 describe 方法：
```
CovidDataSmallSet.describe().show()
```
使用前面的命令后，你将获得类似这样的输出：

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

图 9.29：使用 describe 方法显示每个列的统计信息
还可以找出指定列中空值或缺失数据的百分比。以下是几个示例：
```
from pyspark.sql.functions import  col
(coviddata.where(col("diabetes_prevalence").isNull()).count() * 100)/coviddata.count()
```
输出显示 5.998548320199087，这意味着 95% 的数据是空值。我们应该从数据分析中删除这些列。同样，在 total_tests_per_thousand 列上运行相同命令返回 73.62090418913314，这比前一个列的结果要好得多。

要从 DataFrame 中删除某些列，可以使用以下命令：

coviddatanew=coviddata.drop("iso_code").drop("total_tests").drop("total_tests").drop("new_tests").drop("total_tests_per_thousand").drop("new_tests_per_thousand").drop("new_tests_smoothed").drop("new_tests_smoothed_per_thousand ")

有时，您需要对数据进行聚合。在这种情况下，可以执行数据分组，如下所示：
```
coviddatanew = coviddata.groupBy('location').agg({'date': 'max'})
```
这将显示来自 groupBy 语句的数据：

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

图 9.30：来自 groupby 语句的数据
如你在 max (date) 列中看到的，所有国家的日期大多相同，我们可以使用这个值来过滤记录，并获取每个国家的最大日期对应的一行数据：
```
coviddatauniquecountry = coviddata.filter("date='2020-05-23 00:00:00'")
coviddatauniquecountry.show()
```
如果我们对新 DataFrame 中的记录进行计数，结果是 209。

我们可以将新的 DataFrame 保存到另一个 CSV 文件中，其他数据处理器可能需要该文件：
```
coviddatauniquecountry.rdd.saveAsTextFile("dbfs:/mnt/coronadatastorage/uniquecountry.csv")
```
我们可以使用以下命令检查新创建的文件：
```
%fs ls /mnt/coronadatastorage/
```
挂载路径将显示如下图所示的 图 9.31：

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

图 9.31：Spark 节点中的挂载路径
还可以使用 createTempView 或 createOrReplaceTempView 方法将数据添加到 Databricks 目录中。将数据放入目录后，可以在给定的上下文中使用它。要将数据添加到目录中，可以使用 DataFrame 的 createTempView 或 createOrReplaceTempView 方法，为目录中的表提供一个新视图：
```
coviddatauniquecountry.createOrReplaceTempView("corona")
```
一旦表格进入目录，就可以从你的 SQL 会话中访问，如下所示：
```
spark.sql("select * from corona").show()
```
SQL 语句中的数据将显示为 图 9.32 所示：

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

图 9.32：来自 SQL 语句的数据

可以对表执行额外的 SQL 查询，如下所示：

spark.sql("select * from corona where location in ('India','Angola') order by location").show()

这只是 Databricks 可能性的一小部分。它内部还有许多更多的功能和服务，无法在单一章节中全面覆盖。您可以在 azure.microsoft/services/databricks 上了解更多相关信息。

总结

本章介绍了 Azure Data Factory 服务，它负责提供 Azure 中的 ETL 服务。作为一个平台即服务，它提供无限的可扩展性、高可用性和易于配置的管道。它与 Azure DevOps 和 GitHub 的集成也非常流畅。我们还探索了使用 Azure Data Lake Gen2 存储大数据的功能和优势。它是一种成本效益高、具有高度可扩展性、分层的数据存储方式，用于处理大数据，并且与 Azure HDInsight、Databricks 和 Hadoop 生态系统兼容。

我们并没有对本章中提到的所有主题进行全面深入的探讨。重点更多的是探索 Azure 中的可能性，特别是 Databricks 和 Spark。Azure 中涉及大数据的多个技术，包括 HDInsight、Hadoop、Spark 及其相关生态系统，还有 Databricks，它是一个为 Spark 提供附加功能的“平台即服务”环境。在下一章中，您将学习 Azure 中的无服务器计算能力。

第十章：10. Azure 中的无服务器——与 Azure Functions 一起工作

在上一章中，你了解了 Azure 上的各种大数据解决方案。在本章中，你将学习无服务器技术如何帮助你处理大量数据。

无服务器（Serverless）是当前技术领域最热门的流行词之一，大家都想赶上这股潮流。无服务器在整体计算、软件开发流程、基础设施和技术实现方面带来了许多优势。这个行业中有许多变化：一端是基础设施即服务（IaaS），另一端则是无服务器。在两者之间的是**平台即服务（PaaS）**和容器。我遇到了许多开发人员，似乎他们对 IaaS、PaaS、容器和无服务器计算之间存在一些困惑。此外，人们对于无服务器范式的使用场景、适用性、架构和实现也有很多混淆。无服务器是一个新的范式，正在改变不仅是技术，甚至是组织内部的文化和流程。

本章将通过介绍无服务器开始，并将在接下来的内容中涵盖以下主题：

函数即服务
Azure Functions
Azure Durable Functions
Azure Event Grid

无服务器

无服务器是指一种部署模型，用户只需要负责他们的应用程序代码和配置。在无服务器计算中，客户不需要为自己的底层平台和基础设施操心，而是可以专注于解决业务问题。

无服务器并不意味着没有服务器。代码和配置始终需要计算、存储和网络来运行。然而，从客户的角度来看，他们看不到这些计算、存储和网络。他们不关心底层的平台和基础设施，不需要管理或监控基础设施和平台。无服务器提供了一个可以自动按需扩展、收缩、进出环境，而客户甚至对此一无所知的环境。与平台和基础设施相关的所有操作都发生在幕后，并由云服务提供商执行。客户会获得与性能相关的服务级别协议（SLA），Azure 会确保在任何需求下都能满足这些 SLA。

客户只需要带入他们的代码；云服务提供商负责提供运行代码所需的基础设施和平台。让我们深入探讨 Azure Functions 的各种优势。

Azure Functions 的优势

无服务器计算是一种相对较新的范式，帮助组织将大型功能转化为较小的、离散的按需功能，这些功能可以通过自动触发器和计划任务被调用和执行。这些功能也被称为 功能即服务 (FaaS)，在这种模式下，组织可以专注于领域挑战，而非底层基础设施和平台。FaaS 还有助于将解决方案架构分解为更小、可重用的功能，从而提高投资回报率。

目前有大量的无服务器计算平台可供选择。以下是一些重要的平台：

Azure Functions。
AWS Lambda。
IBM OpenWhisk。
Iron.io。
Google Cloud Functions。

事实上，每隔几天就会有新的平台/框架被推出，企业越来越难以决定哪个框架最适合他们。Azure 提供了一个丰富的无服务器环境，称为 Azure Functions，以下是它支持的一些功能：

有多种方式调用函数——手动调用、按计划调用或基于事件触发。
支持多种绑定类型。
可以同步和异步运行函数。
基于多种触发器类型执行函数的能力。
可以运行长时间和短时间的函数。然而，不推荐运行大型和长时间的函数，因为它们可能导致意外超时。
能够使用代理功能来支持不同的函数架构。
多种使用模型，包括消费模型和应用服务模型。
能够使用多种编程语言（如 JavaScript、Python 和 C#）编写函数。
基于 OAuth 的授权。
Durable Functions 扩展帮助编写有状态的函数。
多种身份验证选项，包括 Azure AD、Facebook、Twitter 和其他身份提供商。
可以轻松配置输入和输出参数。
通过 Visual Studio 集成来编写 Azure 函数。
大规模并行处理。

让我们来看看 FaaS 及其在无服务器架构中扮演的角色。

FaaS。

Azure 提供 FaaS。这些是 Azure 的无服务器实现。使用 Azure Functions，用户可以用任何熟悉的语言编写代码，Azure Functions 会提供一个运行时来执行它。根据选择的语言，平台为用户提供适当的环境来运行自己的代码。函数是部署的基本单元，可以自动扩展和缩减。在处理函数时，用户无法查看底层的虚拟机和平台，但 Azure Functions 提供了一个小窗口，通过 Kudu Console 查看它们。

Azure Functions 有两个主要组件：

Azure Functions 运行时。
Azure Functions 的绑定和触发器。

让我们详细了解这些组件。

Azure Functions 运行时。

Azure Functions 的核心是其运行时。Azure Functions 的前身是 Azure WebJobs。Azure WebJobs 的代码也是 Azure Functions 的核心。Azure WebJobs 增加了额外的功能和扩展，以创建 Azure Functions。Azure Functions 运行时是使函数能够工作的魔法。Azure Functions 托管在 Azure App Service 中。Azure App Service 加载 Azure 运行时，并等待外部事件或手动活动的发生。请求到达或触发器发生时，App Service 加载传入的负载，读取函数的 function.json 文件以查找函数的绑定和触发器，将传入数据映射到传入参数，并使用参数值调用函数。一旦函数完成执行，值通过 function.json 文件中定义为绑定的输出参数再次传回 Azure Functions 运行时。函数运行时将值返回给调用者。Azure Functions 运行时充当粘合剂，支持整个函数的执行。

当前的 Azure 运行时版本是 ~3。它基于 .NET Core 3.1 框架。在此之前，版本 ~2 基于 .NET Core 2.2 框架。第一个版本 ~1 基于 .NET 4.7 框架。

从版本 1 到版本 2 由于底层框架本身的变化，发生了重大变化。然而，从版本 2 到版本 3 几乎没有破坏性变化，大多数在版本 2 中编写的函数仍然能够在版本 3 上运行。然而，建议在从版本 2 升级到版本 3 后进行充分的测试。关于触发器和绑定，从版本 1 到版本 2 也存在破坏性变化。触发器和绑定现在作为扩展提供，在版本 2 和 3 中，每个扩展都位于不同的程序集。

Azure Functions 绑定和触发器

如果 Azure Functions 运行时是 Azure Functions 的大脑，那么 Azure Functions 绑定和触发器就是它的心脏。Azure Functions 通过触发器和绑定促进服务之间的松耦合和高内聚。针对非无服务器环境编写的应用程序使用命令式语法实现传入和传出的参数以及返回值的代码。Azure Functions 使用声明式机制通过触发器调用函数，并使用绑定配置数据流。

绑定是指创建传入数据与 Azure 函数之间连接的过程，并映射数据类型。该连接可以是从运行时到 Azure Functions 的单向连接，也可以是双向的——绑定可以在 Azure 运行时和 Azure Functions 之间双向传输数据。Azure Functions 以声明的方式定义绑定。

触发器是一种特殊类型的绑定，函数可以通过它根据外部事件被调用。除了调用函数，触发器还会将传入的数据、有效负载和元数据传递给函数。

绑定在 function.json 文件中定义，如下所示：

{  "bindings": [    {      "name": "checkOut",      "type": "queueTrigger",      "direction": "in",      "queueName": "checkout-items",      "connection": "AzureWebJobsDashboard"    },    {      "name": "Orders",      "type": "table",      "direction": "out",      "tableName": "OrderDetails",      "connection": "<<Connection to table storage account>>"   }  ],  "disabled": false }

在此示例中，声明了一个触发器，当存储队列中有新项时，会调用该函数。类型为 queueTrigger，方向为输入，queueName 为 checkout-items，并且显示了目标存储帐户连接和表名称的详细信息。所有这些值对于此绑定的功能至关重要。checkOut 名称可以在函数代码中作为变量使用。

类似地，声明了返回值的绑定。这里，返回值命名为 Orders，数据是来自 Azure Functions 的输出。该绑定将返回数据写入 Azure 表存储，使用提供的连接字符串。

绑定和触发器都可以通过更新 function.json 文件进行修改和编写。checkOut 触发器声明如下：

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

图 10.1：集成选项卡的触发器部分

Orders 输出如下所示：

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

图 10.2：为存储帐户添加输出详细信息

Azure 函数的作者无需编写任何管道代码来获取来自多个源的数据。他们只需决定预期的 Azure 运行时数据类型。下一段代码示例中显示了这一点。请注意，结账功能作为字符串提供给函数。可以使用多种数据类型作为函数的绑定。例如，队列绑定可以提供以下内容：

一个普通的 CLR（公共语言运行时）对象 (POCO)
一个字符串
一个字节
CloudQueueMessage

函数的作者可以使用这些数据类型中的任何一种，Azure Functions 运行时会确保将正确的对象作为参数传递给函数。以下是一个接受字符串数据的代码片段，运行时会在调用函数之前将传入的数据封装为 string 数据类型。如果运行时无法将传入的数据转换为字符串，则会生成异常：

using System;public static void Run(string checkOut, TraceWriter log){    log.Info($"C# Queue trigger function processed: { checkOut }");}

同样需要了解的是，在图 10.2中，存储帐户名称为 AzureWebJobsStorage 和 AzureWebJobsDashboard。这两个是定义在 appSettings 部分的密钥，包含存储帐户连接字符串。Azure Functions 内部使用这些存储帐户来维护其状态和函数执行的状态。

有关 Azure 绑定和触发器的更多信息，请参阅 docs.microsoft/azure/azure-functions/functions-bindings-storage-queue。

现在我们已经对 Azure 绑定和触发器有了一个基本的理解，让我们来看看 Azure Functions 提供的各种配置选项。

Azure Functions 配置

Azure Functions 提供了多级配置选项。它为以下内容提供配置：

平台本身
函数应用服务

这些设置会影响它们所包含的每个函数。关于这些设置的更多信息，请访问 docs.microsoft/azure/azure-functions/functions-how-to-use-azure-function-app-settings。

平台配置

Azure 函数托管在 Azure App Service 中，因此它们可以享受所有的 App Service 特性。可以使用平台功能轻松配置诊断和监控日志。此外，App Service 提供了分配 SSL 证书、使用自定义域名、身份验证和授权等网络功能的选项。

尽管客户无需关心函数实际执行的基础设施、操作系统、文件系统或平台，但 Azure Functions 提供了必要的工具，可以深入了解底层系统并进行更改。门户内控制台和 Kudu 控制台是用于此目的的工具。它们提供了丰富的编辑器，用于编写 Azure 函数并编辑其配置。

与 App Service 一样，Azure Functions 允许你将配置信息存储在 web.config 应用程序设置部分，可以按需读取。一些函数应用的 платформ功能如 图 10.3 所示：

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

图 10.3：函数应用的 플랫폼功能

这些平台功能可以用来配置身份验证、自定义域名、SSL 等等。此外，平台功能选项卡提供了可以与函数应用一起使用的开发工具概览。在接下来的章节中，我们将查看在平台功能中可用的函数应用设置。

App Service 函数设置

这些设置会影响所有函数。应用程序设置可以在此处管理。Azure Functions 中的代理可以启用和禁用。我们将在本章后面讨论代理。它们还帮助更改函数应用的编辑模式和部署到槽：

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

图 10.4：函数应用设置

预算是任何项目成功的一个非常重要的方面。让我们来探索 Azure Functions 提供的各种计划。

Azure Functions 费用计划

Azure Functions 基于 Azure App Service，为用户提供了一种经济实惠的模型。它有三种费用模型。

消费计划

这是基于按秒计费的函数消费和执行费用。该计划根据函数的实际消费和执行的计算使用情况来计算费用。如果一个函数没有执行，则不会产生费用。然而，这并不意味着该计划会影响性能。Azure 函数会根据需求自动扩展和缩减，以确保基本的最小性能水平得以保持。一个函数的执行允许 10 分钟完成。

该计划的一个主要缺点是，如果函数几秒钟内没有被消费，函数可能会变冷，接下来的请求可能会因函数处于空闲状态而出现短暂的响应延迟。这种现象称为冷启动。然而，有一些解决方法可以保持函数在没有合法请求时也保持“热”状态。可以通过编写一个计划任务函数，不断调用目标函数，保持其活跃。

高级计划

这是一个相对较新的计划，与应用服务计划和消费计划相比，提供了许多好处。在该计划中，Azure 函数没有冷启动。函数可以与私有网络关联，客户可以选择自己的虚拟机大小来执行函数。它提供了许多之前在其他两种计划中无法实现的现成功能。

应用服务计划

该计划为函数提供了完全专用的虚拟机后端，因此其费用与虚拟机的成本及其大小直接相关。即使函数没有被调用，也会有固定的费用与此计划相关联。函数代码可以运行所需的时间。尽管没有时间限制，但默认限制设置为 30 分钟。可以通过更改 hosts.json 文件中的值来更改此限制。在应用服务计划中，如果函数长时间未使用，函数运行时会进入空闲状态，只能通过 HTTP 触发器激活。可以使用 Always On 设置来防止函数运行时进入空闲状态。扩展可以是手动的，也可以基于自动扩展设置。

除了灵活的定价选项外，Azure 还提供了多种架构部署的托管选项。

Azure Functions 目标主机

Azure Functions 运行时可以托管在 Windows 和 Linux 主机上。基于 PowerShell Core、Node.js、Java、Python 和 .NET Core 的函数可以在 Windows 和 Linux 操作系统上运行。了解函数所需的底层操作系统类型非常重要，因为此配置设置与函数应用程序及其包含的所有函数相关联。

此外，函数还可以在 Docker 容器中运行。这是因为 Azure 提供了预先构建的函数运行时的 Docker 镜像，可以使用这些镜像来托管函数。现在，Docker 镜像可以用于在 Kubernetes Pod 中创建容器，并托管在 Azure Kubernetes 服务、Azure 容器实例或非托管的 Kubernetes 集群中。这些镜像可以存储在 Docker Hub、Azure 容器注册表或任何其他全球和私有镜像库中。

为了更清楚地理解，我们来看看 Azure Functions 中一些最突出使用案例。

Azure Functions 使用案例

Azure Functions 有多种实现方式。让我们来看一下这些使用案例。

实现微服务

Azure Functions 帮助将大型应用程序拆分为更小的独立功能代码单元。每个单元都独立于其他单元发展，拥有自己的生命周期。每个代码单元都有其自己的计算、硬件和监控要求。每个函数可以与所有其他函数连接。这些单元由协调器交织在一起，以构建完整的功能。例如，在一个电子商务应用程序中，可以有多个独立的函数（代码单元），每个函数负责列出目录、推荐、分类、子分类、购物车、结账、支付类型、支付网关、收货地址、账单地址、税费、运费、取消、退货、电子邮件、短信等。其中一些函数被组合在一起，创建用于电子商务应用程序的使用案例，如产品浏览和结账流程。

多个端点之间的集成

Azure Functions 可以通过集成多个函数来构建整体应用程序功能。这种集成可以基于事件触发，也可以是推送方式。这有助于将大型的单体应用程序拆分为小型组件。

数据处理

Azure Functions 可用于批量处理传入数据。它可以帮助处理多种格式的数据，如 XML、CSV、JSON 和 TXT。它还可以运行转换、增强、清理和过滤算法。事实上，可以使用多个函数，每个函数执行转换或增强、清理或过滤操作。Azure Functions 还可以用于结合先进的认知服务，如 光学字符识别（OCR）、计算机视觉、图像处理和转换。如果您想处理 API 响应并进行转换，这是理想的选择。

集成遗留应用程序

Azure Functions 可以帮助将遗留应用程序与更新的协议和现代应用程序集成。遗留应用程序可能未使用行业标准协议和格式。Azure Functions 可以充当这些遗留应用程序的代理，接受用户或其他应用程序的请求，将数据转换为遗留应用程序可以理解的格式，并使用其理解的协议与其进行通信。这为集成和将旧有遗留应用程序引入主流应用组合提供了巨大的机会。

定时作业

Azure Functions 可用于执行持续或定期的某些应用程序功能。这些应用程序功能可以执行诸如定期备份、恢复、批处理作业、导入导出数据和批量发送电子邮件等任务。

通信网关

Azure Functions 可以在使用通知中心、短信、电子邮件等时用作通信网关。例如，你可以使用 Azure Functions 通过 Azure 通知中心向 Android 和 iOS 设备发送推送通知。

Azure 函数有不同的类型，需要根据它们与工作负载优化的关系进行选择。让我们仔细了解它们。

Azure 函数的类型

Azure 函数可以分为三种不同的类型：

按需函数：这些函数在被显式调用或触发时执行。例如，HTTP 基础的函数和 Webhook 就是这类函数。
定时函数：这些函数像定时任务一样，按固定时间间隔执行。
基于事件的函数：这些函数基于外部事件执行。例如，向 Azure Blob 存储上传新文件会生成一个事件，从而启动 Azure 函数的执行。

在接下来的部分中，你将学习如何创建一个事件驱动的函数，该函数将连接到一个 Azure 存储帐户。

创建事件驱动的函数

在此示例中，将创建一个 Azure 函数并将其连接到 Azure 存储帐户。该存储帐户有一个容器来存放所有 Blob 文件。存储帐户的名称是 incomingfiles，容器的名称是 orders，如 图 10.5 所示：

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

图 10.5：存储帐户详情

执行以下步骤从 Azure 门户创建一个新的 Azure 函数：

点击左侧 Functions 菜单旁边的 + 按钮。
从结果页面选择 In-Portal 并点击继续按钮。
选择 Azure Blob 存储触发器，如 图 10.6 所示：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_10_06.jpg

图 10.6：选择 Azure Blob 存储触发器

目前，这个 Azure 函数与存储帐户没有连接。Azure 函数需要存储帐户的连接信息，而这些信息可以从存储帐户的访问密钥标签中获取。同样的信息也可以通过 Azure Functions 编辑器环境获取。事实上，该环境允许从同一个编辑器环境中创建一个新的存储帐户。

可以通过点击存储帐户连接输入框旁的新建按钮来添加 Azure Blob 存储触发器。它允许选择现有的存储帐户或创建一个新的存储帐户。由于我已经有几个存储帐户，所以我在重复使用它们，但你应该创建一个单独的 Azure 存储帐户。选择一个存储帐户后，将更新appSettings部分的设置，并将连接字符串添加到其中。

确保目标 Azure 存储帐户的 Blob 服务中已存在一个容器。路径输入指的是容器的路径。在这种情况下，orders 容器已经存在于存储帐户中。这里显示的创建按钮将为新的函数提供服务，监控存储帐户容器：

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

图 10.7：创建一个监控存储帐户容器的函数

storagerelatedfunctions 函数的代码如下：

public static void Run(Stream myBlob, TraceWriter log){    log.Info($"C# Blob trigger function Processed blob\n  \n Size {myBlob.Length} Bytes");}

绑定如下所示：

{  "bindings": [    {      "name": "myBlob",      "type": "blobTrigger",      "direction": "in",      "path": "orders",      "connection": "azureforarchitead2b_STORAGE"    }  ],  "disabled": false }

现在，将任何 blob 文件上传到 orders 容器应该会触发该函数：

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

图 10.8：C# Blob 触发函数处理的 blob

在接下来的部分，我们将深入探讨 Azure Function Proxies，它将帮助你高效处理 API 的请求和响应。

函数代理

Azure Function Proxies 是 Azure Functions 的一个相对较新的功能。函数代理有助于隐藏 Azure 函数的细节，并向客户公开完全不同的端点。函数代理可以接收端点的请求，通过改变值来修改请求的内容、主体、头部和 URL，增加额外数据，并将其传递给 Azure 函数。一旦它们从这些函数获得响应，它们可以再次转换、覆盖和增强响应，并将其发送回客户端。

它还帮助通过使用不同的头部信息调用不同的函数进行 CRUD（创建、读取、删除和更新）操作，从而将大型函数拆分成更小的函数。它通过不暴露原始函数端点提供了一定的安全性，并且在不影响调用者的情况下，帮助更改内部函数实现和端点。函数代理通过为客户端提供单一的函数 URL，然后在后台调用多个 Azure 函数来完成工作流。有关 Azure Function Proxies 的更多信息，请访问 docs.microsoft/azure/azure-functions/functions-proxies。

在下一节中，我们将详细介绍 Durable Functions。

Durable Functions

Durable Functions 是 Azure Functions 中最新的功能之一。它允许架构师在 Orchestrator 函数中编写有状态的工作流，这是一个新的函数类型。作为开发者，你可以选择编写代码或使用任何形式的 IDE。使用 Durable Functions 的一些优势包括：

函数输出可以保存到本地变量中，你可以同步和异步调用其他函数。
状态会为你保留。

以下是调用 Durable Functions 的基本机制：

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

图 10.9：调用 Durable Functions 的机制

Azure Durable Functions 可以通过 Azure Functions 提供的任何触发器进行调用。这些触发器包括 HTTP、Blob 存储、表存储、服务总线队列等。它们可以由具有访问权限的用户手动触发，也可以由应用程序触发。图 10.9 展示了几个触发器作为示例。这些也被称为启动型 Durable Functions。启动型 Durable Functions 调用 durable orchestrator trigger，该触发器包含编排的主要逻辑，并负责编排活动函数的调用。

在持久编排器中编写的代码必须是确定性的。这意味着，无论代码执行多少次，返回的值应该保持不变。编排器函数本质上是一个长时间运行的函数。这意味着它可以被注水、状态序列化，并在调用持久活动函数后进入休眠状态。因为它不知道持久活动函数何时完成，所以它不想等待。当持久活动函数执行完成时，编排器函数将再次执行。函数执行从顶部开始，并一直执行，直到它调用另一个持久活动函数或完成函数执行。它必须重新执行之前已经执行过的代码行，并且应该得到之前的相同结果。请注意，在持久编排器中编写的代码必须是确定性的。这意味着，无论代码执行多少次，返回的值应该保持不变。

让我通过一个例子来解释这一点。如果我们使用通用的.NET Core 日期时间类并返回当前的日期时间，每次执行函数时，它都会返回一个新的值。持久函数上下文对象提供了CurrentUtcDateTime，它将在重新执行时返回与第一次执行时相同的日期时间值。

这些编排函数也可以等待外部事件，并支持与人工交接相关的场景。这个概念将在本节稍后解释。

这些活动函数可以在有或没有重试机制的情况下被调用。持久函数可以帮助解决许多挑战，并提供以下功能来编写可以执行以下操作的函数：

执行长时间运行的函数
维护状态
并行或按顺序执行子函数
容易从故障中恢复
在工作流中编排函数的执行

现在你对持久函数的内部工作机制有了基本了解，接下来让我们探索如何在 Visual Studio 中创建持久函数。

使用 Visual Studio 创建持久函数的步骤

以下是创建持久函数的步骤：

导航到 Azure 门户并点击左侧菜单中的资源组。
点击顶部菜单中的**+添加**按钮来创建一个新的资源组。
在生成的表单中提供资源组信息并点击创建按钮，如下所示：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_10_10.jpg

图 10.10：创建资源组
导航到新创建的资源组，并通过点击生成的搜索框中的功能应用来添加一个新的功能应用。
选择功能应用并点击创建按钮。填写生成的功能应用表单并点击创建按钮。你也可以重新使用我们之前创建的功能应用。
一旦函数应用创建完成，我们将进入本地开发环境，安装了 Visual Studio 2019 的环境中。我们将开始使用 Visual Studio 创建一个新的 Azure functions 类型项目，提供名称，并为 Function runtime 选择 Azure Functions v3（.NET core）。
创建项目后，我们需要将 DurableTask NuGet 包添加到项目中，以便与 Durable Functions 一起使用。编写本章时使用的版本是 2.2.2：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_10_11.jpg

图 10.11：添加 DurableTask NuGet 包
现在，我们可以在 Visual Studio 中编写持久化函数。添加一个新函数，给它命名，并选择 Durable Functions Orchestration 触发器类型：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_10_12.jpg

图 10.12：选择 Durable Functions Orchestration 触发器
Visual Studio 会为 Durable Functions 生成样板代码，我们将利用这些代码来学习 Durable Functions。Durable Functions 活动是由主 Orchestrator 函数调用的函数。通常会有一个主 Orchestrator 函数和多个 Durable Functions 活动。一旦扩展安装完成，提供一个函数名称并编写一些有用的代码，比如发送电子邮件或短信，连接外部系统并执行逻辑，或者使用其端点执行服务，如认知服务。

Visual Studio 会在一行代码中生成三组函数：
- BlobTrigger，ServiceBus 队列或基于触发器的函数。
- RunOrchestrator：这是主要的持久化协调函数。它负责从启动函数接收参数，并依次调用多个持久化任务函数。每个持久化任务函数负责一个特定功能，这些持久化任务可以根据需要并行或顺序调用。
- SayHello：这是从持久化函数协调器调用的持久化任务函数，用于执行特定任务。
启动函数（HttpStart）的代码如下所示。此函数的触发器类型为 HTTP，并接受一个类型为 DurableClient 的附加绑定。此 DurableClient 对象有助于调用 Orchestrator 函数：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_10_13.jpg

图 10.13：启动函数的代码
Orchestrator 函数（RunOrchestrator）的代码如下所示。此函数的触发器类型为 OrchestrationTrigger，并接受类型为 IDurableOrchestrationContext 的参数。此上下文对象有助于调用持久化任务：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_10_14.jpg

图 10.14：Orchestrator 触发器函数的代码
持久化任务函数的代码（HelloFunction）如下所示。该函数的触发器类型为ActivityTrigger，并接受一个参数，该参数可以是执行其功能所需的任何类型。它的返回值类型为string，并且该函数负责返回一个字符串值给协调函数：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_10_15.jpg

图 10.15：持久化任务函数的代码

接下来，我们可以在本地执行该函数，这将启动一个存储仿真器（如果尚未启动），并为 HTTP 触发器函数提供一个 URL：

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

图 10.16：启动存储仿真器

我们将使用一个工具Postman来调用此 URL（该工具可以从www.getpostman/下载）。我们只需要复制该 URL 并在 Postman 中执行。这个操作如图 10.17所示：

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

图 10.17：使用 Postman 调用 URL

注意，当你启动协调器时，会生成五个 URL：

statusQueryGetUri URL 用于查找协调器的当前状态。在 Postman 中点击该 URL 会打开一个新标签页，如果执行此请求，它将显示工作流的状态：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_10_18.jpg

图 10.18：协调器的当前状态

terminatePostUri URL 用于停止已经在运行的协调器函数。
sendEventPostUri URL 用于向挂起的持久化函数发布事件。当持久化函数在等待外部事件时，它们可以被挂起。在这种情况下，将使用此 URL。
purgeHistoryDeleteUri URL 用于从持久化函数的表存储帐户中删除某个调用的历史记录。

现在你已经知道如何使用 Visual Studio 操作持久化函数，让我们讨论 Azure 函数的另一个方面：将它们链接在一起。

创建具有函数的连接架构

具有函数的连接架构指的是创建多个函数，其中一个函数的输出触发另一个函数，并为下一个函数提供数据以执行其逻辑。在本节中，我们将继续之前的存储帐户场景。在此情况下，使用 Azure 存储 Blob 文件触发的函数输出将把文件的大小写入 Azure Cosmos DB。

接下来展示的是 Cosmos DB 的配置。默认情况下，Cosmos DB 中没有创建任何集合。

在创建一个函数时，Cosmos DB 接收到任何数据时将自动创建一个集合，该函数将被触发：

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

图 10.19：创建 Azure Cosmos DB 账户

让我们按照以下步骤，从一个函数的输出中获取数据，供下一个函数使用。

在 Cosmos DB 中创建一个新的数据库 testdb，并在其中创建一个名为 testcollection 的新集合。在配置 Azure 函数时，您需要同时提供数据库和集合名称：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_10_20.jpg

图 10.20：添加容器
创建一个新的函数，该函数将具有 Blob 存储触发器和 Cosmos DB 输出绑定。该函数返回的值将是上传文件的数据大小。该返回值将写入 Cosmos DB。输出绑定将写入 Cosmos DB 集合。导航到集成标签页，点击新建输出按钮，位于输出标签下方，并选择Azure Cosmos DB：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_10_21.jpg

图 10.21：将输出绑定到 Azure Cosmos DB
提供适当的数据库和集合名称（如果集合不存在，请勾选复选框以创建集合），点击新建按钮选择您新创建的 Azure Cosmos DB，并将参数名称保持为outputDocument：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_10_22.jpg

图 10.22：新创建的 Azure Cosmos DB
按照图 10.23中的方式修改函数：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_10_23.jpg

图 10.23：修改函数
现在，将新文件上传到 Azure 存储账户中的 orders 集合，将会触发一个写入 Azure Cosmos DB 集合的函数。另一个函数可以使用新创建的 Azure Cosmos DB 账户作为触发绑定。它将提供文件的大小，函数可以对其进行处理。如下所示：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_10_24.jpg

图 10.24：编写触发器绑定函数

本节介绍了如何使用一个函数的输出数据来为下一个函数获取数据。在下一节中，您将学习如何通过了解 Azure Event Grid 来启用无服务器事件处理。

Azure 事件网格

Azure Event Grid 是一个相对较新的服务，也被称为无服务器事件平台。它帮助基于事件（也称为事件驱动设计）创建应用程序。了解事件是什么以及在 Event Grid 出现之前我们如何处理事件是非常重要的。事件是指发生的事情——即改变某个主题状态的活动。当一个主题的状态发生变化时，通常会触发一个事件。

事件通常遵循发布/订阅模式（也称为pub/sub 模式），在该模式中，主题因其状态变化而触发事件，其他多个感兴趣的方（即订阅者）可以订阅该事件。事件的作用是通知订阅者这些变化，并将相关数据作为事件的一部分提供给他们。订阅者可以根据需要采取相应的行动，这些行动因订阅者而异。

在事件网格之前，并没有可以称作实时事件平台的服务。曾经有多个独立服务，每个服务都提供了各自的事件处理机制。

例如，Log Analytics，也称为操作管理套件（OMS），提供了一个捕获环境日志和遥测数据的基础设施，基于这些数据可以生成警报。这些警报可以用于执行 Runbook、Webhook 或函数。这接近实时，但并不完全是实时的。而且，捕获单个日志并对其进行处理非常繁琐。同样，Application Insights 也提供了类似于 Log Analytics 的功能，但它是为应用程序提供的。

还有其他日志，例如活动日志和诊断日志，但它们同样依赖于与其他日志相关功能类似的原理。解决方案部署在多个资源组中，跨多个区域，从任何这些区域引发的事件应该能被部署在其他地方的资源访问。

事件网格去除了所有障碍，因此，几乎所有资源都可以生成事件（这些资源正变得越来越可用），甚至可以生成自定义事件。这些事件可以被任何资源、任何区域、任何资源组内的订阅者所订阅。

事件网格已经作为 Azure 基础设施的一部分铺设好了，包括数据中心和网络。一个区域内触发的事件可以轻松地被其他区域的资源订阅，并且由于这些网络是互联的，因此事件传递给订阅者的效率极高。

事件网格

事件网格让你可以创建基于事件的架构应用程序。既有事件的发布者，也有事件的消费者；然而，针对同一事件，可能会有多个订阅者。

事件的发布者可以是一个 Azure 资源，例如 Blob 存储、物联网（IoT）中心等。这些发布者也称为事件源。它们使用现成的 Azure 主题将事件发送到事件网格，无需配置资源或主题。Azure 资源触发的事件已经通过内部使用主题的方式将事件发送到事件网格。一旦事件到达网格，订阅者就可以消费它。

订阅者或消费者是对事件感兴趣并希望基于这些事件执行操作的资源。这些订阅者在订阅主题时提供事件处理程序。事件处理程序可以是 Azure 函数、自定义 Webhook、逻辑应用程序或其他资源。执行事件处理程序的事件源和订阅者如图 10.25所示：

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

图 10.25：事件网格架构

当事件到达主题时，可以同时执行多个事件处理程序，每个处理程序执行自己的操作。

还可以引发自定义事件并将自定义主题发送到事件网格。事件网格提供了创建自定义主题的功能，这些主题会自动附加到事件网格。这些主题知道事件网格的存储位置，并会自动将消息发送到该位置。自定义主题有两个重要属性，如下所示：

端点：这是主题的端点。发布者和事件源通过此端点将事件发送并发布到事件网格。换句话说，主题是通过其端点来识别的。
密钥：自定义主题提供了一些密钥。这些密钥为端点的使用提供安全保障。只有拥有这些密钥的发布者才能将消息发送并发布到事件网格。

每个事件都有一个事件类型，并通过它来识别。例如，Blob 存储提供了事件类型，如 blobAdded 和 blobDeleted。自定义主题可以用来发送自定义定义的事件，如 KeyVaultSecretExpired 类型的自定义事件。

另一方面，订阅者有能力接受所有消息，或者仅根据筛选器获取事件。这些筛选器可以基于事件类型或事件有效负载中的其他属性。

每个事件至少具有以下五个属性：

id：这是事件的唯一标识符。
eventType：这是事件类型。
eventTime：这是事件引发的日期和时间。
subject：这是事件的简短描述。
data：这是一个字典对象，包含特定资源的数据或任何自定义数据（用于自定义主题）。

目前，事件网格的功能并非所有资源都支持；然而，Azure 正在不断增加更多支持事件网格功能的资源。

要了解更多关于能够引发与事件网格相关事件的资源以及能够处理这些事件的处理程序，请访问docs.microsoft/azure/event-grid/overview。

资源事件

本节提供了以下步骤，以创建一个解决方案，其中由 Blob 存储引发的事件发布到事件网格，并最终路由到 Azure 函数：

使用适当的凭据登录到 Azure 门户，并在现有或新的资源组中创建一个新的存储账户。存储账户应该是 StorageV2 或 Blob 存储。如 图 10.26 所示，事件网格不支持 StorageV1：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_10_26.jpg

图 10.26：创建新的存储账户
创建一个新的函数应用程序，或者重用现有的函数应用程序来创建 Azure 函数。Azure 函数将托管在该函数应用程序中。
使用 Azure Event Grid 触发器 模板创建一个新函数。如果尚未安装 Microsoft.Azure.WebJobs.Extensions.EventGrid 扩展，请安装该扩展，如 图 10.27 所示：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_10_27.jpg

图 10.27：为 Azure Event Grid 触发器安装扩展
为 StorageEventHandler 函数命名并创建它。以下是将作为事件处理程序使用的默认生成代码：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_10_28.jpg

图 10.28：事件处理程序代码

存储事件的订阅可以通过 Azure Functions 用户界面 (UI) 配置，方法是点击 添加事件网格订阅，或者通过存储账户本身进行配置。
在 Azure Functions UI 中点击 添加事件网格订阅 链接，为前一步创建的存储账户添加事件订阅。为订阅提供一个有意义的名称，然后选择 事件模式，接着选择 事件网格模式。将 主题类型 设置为 存储账户，选择适当的订阅，并选择包含存储账户的资源组：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_10_29.jpg

图 10.29：创建事件网格订阅

确保选中 订阅所有事件类型 复选框，然后点击创建按钮（选中存储账户后该按钮应自动启用）。
如果我们现在导航到 Azure 门户中的存储账户，并点击左侧菜单中的事件链接，则应能看到该存储账户的订阅：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_10_30.jpg

图 10.30：事件订阅列表
在创建容器后，将文件上传到 Blob 存储，Azure 函数应该会被执行。上传操作将触发一个 blobAdded 类型的新事件，并将其发送到存储账户的事件网格主题。如 图 10.31 所示，订阅已经设置为接收来自该主题的所有事件，函数将作为事件处理程序的一部分执行：https://github/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-arch-3e/img/B15432_10_31.jpg

图 10.31：触发新事件

在本节中，你学习了如何将 Blob 存储引发的事件路由到 Azure 函数。在下一节中，你将学习如何利用自定义事件。

自定义事件

在这个示例中，我们将使用自定义事件，而不是使用现成的资源来生成事件。我们将使用 PowerShell 创建这个解决方案，并重用在上一个练习中创建的相同 Azure 函数作为处理器：

使用 Login-AzAccount 和 Set-AzContext cmdlet 登录并连接到你选择的 Azure 订阅。
下一步是在 Azure 的一个资源组中创建一个新的事件网格主题。使用 New-AzEventGridTopic cmdlet 创建新的主题：
```
New-AzEventGridTopic -ResourceGroupName CustomEventGridDemo -Name "KeyVaultAssetsExpiry" -Location "West Europe"
```
一旦主题创建完成，需要获取其端点 URL 和密钥，因为它们是发送并发布事件到该主题所必需的。Get-AzEventGridTopic 和 Get-AzEventGridTopicKey cmdlet 被用来获取这些值。请注意，获取的是 Key1，用于连接到端点：
```
$topicEndpoint = (Get-AzEventGridTopic -ResourceGroupName containers -Name KeyVaultAssetsExpiry).Endpoint $keys = (Get-AzEventGridTopicKey -ResourceGroupName containers -Name KeyVaultAssetsExpiry).Key1
```
创建一个新的哈希表，包含所有五个重要的事件网格事件属性。为 ID 生成一个新的 id 属性，将 subject 属性设置为 Key vault Asset Expiry，将 eventType 设置为 Certificate Expiry，将 eventTime 设置为当前时间，并将 data 填充证书相关信息：
```
$eventgridDataMessage = @{id = [System.guid]::NewGuid()subject = "Key Vault Asset Expiry"eventType = "Certificate Expiry"eventTime = [System.DateTime]::UtcNow data = @{CertificateThumbprint = "sdfervdserwetsgfhgdg"ExpiryDate = "1/1/2019"Createdon = "1/1/2018"}}
```
由于事件网格数据应以 JSON 数组的形式发布，因此有效负载会被转换为 JSON 数组。"[" 和 "]" 方括号代表 JSON 数组：
```
$finalBody = "[" + $(ConvertTo-Json $eventgridDataMessage) + "]"
```
事件将通过 HTTP 协议发布，必须向请求中添加适当的头信息。请求使用应用程序/JSON 内容类型发送，属于主题的密钥被分配给 aeg-sas-key 头部。必须命名头部并将密钥设置为 aeg-sas-key：
```
$header = @{"contentType" = "application/json""aeg-sas-key" = $keys}
```
创建一个新的订阅，订阅自定义主题，包含名称、包含主题的资源组、主题名称、WebHook 端点和实际作为事件处理器的端点。在此情况下，事件处理器是 Azure 函数：
```
New-AzEventGridSubscription -TopicName KeyVaultAssetsExpiry -EventSubscriptionName "customtopicsubscriptionautocar" -ResourceGroupName CustomEventGridDemo -EndpointType webhook '-Endpoint "https://durablefunctiondemoapp.azurewebsites/runtime/webhooks/EventGrid?functionName=StorageEventHandler&code=0aSw6sxvtFmafXHvt7iOw/Dsb8o1M9RKKagzVchTUkwe9EIkzl4mCg=='-Verbose
```
Azure 函数的 URL 可以从集成选项卡获取，如图 10.31所示：

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

图 10.32：集成选项卡中的事件网格订阅 URL
到目前为止，订阅者（事件处理器）和发布者都已配置完成。下一步是向自定义主题发送并发布事件。事件数据已经在上一步创建，使用Invoke-WebRequest cmdlet，带着请求体和头部将请求发送到端点：
```
Invoke-WebRequest -Uri $topicEndpoint -Body $finalBody -Headers $header -Method Post
```

API 调用将触发事件，事件网格会向我们配置的端点发送消息，该端点是功能应用。通过这项操作，我们将结束本章内容。

摘要

从传统方法到函数的演变，催生了松耦合、独立演化、自给自足的无服务器架构，这在早期只是一个概念。函数是部署单元，提供一个完全无需用户管理的环境。用户只需要关注为功能编写的代码。Azure 提供了一个成熟的平台，用于托管函数并根据事件或按需无缝集成它们。Azure 中几乎所有资源都可以参与由 Azure 函数组成的架构。未来是函数，因为越来越多的组织希望摆脱管理基础设施和平台的任务，想将这些工作交给云服务提供商。对于每个处理 Azure 的架构师来说，掌握 Azure Functions 是一项基本技能。

本章详细介绍了 Azure Functions、函数即服务（Functions as a Service）、持久化函数（Durable Functions）和事件网格（Event Grid）。下一章将重点讲解 Azure Logic Apps，并且我们将构建一个完整的端到端解决方案，结合多个无服务器服务以及其他 Azure 服务，如 Azure Key Vault 和 Azure Automation。

发布者：admin，转转请注明出处：http://www.yc00.com/web/1754957925a5221509.html

第三版指南架构师 Azure

admin

网站建设
微信小程序认证指南及注意事项
如何认证小程序？ 一、操作步骤登录小程序后台： https:mp.weixin.qq (点击前往)找到设置，基本设置；在【基本信息】处
admin
1月前
240
网站建设
【全是细节】大模型SFT的100个关键点：深入解析与实践指南
这篇文章介绍一下大模型的 sft 如何去做。相比较于上一篇文章介绍的 pretrain ，sft 实在没有太多的技术细节和琐碎工作需要科普。因此，我会默认读者们都知道 sft 是做什么的以及如何去
admin
1月前
160
网站建设
红米AC2100刷OpenWrt终极指南：从Breed刷入到SSH配置一步不漏
红米AC2100烧制Openwrt系统 1. 准备工作 1.1 线路连接需要使用网线连接路由器的wan口(最左边的口)和宽带(也可以是寝室，家里的路由器的lan口)，如下图所示&#
admin
1月前
180
网站建设
Azure安全组配置
由于在开发部署过程中客户要求使用Azure平台，而Azure云的安全组配置多了一个目标IP，在配置公网访问时出现了一些错误，对比阿里云平台后才发现本人一直存在一个误区&
admin
1月前
130
网站建设
视频密码访问问题及解决方案指南
本文还有配套的精品资源，点击获取简介：在日常生活中，人们可能会遇到需要密码访问的视频文件，这通常发生在教育、培训或私人分享等场景中。例如&
admin
1月前
220
网站建设
ChatGPT实用指南2024
随着ChatGPT技术的演进，越来越多的人开始在工作中利用此工具。以下是关于ChatGPT的实用指南，适合不太熟悉此技术的朋友参考。一、ChatGPT概述 1. ChatGPT是什么&#
admin
1月前
180
网站建设
AI图书推荐：ChatGPT初学者指南
《ChatGPT初学者指南》（ChatGPT for Beginners. Features, Foundations, and Applications ）的作者是Eric Sarrion，写于2023年底。如果你是一个完全的新手，想知
admin
1月前
160
网站建设
GandCrab V5.0.6勒索病毒删除+数据恢复（卸载指南）
GandCrab V5.0.6勒索软件 - 密码病毒，它在2018年10月以三种不同的变种形式回归 GandCrab勒索病毒是一种广泛使用的加密病毒，自2018年1月以来一直针对来自世界各地的用户。自发布以来不到一年的时间内，恶意软件已经出
admin
1月前
140
网站建设
软件架构师考试重点
目录软件生命周期瀑布模型（面向文档的软件开发模型）螺旋模型构件组装模型统一过程RUP基于架构的软件设计ABSD基于架构的软件开发模型ABSDM可行性研究的内容需求分析的实现步骤软件需求需求工程类U
admin
1月前
230
网站建设
金仓数据库KingbaseES技术实践类深度剖析与实战指南
一、语法兼容及迁移实战（一）语法兼容的多元魅力在当今多元化的数据库应用环境中，金仓数据库管理系统KingbaseES凭借其卓越的语法兼容能力脱颖而出。它采用的融合数据库架
admin
1月前
180
网站建设
网络安全求职指南_看完这篇就足够了~
给大家的福利，点击下方蓝色字即可免费领取↓↓↓ 🤟 基于入门网络安全黑客打造的：👉黑客&网络安全入门&进阶学习资源包概述之
admin
1月前
180
网站建设
Linux系统分区指南：优化SSD和机械硬盘的分区方案
点击上方蓝字关注我们在Linux系统安装过程中，正确的分区方案对系统性能和数据管理至关重要。本文将详细介绍如何优化SSD和机械硬盘的分区，以满足不同硬盘类型的需求。随着技术的进步&#xff
admin
1月前
210
网站建设
【免费下载】 VMware ESXi 7.0 各个版本 ISO 镜像文件下载指南
VMware ESXi 7.0 各个版本 ISO 镜像文件下载指南【下载地址】VMwareESXi7.0各个版本ISO镜像文件下载指南 VMware ESXi 7.0 各个版本 ISO 镜像文件下载指南欢迎来到 VMware ESXi 7
admin
1月前
210
网站建设
ISO 镜像转换QCOW2 制作指南
深入理解 QCOW2 镜像与制作指南在虚拟化技术日益成熟的今天，QCOW2 镜像格式因其独特的优势在众多虚拟化平台中占据了重要地位。本文将详细介绍 QCOW2 镜像的特点、优势以及如何将 ISO 镜像转换为 QCOW
admin
1月前
190
网站建设
6、优化 Windows 8 系统安全的全面指南
优化 Windows 8 系统安全的全面指南在当今数字化时代，计算机安全至关重要。Windows 8 系统提供了一系列安全功能和设置，帮助用户保护他们的计算机和数据。本文将深入介绍 Windows 8 系统的安全优化方法，包括用户账户控
admin
1月前
260
网站建设
腾讯企业QQ服务器完全架设指南
导读： http:www.163vcArticleShowArticle.asp?ArticleID13004 每当登录到QQ服务器中去申请QQ号时，总是见到服务器正忙的提示&#x
admin
1月前
220
网站建设
QQ资料免审核秒认证大学标的完整指南
QQ资料免审核秒认证大学标的完整指南在QQ社交平台上，校园扩列认证标识（即“大学标”）不仅是一种身份象征，还能为用户带来更多的社交互动机会。然而&a
admin
1月前
270
网站建设
Edge浏览器地址栏默认搜索引擎设置指南
前言Microsoft Edge 浏览器允许用户自定义地址栏默认搜索引擎，只是设置入口隐藏比较深，以版本 137.0.3296.83 (正式版本) (64 位)为例详细记录设置地址栏默认搜索引擎
admin
1月前
280
网站建设
Windows 10 升级指南：一步步教你升级操作系统
作为一名计算机用户，你可能想要将你的操作系统升级到最新的版本，以享受更多功能和改进的性能。在本篇文章中，我将为你提供一个详细的指南，教你如何升级你的操作系统到 Windows 10。请按照以下步骤进行操作：确认系统要求：在升级之前，首先
admin
1月前
160
网站建设
Windows 11网络设置重置完全指南：从入门到精通
Windows 11网络设置重置完全指南：从入门到精通引言：为什么需要重置网络设置？在数字化办公时代，网络连接稳定性直接影响工作效率。当遇到以下典型问题时，系统网络配置可能已出现异常：浏览器显示"无Internet连接&
admin
29天前
450

发表回复

评论列表（0条）

暂无评论