利用无服务器函数

提示

此内容摘自电子书《为 Azure 构建云原生 .NET 应用程序》,可在 .NET 文档上获取,也可作为免费可下载的 PDF 脱机阅读。

Cloud Native .NET apps for Azure eBook cover thumbnail.

在从管理物理计算机到利用云功能的范围内,无服务器处于极端的位置。 你唯一的责任就是你的代码,你只需在代码运行时付费。 Azure Functions 提供了一种方法,可以将无服务器功能构建到你的云原生应用程序中。

什么是无服务器?

无服务器是一种相对较新的云计算服务模式。 这并不意味着服务器是可有可无的,你的代码仍会在某个服务器上运行。 区别在于,应用程序团队不再关注如何管理服务器基础结构。 而是让云供应商对此责任。 开发团队通过向客户提供业务解决方案而不是管道来提高其工作效率。

无服务器计算使用事件触发的无状态容器来托管你的服务。 它们可以根据需要横向扩展和横向缩减以满足需求。 Azure Functions 等无服务器平台与其他 Azure 服务(如队列、事件和存储)紧密集成。

无服务器解决了哪些问题?

无服务器平台解决了许多耗时且昂贵的问题:

  • 购买计算机和软件许可证
  • 托管、保护、配置和维护计算机及其网络、电源和空调要求
  • 修补和升级操作系统和软件
  • 将 Web 服务器或计算机服务配置为主机应用程序软件
  • 在其平台中配置应用程序软件

许多公司分配了大量预算,用来支持硬件基础结构问题。 迁移到云有助于降低这些成本;将应用程序切换到无服务器可以帮助消除这方面的成本。

微服务和无服务器函数之间的区别是什么?

通常,微服务封装业务功能,例如在线电子商务网站的购物车。 它公开了多个操作,使用户能够管理自己的购物体验。 然而,函数是一种小型的轻型代码块,它执行单一用途操作来响应事件。 微服务通常构造用于响应请求,通常来自接口。 请求可以是 HTTP REST 或基于 gRPC 的。 无服务器服务响应事件。 它的事件驱动的体系结构非常适合用于处理短时间运行的后台任务。

在哪些场景下适合使用无服务器?

无服务器公开为响应触发器而调用的各个短时间运行的函数。 这使它们非常适合用于处理后台任务。

应用程序可能需要发送一封电子邮件作为工作流中的一个步骤。 不要将通知作为微服务请求的一部分来发送,而是将消息详细信息放到队列中。 Azure 函数可以取消对消息的排队并以异步方式发送电子邮件。 这样做可以提高微服务的性能和可伸缩性。 可以实施基于队列的负载均衡,以避免出现与发送电子邮件相关的瓶颈。 此外,可以在多个不同的应用程序中将此独立服务作为一个实用工具重复使用。

来自队列和主题的异步消息传送是触发无服务器函数的一种常见模式。 不过,Azure Functions 可以由其他事件触发,比如对 Azure Blob 存储进行更改。 支持图像上传的服务可以有一个负责优化图像大小的 Azure 函数。 此函数可通过插入到 Azure Blob 存储中直接触发,使微服务的操作不再复杂。

许多服务在工作流中有长时间运行的进程。 通常,这些任务在用户与应用程序交互的过程中完成。 这些任务可以强制用户等待,从而对其体验产生负面影响。 无服务器计算提供了一种很好的方式,可以将较慢的任务转移到用户交互循环之外。 这些任务可以按需求进行缩放,而无需缩放整个应用程序。

在什么情况下应避免使用无服务器?

无服务器解决方案是按需预配和缩放的。 调用新的实例时,冷启动是一个常见问题。 冷启动是预配此实例所用的时间。 通常,这种延迟可能会有几秒钟,但可能会更长,取决于各种因素。 预配后,只要单个实例接收到定期请求,就会保持活动状态。 但是,如果调用服务的频率较低,Azure 可能会将其从内存中删除,重新调用时需要冷启动。 当函数横向扩展到新实例时,还需要冷启动。

图 3-9 展示了冷启动模式。 请注意,当应用程序处于冷状态时,需要执行额外的步骤。

Cold versus warm start图 3-9. 冷启动与热启动。

为了完全避免冷启动,可以从消耗计划转为专用计划。 你还可以配置一个或多个具有高级计划升级的已预热实例。 在这些情况下,当你需要添加另一个实例时,它已经启动并准备好了。 这些选项可帮助缓解与无服务器计算相关的冷启动问题。

云服务提供商根据计算执行时间和使用的内存对无服务器的使用收费。 长时间运行的操作或高内存消耗工作负荷并非始终是无服务器的最佳候选项。 无服务器函数倾向于小块的工作,可以快速完成。 大多数无服务器平台需要在几分钟内完成单个函数。 Azure Functions 默认有 5 分钟的超时持续时间,最多可以配置为 10 分钟。 Azure Functions 高级计划也可以缓解这个问题,默认超时时间为 30 分钟,并可以配置一个不受限制的更高阈值。 计算时间不是日历时间。 使用 Azure Durable Functions 框架的更高级函数可能会在几天内暂停执行。 计费基于实际执行时间 - 当函数被唤醒并恢复处理时。

最后,利用 Azure Functions 来完成应用程序任务增加了复杂性。 明智的做法是首先将应用程序架构设计为模块化、松散耦合的架构。 然后,确定无服务器提供的优势是否能证明额外的复杂性是合理的。