Azure开发者实用指南：监控、SQL与存储等
原文：
annas-archive.org/md5/a9409a391ef3d7d0acb0e0c2da2a76f3译者：飞龙
第十五章：使用应用程序洞察监控你的应用程序
Azure 不仅仅是关于开发应用程序。一旦我们将解决方案部署到云端，我们就必须以某种方式进行监控和诊断。Azure 应用程序洞察服务提供了一个完整的工具集，用于维护应用程序，提供多种语言和平台的 SDK，警报，查询语言，并与许多本地 Azure 服务集成。它简化了应用程序的登录，并消除了在使用来自多个地方的数据分析问题时的多个数据源。
本章将涵盖以下主题：
-
使用 Azure 应用程序洞察服务
-
监控不同的平台
-
使用分析模块
-
自动化 Azure 应用程序洞察
技术要求
要执行本章的练习，你将需要：
-
一个 Azure 订阅
-
安装了以下工作负载的 Visual Studio——ASP.NET、Web 开发和 Azure 开发
使用应用程序洞察服务
在开发应用程序时（尤其是托管在云中的应用程序），最重要的功能之一就是能够轻松地进行监控，并在早期阶段检测到任何潜在问题或缺陷。为此，你需要一个完整的日志记录、存储和报告工具的架构，这些工具需要集成、配置并每天维护。这要求你的团队具备额外的技能，当然也需要时间——你的应用程序越大，所需的工作量就越多。使用 Azure 应用程序洞察，所有这些操作变得更加简单：你只需要一个服务和一个端点来记录所有需要的信息，剩下的工作自动完成。
在云中记录数据
假设你有以下架构：
它包含了许多不同的 Web 应用程序、不同的存储能力（如 SQL 数据库或 Azure 存储），还有 Azure Functions。如果我们希望能够监控所有这些服务，我们将需要以下组件：
-
一种保存日志的工具（能够使用不同的输出，如存储或文件，可能是跨平台的）
-
能够存储数 GB 日志数据的存储
-
某种仪表板，将从存储中获取数据，并使用不同的筛选器和参数显示它
考虑到所有这些因素后，你可能会发现以下一些警告：
-
存储原始数据是不够的，因为你还需要某种投影视图，能够快速提取，并且不需要额外的转换或处理。
-
你需要找到一种存储数据的方法，使得用户可以根据不同的向量随意查询——追加日志可能非常适合检查最近的记录，但对于创建动态参数的索引却不太理想。
-
你需要实施某种数据保留策略——大多数日志在固定时间段后就没有用了。
-
应用程序和报告解决方案的性能应具有可重复性，并且不应随时间变化（例如，存储的数据量增加时）。
-
为问题跟踪设置专门的团队可能并不是最合理的资源分配——具有报告和数据分析技能的人在处理实际业务数据时会更有价值。
对于前述问题，理想的解决方案是一个能够完成我们之前提到的所有任务的单一组件：
在 Azure 中，类似的组件是 Azure Application Insights，我们将在本章中介绍。
Azure Application Insights 基础知识
连接到 Azure Application Insights 服务可能会因您的情况而异。通常，您在集成该服务时有多种选择：
-
与门户的无缝集成——无需额外的步骤，您只需启用并配置一个功能，剩下的已经实现
-
根据平台使用适当的 SDK
-
将遥测事件直接发送到服务端点
根据您使用的概念，将使用不同的配置：
-
对于门户，您无需额外的步骤，因为您已通过身份验证，并且可以从下拉菜单中选择一个资源。
-
对于 SDK，您需要一个仪表密钥，可以在门户中找到——我们将在本章后续部分讨论这一话题。
-
使用 REST API，有多种选项可用，例如 App ID、密钥或 OAuth2 流程。
请注意，根据使用的日志记录方法，可能会有不同的功能和能力。这对于发送自定义事件或自定义日志逻辑尤其如此——此类操作通常需要使用专用的 SDK。
除了一些显而易见的功能（如记录和存储有关请求或异常的信息的能力），Azure Application Insights 还实现了许多不同的功能：
-
请求遥测：您可以自动收集有关请求次数、平均延迟和失败率的信息。例如，如果您将此服务与 Azure App Services 一起使用，只需实现 SDK 即可获得对您的 Web 应用程序的全面洞察。
-
依赖项：除了常规的遥测信息，Azure Application Insights 还可以提供有关您的依赖项（如 Azure Table Storage 和 Azure SQL）如何执行的信息。如果您集成了多个服务，并且想知道哪个服务对延迟的影响最大，这一点尤为重要。
-
异常：获取有关失败请求或依赖项的信息是一回事，但显示有关错误的汇总数据的详细仪表板则更有用。在 Azure Application Insights 中，您可以轻松查看哪些类型的错误与某些特定子集的请求相关联。这使您更好地理解应用程序内部发生了什么，并知道从哪里开始修复。
-
用户遥测：你想知道到底有多少用户吗？你是否对他们使用应用时的流程感兴趣？在 Azure Application Insights 中，还有其他功能可以提供关于用户和会话数量、他们的行为以及整体活动的信息。
当然，我没有列出所有可用的功能——还有更多的功能，比如收集有关 AJAX 调用、页面视图和网页性能的信息；性能计数器（用于虚拟机），以及来自 Docker 的主机诊断。实际上，功能的可用性也取决于你选择的服务——为 Azure Functions 和 Azure App Services 收集的遥测数据是不同的。
实际上，你可以通过类似的图表和诊断，使用大多数服务实现与你的日志相同粒度的分析。不同的是所需的工作量——一个服务与 Azure Application Insights 集成得越少，你需要做的事情就越多。
在门户中创建 Azure Application Insights
要创建一个 Azure Application Insights 实例，你需要在市场中搜索该服务。
你需要填写以下简单的表单以继续操作：
事实上，它包含了一个你可能还没遇到过的字段：
- 应用类型：根据你的选择（ASP.NET Web 应用、Java、App Center、Node.js 或通用），将选择不同的图表集。这个选项不会影响服务的可用功能。它只是确保，对于特定实例，你将只看到你最感兴趣的信息。
你的实例能够做的其他事情完全取决于与它集成的服务以及发送到它的数据量。
与大多数 Azure 服务不同，在 Azure Application Insights 中，并没有要求为所有实例提供一个全球唯一的服务名称——在这里，你只需要避免在一个服务内为多个实例使用相同的名称。这是因为它不使用 DNS 名称来工作并与其他应用连接。
当你点击创建时，应该不会花费太长时间来配置一个新的服务实例，它看起来应该与以下内容相似：
如你所见，有一个默认隐藏的 Essentials 部分——它包含一些常见的元数据，更重要的是，包含一个仪器密钥——以及一个标识符，它唯一地标识你的服务实例。我们将使用它来实际连接到 Azure Application Insights——本章后续会详细介绍其他功能。
监控不同平台
Azure Application Insights 的优势在于它能够同时监控不同平台。你可以选择从 ASP.NET 页面、Java、Node.JS，甚至是 Python 或 Ruby（不过，有些语言和框架是 Application Insights 团队官方支持的，有些则是社区支持的）。关键是，它是与平台无关的。实际上，当你需要实现通信通道时，只需提供一个仪表密钥，就可以轻松将数据发送到服务实例，而无需额外的密钥和复杂的配置。在本节中，我们将专注于从不同平台发送信息，因此你将能够轻松开始在自己的项目中进行集成。
.NET
在 .NET 应用程序中，开始的唯一操作是安装最新的Microsoft.ApplicationInsights包。最简单的方法是使用以下代码片段：
TelemetryConfiguration.Active.InstrumentationKey = "<instrumentation-key>";
var telemetryClient = new TelemetryClient();
这段代码做了两件事：
-
通过提供仪表密钥来设置当前配置。连接到服务所需的全部内容。
-
初始化一个
TelemetryClient实例——这个类是一个代理，用于与服务进行通信。
然后，你可以使用不同的方法来记录一些数据：
telemetryClient.TrackTrace("Hello World!");
telemetryClient.TrackException(new Exception());
telemetryClient.TrackDependency(new DependencyTelemetry());
当然，还有更多可用的方法——你可以在进一步阅读部分找到它们。在第一个代码片段中，我们使用了TelemetryConfiguration类型——实际上，它提供的配置中存储的数据最初是从ApplicationInsights.config文件中获取的——它看起来可能是这样的：
<?xml version="1.0" encoding="utf-8"?>
<ApplicationInsights >
<InstrumentationKey>8sad7asd-asd876asf-jr323jsd-3hshjahj</InstrumentationKey>
<TelemetryInitializers>
<Add Type="Microsoft.ApplicationInsights.DependencyCollector.HttpDependenciesParsingTelemetryInitializer, Microsoft.AI.DependencyCollector"/>
</TelemetryInitializers>
<TelemetryModules>
<Add Type="Microsoft.ApplicationInsights.DependencyCollector.DependencyTrackingTelemetryModule, Microsoft.AI.DependencyCollector">
<ExcludeComponentCorrelationHttpHeadersOnDomains>
</ExcludeComponentCorrelationHttpHeadersOnDomains>
<IncludeDiagnosticSourceActivities>
<Add>Microsoft.Azure.ServiceBus</Add>
<Add>Microsoft.Azure.EventHubs</Add>
</IncludeDiagnosticSourceActivities>
</Add>
</TelemetryModules>
<TelemetryChannel Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel, Microsoft.AI.ServerTelemetryChannel"/>
</ApplicationInsights>
如果文件不存在（或者它没有包含所有值），配置将不正确；在这种情况下，你需要手动提供它。
请注意，上述指令仅适用于使用 .NET 框架的情况。
这里值得提一下的是，设置在不同平台之间有所不同。我们讨论了最基本的（控制台应用）设置，但我们还可以使用其他应用类型，比如 Windows 桌面应用：
public partial class Form1 : Form
{
private TelemetryClient _telemetryClient = new TelemetryClient();
private void Form1_Load(object sender, EventArgs e)
{
_telemetryClient.InstrumentationKey = "<instrumenation-key>";
_telemetryClient.Context.User.Id = Environment.UserName;
_telemetryClient.Context.Session.Id = Guid.NewGuid().ToString();
_telemetryClient.Context.Device.OperatingSystem = Environment.OSVersion.ToString();
_telemetryClient.TrackPageView("Form1");
}
}
或者我们可以使用与 Azure Application Insights 无缝集成的 Web 应用。
Node.js
要在 Node.js 中开始使用 Azure Application Insights，你需要以下命令：
npm install applicationinsights
它将安装一个 NPM 包——Application Insights，这个包允许你与该服务进行交互。以下是这个包接口的完整示例：
let http = require("http");
let appInsights = require("applicationinsights");
appInsights.setup("<instrumentation-key>");
appInsights.start();
let client = appInsights.defaultClient;
client.trackEvent({name: "my custom event", properties: {customProperty: "custom property value"}});
client.trackException({exception: new Error("handled exceptions can be logged with this method")});
client.trackMetric({name: "custom metric", value: 3});
client.trackTrace({message: "trace message"});
client.trackDependency({target:"http://dbname", name:"select customers proc", data:"SELECT * FROM Customers", duration:231, resultCode:0, success: true, dependencyTypeName: "ZSQL"});
client.trackRequest({name:"GET /customers", url:"http://myserver/customers", duration:309, resultCode:200, success:true});
http.createServer( (req, res) => {
client.trackNodeHttpRequest({request: req, response: res});
}).listen(1337, "127.0.0.1");
console.log('Server running at http://127.0.0.1:1337/');
尝试运行示例并查看洞察结果——你会看到最初的请求已经被记录：
Azure Functions
Azure Application Insights 还提供与另一个 Azure 服务——Azure Functions 的无缝集成。启用集成有两种方式：在创建服务时开启，或者通过在设置中手动提供仪表密钥。
以下是可以启用此功能的表单：
然而，这种设置有一个警告：如果你已经有一个服务实例，则无法选择另一个实例。要做到这一点，你需要通过在功能应用的设置中提供APPINSIGHTS_INSTRUMENTATIONKEY来手动启用集成。
还有一个选项。你可以点击任何功能的“监视”标签，然后点击“配置”，而不是手动提供密钥。如果经典视图尚未启用，这个选项将会可用。
启用集成后，你将能够分析所有查询的执行情况：
分析模块
将 Azure Application Insights 与不同服务（以及自定义应用程序）集成的多种方式并不是此服务的唯一大特点。另一个重要且至关重要的部分是分析模块中提供的分析语言。这是一种交互式查询语言，使你能够使用简单直观的语法轻松探索日志数据。它的另一个优点是，你不需要任何额外的工具就可以开始使用——一旦存储了跟踪、异常或请求数据，它就可以开箱即用——你需要做的唯一事情就是编写查询。在本节中，我们将介绍查询语言和模块，这样你就可以开始编写自己的查询，并发现存储日志中可用的许多不同维度。
访问分析模块
使用分析模块非常简单。转到你的 Azure 应用程序分析实例的概览页面，然后点击分析按钮：
它会显示一个新窗口，显示新的选项，例如输入查询、使用预定义的查询，或者仅仅探索可用的不同维度：
这里最重要的是查询窗口。它是一个交互式功能，使你能够编写查询，并提供额外的功能，如语法验证器和建议。我们先从一个简单的查询开始，显示过去几天的请求计数：
requests
| summarize totalCount=sum(itemCount) by bin(timestamp, 30m)
| render timechart
如你所见，它分为三个部分：
-
requests：你查询的维度 -
summarize：定义你想从该维度获取的数据的函数 -
render：一个可选函数，根据数据绘制图表
当然，查询可以有不同的结构；你可以找到一个稍微复杂一点的查询：
requests
| summarize RequestsCount=sum(itemCount), AverageDuration=avg(duration), percentiles(duration, 50, 95, 99) by operation_Name
| order by RequestsCount desc
从前面的示例来看，将不会显示图表——相反，它会显示一个表格：
重要的是查询的日期范围，因为在这个范围内你可以过滤数据。你必须选择你感兴趣的日期。为此，点击“时间范围”按钮，该按钮位于“运行”按钮旁边，然后选择正确的选项：
Azure 应用分析中的查询语言非常丰富，它定义了许多不同的数据类型和操作的函数（例如，您可以使用许多不同的窗口函数，像是next()）。相关的参考资料可以在进一步阅读部分找到。
此外，当执行查询时，您可以为其选择一个额外的过滤器（基于结果），从而选择特定的记录：
另一个有用的分析模块功能是智能分析。它是一组附加功能，通过在数据分析中引入机器学习元素来扩展分析能力。目前，提供以下功能：
-
自动聚类：此功能自动将数据分成若干集群，以便更易于理解。
-
篮子：此功能会自动在查询结果中寻找有趣的数据。
-
差异模式：此功能操作于存储真/假数据的列上，并尝试找到对应于它们之间差异的模式。
-
定时系列：此功能（
make-series）将数据转换为单行，便于分析问题的根本原因。 -
线性回归：使用此功能，您可以轻松地根据结果（例如，异常数量是否增长）找到数据趋势。
-
异常值检测：此功能可以发现数据中某个值与其他值的异常差异。
使用这些高级功能，您可以大大提高数据分析的效果。它们结合了许多有用的功能，使整个服务更加灵活。而且，您不必是数据科学家就可以进行数据分析，发现趋势和异常。
应用洞察自动化
监控并不是您每天都愿意花时间做的事。事实上，服务的自动化程度越高，您可以获得的结果就越好。让机器查看不同的维度并根据预设规则找出问题，总是比自己来做更快捷、更细致。在 Azure 应用洞察中，您有许多自动化选项：ARM 模板、门户中的警报，或者集成外部服务（例如 Microsoft Flow）。在本章的最后部分，您将学习如何开始使用自动化，并确保将精力集中在开发上，而不是日志分析和服务维护。
警报
警报是一项功能，可以在发生异常时通知您。在设置警报时有很多不同的选项，首先从 ARM 模板开始：
{
"name": "[variables('myFirstAlertName')]",
"type": "Microsoft.Insights/alertrules",
"apiVersion": "2014-04-01",
"location": "[parameters('appLocation')]",
"dependsOn": [
"[resourceId('Microsoft.Insights/components', parameters('myApplicationName'))]"
],
"tags": {
"[concat('hidden-link:', resourceId('Microsoft.Insights/components', parameters('myApplicationName')))]": "Resource"
},
"properties": {
"name": "[variables('responseAlertName')]",
"description": "response time alert",
"isEnabled": true,
"condition": {
"$type": "Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.ThresholdRuleCondition, Microsoft.WindowsAzure.Management.Mon.Client",
"odata.type": "Microsoft.Azure.Management.Insights.Models.ThresholdRuleCondition",
"dataSource": {
"$type": "Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.RuleMetricDataSource, Microsoft.WindowsAzure.Management.Mon.Client",
"odata.type": "Microsoft.Azure.Management.Insights.Models.RuleMetricDataSource",
"resourceUri": "[resourceId('microsoft.insights/components', parameters('myApplicationName'))]",
"metricName": "request.duration"
},
"threshold": "[parameters('responseTime')]",
"windowSize": "PT15M"
},
"actions": [{
"$type": "Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.RuleEmailAction, Microsoft.WindowsAzure.Management.Mon.Client",
"odata.type": "Microsoft.Azure.Management.Insights.Models.RuleEmailAction",
"sendToServiceOwners": true,
"customEmails": []
}]
}
}
虽然最初这样的 ARM 模板可能有些令人生畏，但实际上它包含了一组固定的参数，可以通过资源浏览器轻松找到（您可以在进一步阅读部分找到相关链接）。在这里，您可以了解如何发现现有的警报规则：
在上面的截图中，我展示了在一个特定资源组内创建的 Azure Application Insights 实例中可用的警报规则。当你点击它时，你将看到 Azure 中该资源的完整描述。
资源浏览器是一个非常好的工具，尤其是在使用 ARM 模板并寻找某个特定资源的引用时。它显示了从 ARM 视角描述服务的所有参数。
在这里，你可以找到服务部署时创建的默认警报：
{
"id": "/subscriptions/.../resourceGroups/handsonazure-rg/providers/microsoft.insights/alertrules/Failure Anomalies - handsonazure-ai",
"name": "Failure Anomalies - handsonazure-ai",
"type": "Microsoft.Insights/alertRules",
"location": "West Europe",
"properties": {
"name": "Failure Anomalies - handsonazure-ai",
"description": "",
"isEnabled": true,
"condition": {
"$type": "Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.ThresholdRuleCondition, Microsoft.WindowsAzure.Management.Mon.Client",
"odata.type": "Microsoft.Azure.Management.Insights.Models.ThresholdRuleCondition",
"dataSource": {
"$type": "Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.RuleMetricDataSource, Microsoft.WindowsAzure.Management.Mon.Client",
"odata.type": "Microsoft.Azure.Management.Insights.Models.RuleMetricDataSource",
"resourceUri": "/subscriptions/.../resourcegroups/handsonazure-rg/providers/microsoft.insights/components/handsonazure-ai",
"resourceLocation": null,
"metricNamespace": null,
"metricName": "...",
"legacyResourceId": null
},
"operator": "GreaterThan",
"threshold": 2,
"windowSize": "PT1H",
"timeAggregation": null
},
"action": null,
"lastUpdatedTime": "2018-09-14T12:04:57.6355645Z",
"provisioningState": "Succeeded",
"actions": [
{
"$type": "Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.RuleEmailAction, Microsoft.WindowsAzure.Management.Mon.Client",
"odata.type": "Microsoft.Azure.Management.Insights.Models.RuleEmailAction",
"sendToServiceOwners": true,
"customEmails": []
}
]
}
}
为了让事情更容易理解，我们来看一下如何在门户中设置警报。你可以在“配置”部分访问“警报”面板：
要开始，你需要点击“+ 新建警报规则”按钮。你将看到一个详细的向导，提供设置警报的快捷方式。这里最重要的是条件——它们定义了警报的触发方式：
当然，警报可以有多个触发条件，因为这取决于它的特性。更重要的是，条件可以非常复杂；它们可以涉及多个资源，并引入复合警报规则的概念。接下来在这里定义的是警报的详细信息——你需要提供一些描述它们的元数据：
重要的事项是警报的严重性：它越高，警报就越重要。向导的最后一部分是实际的操作，你可以选择多个选项：
-
邮件/SMS/推送/语音
-
Azure Function
-
LogicApp
-
Webhook
-
ITSM
-
自动化运行簿
其中一些要求你已经有一个处理警报的服务——你需要选择最适合你需求的选项。当你创建一个警报时，它将会处于活动状态，并在服务中可见：
总结
在本章中，你了解了一个适用于 Azure 的监控解决方案：Azure Application Insights。我们讨论了资源的配置、创建警报以及与其他服务的集成等内容。除了本章中提到的功能外，这个 Azure 组件还提供了许多附加功能——例如智能检测、数据的持续导出和详细的使用日志。我强烈鼓励你进一步探索它，因为它极大地简化了监控活动和解决问题的过程。在下一章中，我们将介绍本书范围内的最后一个 Azure 服务：Azure SQL，它是一个 PaaS 服务，是 Azure 版本的知名数据库引擎。
问题
-
识别 Azure Application Insights 实例并连接到它需要什么？
-
是否可以在 Node.js 应用程序中使用 Azure Application Insights？
-
什么是智能分析模块？
-
如何查询存储在 Azure Application Insights 中的日志？
-
如何在服务中自动创建警报？
-
是否可以将短信作为触发警报的动作？
进一步阅读
-
TelemetryClient 参考:
docs.microsoft.com/pl-pl/dotnet/api/microsoft.applicationinsights.telemetryclient?view=azure-dotnet -
Azure 日志分析参考:
docs.loganalytics.io/index -
智能分析:
docs.loganalytics.io/docs/Learn/Tutorials/Smart-Analytics/Understanding-Autocluster -
资源浏览器:
resources.azure.com/
第十六章：Azure 中的 SQL - Azure SQL
Microsoft SQL Server 是最流行的数据库之一，通常是许多流行应用程序的核心。借助 Azure，我们可以跳过整个集群设置、安装和维护的过程，使用 Azure SQL —— 这是 SQL Server 的云版本，具有相同的功能。得益于灵活的定价，我们可以根据性能和可用功能选择任何我们想要的选项。我们也不需要担心地理复制和存储备份 —— 所有这些功能都可以在云中轻松配置和自动化。
本章将涵盖以下主题：
-
Microsoft SQL Server 和 Azure SQL 之间的差异
-
在 Azure 门户中使用 Azure SQL
-
Azure SQL 的安全特性
-
扩展和监控 Azure SQL
技术要求
要执行本章中的练习，你将需要：
- 一个 Azure 订阅
Microsoft SQL Server 和 Azure SQL 之间的差异
Microsoft SQL Server 是一个广为人知且广泛使用的 SQL 数据库服务器，已经获得了很高的流行度，并且被认为是许多项目的默认选择，这些项目从非常简单的网站到处理高负载并对业务至关重要的企业级服务都有。随着云技术的日益流行，随着这种情况的自然发展，人们期望通过将应用程序迁移到 Azure，数据库也能够随之迁移。为了满足这种需求，微软开发了 Azure SQL Service —— 一种微软 SQL Server 的 PaaS 版本，由他们的团队进行管理和升级；你需要负责的只有配置和数据管理。Azure 还提供了另一种选项，即 SQL Server VMs，这是在云中使用该数据库的另一种方式。在本节中，我们将重点讨论这两种服务的区别，并尝试识别它们的不同使用场景。
Azure SQL 基础知识
通过使用云中的 PaaS 服务，你正在稍微转移一些责任：
-
你不再是基础设施的维护者
-
当软件被考虑时，你不再需要负责不同的更新
-
通过与提供商签署 SLA，提供商负责确保服务正常运行
相反，你应该专注于以下几点：
-
正确配置服务，以满足你的性能目标和法律要求
-
集成不同的服务和应用程序，以便它们在与服务通信时能够体现最佳实践
-
实现 HA/DR 场景，以确保某一地区的故障或灾难不会影响你的系统
使用 Microsoft SQL Server 时，你完全在你自己的机器或租赁机器上，这些机器需要你自己维护和监控。虽然在许多场景下这种情况是合理的（因为可能有一些法律要求禁止你将数据存储在自己的数据中心以外，或者由于某些原因 Azure 无法提供你期望的性能），但在许多情况下，使用 PaaS 实例的 SQL 数据库是一个巨大的改进。事实上，使用此服务时，你有几个不同的选择：
-
具有隔离资源的单一数据库
-
弹性池中的池数据库
-
托管实例，这是与本地 SQL Server 最相似的模型
需要了解的重要一点是，所有新功能和更新都会部署到托管在 Azure 中的 SQL 数据库。这相比传统的 Microsoft SQL Server 给你带来了优势，因为你始终保持最新：你不需要自行安排服务器上的更新。
你拥有的服务器和数据库越多，更新它们的过程就变得越复杂和困难。比较这两种产品时，请考虑这一点。
另一个谈论 Azure SQL 时至关重要的方面是其购买模型。目前，你有两个选项：
-
基于 DTU：DTU 是计算、内存和 I/O 资源的混合，这些资源分配给你的数据库
-
基于 vCore：这个选项允许你自己选择所有内容（包括 vCore 数量、内存大小和存储性能）。
你可能会想知道 DTU 如何反映实际的硬件；有一篇很好的文章试图在本章的进一步阅读部分解释这些度量标准。
在大多数情况下，使用 DTU 作为度量标准是更好的选择——因为很难预测应用程序的确切硬件需求。当你是高级 SQL Server 用户并且知道自己究竟需要多少核心或内存时，可以使用基于 vCore 的模型。
你可能会想，Azure SQL Service 的扩展能力是什么？当然，你可以为你的数据库分配更多（或更少）资源，但有些场景下这会使事情变得更加复杂（或者你的应用程序在数据库性能方面有不同的需求，这种模型根本行不通）。为了应对这些情况，你可以选择使用弹性池。这个概念相当简单——通常，你为单个数据库分配资源：
使用弹性池时，你稍微改变了模型，池中的资源被分配，具体如下：
这有什么变化呢？这为你提供了更多的灵活性；你不再需要托管一个庞大的单一数据库（在资源分配方面），你可以轻松地进行扩展，使其与其他实例共享负载。而且，它在成本控制方面也更具优势；你可以同时扩展多个数据库，而不需要控制它们各自的需求。
扩展 Azure SQL 是一个重要的课题，需要最初的很多关注——我们将在本章末尾回到这个话题。
除了性能和不同的扩展能力外，Azure SQL 还提供了许多在考虑将其作为数据存储时非常重要的附加功能。因为没有存储在数据库中的信息，通常情况下一个应用程序是没有意义的，因此可用性也是非常重要的。幸运的是，Azure SQL 实现了许多出色的功能，使其成为一个成熟的存储选项：
-
自动备份：在本地环境中，配置和管理备份要复杂得多，因为你需要了解服务器配置并找到存储它们的地方。而在 Azure 中，事情变得非常简单，因为 Azure Storage 集成了自动备份，确保性能和可靠性。
-
地理复制：即使单个区域出现故障，你仍然可以为客户提供数据。通过 Azure SQL，你可以配置一个次级读取区域，确保在故障解决之前你能保持在线。
-
故障转移组：你不需要自己实现故障转移能力和逻辑，可以依赖 Azure SQL 当前提供的功能。这使得创建全球分布的应用程序变得更加容易，因为你只需要关注配置，而不需要担心基础设施。
要准确了解 Azure SQL 与 Microsoft SQL Server 的区别，可以参考以下链接：docs.microsoft.com/en-us/azure/sql-database/sql-database-features。
高级 Azure SQL 特性
除了一些确保 Azure SQL 是一个完整的关系型数据库并且可以依赖构建系统的基本功能外，还有许多附加功能，使得使用这个服务变得非常有趣：
-
自动监控和调优：你有没有遇到过这样的情况，在使用数据库几个月后，数据库里充满了过时的索引、存储过程和函数？Azure SQL 通过主动监控你如何使用和维护数据库，并在有改进的空间时给出建议，使这一过程变得更加简单。我发现这个功能非常有帮助——如今，开发速度特别快，且重点在于为市场提供新价值，很容易迷失方向，忽视应该从数据库中移除的内容。借助服务推荐来删除索引、改进模式和查询参数化，我发现大多数时候我的存储状态更好了。
-
自适应查询处理：虽然 SQL Server 也有这个功能，但在 Azure SQL 中使用它是对其他性能推荐的一个重要补充。基本上，当启用此功能时，服务器引擎会尝试找到查询的最佳执行计划。
-
安全性和合规性功能：确保你存储的数据是安全的，并且所有漏洞能够尽早被发现是非常重要的。在 Azure SQL 中，提供了很多额外功能，旨在从敏感性和合规性的角度分析你的数据。有内建工具会搜索任何可能影响数据完整性或导致数据泄露的异常和威胁。此外，Azure SQL 与 Azure Active Directory (AD) 集成，并支持 多因素认证 (MFA)——这使得审计和授权等操作变得更加简单，无需额外努力。
Azure SQL 的安全功能将在本章后续部分进行描述，这样你可以全面了解该服务的功能。
SQL Server 在虚拟机上
如果你不想完全使用 PaaS，你可以创建一个已经内置 SQL Server 镜像的虚拟机。在这种选项下，服务的性能将依赖于虚拟机的性能——如果你发现数据库的 CPU 或内存资源不足，唯一需要做的就是扩展虚拟机。要在门户中创建虚拟机，你需要搜索运行在你选择操作系统上的 SQL Server，如下所示：
如你所见，提供了免费的 SQL Server 许可证，而且更重要的是，更新的版本可以在 Linux 机器上运行。一旦你选择了感兴趣的镜像，你可以点击“创建”按钮开始配置虚拟机。
如下截图所示，有许多字段需要填写，才能实际使用该服务：
当然，这与 SQL 服务器在 Azure 中的 IaaS 模型相关。配置向导将为你提供关于虚拟机默认大小和其他所需参数的建议。一旦配置完成，你将能够通过 RDP 或安全的 SSH 隧道连接到它。
如果你想远程连接到 SQL 服务器，记得打开 1433 端口。
创建和配置 Azure SQL
在阅读本章开头后，你应该能够感知到 Azure SQL 如何工作以及它为你提供了什么。尽管一些理论始终是有益的，但实践才能勾画出完整的图景，并让你完全理解这个话题。在本节中，我们将专注于在门户中创建和配置 Azure SQL，并尝试识别所有前述功能。你还将看到，管理这个 PaaS 服务与本地版本的区别，特别是在使用其功能时。
创建 Azure SQL 实例
在 Azure 门户中，当你搜索 Azure SQL 时，你将看到许多不同的选项，如 SQL 数据库、SQL 服务器（逻辑服务器）或 SQL 弹性数据库池。虽然它们都允许你创建一个数据库，但开始使用该服务的最简单方法是使用 SQL 数据库 ——这仍然需要创建一个服务器。在下面的截图中，你可以看到我的服务器配置：
以下是我的数据库配置：
这里重要的是选择源——你有三个选项：
-
空白数据库：在大多数情况下，这是你最感兴趣的第一个选项
-
示例：我已经使用它，因此我的数据库中已经有数据
-
备份：如果你想从现有的备份中恢复一个数据库，这是一个很好的选项
对于空白数据库选项，你还可以选择排序规则；在下拉菜单中，选择适合你数据的选项。我们还将稍微关注一下定价配置：
如你所见，使用 DTU 模型时，你可以选择三个不同的层级：
-
基本：适用于较小的工作负载
-
标准：在成本和性能之间提供最佳平衡
-
高级：适用于需要大规模性能能力的所有工作负载
根据层级，你将获得固定的 DTU 数量（对于基本层），或者你需要选择你感兴趣的数量：
这里重要的是，大部分数据库成本都是基于资源分配的——记得选择你能选择的最大数据库大小（例如，在标准层并选择 400 DTU 时，100 MB 和 250 GB 之间的定价没有差异）。
当然，你还可以在基于 DTU 的模型和 vCores 选择之间切换：
使用 vCore 时，选择“最大数据大小”会影响定价。此外，这里你可以选择两个不同的定价层：
-
一般用途：适用于大多数常见场景，无需特别的弹性和流量需求
-
业务关键：此级别提供更好的性能和更低的延迟（且价格显著更高）
当你对配置满意后，可以点击“创建”按钮，开始资源配置过程。配置完成后，你可以通过访问“概览”面板来查看基本信息：
现在我们将尽量介绍大部分功能，以便你更好地理解如何使用此服务。
Azure SQL 功能在门户中
我们将从“配置”面板开始——当你点击它时，你将看到它允许你设置数据库的等级和定价模型。当你想提高数据库的性能时，这个选项特别有用；你可以轻松更改为其分配的 DTU 或 vCore 数量，使其可以更快速地处理查询。
正如我之前提到的，配置单一数据库适用于较简单的场景，在这些场景中，你可以轻松监控数据库，且性能需求不会快速变化。在所有其他情况下，更好的选择是使用弹性池。
当你进入“地理复制”面板时，你将看到一个类似于测试时在 Azure Cosmos DB 中看到的地图：
在此页面上，你可以快速创建一个次级区域，以便在需要时执行故障转移。为此，点击你感兴趣的区域，接着将显示“创建次级”屏幕：
你将需要再次创建一个服务器（如果该区域内还没有现有的服务器）以及定价层（当然，次级数据库的定价层可以不同）。此外，在此面板中，你可以启用数据库的故障转移组——为此，请点击以下面板：
通过实现故障转移组，你可以为你的数据库引入自动故障转移：
然而，如果你想执行强制故障转移，你可以点击次级数据库，这将显示一个允许执行该操作的屏幕：
请记住，执行故障转移可能需要一些时间才能完全传播——确保你已做好准备。
当你进入连接字符串面板时，你将看到一个适用于不同环境的连接字符串模板：
你还可以下载不同的驱动程序，如 ADO.NET、JDBC、ODBC 或 PHP。
请记住，该服务仅提供连接字符串的模板——您必须设置用户名和密码才能使其工作。
目前，我们正在探索 Azure 中的 SQL 数据库——让我们看看当前 SQL 服务器的具体情况。您可以通过点击“概览”面板上的服务器名称找到它。最初，屏幕看起来一样，但您很快会意识到它提供了许多不同的功能：
不幸的是，我们无法覆盖所有功能，但我会尽量为您描述其中的大部分。当我们查看“设置”部分时，我们可以看到以下面板：
-
故障转移组：如前所述，要引入自动故障转移，您必须创建一个故障转移组。一个组由主服务器和备用服务器组成，具有定义好的故障转移策略和宽限期——这个设置定义了从故障检测到实际故障转移之间的时间。
-
管理备份：要为您的服务器配置备份（例如，启用长期保留（LTR）），您可以访问此面板。它还显示所有可用的备份。
-
活动目录管理员：可以使用定义在活动目录用户中的用户设置服务器管理员。当然，您可以为此设置多个用户——窍门是使用组而不是单个帐户。
-
SQL 数据库：要快速访问由此特定服务器提供的数据库，请使用此面板。
-
SQL 弹性池：与 SQL 数据库类似，此面板显示可用的弹性池。要创建新的池，请转到“概览”面板并点击“+ 新建池”按钮。
-
删除的数据库：即使数据库从服务中删除，您仍然有机会恢复它。在这种情况下，请查看该面板以查看所有可恢复的数据库。
-
导入/导出历史：所有对数据库进行的导入和导出操作将在此处显示。这是一个很好的审计工具，因此您不会错过任何未经通知的数据库导出情况。
-
DTU 配额：如果您有兴趣查看服务器的 DTU/vCore 配额，可以访问此面板。
安全
关于 Azure SQL 功能，有多种不同的选项可以用来确保您的解决方案安全。诸如防火墙、完整的操作审计和数据加密等功能是此服务的常见功能，甚至在基础层也可以使用。在本节中，我们将重点学习上述功能，以确保您的实例得到保护并免受大多数威胁。
防火墙
浏览 SQL 数据库时，您可能注意到在“概览”面板上有一个“设置服务器防火墙”按钮：
这是设置允许流量进入 Azure SQL 防火墙规则的最简单方法。
在 Azure SQL 中，所有流量默认被拒绝——您必须将所有应允许与服务器通信的计算机的 IP 列入白名单。
在我们开始配置防火墙之前，您必须了解我们为什么真的需要它。如果我尝试使用 Microsoft SQL Server Management Studio 连接到我的服务器，这里会发生什么：
如您所见，它自动检测到我的 IP 地址没有被列入白名单，因此服务器拒绝与我通信。我们需要在此添加一个特定的 IP 地址，这样通信就会被允许。
实际上，默认情况下，只有托管在 Azure 内的机器被允许与 Azure SQL 通信。如果您希望从本地计算机连接到服务器，您必须设置防火墙规则。
在门户中，您可以通过点击设置服务器防火墙按钮来添加规则——这将显示一个屏幕，您可以在其中明确设置一个应能够与服务器通信的 IP 地址：
在此屏幕上，您还可以防止 Azure 服务与您的 Azure SQL 实例通信。此外，您可以在此处添加虚拟网络——借助此功能，您可以创建包含应用程序和数据库的整个生态系统，从而通过一套非常严格的规则保护它免受访问。
高级威胁保护
高级威胁保护（ATP）是 Azure SQL 的一个高级功能，默认情况下在服务中未启用。目前，它提供 60 天的免费试用期，您可以在此期间测试此功能是否适合您。您可以通过高级威胁保护面板启用它：
如您所见，它由三个独立的功能组成：
-
数据发现与分类：用于从敏感性和法律分类（例如—GDPR 要求）角度分析数据
-
漏洞评估：这使用 SQL Server 的最佳实践检查您的数据库是否存在可能的漏洞
-
威胁检测：一个主动监控数据库中可疑活动并为您记录的功能
在下文中，您可以看到 Azure SQL 如何对示例数据进行分类：
结果是，它自动检测了信息类型并声明了其敏感性标签。然后，它显示了一个摘要，向您提供存储在数据库中的数据形态的整体概览。
这个功能是分析大型数据库是否符合新规定的一个极好的工具——如果您不确定自己是否存储了敏感数据，可以使用它。
在漏洞评估方面，以下是我数据库示例扫描的结果：
扫描完成后，系统会给出安全检查结果——它检查诸如数据分类、是否启用审计或谁可以访问数据等事项。例如，如果你有许多用户并分配了广泛的权限，则会对此发出警报。在扫描过程中将检查近 50 条规则，这是对其他所有安全功能的一个重要补充。
更多的安全指南可以在进一步阅读部分的相关链接中找到。
审计
如果你想确切知道服务器内部发生了什么，你必须启用审计：
这将记录所选存储中的所有操作（当然，如果你选择了存储选项的话）。目前，有三种不同的存储审计日志选项：
-
存储
-
日志分析（预览版）
-
事件中心（预览版）
虽然存储选项有点静态，但你可以使用剩下的两个选项进行更动态的集成（尤其是在使用 Azure 事件中心时）。一旦启用审计，你就可以在点击查看审计日志按钮时看到所有已记录的操作：
动态数据掩码
有时你可能希望允许某人读取数据库中的数据，但同时又不希望他或她读取更敏感的数据（例如出生日期、地址或姓氏）。在 Azure SQL 中，有一个名为动态数据掩码（Dynamic Data Masking）的功能可以实现这一点：
有两种方法可以添加掩码——要么使用推荐方法，要么点击+ 添加掩码按钮手动添加：
你需要做的是选择模式、表格、列以及掩码字段格式——一旦配置这些并保存规则，非管理员用户将看到掩码后的值。以下显示的是管理员的值：
以下显示的是没有管理员权限的用户的值：
如你所见，LastName和Email对于非管理员用户是被掩码的，正如计划所示。
扩展 Azure SQL
数据库的性能需求可能会根据应用程序的时间和当前状态而有所不同。这时，扩展功能就显得至关重要——你可以根据服务的需求调整成本和可用资源。在 Azure SQL 中，有多个不同的场景需要考虑：你是使用单一数据库还是弹性池，是否需要扩展读取，或者是否需要在任何地方都能使用所有功能。在这一小节中，我将向你展示如何快速做出决策以及在哪里可以找到扩展工具。
单一数据库
正如我们之前提到的，单一数据库的扩展非常简单——只需进入 Configure blade 并选择您感兴趣的新层级。您可以通过观察数据库性能轻松决定是否需要扩展数据库：
如果您看到数据库的使用率不断激增，或者数据库的利用率已经接近最大值，增加一些 DTU 或其他资源总是一个好主意。
请记住，您可以在使用率达到上限时设置警报，因此有一些方法可以自动化这一过程。
弹性池
启用弹性池后，情况会有所不同——例如，您不再是单个数据库操作一个 DTU，而是可以选择一个弹性池，这引入了一个稍微不同的弹性 DTU 模型：
在这种模型中，您将使用弹性池配置来扩展数据库。对于单一数据库，您只能更改可用的最大数据大小（该大小也受到池所设置值的限制）。
读取扩展
有时您只需要扩展数据库的读取能力。这种情况发生在您更倾向于提供内容而不是修改它时（例如，您有一个非常受欢迎的门户，虽然管理单一位置，但内容却是全球提供的）。在 Azure SQL 中，您可以只扩展服务的某一部分——即负责为您管理读取操作的部分。
请注意，您需要选择 Premium/Business Critical 层级才能使此功能生效。
要启用数据库的读取扩展，您可以使用 REST API：
HTTP PUT https://management.azure.com/subscriptions/{SubscriptionId}/resourceGroups/{GroupName}/providers/Microsoft.Sql/servers/{ServerName}/databases/{DatabaseName}?api-version= 2014-04-01-preview
Body:
{
"properties":
{
"readScale":"Enabled"
}
}
或者，您可以使用 PowerShell：
Set-AzureRmSqlDatabase -ResourceGroupName <my-resource-group> -ServerName <my-server> -DatabaseName <my-database> -ReadScale Disabled
分片
扩展数据库的另一种方式是使用分片。与弹性池不同，通过使用分片，您为每个数据库分配独立的资源。它也是一种横向扩展模型（即，您会更倾向于提供另一个数据库，而不是扩展现有的数据库）。
请注意，您还可以通过使用弹性数据库拆分合并工具来为弹性池使用分片：docs.microsoft.com/en-us/azure/sql-database/sql-database-elastic-scale-overview-split-and-merge。
通常情况下，如果您：
-
数据量过大，无法通过单个实例处理
-
想要进行负载均衡请求
-
想要实现数据的地理分布
这里的关键是每个分片的数据结构必须相同。您可以在本章的 进一步阅读部分找到有关分片的完整文档。
监控与调优
本章我们讨论的最后一项内容是 Azure SQL 的监控与调优。由于数据库通常是许多应用程序的核心，因此快速诊断性能或使用方面的问题并在需要时轻松调整至关重要。Azure SQL 提供了多种不同的功能，您可以利用它们从您的实例中获取洞察。
监控
要监控您的 SQL 数据库，您可以使用警报（假设您已经阅读了上一章，第十五章，使用应用程序洞察监控您的应用程序）。您可以通过点击警报面板访问此功能：
这里有两种可用的警报类型：
-
添加指标警报（经典）
-
添加活动日志警报
它们的工作方式稍有不同——指标警报是基于 CPU 百分比、死锁或数据库总大小等值触发的，而活动日志警报则是在发生事件时触发。您可以同时使用它们来覆盖以下内容：
-
性能不足（指标）
-
无效查询（指标）
-
配置问题（指标）
-
整体服务健康状况（指标）
-
即将进行的维护活动（活动日志）
-
实际服务问题（活动日志）
-
服务健康建议（活动日志）
调优
有一个叫做智能性能的功能组，它允许您监控和调优 SQL 数据库的性能：
现在让我们查看性能建议：
虽然最初此功能为空，但在使用 Azure SQL 时，它会显示不同的建议。这里的重点是我们可以自动化操作——只需点击自动化按钮，显示另一个屏幕，您可以在其中选择感兴趣的内容：
这个屏幕实际上是之前展示的自动调优面板。您可以使用它来自动执行诸如管理索引或强制查询计划之类的操作。
总结
Azure SQL 是一个非常复杂且扩展的服务，工作方式与其本地版本 Microsoft SQL Server 类似。虽然它是一个完整的 PaaS Azure 组件，但仍然支持许多高级操作，如分片、多租户、AD 集成、故障转移和地理复制。除了托管在云中，您仍然可以像使用独立版本的 SQL Server 一样使用它。在下一章，我们将讨论本书中提到的最后一个 PaaS 服务，即 Azure Data Lake Storage。
问题
-
在更新策略方面，Azure SQL 与 Microsoft SQL Server 有何不同？
-
什么是分片？
-
您在 Azure SQL 中创建了一个新的 SQL 数据库，但服务器拒绝连接到它。可能是什么问题呢？
-
Azure SQL 的两种购买模式是什么？
-
什么是弹性池？
-
DTU 和 eDTU 之间有什么区别？
-
如何在 Azure SQL 中屏蔽特定字段？
-
可用的审计日志目标有哪些？
进一步阅读
-
如何理解 DTU：
sqlperformance.com/2017/03/azure/what-the-heck-is-a-dtu -
性能建议：
docs.microsoft.com/en-us/azure/sql-database/sql-database-advisor -
SQL 数据库安全性：
docs.microsoft.com/en-us/azure/sql-database/sql-database-security-overview -
读取扩展：
docs.microsoft.com/en-us/azure/sql-database/sql-database-read-scale-out -
分片：
docs.microsoft.com/en-us/azure/sql-database/sql-database-elastic-scale-introduction
第十七章：大数据存储 - Azure Data Lake
有时，我们需要存储无限量的数据。这种情况涵盖了大多数大数据平台，其中即便是一个软限制最大容量也可能会在应用的积极开发和维护中引发问题。得益于 Azure Data Lake，我们在存储结构化和非结构化数据方面拥有无限的可能性，所有这些都拥有高效的安全模型和出色的性能。
本章将涵盖以下主题：
-
Azure Data Lake Store 基础
-
存储数据到 Azure Data Lake Store
-
安全特性与关注点
-
使用 Azure Data Lake Store 的最佳实践
技术要求
要完成本章的练习，你将需要：
- 访问 Azure 订阅
了解 Azure Data Lake Store
在考虑存储解决方案时，你必须考虑你希望存储的数据量。根据你的需求，你可能会选择 Azure 中不同的服务选项——Azure Storage、Azure SQL 或 Azure Cosmos DB。也有各种数据库可以作为虚拟机的镜像（如 Cassandra 或 MongoDB）；这个生态系统相当丰富，所以每个人都能找到所需的东西。当你没有存储数据量的上限，或者在考虑到当今应用的特点时，数据量增长得如此迅速，以至于没有可能声明一个永远不会达到的安全上限时，就会出现问题。对于这种情况，有一种专门的存储方式，叫做 Data Lakes。它们允许你以数据的自然格式存储数据，因此不需要对存储的信息进行任何结构化。在 Azure 中，针对这种问题的解决方案叫做 Azure Data Lake Store；在本章中，你将学习该服务的基础知识，从而能够深入了解并根据自己的需求进行调整。
Azure Data Lake Store 基础
Azure Data Lake Store 被称为超大规模数据存储库并非没有原因——在存储文件时没有限制。它可以支持任何格式、任何大小，并存储以不同方式结构化的信息。这也是大数据分析的一个理想模型，因为你可以根据自己的处理服务需求来存储文件（有些人更喜欢少量的大文件，有些人则喜欢很多小文件——选择最适合你的方式）。对于关系型、NoSQL 或图形数据库等其他存储解决方案来说，这是不可行的，因为它们在保存非结构化数据时总是存在某些限制。让我们看一个关于 Azure Data Lake Store 与 Azure Storage 的比较示例：
| AZDS | Azure Storage | |
|---|---|---|
| 限制 | 无文件大小/文件数量限制 | 最大账户容量为 500 TB，文件的最大大小 |
| 冗余 | LRS | LRS/ZRS/GRS/RA-GRS |
| API | WebHDFS | Azure Blob Storage API |
这里最重要的是冗余——目前，Azure Data Lake Store 支持的唯一模型是 LRS。这意味着在发生灾难时，可能会丢失存储在单个数据中心的数据。为了避免这种情况，你必须实施自己的策略将数据复制到副本中。实际上，你有两种模型可以选择——同步复制，如下所示：
或者你可以选择异步复制，如下所示：
这两种解决方案有一些明显的优缺点：
-
同步：确保数据已保存到副本中，考虑到重复数据时更难处理，且性能较低。
-
异步：数据可能会丢失（因为在灾难发生之前，你不会将数据移到副本），但性能更好（因为你只需保存数据而不等待复制），且更容易处理。
虽然复制看起来对 Azure Storage 更有利，但请记住，Azure Data Lake Store 文件系统基于 HDFS——这使得与许多开源工具的无缝集成成为可能，例如：
-
Apache Hive
-
Apache Storm
-
Apache Spark
-
MapReduce
-
Apache Pig
-
还有更多…！
这为你提供了一个更好的生态系统和工具。如果你想将数据存储在 Azure Data Lake Store 中，并希望使用 HDInsights 来对你的文件进行分析和转换，而不是使用其他 Azure 工具，你可以轻松连接到你的实例并开始工作。
请注意，目前 ADLS 支持 HDInsight 3.2、3.4、3.5 和 3.6 版本。
在访问存储在 Azure Data Lake Store 实例中的文件时，它采用了类似 POSIX 的权限模型；你基本上会操作三种不同的权限，这些权限可以应用于文件或文件夹：
-
读取 ®：用于读取数据
-
写入 (W)：用于写入数据
-
执行 (E)：适用于文件夹，用于授予文件夹上下文中的读写权限（例如创建子文件夹或列出文件）
我们将在安全部分讨论更多的安全概念。
创建一个 Azure Data Lake Store 实例
要创建一个 Azure Data Lake Store 实例，你需要在门户中搜索 Azure Data Lake，并填写以下表格：
然而，你需要考虑以下几点：
-
位置：目前有四个不同的可用位置——美国中部、美国东部 2、北欧和西欧。请记住，在数据中心之间传输数据会额外收费，所以如果计划使用此服务，请仔细规划您的架构。
-
定价包：有两种可用的定价模型——按使用付费和固定月度承诺。它们各有优缺点（固定定价通常更便宜，但当您的应用程序增长时，它不那么灵活，有时很难提前规划所需的容量），因此请尽量了解您的应用程序使用该服务的特性，以选择最适合您的那种。
-
加密设置：默认情况下，新帐户的数据加密已启用。虽然可以禁用它，在大多数情况下您将保持默认设置。此外，有两种加密模式——要么让服务为您管理加密密钥，要么提供您自己的密钥（存储在 Azure 密钥保管库中）。
由于轮换加密密钥是个好主意，您可能会遇到问题，即使由于故障，您的数据的冗余副本也无法访问。虽然可以从备份数据中恢复，但您需要一个旧密钥来解密它。因此，建议在意外中断时存储旧密钥的副本。
当您点击“创建”按钮时，您的服务将被配置好—您可以访问它以查看概览：
由于它是新创建的，我们看不到描述我们存储了多少数据的不同指标。而且，当前成本为 0 美元——这当然是我们预期的，因为没有文件上传到服务中。从用户界面的角度来看，目前我们无法做太多事情；一些额外功能，如“防火墙”，将在本章后面描述。除了门户，您还可以通过使用 Microsoft Azure 存储资源管理器轻松访问您的 Azure 数据湖存储实例：
当您有多个文件和文件夹并尝试浏览它们时，这将使事情变得更加容易。
在 Azure 数据湖存储中存储数据
因为 Azure 数据湖存储的全部关注点是存储数据，在本章的这一部分中，您将看到如何存储不同的文件，使用权限限制对其的访问，并组织您的实例。在这里需要记住的重要事情是，您不仅限于使用大数据工具来存储或访问存储在服务中的数据——如果您设法与 Azure 数据湖存储协议通信，您可以轻松地使用 C#、JavaScript 或任何其他类型的编程语言操作文件。
使用 Azure 门户进行导航
要开始在 Azure 门户中使用文件，您需要点击“数据浏览器”按钮：
一旦您点击它，您将看到一个新屏幕，在那里您可以选择许多不同选项来创建文件夹、上传文件或更改访问属性。虽然这个工具不是管理成千上万个文件的最佳方式，但它可以让您了解存储了什么以及如何存储：
门户中提供的用户界面的缺点是，它有时会卡顿，尤其是在你拥有数百个文件时。如果你存储了数 GB 的数据，一些操作（如删除文件夹）也可能会失败。在这种情况下，最好使用 PowerShell 或自定义流程来执行操作。
现在我们将讨论用户界面上可用的选项。
筛选器
当你点击“筛选器”按钮时，你将看到一个屏幕，显示你感兴趣的文件：
这是快速限制文件夹内显示文件的最简单方法，但当然也有一些限制——例如，你不能使用通配符只筛选特定的文件扩展名。
要移除筛选器，请点击筛选器屏幕上的重置按钮。
新文件夹
这个简单的选项让你有可能创建一个新文件夹：
请注意，默认情况下，只有你可以访问新文件夹——为了让其他人可见（并允许他们读取），你必须显式地为其分配特定的用户组。
上传
使用“上传”功能，你可以直接从本地计算机将文件上传到云端：
你选择的文件将被上传到你当前浏览的文件夹中。还可以选择允许覆盖现有文件；如果你决定不覆盖并上传重复文件，你将看到以下错误：
访问权限
Azure 数据湖存储的最重要特点之一是能够完全声明对存储在其中的特定资源的访问权限：
默认情况下，只有你可以访问文件或文件夹。要添加新的用户或组，可以点击“+ 添加”按钮：
我想在这里讨论一些重要的内容：
-
权限：请记住，要授予某人列出文件夹内文件的权限，你需要分配两个权限：读取和执行。创建文件夹内的子项时也适用相同的要求。
-
添加到：可以将特定权限集传播到不仅是单个文件夹，而是文件夹内的所有文件夹。当你希望快速允许某人列出某个父目录下的文件和文件夹时，这尤其有用。
-
添加为：你可以将一组权限添加为默认权限条目（默认分配给文件夹的所有其他用户）或访问权限条目（指定某人如何访问它）。你也可以结合使用这两种方式以加快操作。
文件和文件夹
在每个可见的文件和文件夹旁边，你可以看到一个图标，点击该图标会显示一个菜单，提供额外的选项：
事实上，这些选项与我们刚刚讨论的相同——它们只是应用于特定的文件夹和文件。
Microsoft Azure Storage Explorer
大多数前述选项都可以通过 Microsoft Azure Storage Explorer 来执行：
不幸的是，它不提供为文件和文件夹分配权限的功能。不过，它在浏览存储数据时是一个更好的选择——更重要的是，它会自动显示分配给项目的一组所需权限。
使用 SDK
管理文件和你的 Azure Data Lake Store 实例的最灵活（也是最先进）选项是使用适合你当前语言的 SDK。目前，官方支持三种不同的语言：
-
.NET 平台
-
Java
-
Python
还可以使用 REST API，基本上你可以使用任何语言连接它。以下代码片段可以让你连接到服务：
var client = AdlsClient.CreateClient("<account-name">, <credentials>);
在进行身份验证以连接到你的服务时，有两种可用的选项：
-
终端用户身份验证
-
服务到服务的身份验证
这两种场景在进一步阅读部分的文档中有详细描述。无论你选择哪种选项，最终都会使用生成的 OAuth 2.0 令牌。在这里，你可以找到一个简单的服务提供者，它利用了所描述的方法，并允许你轻松创建新文件夹并向文件中追加数据：
public class DataLakeProvider : IDisposable
{
private readonly DataLakeStoreFileSystemManagementClient _client;
public DataLakeProvider(string clientId, string clientSecret)
{
var clientCredential = new ClientCredential(clientId, clientSecret);
var creds = ApplicationTokenProvider.LoginSilentAsync("domainId", clientCredential).Result;
_client = new DataLakeStoreFileSystemManagementClient(creds);
}
public Task CreateDirectory(string path)
{
return _client.FileSystem.MkdirsAsync("datalakeaccount", path);
}
public async Task AppendToFile(string destinationPath, string content)
{
using (var stream = new MemoryStream(Encoding.UTF8.GetBytes(content)))
{
await _client.FileSystem.ConcurrentAppendAsync("datalakeaccount", destinationPath, stream, appendMode: AppendModeType.Autocreate);
}
}
public void Dispose()
{
_client.Dispose();
}
}
你可以在进一步阅读部分提到的博客文章中阅读更多关于如何编写这种提供者的内容。
使用 SDK 的一个重要优点是能够抽象化许多操作并自动化它们——你可以轻松地递归删除文件或动态创建文件。使用 UI 时，这些操作是无法实现的，而大多数严肃的项目开发人员宁愿编写代码，也不愿依赖手动文件管理。
安全性
Azure Data Lake Store 提供了一种与其他 Azure 存储选项不同的安全模型。实际上，它为你提供了一个复杂的解决方案，包含身份验证、授权、网络隔离、数据保护和审计。由于它被设计为数据驱动系统的基础，因此在保护谁（或什么）以及如何访问存储的信息时，必须扩展常见的功能。本节将介绍不同的安全功能并详细描述它们，让你熟悉它们并了解如何使用。
身份验证和授权
为了验证谁或什么可以访问存储的数据， Azure Data Lake Store 使用 Azure Active Directory 来识别当前访问数据的实体。为了授权它，Azure 通过 基于角色的访问控制（RBAC）来保护资源本身，并使用 POSIX ACL 来保护数据。
了解这两个术语之间的区别非常重要：
-
身份验证：这决定了谁或什么尝试访问特定的资源。
-
授权：通过限制仅将资源的访问权限分配给已被分配特定权限集的人员，从而保护资源。
重要的是要记住，如果你有多个订阅承载着不同的资源，并希望它们访问 Azure Data Lake Store，你必须将相同的 Azure AD 实例分配给它们所有——如果没有这样做，其中一些将无法访问数据，因为只有在分配给 ADLS 的目录中定义的用户和服务才能通过身份验证并获得访问权限。
让我们查看 RBAC 和 POSIX 模型之间的区别。
RBAC
RBAC 控制谁可以访问 Azure 资源。它是一个独立的角色和权限集合，与存储的数据无关。要检查此功能，请点击**访问控制（IAM）**刀片：
在前面的屏幕上，你可以看到我为资源分配了三个不同的应用程序（服务）和一个用户。他们还具有不同的角色：
-
所有者：完全访问权限，包括确定谁可以访问该资源
-
贡献者：完全访问权限，除非确定谁可以访问该资源
如果你点击角色按钮，你将看到 ADLS 可能角色的完整列表：
使用**访问控制（IAM）**刀片，你可以轻松控制谁能访问你的 Azure Data Lake Store 实例以及如何访问——每当你想更改权限或访问它的用户/服务集合时，使用它。
一个好的做法是管理组而不是单独的实体——这让你可以在一个地方（Azure AD）添加/移除用户或实体，而不必浏览资源及其 RBAC。
POSIX ACL
如前所述，你可以通过提供一组定义为读取、写入和执行的权限来管理对你实例中数据的访问。它们是 POSIX 访问控制列表（ACL）的一部分，而 ACL 是 Hadoop HDFS 的一部分，HDFS 是此 Azure 服务的引擎之一。如果你曾使用过 FTP 服务器，可能已经处理过文件系统权限；它们通常被描述为包含r、w、x和字符-的数字或字符串。以下是一个示例：
-
-rwx------等同于0700，并仅声明所有者具有读取、写入和执行权限。 -
-rwxrwxrwx等同于0777，并声明每个人都可以读取、写入和执行权限。 -
-rw-rw-rw-等同于0666，并声明所有人均可读取和写入权限。
你可以在进一步阅读部分中找到更多关于 POSIX ACL 模型的信息。
网络隔离
我之前提到了防火墙刀片，但我们跳过了它，目的是让你在熟悉该服务后能学到一些东西。当你点击防火墙刀片时，你会看到一个屏幕，允许你指定哪些 IP 地址可以访问你的实例：
这里最重要的是能够阻止其他 Azure 服务访问您的数据——如果您有要求必须禁止任何人读取存储在 ADLS 中的信息，这一点非常有用。您可以在 进一步阅读 部分的链接中了解更多关于安全功能的信息。
最佳实践
Azure Data Lake Store 在访问存储的数据以及执行读写操作时与其他服务有所不同。由于此服务旨在存储 PB 级别的数据，了解如何存储数据的最佳实践非常重要，这样可以避免像需要重新组织所有文件或读取/写入速度慢等问题。这还包括安全功能（如前所述），因为它是整个解决方案的重要组成部分。在本节中，我们将重点讨论多个关于 ADLS 的建议，帮助您在使用时更加得心应手，并能够利用最佳实践。
性能
许多存储解决方案的一个重要特性是它们的性能。通常，我们期望无论负载高低、单个记录大小如何，数据库都能正常工作。对于 ADLS，您需要考虑以下因素：
-
并行性：正如文档中所述，在执行读写操作时，确保提供一定程度的并行性非常重要。每个核心的理想线程数被定义为 8-12。
-
文件大小：虽然不同的数据分析解决方案可能会根据文件大小的不同而有不同的表现，但同样重要的是要知道，ADLS 也有一个最佳的文件大小。由于它基于 HDFS，并利用 POSIX 模型来处理权限，它更倾向于使用较大的文件（几百兆字节）而不是较小的文件，以避免在复制、连接和身份验证检查时出现问题。
-
I/O 限制：虽然 Azure Data Lake Store 在吞吐量方面没有启用硬性限制，但当您的作业在容量上非常苛刻时，仍然可能会遇到一些问题。重要的是要记住，即使在这个服务中，您仍然可能会遇到一些软限制，这些限制可以在联系 Azure 支持后解除。如果遇到 429 错误，可能是由于限流。
-
批处理：在许多面对高吞吐量的情况下，使用批处理来减少写入操作可能是有益的。在 ADLS 中，批处理的最佳大小被定义为 4 MB —— 通过执行这种大小的写入操作，您可以减少所需的 IOPS，并提升服务的整体性能。
安全性
我们之前稍微讨论过这个话题，在这里我们做个总结。当使用 ADLS 并考虑其安全功能（如身份验证、授权和文件访问）时，重要的是要记住以下几点：
-
优先使用组而不是用户/服务：虽然最初将单个用户分配到资源或文件夹可能更容易，但一旦对数据感兴趣的人数迅速增长，您将迅速面临问题。这就是为什么最好使用 Azure AD 组来确定对资源本身的 RBAC 访问以及对文件和文件夹的 POSIX ACL。它还提高了解决方案的性能，因为检查实体是否属于组比遍历长用户列表更快。
-
最小权限集合：与其他服务一样，始终从访问您的 Azure 数据湖存储实例所需的最小权限集合开始。不要为仅读取数据的用户分配写入权限，或者为仅在文件夹中读取单个文件的服务分配执行权限。
-
启用防火墙：通常情况下，您不希望允许任何人访问存储在 ADLS 中的数据。为了保护您的解决方案，使只有子集 IP 地址能够访问信息，启用防火墙，以便拒绝名单之外的任何人。
弹性
确保数据安全存储并且在 DC 内部出现问题时不会丢失是至关重要的。正如本章开头所提到的，ADLS 不支持地理冗余性——您必须自行实施。为此，您必须集成一个工具，允许您按照需要复制数据。文档中提到了三种不同的工具——Distcp、Azure 数据工厂和 AdlsCopy，当然，您也可以使用任何其他能够连接到 Azure 数据湖存储并与服务集成的工具。
在考虑 Azure 数据湖存储的灾难恢复（DR）或高可用（HA）时，考虑诸如 RPO、不一致性和执行故障切换时的复杂数据合并问题等因素。有时，等待服务恢复而不是切换到次要副本可能更好。
数据结构
您将根据不同的使用场景选择不同的数据结构——对于 IoT 数据，它将非常细粒度：
{Vector1}/{Vector2}/{Vector3}/{YYYY}/{MM}/{DD}/{HH}/{mm}
另一方面，用于存储用户数据的结构可能完全不同：
{AppName}/{UserId}/{YYYY}/{MM}/{DD}
这完全取决于您当前的需求。在计划对存储的文件执行分析时，数据结构至关重要——它直接影响文件的大小和数量，进而可能影响您的活动可能工具集。
这里另一个重要的事项是法律要求——如果您使用任何敏感数据作为文件夹或文件名，您必须能够在用户告诉您希望被遗忘或要求删除账户时有效地执行清理。
概要
在本章中，你已经学习了一些关于 Azure Data Lake Store 的知识，它是一个旨在存储几乎无限数据量的 Azure 服务，并且不影响数据的结构。我们已经讨论了数据结构、安全功能和最佳实践等内容，因此你应该能够开始构建自己的解决方案，基于这个特定的 Azure 组件。请记住，Azure Storage 可能很容易替代它——这完全取决于你的需求和期望。如果你需要更灵活的安全模型、更好的性能和更高的限制，ADLS 就是你的选择。这部分书籍到此结束，涵盖了存储数据的服务、监控服务以及它们之间的通信。下一章，你将学习更多关于 Azure 的扩展性、性能和可维护性方面的知识。
问题
-
哪种安全模型更好——管理安全组还是单独管理实体？为什么？
-
RBAC 和 POSIX ACL 之间有什么区别？
-
ADLS 中的文件最大可以有多大？
-
哪种数据结构更好——一个包含成千上万文件的单一文件夹，还是一个包含多个文件的文件夹层级结构？
-
Azure Data Lake Store 可以与任何编程语言一起使用吗？
-
ADLS 和 Azure Storage 有什么区别？
-
如何确保基于 ADLS 的解决方案具有地理冗余性？
进一步阅读
-
终端用户认证：
docs.microsoft.com/en-us/azure/data-lake-store/data-lake-store-end-user-authenticate-net-sdk -
服务到服务认证**(authentication)**：
docs.microsoft.com/en-us/azure/data-lake-store/data-lake-store-service-to-service-authenticate-net-sdk -
编写 Data Lake Store 提供程序：
blog.codenova.pl/post/azure-functions-webjobs-and-data-lake-writing-a-custom-extension-2 -
Data Lake Store 操作.NET：
docs.microsoft.com/en-us/azure/data-lake-store/data-lake-store-data-operations-net-sdk -
安全概述：
docs.microsoft.com/en-us/azure/data-lake-store/data-lake-store-security-overview -
最佳实践：
docs.microsoft.com/en-us/azure/data-lake-store/data-lake-store-best-practices
第十八章：扩展 Azure 应用
在云中谈论可靠和稳定的应用程序时，扩展是必不可少的。虽然在基础设施即服务（IaaS）或本地部署的模型中，这个过程可能显得有些复杂且笨重，但 Azure 提供了多种不同的方式，可以快速扩展我们的应用程序，且没有停机时间。
本章将涵盖以下主题：
-
自动扩展、向上扩展、向外扩展
-
扩展 Azure 应用服务
-
扩展 Azure 函数
-
扩展 Azure 服务结构
技术要求
要执行本章的练习，您将需要以下内容：
- 访问 Azure 订阅
自动扩展、向上扩展、向外扩展
云计算的核心是扩展——这是此类设置相比本地部署设置的最重要优势之一。云能够快速适应新需求，尤其是流量的增加，而云所提供的灵活性使您能够创建更稳定的服务，减少意外负载峰值和硬件性能不足的风险。在本章中，我们将深入探讨扩展主题，帮助您深入理解 Azure 中不同服务的行为，并确保扩展功能是自动化的，并且尽可能少需要关注。
自动扩展
您可以按以下方式定义许多服务的自动扩展功能：
自动扩展是一项功能，允许服务、机器或应用程序根据预定义的参数（如 CPU 利用率、内存使用情况或人工因素，如吞吐量单元或工作者利用率）自动向上或向外扩展。
通常，您可以按以下方式描述自动扩展：
前面的图示可以按以下方式描述：
-
资源正常接受传入请求
-
同时，有一个实体监控资源——它会根据扩展规则检查资源，并决定是否需要执行扩展操作。
-
一个实体根据设置决定是否扩展资源，它可以将资源向上/向下扩展或向外扩展。
当然，除了优点，扩展也有其缺点：
-
它可能会使您的应用程序变得无响应。
-
它需要额外的资源来进行负载均衡（如果是向外扩展）。
-
这需要时间，具体取决于扩展特性。因此，必须在设计阶段规划此类操作。
-
在许多情况下，这会使您的解决方案变得更加昂贵。
服务如何扩展完全取决于服务本身。让我们看一些例子：
-
Azure 事件中心可以手动/自动扩展（使用自动膨胀功能）。您可以为实例分配更多的吞吐量单元（TUs），使其能够接收更多的消息。自动缩减扩展尚未实现。
-
Azure 应用服务可以手动和自动扩展（取决于您选择的层级）。您可以使用多个不同的参数，缩小扩展也会自动进行。
-
Azure Cosmos DB 依赖于分配给实例的请求单元（RU）。
-
Azure SQL 有不同的扩展模型——你可以使用数据库事务单元（DTUs）或虚拟核心（vCores）。
-
Azure Functions 通过内部的工作者和扩展控制器机制自动扩展。
-
Azure 存储不支持扩展。
如你所见，在 Azure 中没有单一的扩展解决方案——你必须为每个组件单独实现可行的解决方案。经验法则是，你对资源的控制越少，扩展将越自动化。而对于 IaaS 场景，你必须操作虚拟机的数量，而在PaaS中，你将最终得到虚拟核心或其他单元。这里你可以找到按扩展复杂度从左到右排列的不同云模型（其中IaaS具有最复杂的模型）：
向上扩展与向外扩展
有两种不同类型的扩展（至少在 Azure 中是这样）：
-
水平扩展：通过升级硬件/增加一个层级来进行扩展
-
水平扩展：添加服务的实例
向上扩展可以如下呈现：
而为了进行比较，水平扩展的描述如下：
因此，在第一个场景中（向上扩展），你将从单个实例中获得更好的性能，而水平扩展则允许你并行处理工作。两种选项的使用场景不同，基本上取决于你计划运行的工作负载。这些是一些例子：
-
如果你的代码是顺序执行且无法并行化，使用向上扩展。
-
如果你的代码在单位时间内需要大量的计算能力，而不是将其分配到多台机器上，使用向上扩展。
-
如果你有方法对负载进行负载均衡，使用水平扩展。
-
如果你能够在多台机器上执行相同的工作，并且没有碰撞的风险，使用水平扩展。
使用水平扩展可以比作多线程——但当然是在一个更大的规模上。事实上，问题非常相似。如果你的机器有多个核心，并且能够同时执行你的代码，那么你必须引入非常相似的约束。
水平扩展的常见问题通常是由访问状态引起的——无论它是通过任何类型的存储共享，还是在多台机器之间分布。在使用此功能之前，请确保了解这些问题。
在 Azure 中，多个服务的扩展方式不同。我们将重点讨论其中三个，以便更好地理解这一主题。
扩展 Azure 应用服务
我们通过学习一些基本的 Azure 应用服务 开始了在 Microsoft Azure 上的旅程。这是一个非常常见的 PaaS 组件，在许多 Azure 用户中被广泛使用，适用于非常简单的网站和要求高性能与高可靠性的复杂系统。为了确保您的 Web 应用 始终在线，或者检查它是否面临压力，您需要实施某种扩展规则。对于此服务，您有两个选择——要么使用手动扩展（并实现某种警报，以便知道何时执行此操作），要么使用自动扩展功能，这样在维护方面会更轻松。在本节中，我们将介绍并比较这两者。
手动扩展
手动扩展是从基础层开始提供的功能——它不适用于免费的或共享的服务。根据所选择的实际层级，您的应用服务可以使用不同数量的实例。
在这里，您可以查看 B2 层的情况：
在前面的配置中，最大可用实例数设置为三。 However，如果我将扩展到标准层，结果如下：
情况看起来有些不同——两个功能发生了变化：
-
我可以将实例数量设置为最多 10 个
-
可以启用自动扩展
请注意，将扩展到高级层将允许您为应用服务设置最多 20 个实例。
自动扩展
虽然手动扩展对于需求较低的网站和系统可能是合适的（因为它们在发生事件时不需要迅速采取行动），但如果您的应用程序是一个受欢迎的电子商务网站，您希望操作快速执行，包括扩展。例如，让我们尝试现在启用自动扩展——这将显示一个表单，允许您管理这些设置：
事实上，您在这里有两个选择：
-
基于指标扩展：允许您选择一个指标，该指标将作为自动扩展的触发条件
-
扩展到特定的实例数：默认情况下执行（因此应该与基于指标的扩展一起使用）
要根据指标配置自动扩展，您需要一个规则。您可以通过点击 + 添加规则链接来添加该规则。这样做将显示另一个表单（比当前的表单复杂得多），您可以在其中选择所有对您有意义的内容：
在前面的截图中，您可以看到一个规则，当 CPU 使用率在 10 分钟内超过 70% 时，会触发自动扩展。一旦满足所有条件，运行时将向应用服务添加另一个实例。更重要的是，如果条件在 5 分钟后仍然成立（冷却时间（分钟）期间），将再次触发扩展操作。这将一直持续，直到达到您设置的最大实例数为止。
请记住，你可以为应用程序设置多个规则。而且，似乎创建一个按规则减少实例数的规则是个好主意，这样当负载恢复正常时，它会移除多余的实例。
一旦添加了规则，你可以点击保存以确认更改——现在，每当规则被认为是激活状态时，你的应用程序就会自动扩展。在继续之前，我想向你展示另外两件事。你可能注意到在扩展页面上有两个额外的部分：JSON 和 Notify。它们在管理服务时提供了一些额外的选项：
-
JSON: 这会生成一个 JSON 模板，可以与 ARM 模板一起使用，以自动配置你的资源。当创建服务时，它会自动添加扩展规则。
-
Notify: 这使你能够在 Azure 中自动向资源管理员发送通知，当出现问题时通知他们。
这里你可以看到为我的规则生成的 JSON：
{
"location": "West Europe",
"tags": {
"$type": "Microsoft.WindowsAzure.Management.Common.Storage.CasePreservedDictionary, Microsoft.WindowsAzure.Management.Common.Storage"
},
"properties": {
"name": "handsonazure-euw-webapp-autoscale",
"enabled": true,
"targetResourceUri": "/subscriptions/1a2d5d1c-dee5-4deb-a93a-366cc83feb46/resourceGroups/handsonazure-euw-rg/providers/Microsoft.Web/serverfarms/handsonazure-euw-appserviceplan",
"profiles": [
{
"name": "Auto created scale condition",
"capacity": {
"minimum": "1",
"maximum": "10",
"default": "1"
},
"rules": [
{
"scaleAction": {
"direction": "Increase",
"type": "ChangeCount",
"value": "1",
"cooldown": "PT5M"
},
"metricTrigger": {
"metricName": "CpuPercentage",
"metricNamespace": "",
"metricResourceUri": "/subscriptions/1a2d5d1c-dee5-4deb-a93a-366cc83feb46/resourceGroups/handsonazure-euw-rg/providers/Microsoft.Web/serverFarms/handsonazure-euw-appserviceplan",
"operator": "GreaterThan",
"statistic": "Average",
"threshold": 70,
"timeAggregation": "Average",
"timeGrain": "PT1M",
"timeWindow": "PT10M"
}
}
]
}
],
"notifications": [],
"targetResourceLocation": "West Europe"
},
"id": "/subscriptions/1a2d5d1c-dee5-4deb-a93a-366cc83feb46/resourceGroups/handsonazure-euw-rg/providers/microsoft.insights/autoscalesettings/handsonazure-euw-webapp-autoscale",
"name": "handsonazure-euw-webapp-autoscale",
"type": "Microsoft.Insights/autoscaleSettings"
}
扩展 Azure Functions
使用 PaaS 服务时，你可以配置当 CPU 使用率达到最大允许值，或请求数超过阈值时，应用程序的行为。然而，Azure 还提供了其他模型的服务——其中最有趣的是无服务器架构，它进一步抽象了控制，旨在提供更简便的配置、最小的维护以及专注于提供业务价值的能力。
在本节中，你将看到 Azure 应用服务和 Azure Functions 在扩展方面的不同，从技术和概念的角度来看。
扩展无服务器应用程序
当使用无服务器服务（例如 Azure Functions、Azure Cosmos DB 或 Azure Event Grid）时，配置该功能的选项非常有限。例如：
-
在 Azure Functions 中，你依赖于定价模型（消费计划与应用服务计划）
-
在 Azure Cosmos DB 中，你修改 RU 的数量
-
在 Azure Event Grid 中，你无法定义服务如何扩展。
这一切的原因是你无法控制应用程序主机——底层服务引擎与应用程序完全分离，无法直接修改。你能做的是间接控制它，要么通过改变处理单元的数量，要么通过可用的配置选项，这些选项可以被解释并应用。
请注意，无服务器是一个模型，你与运行时（在某些情况下甚至与云服务提供商）是隔离的。如果这种缺乏控制不适合你，最好尝试 PaaS 或 IaaS 模型和服务。
扩展 Azure Functions
在 Azure Functions 中，至少在消费计划下，不可能进行扩展。当然，使用 App 服务计划时，您可以进行扩展并获得更好的硬件，但这不会影响服务本身。相反，它会创建更多的资源来消耗。另一方面，您不能手动扩展。唯一的可能性是让 Azure Functions 自动扩展。为此，该服务实现了扩展控制器的概念。这是一个内部功能，它持续监控承载函数运行时的特定工作进程的行为，如果其中一个似乎过载，则会向工作集添加另一台机器。
Azure Functions 的扩展行为非常复杂且仅部分描述，因为它包含了开源部分或未公开的部分。我将在本章中尽力详细描述，以便您了解做出扩展决策的准确算法。
在您的 Azure Functions 实例做出扩展决策之前，它会检查以下内容：
-
扩展间隔：扩展仅在经过特定时间间隔后发生。
-
当前工作进程数：如果工作进程的数量（运行函数宿主的工作进程）超过了配置的最大值，系统会决定从工作集移除一个工作进程。
-
负载因子：如果负载因子接近最大值，则会添加一个新的工作进程。相反，如果负载因子下降，则会移除一个工作进程。
-
繁忙工作进程比例：如果繁忙的工作进程数超过了配置的最大值，则会向工作集添加另一个工作进程。
-
空闲工作进程：如果空闲工作进程的数量大于定义的最大值，系统会从工作集移除其中一个工作进程。
上述操作的定义值可以如下找到：
public const int DefaultMaxWorkers = 100;
public const int DefaultBusyWorkerLoadFactor = 80;
public const double DefaultMaxBusyWorkerRatio = 0.8;
public const int DefaultFreeWorkerLoadFactor = 20;
public const double DefaultMaxFreeWorkerRatio = 0.3;
public static readonly TimeSpan DefaultWorkerUpdateInterval = TimeSpan.FromSeconds(10);
public static readonly TimeSpan DefaultWorkerPingInterval = TimeSpan.FromSeconds(300);
public static readonly TimeSpan DefaultScaleCheckInterval = TimeSpan.FromSeconds(10);
public static readonly TimeSpan DefaultManagerCheckInterval = TimeSpan.FromSeconds(60);
public static readonly TimeSpan DefaultStaleWorkerCheckInterval = TimeSpan.FromSeconds(120);
上述值来自 Azure Functions Host 的 GitHub 仓库。这些值可能会在一段时间后更改，但如果您有兴趣，可以查看以下项目：github.com/Azure/azure-functions-host
此外，您可以通过在应用程序设置中提供 WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT 值来控制实例的最大数量：
更重要的是，如果您将 Function App 实例连接到 Azure Application Insights 实例，您将能够通过检查 Live Metrics Stream 功能查看它有多少个工作进程：
扩展 Azure Service Fabric
我们已经讨论了通过与两个不同的 Azure 服务合作来扩展的两种不同模型；Azure 应用服务和 Azure Functions。
在添加新实例或提升硬件性能方面，它们有很大的不同，因为它们引入了多个概念，并提供了不同的灵活性。在本章的最后部分，我们将介绍另一个服务——Azure Service Fabric。这个 Azure 产品在进行垂直或水平扩展时行为略有不同，因为它要求你管理虚拟机。此外，执行这一操作需要一组独特的技能，以确保操作顺利且正确。
手动扩展集群
在 Azure Service Fabric 中，集群可以通过两种方式进行缩放：
-
手动：通过在集群配置中选择适当的选项
-
程序化：通过使用 Azure SDK
实际上，集群的特性在一开始就已经选定，当你选择节点类型及其配置时，如下截图所示：
扩展 Azure Service Fabric 服务类似于扩展虚拟机，因为它基于包含不确定数量虚拟机的节点，这意味着你实际上依赖于扩展集。
最好在一开始就搭建一个能够处理计划负载的集群，而不是在压力下进行缩放，尤其是当你需要严格的事务保证时，这可能会影响缩放时间。请查看进一步阅读部分，那里有一篇文章描述了高效的集群规划。
在使用 Azure Service Fabric 扩展时，请记住，向扩展集添加机器总是需要时间。因此，请考虑提前规划此类操作，以便将对当前操作的影响降至最低。要实际扩展你的集群，你需要使用创建时就配置的扩展集的扩展功能，如下图所示：
执行此操作的另一个选项是使用 ARM 模板，代码片段如下：
"resources":[
{
"type":"Microsoft.Compute/virtualMachineScaleSets",
"apiVersion":"2017-03-30",
"name":"[parameters('<scale-set-name>')]",
"location":"[resourceGroup().location]",
"sku":{
"name":"[parameters('<sku>')]",
"tier":"<tier>",
"capacity":"[parameters('<capacity>')]"
}
}
]
通过提供<capacity>值，你可以轻松更改为你的 SF 集群提供计算的虚拟机数量。
使用 Azure SDK 来扩展你的集群
另一个缩放集群的选项是使用 Azure 计算 SDK。你可能会想，这个特性有哪些使用场景——毕竟，我们已经有了手动/自动缩放功能。然而，仍然有一些更高级的场景，可能适合使用自己的控制器进行缩放：
-
使用自定义度量进行扩展，而这并不适用于自动扩展。
-
在缩放操作之前可以执行额外的操作。
-
在关键工作负载的情况下，完全控制缩放操作。
要获取 Azure 计算 SDK，你需要下载以下 NuGet 包：Microsoft.Azure.Management.Fluent，网址为：www.nuget.org/packages/Microsoft.Azure.Management.Fluent/。其他语言（如 Java 或 Python）也有类似的库，你可以在进一步阅读部分的链接中找到它们。
要扩展集群的规模，你可以使用以下代码片段：
var vmScaleSet = AzureClient.VirtualMachineScaleSets.GetById(ScaleSetId);
var capacity = (int)Math.Min(MaximumNodeCount, vmScaleSet.Capacity + 1);
vmScaleSet.Update().WithCapacity(capacity).Apply();
同样的方式也适用于 Java：
vmScaleSet.update().withCapacity(capacity).apply();
如你所见，这段代码非常简单—你只需要获取当前的规模集 ID 来引用它，然后修改其容量。在这个示例中，我使用了值 1，但没有任何限制，阻止你使用其他数字。
通过前面的示例，你也可以缩减集群的规模。然而，请记住，你不应该将集群缩减到低于其可靠性层级。如果这样做，你将无法再依赖它，甚至可能导致集群不稳定。
如果你使用的是比铜更高的可靠性层级，那么你不需要担心未使用的机器，因为它们会被自动移除。否则，你需要手动处理。为此，你需要知道哪些虚拟机当前没有被使用。要移除不再需要的节点，你可以使用以下操作：
await client.ClusterManager.DeactivateNodeAsync(node.NodeName, NodeDeactivationIntent.RemoveNode);
scaleSet.Update().WithCapacity(capacity).Apply();
await client.ClusterManager.RemoveNodeStateAsync(node.NodeName);
它们基本上做三种不同的事情：
-
停用并从集群中移除节点
-
减少规模集容量
-
删除节点状态
要找到要移除的节点，你必须查询集群并查找最近添加的机器：
using (var client = new FabricClient())
{
var node = (await client.QueryManager.GetNodeListAsync())
.Where(n => n.NodeType.Equals(NodeTypeToScale, StringComparison.OrdinalIgnoreCase))
.Where(n => n.NodeStatus == System.Fabric.Query.NodeStatus.Up)
.OrderByDescending(n =>
{
var instanceIdIndex = n.NodeName.LastIndexOf("_");
var instanceIdString = n.NodeName.Substring(instanceIdIndex + 1);
return int.Parse(instanceIdString);
})
.FirstOrDefault();
}
你可能会想，为什么最近添加的机器会成为扩展操作的受害者？这是因为在集群利用率较高时，工作被委派给了它。它最初并不属于该规模集，完成任务后可以移除。
总结
在本章中，我们涵盖了三种完全不同的服务扩展—Azure App Service、Azure Functions 和 Azure Service Fabric。你看到这种操作如何适应不同的应用模型—有时你扩展服务实例、虚拟机，或者干脆不控制它，而是让运行时为你处理。实际上，在云中进行服务扩展比使用自有服务器要容易得多。你无需重新配置负载均衡器、防火墙、路由器和服务器。使用扩展功能时，始终尽量自动化这一过程—手动扩展仅适用于非常简单的场景，而且容易让服务器处于低效使用状态。
在接下来的两章中，我们将介绍另外两个 Azure 服务：Azure CDN 和 Azure Traffic Manager，它们帮助确保你的应用在高负载下仍然可用。
问题
-
扩展和扩展的区别是什么？
-
扩展的使用场景有哪些？
-
在无服务器服务中可以进行扩展吗？
-
在 Azure App Services 中，扩展是否会影响服务的定价？
-
为什么在 Azure Service Fabric 中，扩展操作可能是危险的？
-
手动扩展的缺点是什么？
-
如果你想在 CPU 使用率达到 80% 时自动扩展你的 Azure 应用服务，应该怎么做？
进一步阅读
-
Service Fabric 集群规划：
docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-capacity -
Service Fabric 集群扩展：
docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-scaling -
Azure SDK：
docs.microsoft.com/en-us/azure/index#pivot=sdkstools&panel=sdkstools-all
第十九章：使用 Azure CDN 提供静态内容
托管许多静态文件，尤其是在我们开发一个非常受欢迎的应用程序时，是一项严峻的任务，它影响着我们的 Web 服务性能和整体用户体验。如果我们加载图片、文件或文档的速度过慢，客户可能会选择我们的一位竞争对手，他们提供类似的功能，但表现更好。得益于像 Azure 内容交付网络（CDN）这样的云服务，我们能够快速处理大带宽的内容，这是因为它与 Azure 存储的集成，并使用 Azure 的本地组件。
本章将涵盖以下主题：
-
CDN
-
使用和配置 Azure CDN
-
使用 Azure CDN 优化静态内容的提供
-
使用 Azure CDN 开发应用程序
技术要求
要完成本章的练习，您将需要以下内容：
-
一个 Azure 订阅
-
Visual Studio 2017
Azure CDN 基础
如果您托管的是一个包含许多静态文件的热门网站，您可能会想知道如何优化这些文件的提供给用户。当寻找解决方案时，您必须考虑许多不同的因素；如 HTTP 协议规范、浏览器能力、服务器性能、网络延迟等。整个问题远非简单，并且需要大量资源才能以正确的方式实现。为了解决这些困难，CDN 的概念应运而生。CDN 代表内容分发网络，概括了一个复杂服务的概念，该服务负责将内容提供给所有浏览您网站的用户。在本章中，您将学习 Azure CDN，这是一个 Azure 组件，旨在为所有列举的问题提供快速且可靠的解决方案。
使用 CDN
当用户访问您的网站时，必须获取为特定页面提供的所有静态内容。这意味着以下操作：
-
浏览器必须请求网页所需的所有图片、文件和脚本
-
请求必须排队，因为浏览器对单个域的请求次数是有限制的
-
在大多数情况下，页面必须逐步呈现，因为内容是从服务器获取的
-
如果服务器当前负载过重，它可以限制请求
-
浏览器必须遵循所有已实现的缓存机制，当然，前提是您的网站告诉它如何执行
我们可以将整个过程描述如下：
在前面的场景中，用户的每个请求直接路由到网站，然后与服务器连接以获取数据。当然，我们可以想象文件由不同的服务器托管的情况，如下图所示：
这种替代方案可以稍微提高性能（因为服务器将使用不同的域名进行识别），但它增加了维护和配置的复杂性。而且，如果你面临网络延迟问题，这种设置并不是正确的解决方案（因为增加一个服务器不会产生太大差异）。在我们讨论不同架构时，你可能开始想象另一种可能产生区别的设置。
作为 网站 和 服务器 之间的代理，负责适当的缓存，它可以轻松地扩展，并且具有高可用性，如下图所示：
CDN 正是我们所说的代理。它们提供以下功能：
-
如果负载超过预期，它们可以轻松地进行扩展
-
它们可以缓存请求，从而减少最终服务器的负载
-
它们尊重缓存控制头，因此可以轻松提供资源的 生存时间 (TTL)
-
它们通过同时为多个用户提供内容，提高了你网站的响应能力
在本章后续，你将学习如何利用这些服务，通过使用 Azure CDN。
在门户中创建 Azure CDN
创建 Azure CDN 的过程与本书中其他服务的创建过程相似。首先，你需要点击 + 创建资源按钮，并搜索 Azure CDN。从搜索结果中选择 CDN。这将带你进入一个表单，你可以在其中输入有关新服务的所有必要信息：
这里有两点值得一提：
-
定价层：与其他 Azure 服务相比，定价层略有不同，因为你不再可以选择 Basic、Standard 和 Premium 选项。在这里，你需要决定将使用哪种 产品——你可以从包含 Verizon、Akamai 和 Microsoft 等提供商的列表中选择。它们提供不同的功能，如动态站点加速、视频流优化和资产预加载。完整的列表可以在本章的 进一步阅读 部分找到。
-
现在创建一个新的 CDN 端点：如果你知道你的源（一个缓存资源的端点）是什么，你可以立即为整个服务创建它。
要快速查看特定定价层中提供的内容，你可以点击 查看完整定价详情链接：
如你所见，你需要为每 GB 的出站数据传输付费，根据选择的提供商，价格可能差异近五倍。当你点击 创建按钮时，服务创建过程将开始。创建完成后，你可以访问你自己的 Azure CDN 实例：
如果你决定不与服务一起创建端点，你将看到一个与我的类似的页面， 端点 部分为空。让我们点击 + 端点 按钮来实际创建一个。如前所述，端点是 CDN 的元素，它缓存数据并用于特定目的。在接下来的部分，你可以看到我为第一个端点设置的示例：
如你所见，我选择了 Storage 作为源类型。为了能够这么做，你必须在与你的 CDN 位于同一资源组中实际拥有一个 Azure Storage 实例。你还可以选择其他可用类型，如 Cloud Service、Web App 或自定义源。一旦添加了端点，你将能够通过点击 概述 选项卡上的端点来管理它。
优化与缓存
CDN 的核心是优化内容并进行缓存。通过这种方式，它们提升了你网站的性能和用户体验。在上一节中，你了解了内容分发网络（CDN）的概念，并配置了你的 Azure CDN* 实例。现在我们将尝试学习一些更高级的功能，例如压缩、缓存规则和优化。
配置端点
要访问端点配置，你必须在 概述 选项卡上点击它：
这将显示一个新页面，在该页面中你可以找到关于特定 CDN 端点的所有信息，如其主机名、可用协议以及配置的内容优化规则。事实上，该页面看起来与前一个页面非常相似——它只提供了一些附加选项：
现在我们将讨论可用于端点的不同功能。
压缩
CDN 的基本功能之一是压缩——它们允许你动态压缩不同类型的文件，例如降低文件大小并减少网络延迟：
启用后，你可以选择你感兴趣的 MIME 类型。如果你计划支持其他类型，也可以添加新的类型。
记住，文件必须被 CDN 缓存，才能在动态过程中进行压缩。
缓存规则
默认情况下，CDN 根据你提供的 Cache-Control 头部缓存内容。然而，你可以明确地定义它应该如何行为，如果：
-
缺少头部信息
-
引入了查询字符串
-
特定的匹配条件匹配
在这里，你可以找到此功能的基本设置：
如你所见，它为你提供了对服务行为的很大控制，尤其是通过自定义缓存规则。
地理过滤
有时，你需要为特定国家/地区屏蔽特定的内容。没有 CDN，这样的功能可能会遇到问题——你必须通过编程控制谁可以根据地理位置访问特定的图像或文件。使用 Azure CDN，你可以在几秒钟内启用该功能：
在 Geo-filtering 面板上，你可以为特定国家/地区配置不同的规则，阻止或允许访问 CDN 中的文件夹或特定文件。
使用 Azure CDN 开发应用程序
Azure CDN 本身并没有提供什么特殊功能——它只是缓存内容，并负责无延迟地提供它。然而，重要的是要了解如何在你的应用程序中使用它。在 Azure 中，集成 Azure CDN 和例如 Azure App Services 是小菜一碟。只需几次鼠标点击，你就可以让你的 CDN 与现有的 Web 应用程序协同工作。在本章的最后一节，你将看到配置集成所需的步骤，并能够提升你网站的性能。
配置 Azure App Service 与 Azure CDN
要配置 Azure App Service 使其与 Azure CDN 实例一起工作，你需要找到 Networking 面板。它让你能够启用不同的 Web 应用功能，包括 CDN：
当你点击为应用程序配置 Azure CDN 时，你将看到另一个屏幕，在那里你可以配置 Azure App Service 和 Azure CDN 之间的链接。
Azure CDN 将自动开始缓存静态文件，这些文件可以在你的网站中找到。此时发布应用程序是一个好主意，这样你就不必等到过程结束之后再发布。
事实上，你现在有两个选项可以继续：
-
使用现有的 CDN 配置文件（如果你已经完成了本章前面部分的练习，你应该已经创建并准备好使用 CDN）
-
创建一个全新的配置文件
在接下来的部分，你可以找到我的配置（我选择了一个现有的端点来加速进程）：
一旦你的端点创建完成，你可以检查它是否工作。你可以例如检查我的应用程序的资源，如我所做的那样：
为了本次练习，我使用了模板中的一个示例应用程序。如你所见，配置了 CDN 后，我的应用程序的源自动被修改——所有静态内容都通过我的 Azure CDN 端点提供，而不是我的服务器。
总结
在本章中，你了解了什么是 CDN，以及它们如何帮助你为 Web 应用程序实现更好的性能和用户体验。我们已经配置了 Azure CDN 实例，并看到了如何通过压缩内容来优化内容的提供。阅读完本章后，你应该能够为特定国家/地区过滤特定内容，并能够制定合适的缓存规则，从而定义你的实例将如何表现。
在本书的下一章中，这是描述 Azure 服务的最后一章，我们将介绍一个更高级的场景——使用 Azure Traffic Manager 分配负载并保护数据免受故障的影响。
问题
-
使用 Azure CDN 可以解决哪些问题？
-
Azure CDN可用的 CDN 提供商有哪些？
-
CDN 的起源是什么？
-
压缩在 Azure CDN 中是如何工作的*？*
-
存储在 Azure CDN 中的内容的默认 TTL 是多少？
进一步阅读
第二十章：使用 Azure 流量管理器分配负载
有时我们希望根据后端的性能来分配负载，或者在某些服务器正在维护时将用户路由到不同的服务器。如果没有一个能无缝、快速完成这项任务的服务，这可不是一件容易的事。感谢Azure 流量管理器，我们能够提高关键应用的可用性，在执行大型复杂部署时分配流量，或者在进行维护时避免停机。
本章将涵盖以下主题：
-
使用 Azure 流量管理器
-
不同的路由方法
-
端点监控
技术要求
要进行本章的练习，您需要以下内容：
- 访问 Azure 订阅
Azure 流量管理器基础
假设以下情况——您有一个需要全球服务的应用。为了保证全球所有客户的最佳性能，您在不同的区域（一个在北美，一个在欧洲，一个在非洲）提供了不同的服务实例。然而，有一个问题。您必须明确告诉客户访问应用的特定实例——即离他们位置最近的那个实例。
虽然这当然是可行的（只需提供正确的 URL），但这个解决方案并不理想。例如，如果您的客户去度假，并在接下来的两周里呆在欧洲而不是非洲怎么办？为了克服这种问题，您可以在 Azure 中利用一个名为Azure 流量管理器的服务，它会处理来访请求的正确路由，并允许您在应用中实现高可用性。
Azure 流量管理器的功能
您可以将Azure 流量管理器视为一个在 DNS 层级上工作的负载均衡器。为了理解这个概念，请看以下示例。默认情况下，如果没有像Azure 流量管理器这样的服务，您的客户将使用端点 URL 将请求从客户端应用发送到服务器应用：
如果您想要对来访请求进行负载均衡，您必须在架构中引入另一个元素，来负责将请求路由到正确的后端（并可能确保它们是健康的）：
这种设置的缺点是可能会引入延迟。更重要的是，在这种情况下，您的客户直接通过负载均衡器连接，这并没有解决全球分配入口点的问题。
上面的示例是使用反向代理时常见的解决方案，反向代理充当您系统的网关。
上述场景定义了一种解决方案，其中负载均衡基于基于 TCP/UDP 分配流量，因此它比 DNS 层级要低得多。当使用Azure 流量管理器时，请求的流动方式完全不同：
流程可以描述如下：
-
向DNS 服务发送DNS 查询以获取服务器地址。
-
DNS 服务被配置为指向Azure 流量管理器，而不是直接指向某个服务。
-
Azure 流量管理器根据查询特征选择正确的端点，并返回一个包含正确服务器地址的DNS 响应。
-
客户端接收到DNS 响应并使用它连接到正确的服务器。
实际上，客户端需要执行两个请求：
-
获取服务器的 URL。
-
发送实际请求
虽然这看起来可能有些开销，但实际上，这种影响是不可察觉的。
请注意，采用这种解决方案的优势在于能够直接将请求发送到服务器，而没有参与通信的中介服务。
在 Azure 门户中创建 Azure 流量管理器。
要在门户中开始使用 Azure 流量管理器，您需要点击+ 创建资源按钮并搜索 traffic manager。然后在搜索结果中选择流量管理器配置文件。您将看到一个表单，您需要在其中填写所有必填字段才能创建服务：
虽然大多数选项应该不言自明，但有一个下拉框需要我们特别关注，即路由方法。这里有六种不同的可用方法：
-
性能
-
权重
-
优先级
-
地理位置
-
MultiValue
-
子网
在描述每个选项之前，您需要理解路由方法到底是什么。之前我提到过，Azure 流量管理器决定将用户路由到哪个端点。这个路由操作可能会根据选择的方法给出不同的结果。让我们考虑以下场景：
-
您的应用程序实例在全球分布，您希望将用户路由到离其最近的实例。
-
您的应用程序实例提供不同的性能，您希望将用户路由到提供最佳用户体验的实例。
-
您有一个处理所有流量的主要区域，并希望在发生故障或临时问题时将用户路由到次要区域。
-
您希望均匀分配流量，或者按照设定的权重分配流量。
-
您希望将用户的 IP 地址映射到特定实例。
根据选择的场景，应该选择不同的路由方法。接下来我将详细描述它们。
路由方法 – 性能
当使用性能路由方法时，用户将被路由到“最接近”的端点。需要记住的是，这个“最接近”的端点可能不是地理上最接近的，因为此方法考虑的是性能而非距离。假设内部的 Azure 流量管理器存储了关于配置的端点以下信息：
| 端点 | 区域 | 延迟 |
|---|---|---|
| 服务器 A | 西欧 | 12 毫秒 |
| 服务器 B | 东部美国 2 | 67 毫秒 |
在前面的场景中，表现更好的端点是 服务器 A。当选择性能路由方法时，用户将被路由到该服务器。
需要记住的是，在性能路由方法下，Azure 流量管理器会检查响应的延迟，并考虑发送请求的 DNS 服务器的 IP 地址，而不是客户端的 IP 地址。
路由方法 - 权重
当你想要均匀分配流量或基于预定义权重分配流量时，权重路由方法是你要寻找的解决方案。使用该方法时，你需要定义权重，在决定请求应该路由到哪里时，这些权重将被考虑在内。让我们来看一下以下表格：
| 端点 | 权重 | 状态 |
|---|---|---|
| 服务器 A | 100 | 在线 |
| 服务器 B | 100 | 降级 |
| 服务器 A - staging | 5 | 在线 |
在前面的例子中，我们有三个端点，其中一个报告了问题。尽管 服务器 A 和 服务器 B 的权重相同，但由于服务器 B 的状态报告为降级，它将不会被视为健康的端点，因此用户将不会被路由到它。剩下的两个服务器有不同的权重。在这种情况下，Azure 流量管理器将随机将用户分配到一个端点，其概率由该端点的权重决定。如果我们假设有 105 个请求，其中 100 个会被路由到 服务器 A，其余的路由到 服务器 A – staging。
权重路由方法是进行 A/B 测试的绝佳选择，你可以随机将用户路由到包含新特性的应用程序新实例。如果用户喜欢新特性，你可以调整权重并将其余流量路由到该实例。
路由方法 - 优先级
优先级路由方法是最简单的方法，适用于一个简单的场景，其中你有一个主区域托管你的应用程序，并且你希望确保在出现问题时可以轻松地切换到次要区域。让我们考虑以下场景：
| 服务器 | 优先级 | 状态 |
|---|---|---|
| 服务器 A | 1 | 在线 |
| 服务器 A - 辅助 | 2 | 在线 |
在前面的例子中，所有流量将被路由到服务器 A，原因如下：
-
它的优先级设置为
1 -
它的状态被认为是在线的
现在发生了一些事情，主副本宕机了：
| 服务器 | 优先级 | 状态 |
|---|---|---|
| 服务器 A | 1 | 降级 |
| 服务器 A - 次要 | 2 | 在线 |
由于服务器 A 被认为不健康，所有流量将被路由到辅助实例，直到主实例恢复正常。
请记住，客户端可能会缓存 DNS 响应，这会延长你的端点对它们不可用的时间。
路由方法 - 地理位置
有时候你需要将用户路由到特定区域，考虑到它的位置。这样做有多个原因，例如：
-
法律要求
-
内容本地化
-
从最接近的服务器提供应用程序，考虑到距离因素
请记住，最靠近用户的区域可能并不是网络延迟最小的区域。不要过度使用此路由方法来实现最佳的用户体验。
使用地理路由方法时，你将区域分配给已配置的端点：
| 服务器 | 区域 |
|---|---|
| 服务器 A | 法国 |
| 服务器 B | 亚洲 |
| 服务器 C | 全球 |
现在，为了将用户路由到正确的服务器，Azure 流量管理器尝试通过读取源 DNS 服务器的 IP 地址来确定其位置。它从州/省（如果不支持，则为国家/地区）开始，最终确定在全球值上。
使用地理路由方法时，Azure 流量管理器会返回一个端点，不论其是否健康。利用嵌套配置文件来扩展路由方法并实现高可用性是非常重要的。
路由方法 – 多值
多值路由方法与其他路由方法略有不同，因为它允许返回多个健康的端点，并让客户端选择使用哪个端点。这种场景适用于当你不知道如何将用户路由到服务端，但同时你希望确保用户被路由到健康端点的情况。
为确保该路由方法能够返回端点，必须将其设置为“外部”并分配 IPv4 或 IPv6 地址。
路由方法 – 子网
最后一种路由方法是最复杂的，因为它允许你将特定的 IP 地址（或一系列 IP 地址）映射到特定的端点。
该方法的使用案例可能有所不同，例如：
-
你想要阻止使用特定 ISP 的用户
-
你希望将来自公司网络的用户路由到应用程序的内部实例
-
你已经为应用程序设置了品牌，并希望将来自不同公司网络的用户路由到特定的品牌实例
使用子网路由方法时，确保覆盖所有可能的 IP 地址，因为如果未能做到这一点，将会返回 NODATA 响应，导致客户端返回错误。
一旦你对选择的路由方法满意，可以点击“创建”按钮，在 Azure 中创建资源。
在 Azure 门户中使用 Azure 流量管理器
当你访问你的 Azure 流量管理器实例时，你会看到一个包含服务概览的默认屏幕：
由于当前没有端点附加到这个特定配置文件，显示的端点列表为空。在添加新端点之前，我们先简单了解一下其他服务功能。
配置
当你访问配置面板时，你将看到 Azure 流量管理器实例的完整配置：
它包含诸如路由方法（默认显示您在创建服务时选择的那个）、端点监控设置和快速端点故障转移设置等内容。从此屏幕，您基本上可以控制 Azure Traffic Manager 的行为。例如，假设您的每个端点都有一个自定义的/status端点，专为与服务配合使用而设计。默认情况下，Azure Traffic Manager 检查默认端点 URL（在此设置为/），因此您需要更改路径字段，如下所示：
对于期望的状态码也是如此。如果您的端点可以返回一系列 HTTP 状态码，并且每一个都应该被视为成功，您可以在“期望状态码范围”字段中输入该范围：
您可以在此尝试不同的设置，以便它们能够反映您需要覆盖的实际场景。
真实用户测量
使用性能路由方法时，Azure Traffic Manager 会检查 DNS 请求的来源，并将结果转换为一个内部表格，反映不同终端用户网络的网络延迟。虽然此选项适用于大多数用例，但有时您可能希望能够告诉 Azure Traffic Manager 实际的延迟。通过“真实用户测量”功能，您可以将 JavaScript 代码注入到客户端端点，直接将延迟信息发送到此 Azure 服务。
为此，请转到“真实用户测量”选项卡，并点击生成密钥按钮：
您将看到两个字段：
-
密钥：存储生成的密钥
-
测量 JavaScript：保存应注入到客户端应用程序中的脚本。
一旦使用生成的脚本，它将开始向您的 Azure Traffic Manager 实例发送有关延迟和客户端网络的附加信息，从而提高服务做出决策的准确性。
准确性改进不是即时的——Azure Traffic Manager 需要从不同网络收集大量数据，以提高性能。
端点
Azure Traffic Manager 的主要功能是配置它所处理的端点。您可以通过 Endpoints 选项卡访问它：
要添加一个端点，您必须输入以下值：
-
类型：您可以选择 Azure 端点、外部端点和嵌套端点三种类型。不同的选择会影响整个表单——选择 Azure 端点时，您可以选择一个 Azure 服务；选择外部端点时，您需要提供一个完全合格的域名或 IP 地址；而选择嵌套端点时，您可以指向另一个 Traffic Manager 配置文件。
-
名称：端点的唯一名称。
-
目标资源类型/FQDN 或 IP/目标资源：根据 Type 值，您需要选择不同的值来配置端点。
-
Priority：因为我的路由方法是 Priority，我必须为这个特定的终端输入正确的值。如果选择了其他方法，您可能会在此处看到其他字段。
在以下示例中，我选择了一个 Azure 端点，并将配置指向我的一个 Azure 应用服务。我执行了两次操作，并向我的应用程序的两个实例添加了两个不同的端点：
记住，您不能将指向同一区域的服务域添加到单一的 Azure Traffic Manager 配置文件中。
如您所见，在添加终端后，它们的状态显示为“检查终端”。这意味着 Azure Traffic Manager 正在尝试收集关于它们健康状况的信息。如果有问题，您会看到“降级”状态：
就我而言，问题是由于配置无效导致的，因为我将 Configurationblade 中的Path字段设置为/status，结果发现这是一个无效值（在我的应用中，我将该端点实现为/api/status）。在主服务中修正配置后，其状态显示为在线：
最后需要配置的是在 DNS 服务器上设置 DNS 记录，指向您的 Azure Traffic Manager 实例（通过使用可以在 Overview blade 上找到的 DNS 名称）。
监控
除了将流量路由到不同的终端，Azure Traffic Manager 还提供了一些额外的监控功能。除了传统的 Metrics blade 外，还有一个额外的功能叫做流量视图，它使您能够进行监控。此外，您可以使用许多不同的内建机制（如 Windows 操作系统中的nslookup），来检查服务的当前配置。
Nslookup
要使用 nslookup，您必须使用管理员帐户在 Windows 中运行命令行。加载完成后，输入以下命令：
nslookup <Traffic-Manager-DNS-name>
稍等片刻，它应该返回一个结果，显示命令解析：
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
Name: waws-prod-db3-119.cloudapp.net
Address: 40.85.74.227
Aliases: handsonazure.trafficmanager.net
handsonazure02-eun-appservice.azurewebsites.net
waws-prod-db3-119.sip.azurewebsites.windows.net
如您所见，它指向我的应用程序的第二个实例（handsonazure02，托管在北欧区域）。我得到这个响应的原因是，主端点被认为已经降级。一旦它重新上线，我再次运行了命令，得到了一个截然不同的响应：
Name: waws-prod-am2-229.cloudapp.net
Address: 104.40.250.100
Aliases: handsonazure.trafficmanager.net
handsonazure01-euw-appservice.azurewebsites.net
waws-prod-am2-229.sip.azurewebsites.windows.net
现在它返回了主服务器（如预期，使用的是 Priority 路由方法）。
记住，您必须等待固定时间，才能使所有 DNS 更改传播。这个时间值可以在 Configurationblade 中配置，方法是修改 DNS 生存时间字段（DNS time to live）。
流量视图
流量视图是一个附加的监控功能，允许您查看所选路由方法在 DNS 层面的具体工作情况。它提供了额外的有用信息，例如：
-
实际延迟级别
-
流量量级
-
用户位置
记住，此功能最多需要 24 小时才能传播并收集所有必要的信息。
默认情况下，该功能的屏幕如下所示：
一旦收集到信息，你可以利用图形化的数据展示，更好地理解所选路由方法的行为（并可能加以改进）。
总结
这是本书的最后一章，介绍了 Azure 服务之一——Azure Traffic Manager 的基础知识。你已经学习了流量分配的基本概念和多种路由方法，这些方法涵盖了许多实际的使用案例，可能会在你的日常工作中遇到。现在你应该理解这个特定的 Azure 服务是如何工作的，以及如何通过正确使用其功能（如配置、真实用户测量和监控）来实现预期目标。在下一章（也是最后一章）中，我将为你展示一些在 Azure 门户和不同云组件上工作的实用技巧，进一步提升你的技能。
问题
-
Azure Traffic Manager 支持哪些路由方法？
-
如何使用真实用户测量功能？
-
你可以链接不同的 Azure Traffic Manager 配置文件吗？
-
是否可以使用外部终端节点？
-
客户端是否直接连接到 Azure Traffic Manager 返回的终端节点？
-
网关和 Azure Traffic Manager 之间的主要区别是什么？
-
Azure Traffic Manager 可以用来实现高可用性吗？如果可以，如何实现？
进一步阅读
-
使用 Azure DNS 和 Traffic Manager 进行灾难恢复：
docs.microsoft.com/en-us/azure/networking/disaster-recovery-dns-traffic-manager -
它是如何工作的：
docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-how-it-works
第二十一章：Azure 提示和技巧
做事总有不止一种方式。这句话在 Azure 生态系统中尤为真实，我们在配置资源、管理服务和开发应用程序时，提供了多种工具和快捷方式。本章将向读者展示如何进一步提高生产力，并缩短交付可用解决方案所需的时间。
本章将涵盖以下主题：
-
Cloud Shell 和 Azure CLI
-
锁定资源
-
正确的命名规范
-
Azure 中的资源
技术要求
为了进行本章的练习，你将需要以下内容：
-
Azure 订阅
-
Azure CLI，访问
docs.microsoft.com/en-us/cli/azure/install-azure-cli?view=azure-cli-latest
Azure CLI 和 Cloud Shell
使用 Azure 门户执行所有操作，如配置资源、修改配置或查找特定值，确实是管理订阅和已部署服务的最简单方式之一。然而，当你有数十个或数百个不同的订阅、资源组和实例时，这可能会变得繁琐。在这种情况下，能够访问脚本和命令来加速操作并实现自动化（如果需要）是更好的选择。在本节中，我们将介绍 Azure 提供的两种基本工具：Azure CLI 和 Cloud Shell，当仅使用门户不足以满足需求时，你可以使用这两种工具。
Azure CLI
Azure CLI 是一款跨平台的命令行工具，你可以将其安装在本地以管理 Azure 资源。通常，命令的格式如下：
$ az [resource] [command] -param1 "Foo" -param2 123
例如，你可以使用 Azure CLI 创建一个函数应用，如下所示：
$ az functionapp create --name "handsonazureapp" --storage-account "handsonazurestorage" --consumption-plan-location "westeurope" --resource-group "myResourceGroup"
安装 Azure CLI 的说明可以在技术要求部分找到。该部分指向一篇文章，描述了多个不同平台的安装过程，例如 Windows、macOS 和 Linux。安装完 Azure CLI 后，打开命令行终端并输入以下命令：
$ az login
片刻后，你应该会看到类似于我的结果，系统会要求你在本地验证 Azure CLI：
$ az login
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code DRXXXXXXX to authenticate.
要验证工具，请访问显示的网页并输入显示的代码。如果一切正确，命令将成功结束，结果会显示与你的帐户关联的所有订阅信息。使用 Azure CLI 时，你不需要记住所有命令——你可以使用以下命令来查找相关命令：
$ az find -q "query"
假设你现在想要使用 Azure Functions。要查询与该服务相关的所有命令，我可以使用以下查询：
$ az find -q function
`az functionapp create`
Create a function app.
The function app's name must be able to produce a unique FQDN as
AppName.azurewebsites.net.
`az functionapp list`
List function apps.
`az functionapp delete`
Delete a function app.
`az functionapp stop`
Stop a function app.
`az functionapp start`
Start a function app.
`az functionapp restart`
Restart a function app.
`az functionapp update`
Update a function app.
`az functionapp`
Manage function apps.
`az functionapp config`
Configure a function app.
`az functionapp show`
Get the details of a function app.
如你所见，这非常简单——你可以快速部署新资源，而无需触碰 Azure 门户。在这里，你可以找到创建函数应用的完整示例说明：
$ az storage account create --sku Standard_LRS --kind Storage --resource-group handsonazure-euw-rg --name handsonazurestorage
$ az functionapp create --name handsonazure-euw-functionapp --storage-account handsonazurestorage --resource-group handsonazure-euw-rg --consumption-plan-location westeurope
在上面的示例中，我跳过了创建资源组的过程。如果你想创建一个新的资源组，只需使用az group create命令。
Cloud Shell
使用 Azure CLI 的替代方法是一个名为 Cloud Shell 的工具。你可以通过点击 Azure 门户中的 Cloud Shell 按钮直接访问它：
当你打开 Cloud Shell 时，门户底部将显示一个欢迎屏幕，询问你选择感兴趣的 shell：
选择并不重要，因为你可以随时更改所选选项。由于我个人更喜欢 PowerShell 而非 Bash，因此我的默认选项是前者。
Bash 和 PowerShell 脚本在功能上是对等的。你应该选择一个你更喜欢使用的 shell。
如果这是你第一次使用 Cloud Shell，你还需要挂载一个存储账户，该账户可以与此功能一起使用。Cloud Shell 用它在会话之间保持文件。这里有两个选择；你可以让它为你创建一个存储账户，或者点击“显示高级设置”按钮选择特定选项：
一旦一切配置正确，Azure 将尝试初始化你的 Cloud Shell 账户：
Your cloud drive has been created in:
Subscription Id: <subscription-id>
Resource group: cloudshell-euw-rg
Storage account: cloudshelleuwstorage
File share: cloudshelleuwfileshare
Initializing your account for Cloud Shell...\
Requesting a Cloud Shell.Succeeded.
Connecting terminal...
Welcome to Azure Cloud Shell
Type "dir" to see your Azure resources
Type "help" to learn about Cloud Shell
MOTD: Switch to PowerShell from Bash: pwsh
VERBOSE: Authenticating to Azure ...
VERBOSE: Building your Azure drive ...
Azure:/
PS Azure:\>
使用 Cloud Shell 类似于浏览文件系统。你的 Azure 资源以目录的形式呈现，可以通过常见的命令行命令如dir或cd访问。你可以通过输入以下命令选择你希望使用的订阅：
PS Azure:\> cd <subscription-name>
然后，你可以通过以下命令轻松浏览其中的所有资源：
PS Azure:\> cd AllResources
PS Azure:\> dir
请注意，你可以通过 Cloud Shell 访问的资源是有限制的——目前你可以使用它操作以下服务：
-
资源组
-
Web 应用
-
存储账户
-
虚拟机
例如，要获取 Azure Files 的连接字符串，你可以使用类似这样的命令：
PS Azure:\> cd StorageAccounts\<storage-account-name>\files
PS Azure:\> dir
当然，在 Cloud Shell 中，你可以同时使用 Azure PowerShell 命令和 Azure CLI。如果你在命令行中输入az命令，你将看到以下结果：
基本上，你在上一节中学到的所有内容都可以在这里应用。这是一个很棒的工具，一旦你习惯使用命令代替浏览 Azure 门户，它将大大提高你的工作效率。
锁
当利用可用的各种命令时，创建和管理 Azure 资源变得更加简单，这些命令可以让您工作更快，同时还能够自动化流程。然而，当您部署数百个资源时，可能会出现错误 —— 您可能会意外移动、重命名甚至删除不应该被触碰的资源。为了防止这种情况发生，可以使用锁定功能 —— 一种简单的功能，可以阻止您执行禁止的操作。在本节中，您将学习如何创建它们，并根据自己的需求使用它们。
创建和管理锁定
锁定几乎所有资源在门户上是可用的。您只需点击锁定选项卡即可访问它们：
在上述示例中，假设我想要保护我的资源组并禁止删除它。为此，我必须单击“+ 添加”按钮和相应的锁定类型：
现在，如果我尝试删除一个资源组，我将收到以下错误：
正如您可能注意到的，有两种类型的锁定；删除和只读。
只读锁定会阻止我对资源进行更改 —— 对于资源组来说，例如，我无法添加新服务：
当然，只读锁定对不同的资源起作用方式不同。如果我向我的 Azure 存储帐户引入一个只读锁定，它将阻止我对服务配置进行任何更改：
锁定也是 Azure 资源，这意味着您可以通过 Azure Powershell 命令（例如Get-AzureRmResourceLock）或 ARM 模板来管理它们。
命名约定
如果您不引入简单、直观且易于遵循的命名约定，那么在 Azure 中治理和管理资源可能会变得具有挑战性。在软件开发领域，服务的适当命名尤其困难，因为您必须考虑不同的区域、环境和实例。在本节中，我们将尝试探讨命名约定的不同概念，您可以根据需要应用或调整。
查找最佳命名约定
在 Azure 中，您必须考虑资源的以下方面：
-
部署资源的区域
-
资源类型
-
资源名称
-
资源实例类型/环境
我们将从资源组开始。默认情况下，您可以按以下方式命名它：
MyNewService
newPortal
oldplatform
一个经验法则是选择一个自解释的名称。例如选择一个名为MyNewService的名称是可以的，但它并没有提供以下信息：
-
资源组所在的位置
-
它代表什么环境（测试/生产/暂存等等）
更重要的是，如果你例如列出你订阅中的资源，你将无法知道MyNewService是什么资源类型，除非选择其类型。当然，像az group list这样的命令会为你提供资源的完整信息，如果你只想导出资源名称，你需要额外添加一个字段。在这种情况下，值得在资源组名称中注解资源类型，格式如下：
MyNewServiceResourceGroup
newPortal-resourceGroup
oldplatform-rg
到目前为止，情况不错——资源的名称现在看起来好多了。接下来，让我们考虑添加位置：
MyNewResourceResourceGroupEastUS2
newPortal-westEurope-resourceGroup
oldplatform-eun-rg
现在情况好多了——我们立刻知道我们正在考虑什么资源类型以及它位于哪里。有了这些信息，浏览不同服务变得更加容易。最后可以添加的内容是环境：
MyNewResourceResourceGroupEastUS2Test
newPortal-westEurope-prod-resourceGroup
oldplatform-staging-eun-rg
现在信息已完整。当然，一切取决于你的个人设置，因为你可能决定将所有环境存储在一个单一的资源组中。即便如此，还是值得包含其余的数据，以便为所有已提供的资源创建一致的名称。
记住，不同的 Azure 资源在命名时有不同的限制。虽然 Azure App Services 对此可能较为宽松，Azure Storage 则不允许使用字母和数字以外的字符。
实际上，你对命名约定的要求将决定资源名称中需要包含的内容，例如：
-
是否在不同地区部署资源
-
是否使用多个环境来开发你的应用
-
是否为多个环境使用单一资源组
一般规则是使用你喜欢的，并且足够灵活的命名约定，以便几年后仍然能涵盖部署到 Azure 的服务。这里最糟糕的情况是，过一段时间不得不更改它，因为它无法反映你业务的变化。
Azure 中的资源
Microsoft Azure 的核心就是资源——你直接或间接地管理它们，但无论如何，你接触的大多数内容都是某种形式的资源。无论它是某个特定服务（如 Azure Functions 或 Azure Traffic Manager），它的某个部分（如 Azure App Services 的应用设置），还是某个独立功能（如本章讨论的锁定功能），你都可以通过 Azure 资源管理器（通常简称为 Azure RM）来管理它们。在本章的最后部分，我们将讨论如何访问 Azure 资源的属性，以便你可以利用这些属性来调查配置并自动化流程，例如部署或监控。
Azure 资源浏览器
访问 Azure 资源的最简单方法是使用Azure 资源浏览器。你可以通过访问resources.azure.com/来使用它。
你的默认界面将类似于我的界面：
要浏览您的资源，您必须展开左侧可用的节点。最初，您可以访问两种不同的节点类型：
-
提供者：这些与特定的 Azure 服务相关，例如 Azure Cosmos DB 或 Azure Storage。
-
订阅：由于订阅本身也是一个 Azure 资源，因此您可以使用 Azure 资源浏览器来浏览它。
这两种节点类型使您能够进行不同类型的操作；提供者是特定 Azure 服务的高级表示，而订阅包含有关其中配置资源的信息。更重要的是，它使您可以直接查看资源的参数：
收集到的信息可以用于在 ARM 模板中输入所需的信息。您可以随时根据 Azure 资源浏览器中的可见结果进行参考。此工具还允许您直接编辑资源参数（通过点击“编辑”按钮），并生成一个 PowerShell/Ansible 脚本，该脚本可以用于管理资源。以下是为我的 Azure 存储账户生成的 PowerShell 命令示例：
# PowerShell equivalent script
# GET handsonazureeuwstorage
Get-AzureRmResource -ResourceGroupName handsonazure-euw-rg -ResourceType Microsoft.Storage/storageAccounts -ResourceName "handsonazureeuwstorage" -ApiVersion 2017-10-01
# SET handsonazureeuwstorage
$PropertiesObject = @{
#Property = value;
}
Set-AzureRmResource -PropertyObject $PropertiesObject -ResourceGroupName handsonazure-euw-rg -ResourceType Microsoft.Storage/storageAccounts -ResourceName "handsonazureeuwstorage" -ApiVersion 2017-10-01 -Force
# DELETE handsonazureeuwstorage
Remove-AzureRmResource -ResourceGroupName handsonazure-euw-rg -ResourceType Microsoft.Storage/storageAccounts -ResourceName "handsonazureeuwstorage" -ApiVersion 2017-10-01 -Force
# Action ListAccountSas
$ParametersObject = @{
signedServices = "(String)"
signedResourceTypes = "(String)"
signedPermission = "(String)"
signedIp = "(String)"
signedProtocol = "(String)"
signedStart = "(String)"
signedExpiry = "(String)"
keyToSign = "(String)"
}
Invoke-AzureRmResourceAction -ResourceGroupName handsonazure-euw-rg -ResourceType Microsoft.Storage/storageAccounts -ResourceName handsonazureeuwstorage -Action ListAccountSas -Parameters $ParametersObject -ApiVersion 2017-10-01 -Force
# Action ListServiceSas
$ParametersObject = @{
canonicalizedResource = "(String)"
signedResource = "(String)"
signedPermission = "(String)"
signedIp = "(String)"
signedProtocol = "(String)"
signedStart = "(String)"
signedExpiry = "(String)"
signedIdentifier = "(String)"
startPk = "(String)"
endPk = "(String)"
startRk = "(String)"
endRk = "(String)"
keyToSign = "(String)"
rscc = "(String)"
rscd = "(String)"
rsce = "(String)"
rscl = "(String)"
rsct = "(String)"
}
Invoke-AzureRmResourceAction -ResourceGroupName handsonazure-euw-rg -ResourceType Microsoft.Storage/storageAccounts -ResourceName handsonazureeuwstorage -Action ListServiceSas -Parameters $ParametersObject -ApiVersion 2017-10-01 -Force
# Action listKeys
Invoke-AzureRmResourceAction -ResourceGroupName handsonazure-euw-rg -ResourceType Microsoft.Storage/storageAccounts -ResourceName handsonazureeuwstorage -Action listKeys -ApiVersion 2017-10-01 -Force
# Action regenerateKey
$ParametersObject = @{
keyName = "(String)"
}
Invoke-AzureRmResourceAction -ResourceGroupName handsonazure-euw-rg -ResourceType Microsoft.Storage/storageAccounts -ResourceName handsonazureeuwstorage -Action regenerateKey -Parameters $ParametersObject -ApiVersion 2017-10-01 -Force
正如您所见，您无需自己编写这样的脚本，您可以直接使用 Azure 资源管理器，复制它们，并根据需要进行调整。
总结
在本书的最后一章中，我们讨论了与特定服务无关的主题，而是扩展了您当前的知识，并使您成为 Microsoft Azure 平台上更好的用户、开发人员和架构师。您已经学会了如何使用 Azure CLI 和 Cloud Shell 来简化管理操作，如何利用锁来保护所有脆弱的资源，以及如何读取 Azure 服务配置。我们还讨论了采用适当命名约定的好处以及它们如何影响您在 Azure 上部署的应用程序。这是一次激动人心的 Azure 云之旅，您发现了来自该平台的许多不同 PaaS 服务。Azure 是一个极好的生态系统，允许您构建小型网页和复杂的企业级平台。而且，它也非常动态——这就是为什么我强烈建议您查看本书中详细列出的进一步阅读部分，以便您能获得更多经验，熟悉更高级的概念。这里重要的一点是，您要不断更新自己的知识，无论是通过阅读博客、参加聚会或会议，还是阅读文章和书籍。由于云计算是近年来软件开发中的一个主要话题，熟悉它并建立自己的技能集是至关重要的，这将帮助您在日常工作中得心应手。
问题
-
在 Azure 中，资源的两种不同锁类型是什么？它们是如何工作的？
-
您可以在 Cloud Shell 中使用 Azure CLI 吗？
-
您可以从哪里获得有关您在 Azure 中配置资源的详细信息？
-
合适的命名规范能带给你哪些好处？
-
为什么 Cloud Shell 需要配置存储账户？
深入阅读
- 请参考 Azure 博客：
azure.microsoft.com/en-us/blog/。
扫一扫
1039
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
