通过使用无服务器技术在云中自动执行工作流和重复任务，可以显著提高组织 DevOps 团队的工作效率。 无服务器模型最适合于符合事件驱动方法的自动化方案。
体系结构
方案
本文演示了两种关键云自动化方案：
成本中心标记：此实现跟踪每个 Azure 资源的成本中心。 Azure Policy 服务使用默认成本中心 ID 在组中标记所有新资源。 Azure 事件网格会监视资源创建事件，然后调用 Azure 函数。 该函数与 Microsoft Entra ID 交互，并验证新资源的成本中心 ID。 如果不同，它会更新标记，并向资源所有者发送电子邮件。 为简单起见，模拟了适用于 Microsoft Entra ID 的 REST 查询。 还可以使用 Microsoft Graph PowerShell 模块或适用于 Python 的 Microsoft 身份验证库 (MSAL) 集成 Microsoft Entra ID。
限制响应：此示例监视 Azure Cosmos DB 数据库以进行限制。 当针对 Azure Cosmos DB 的数据访问请求超过以请求单位（或 RU）计算的容量时，会触发 Azure Monitor 警报。 Azure Monitor 操作组配置为调用自动化函数以响应这些警报。 该函数会将 RU 扩展为更高值，从而增加容量，进而停止警报。
注意
这些解决方案并不是完成这些任务的唯一方式，演示它们是为了说明无服务器技术如何应对环境信号（事件）并影响环境的变化。 在可行的情况下，请使用平台本机解决方案而不是自定义解决方案。 例如，Azure Cosmos DB 以本机方式支持自动缩放吞吐量，作为限制响应方案的本机替代方法。
GitHub 中提供了方案一的参考实现。
这些无服务器云自动化方案中的函数通常以 PowerShell 和 Python 编写，这是系统自动化中使用的最常见的两种脚本语言。 它们在 Azure CLI 中使用 Azure Functions Core Tools 进行部署。 或者，可以使用 Az.Functions PowerShell cmdlet 部署和管理 Azure Functions。
工作流
基于事件的自动化方案最好使用 Azure Functions 来实现。 它们遵循以下常见模式：
响应资源上的事件。 这些是对创建、删除、更改 Azure 资源或资源组等事件的响应。 此模式使用事件网格为此类事件触发函数。 成本中心标记方案是此模式的示例。 其他常见方案包括：
- 向 DevOps 团队授予对新创建的资源组的访问权限，
- 删除资源时向 DevOps 发送通知，以及
- 响应资源（例如 Azure 虚拟机 (VM)）的维护事件。
计划任务。 这些通常是使用计时器触发的函数执行的维护任务。 此模式的示例包括：
- 在夜间停止资源，在早上启动，
- 按定期间隔读取 Blob 存储内容，并转换为 Azure Cosmos DB 文档，
- 定期扫描不再使用的资源，并移除它们，以及
- 自动备份。
处理 Azure 警报。 此模式使用将 Azure Monitor 警报和操作组与 Azure Functions 集成的便利性。 函数通常执行修正操作，以响应源自应用程序和基础结构的指标、日志分析和警报。 限制响应方案是此模式的示例。 其他常见方案包括：
- 在 SQL 数据库达到最大大小时截断表，
- 在 VM 中的某个服务错误停止时重启该服务，以及
- 在函数失败时发送通知。
与外部系统进行协调。 此模式通过使用逻辑应用协调工作流，来实现与外部系统的集成。 逻辑应用连接器可以轻松地与多个第三方服务以及 Microsoft 服务（如 Microsoft 365）集成。 Azure Functions 可用于实际自动化。 成本中心标记方案演示了此模式。 其他常见方案包括：
- 监视 IT 流程（例如更改请求或审批），以及
- 在完成自动化任务时发送电子邮件通知。
公开为 Webhook 或 API。 使用 Azure Functions 的自动化任务可以集成到第三方应用程序甚至是命令行工具中，具体方法是使用 HTTP 触发器将函数公开为 Webhook/API。 PowerShell 和 Python 中提供了多种身份验证方法来保护对函数的外部访问。 进行自动化是为了响应特定于应用的外部事件，例如与 Power Apps 或 GitHub 的集成。 常见方案包括：
- 为失败服务触发自动化，以及
- 将用户加入组织的资源。
创建 ChatOps 界面。 此模式使客户可以创建基于聊天的操作界面，并按照人工协作运行开发和操作函数与命令。 这可以与 Azure Bot Framework 集成，并将 Microsoft Teams 或 Slack 命令用于部署、监视、常见问题等。 ChatOps 界面可创建用于管理生产事件的实时系统，其中每个步骤都会自动记录在聊天中。 有关详细信息，请阅读 ChatOps 如何帮助你改进 DevOps。
混合自动化。 此模式使用 Azure 应用服务混合连接在本地计算机上安装软件组件。 通过此组件可以安全地访问该计算机上的资源。 目前能够使用 PowerShell 函数在基于 Windows 的系统上管理混合环境。 常见方案包括：
- 管理本地计算机，以及
- 通过跳转服务器管理防火墙后面的其他系统（例如本地SQL Server）。
组件
该体系结构包括以下组件：
Azure Functions。 Azure Functions 可在此体系结构中提供事件驱动的无服务器计算功能。 在事件或警报触发时，函数会执行自动化任务。 在两种情况下，使用 HTTP 请求调用函数。 应通过开发无状态的幂等函数，尽量降低代码复杂性。
幂等函数的多个执行会创建相同的结果。 为了维护幂等性，限制方案中的函数缩放保持简单化。 在实际自动化中，请确保适当地纵向扩展或缩减。 阅读优化 Azure Functions 的性能和可靠性，了解编写函数时的最佳做法。
Azure 逻辑应用。 逻辑应用可用于执行可使用内置连接器轻松实现的较简单任务。 这些任务的范围从电子邮件通知，到与外部管理应用程序集成。 若要了解如何将逻辑应用与第三方应用程序配合使用，请阅读 Azure 中的基本企业集成。
逻辑应用提供无代码或低代码可视化设计器，可以在某些自动化方案中单独使用。 请阅读 Azure Functions 与逻辑应用之间的这一比较，以了解哪些服务适合你的方案。
事件网格。 事件网格以内置方式支持来自其他 Azure 服务的事件，以及自定义事件（也称为自定义主题）。 可以使用事件网格的内置机制轻松地将操作事件（例如资源创建）传播到自动化函数。
事件网格使用发布-订阅模型简化基于事件的自动化，从而可为通过 HTTPS 传递的事件实现可靠的自动化。
Azure Monitor。 Azure Monitor 警报可以监视关键条件，并使用 Azure Monitor 操作组执行纠正措施。 这些操作组可轻松地与 Azure Functions 集成。 这对于监视和修复基础结构中的任何错误条件（例如数据库限制）非常有用。
自动化操作。 这一广泛的块表示函数可以与之交互以提供自动化功能的其他服务。 例如，第一个方案中用于标记验证的 Microsoft Entra ID，或第二个方案中要预配的数据库。
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改善工作负载质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
复原
Azure Functions
处理 HTTP 超时
若要避免较长的自动化任务出现 HTTP 超时，请在服务总线中对此事件进行排队，并在另一个函数中处理实际自动化。 限制响应自动化方案演示了此模式，即使实际 Azure Cosmos DB RU 预配速度较快。
在调用之间维护状态的 Durable Functions 可提供以上方法的替代方法。 Durable Functions 仅支持特定语言。
记录失败
作为最佳做法，函数应记录在执行自动化任务时出现的任何失败。 这样可以对错误情况进行正确的故障排除。 Azure Functions 以本机方式支持与作为遥测系统的 Application Insights 进行集成。
并发
验证自动化函数的并发要求。 通过在文件 host.json 中设置变量 maxConcurrentRequests 来限制并发。 此设置会限制在函数应用中运行的并发函数实例数。 由于每个实例都会占用 CPU 和内存，因此需要针对 CPU 密集型操作调整此值。 如果函数调用显得太慢或无法完成，请降低 maxConcurrentRequests。 有关更多详细信息，请参阅配置主机行为以更好地处理并发性部分。
幂等性
确保自动化函数是幂等的。 Azure Monitor 和事件网格都可能会发出警报或事件以指示进度（例如订阅的事件已解决、触发、正在进行等，资源正在进行预配、已成功创建等），甚至会由于配置错误而发送虚假警报。 请确保函数仅对相关警报和事件执行操作，并忽略所有其他内容，以便虚假或错误配置的事件不会导致不需要的结果。 有关详细信息，请参阅针对完全相同的输入设计 Azure Functions。
事件网格
如果工作流使用事件网格，请检查你的方案是否可能会生成足以堵塞网格的大量事件。 请参阅事件网格消息传送和重试以了解如何在未确认传送时处理事件，并相应地修改逻辑。 成本中心工作流不对此实现其他检查，因为它只监视资源组中的资源创建事件。 监视整个订阅中创建的资源可能会生成大量事件，从而需要复原能力更强的处理。
Azure Monitor
如果生成了大量警报，并且自动化会更新 Azure 资源，则可能会达到 Azure 资源管理器限制的上限。 这会对该订阅中的其余基础结构产生负面影响。 可通过限制 Azure Monitor 生成警报的频率来避免这种情况。 还可以限制为特定错误生成的警报。 有关详细信息，请参阅有关 Azure Monitor 警报的文档。
安全性
安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息，请参阅安全性支柱概述。
控制对函数的访问
通过设置授权级别来限制对 HTTP 触发的函数的访问。 借助匿名身份验证，可以使用 URL（例如 http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>）轻松访问函数。 通过要求在 URL 中提供函数密钥，函数级别身份验证可以模糊化 http 终结点。 此级别在文件 function.json 中设置：
{
"bindings": [
{
"authLevel": "function",
"type": "httpTrigger",
"direction": "in",
"name": "Request",
"methods": [
"get",
"post"
]
},
{
"type": "http",
"direction": "out",
"name": "Response"
}
]
}
对于生产环境，可能需要其他策略来保护函数。 在这些方案中，函数由其他 Azure 服务在 Azure 平台中执行，不会向 Internet 公开。 函数授权有时足以用于作为 Webhook 进行访问的函数。
请考虑在函数身份验证之上添加安全层，例如，
- 使用客户端证书进行身份验证，或者
- 通过启用应用服务身份验证，确保调用方属于或有权访问托管函数的目录。
函数级别身份验证是使用 Azure Functions 的 Azure Monitor 操作组可以使用的唯一选项。
如果需要从第三方应用程序或服务调用函数，则建议使用 API 管理层提供对函数的访问。 此层应强制进行身份验证。 API 管理具有与 Azure Functions 集成的消耗层，这使你可以仅当执行 API 时才进行付费。 有关详细信息，请阅读使用 OpenAPI 创建和公开函数。
如果调用服务支持服务终结点或专用链接，请考虑以下成本更高的选项：
- 使用专用应用服务计划，其中可以在虚拟网络中锁定函数以限制对其的访问。 这在基于消耗的无服务器模型中是无法实现的。
- 使用 Azure Functions 高级计划，其中包括要由函数应用使用的专用虚拟网络。
若要比较这些选项之间的定价和功能，请阅读 Azure Functions 缩放和托管。
控制函数可以访问的内容
Azure 资源托管标识（一种 Microsoft Entra ID 功能）简化了函数对其他 Azure 资源和服务进行身份验证和访问的方式。 代码无需管理身份验证凭据，因为它由 Microsoft Entra ID 管理。
托管标识分为两种类型：
系统分配的托管标识：这些标识作为 Azure 资源的一部分进行创建，无法在多个资源之间共享。 删除资源时会删除这些标识。 可将这些标识用于涉及单个 Azure 资源或需要独立标识的方案。 这两种方案都使用系统分配的标识，因为它们仅更新单个资源。 托管标识仅在更新另一个资源时才需要。 例如，函数可以在没有托管标识的情况下读取资源标记。 请参阅这些说明以将系统分配的标识添加到函数。
用户分配的托管标识：这些标识创建为独立 Azure 资源。 这些标识可以在多个资源间共享，在不再需要时需要显式删除。 请阅读有关如何用户分配的标识添加到函数的这些说明。 可请这些标识用于具有以下特征的方案：
- 需要访问可共享单个标识的多个资源，或
- 需要在预配过程中预先获取对安全资源的授权，或
- 具有经常回收的资源，同时权限需要一致。
将标识分配到 Azure 函数后，请使用 Azure 基于角色的访问控制 (Azure RBAC) 向它分配角色以访问资源。 例如，若要更新资源，需要将参与者角色分配给函数的标识。
成本优化
成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息，请参阅成本优化支柱概述。
使用 Azure 定价计算器估算成本。 以下是降低成本的一些注意事项。
Azure 逻辑应用
逻辑应用采用即用即付定价模型。 每次运行逻辑应用时，都会计量触发器、操作和连接器执行。 所有成功操作和失败操作（包括触发器）都视为执行。
逻辑应用还采用固定定价模型。 如果需要运行在 Azure 虚拟网络中与安全资源通信的逻辑应用，则可以在集成服务环境 (ISE) 中创建它们。
有关详细信息，请参阅 Azure 逻辑应用的定价模型。
在此体系结构中，逻辑应用在成本中心标记方案中用于协调工作流。
内置连接器用于连接到 Azure Functions 并在自动化任务完成时发送电子邮件通知。 函数使用 HTTP 触发器作为 Webhook/API 进行公开。 仅当发生 HTTPS 请求时，才会触发逻辑应用。 与函数持续轮询并检查特定条件的设计相比，这是一种经济高效的方法。 每个轮询请求都作为操作进行计量。
有关详细信息，请参阅逻辑应用定价。
Azure Functions
以下三个定价计划提供了 Azure Functions。
消耗计划。 这是提供的最经济高效的无服务器计划，你只需为函数运行的时间付费。 在此计划下，函数一次最多可以运行 10 分钟。
高级计划。 请考虑对具有其他要求（例如专用虚拟网络、较长的执行持续时间等）的自动化方案使用 Azure Functions 高级计划。 这些函数最多可以运行一小时，应选择用于较长的自动化任务，例如运行备份、数据库索引或生成报告。
应用服务计划。 使用 Azure 应用服务混合连接的混合自动化方案需要使用应用服务计划。 在此计划下创建的函数可以无限期运行（类似于 Web 应用）。
在这些自动化方案中，Azure Functions 用于更新 Microsoft Entra ID 中的标记，或者通过将 RU 纵向扩展到更高值来更改 Azure Cosmos DB 配置等任务。 消耗计划适用于此用例，因为这些任务是交互式的，并且不长时间运行。
Azure Cosmos DB
Azure Cosmos DB 按小时对预配吞吐量和消耗的存储计费。 预配的吞吐量以每秒请求单位表示 (RU/s)，可用于插入、读取等典型的数据库操作。 存储费用按存储数据和索引所用的每 GB 计算。 有关详细信息，请参阅 Azure Cosmos DB 定价模型。
在此体系结构中，当针对 Azure Cosmos DB 的数据访问请求超过以请求单位（或 RU）计算的容量时，Azure Monitor 会触发警报。 为响应这些警报，Azure Monitor 操作组配置为调用自动化函数。 函数会将 RU 扩展为更高值。 这可帮助降低成本，因为只需为工作负载每小时所需的资源付费。
若要快速估算工作负载成本，请使用 Azure Cosmos DB 容量计算器。
有关详细信息，请参阅 Microsoft Azure 架构良好的框架中的“成本”部分。
部署注意事项
对于管理应用程序行为的关键自动化工作流，必须使用高效 DevOps 管道实现零停机时间部署。 有关详细信息，请阅读无服务器后端部署。
如果自动化涵盖多个应用程序，请将自动化所需的资源保留在单独的资源组中。 如果自动化涵盖单个应用程序，则可以在自动化与应用程序资源之间共享单个资源组。
如果工作流涉及许多自动化函数，请将适用于一个方案的函数分组在单个函数应用中。 有关详细信息，请阅读管理函数应用。
部署应用程序时，需要监视它。 请考虑使用 Application Insights 来让开发人员监视性能和检测问题。
有关详细信息，请参阅 Microsoft Azure 架构良好的框架中的“DevOps”部分。
针对 Azure 资源的命令性操作
在以上两种方案中，最终结果是通过直接 Azure 资源管理器交互更改 Azure 资源状态。 虽然这是预期结果，但如果修改的资源最初以声明方式部署（例如 Bicep 或 Terraform 模板），请考虑这样做可能对环境产生的影响。 除非将这些更改复制回源模板，否则这些模板的下一次使用可能会撤消此自动化进行的更改。 请考虑混合使用对通过模板定期部署的 Azure 资源进行命令性更改的影响。
部署此方案
若要部署成本中心方案，请参阅 GitHub 上的部署步骤。