你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

混合环境中的 Azure Functions

Azure Functions
Azure Monitor
Azure Pipelines
Azure 存储
Azure 虚拟网络

此参考体系结构演示了一个组织在地理上分布的多个本地分支机构。 每个位置都使用一个 Microsoft Azure 函数应用,该应用在附近的云区域中配置了高级计划。 此体系结构中的开发人员通过将 Azure Monitor 用作单一虚拟管理平台来监视所有 Azure 函数应用。

体系结构

该图说明了连接到不同区域中 Azure Functions 的多个本地虚拟机 (VM)。开发人员正在使用 Azure Monitor 监视他们的函数应用。

下载此体系结构的 Visio 文件

组件

该体系结构包括以下组件:

  • Azure Functions Azure Functions 是 Azure 中的无服务器平台即服务 (PaaS),它运行小型单任务代码,无需启动新的基础结构。 Azure Functions 高级计划可通过虚拟网络专门与 Azure Functions 通信。
  • Azure 虚拟网络。 Azure 虚拟网络是在 Azure 云平台上构建的专用网络,因此 Azure 资源可以以安全的方式相互通信。 Azure 虚拟网络服务终结点可确保 Azure 资源只能通过安全虚拟网络主干进行通信。
  • 本地网络。 在此体系结构中,组织创建了一个连接各种分支的安全专用网络。 此专用网络使用站点到站点连接以此连接到其 Azure 虚拟网络。
  • 开发人员工作站。 在此体系结构中,单个开发人员可以完全在安全专用网络上或任何远程位置处理 Azure Functions 的代码。 在任一场景中,开发人员都有权访问 Azure Monitor 来查询或观察函数应用的指标和日志。

方案详细信息

此体系结构的典型用途包括:

  • 许多物理位置连接到 Azure 中的一个虚拟网络以与 Azure Functions 进行通信的组织。
  • 在本地使用 Azure Functions 并保留使用 Azure 进行任何意外工作突发的选项的高增长工作负载。

建议

以下建议适用于大多数方案。 除非有优先于这些建议的特定要求,否则请遵循这些建议。

设计无服务器体系结构

传统企业应用程序倾向于整体应用程序体系结构,该体系结构使用一种代码“解决方案”运行整个组织的业务逻辑。 对于 Azure Functions,最佳做法是设计一种无服务器体系结构,其中单个函数执行单个任务。 这些单项任务旨在快速运行并集成到更大的工作流中。

Azure Functions 上的无服务器体系结构有许多好处,包括:

  • 应用程序可以按单个业务函数自动缩放,而不是缩放整个解决方案。 这有助于通过仅缩放每个任务所需的内容来为现有工作负载提供服务,从而降低成本。
  • Azure Functions 为许多 Azure 服务提供声明式绑定,从而减少团队需要编写、测试和维护的代码量。
  • 可以重复使用单个函数,从而减少大型企业解决方案所需的重复代码量。

在本地运行 Azure Functions

可以选择在本地而不是 Azure 中运行 Azure Functions;例如:

  • 你的团队可能需要在现有的本地 Kubernetes 安装中运行 Azure Functions。
  • 在开发过程中,团队可能会发现使用命令行接口而不是门户编辑器在本地进行开发会更容易。
  • 函数将在本地运行,工具集安装在本地 VM 上。

可以通过三种方式在本地运行 Azure Functions:

网络连接

使用高级计划创建函数应用程序可以在 Azure 虚拟网络、Azure 和本地网络以及每个本地分支的网络之间实现高度安全的跨网络连接

应在 Azure 虚拟网络与本地网络之间使用站点到站点Azure ExpressRoute 连接。 这样,本地分支就可以使用其服务终结点与 Azure 中的函数应用通信。

此外,Azure 中的每个虚拟网络还应使用虚拟网络对等互连来启用跨区域的各个函数应用之间的通信。

注意事项

这些注意事项实施 Azure 架构良好的框架的支柱原则,即一套可用于改善工作负载质量的指导原则。 有关详细信息,请参阅 Microsoft Azure 架构良好的框架

可伸缩性

  • 应设计 Azure Functions 代码,使其可以无休止地横向扩展。 请考虑争用条件、租用的文件和其他可能导致一个函数运行阻止另一个工作负载。 还可以考虑将所有 Azure Functions 代码编写成无状态和防御性的设计。
  • 对于在触发器或绑定中使用 Azure 存储 帐户的函数应用,请勿重复使用用于存储有关函数应用及其运行的元数据的同一帐户。

可用性

  • 通常,消耗计划中的 Azure Functions 可以纵向缩减为零个实例。 当新事件触发函数应用时,必须创建一个新实例并在其上运行代码。 与此过程相关的延迟称为冷启动。 Azure Functions 高级计划提供用于配置预热实例的选项,这些实例已准备好处理任何新请求。 可以将预热的实例数配置为横向扩展配置中的最小实例数。
  • 请考虑在多个区域中部署多个高级计划,并使用 Azure 流量管理器适当路由请求。

可管理性

  • Azure Functions 必须位于空子网中,该子网与其他 Azure 资源的子网不同。 这可能需要在为虚拟网络设计子网时进行仔细规划。
  • 请考虑为每个 Azure Functions 可能需要访问的本地资源创建代理。 这可以保护应用程序完整性免受任何意外的本地网络更改的影响。
  • 使用 Azure Monitor 来观察整个解决方案中 Azure Functions 的分析和日志

DevOps

  • 理想情况下,部署操作应来自单个团队(Dev 或 DevOps),而不是来自每个分支。 请考虑使用新式工作流系统(如 Azure Pipelines 或 GitHub Actions)在所有 Azure 区域和本地以可重复的方式部署函数应用。
  • 使用工作流系统自动将代码重新部署到 Azure Functions,因为代码已更新并标记为发布。
  • 使用部署槽位在 Azure Functions 最终版推送到生产之前对其进行测试。

成本优化

成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息,请参阅成本优化支柱概述

  • 使用 Azure 定价计算器估算成本。
  • Azure 虚拟网络连接、专用站点访问、服务终结点和预热实例需要 Azure Functions 高级计划。
  • Azure Functions 高级计划针对实例而不是针对消耗计费。 单个实例的最小值可确保即使没有运行,也至少会有一些每月帐单。 可以设置最大实例计数来控制可能大小突发的工作负载的成本。

作者

本文由 Microsoft 维护, 它最初是由以下贡献者撰写的。

主要作者:

若要查看非公开的 LinkedIn 个人资料,请登录到 LinkedIn。

后续步骤

请参阅以下 Azure Functions 体系结构指南:

请参阅 Azure 虚拟网络的以下体系结构指南: