微软推出 Azure Functions 预览版，涉足无服务器应用领域

在 4 月份举行的 Build 大会上，微软宣布了 Azure Functions 预览版，这是一个根据需求运行代码的服务。Azure Functions 意味着微软已经进入日益流行的、由 Amazon、 Google、IBM 等主导的事件驱动无服务器计算领域。

Azure Functions 让开发人员可以发布基于外部触发执行的代码，而不用考虑准备计算或存储资源。这些函数——使用 C#、JavaScript、Bash、F#、PHP、PowerShell 或 PHP 编写——通常表现为短期异步任务。在一篇有关预览版发布的博文中，微软将“数据处理”作为发布这类服务的一个重要原因。

数据无所不在。它在云端，在本地，并越来越多地扩展到联网设备。组织正在努力发现那些数据的价值，要求他们的开发人员以高可扩展的解决方案作为回应，而方案的构建时间表被空前地压缩。这些方案通常需要开发人员实现按需或定时的批处理任务，以协调事务、获取和处理数据，或者实时响应事件。

开发人员可以以多种方式触发 Azure Functions，包括 HTTP 调用、修改 Azure 队列或 Blob 存储以及通过 cron 调度。微软指出，支持 HTTP 让 Azure Functions 成为软件即服务应用发送的“网勾（webhook）”消息的理想接收者。

微软为 Azure Functions 提供了两种托管选项：传统的“应用服务（App Service）”方案或新推出的“动态服务（Dynamic Service）”方案。这个选择会影响到扩展性和成本。在应用服务方案中，Azure Function 运行在专用的虚拟机上，Function 可能会同其他运行在用户账户下的应用共享服务器。如果选择了动态服务方案，那么Azure Function 会跨多个应用实例并行运行，而且这些实例可以根据使用情况自动缩放。在这个方案中，用户只需为实例的执行时间付费，而应用服务方案的用户需要为托管的虚拟机付费，不管使用情况如何。

开发人员可以从起始模板或者从头开始创建这些单一用途的函数。微软提供了一个基于Web 的开发环境，并且还提供了Git 端点，允许开发人员使用GitHub、Bitbucket、Visual Studio Team Services、 Dropbox 等进行本地开发及持续集成。这个基于Web 的IDE 提供了特定于语言的语法格式化、代码补全提示以及一些基本的测试工具。在函数的应用设置中，用户可以指定Azure Functions 可以使用的内存量（最大1536MB），是否应用用户身份验证以及如何暴露服务元数据。

基于像应用服务和 WebJobs 这样的已有 Azure 服务，微软用 90 天构建出了 Azure Functions。按照微软的说法，简洁是关键。他们引入了一个名为“绑定（bindings）”的特性，实现了 Azure Function 代码同数据源或目的地的分离。

借助 Functions 绑定，开发人员可以通过他们的 Function 很轻松地同其他数据源和服务进行交互，而不必考虑数据如何流入及流出一个 Function。绑定让类似向队列添加一条消息或者获取一个 Blob 的任务同向 Function 输出变量传递一个 JSON 或者从 Function 输入变量读取一个 Blob 一样简单。使用这项功能，开发人员需要对他们与之交互的底层服务有一点了解，以便后续可以简单地切换到一个不同的服务。

微软并不是第一个引入无服务器计算模型的。虽然该服务听上去与传统的平台即服务（PaaS）产品有点类似，但微软声称，Azure Functions 通过提供基于执行的计费和基于需要的实例缩放扩展了 PaaS 的概念。Azure Functions 更像 AWS Lambda 、 Google Cloud Functions 、 IBM Bluemix OpenWhisk 、 Auth0 WebTask 这样的产品。

Azure Functions 在许多方面都不同于 AWS Lambda，包括一个开源的运行时、更广泛的语言支持及没有执行时间限制。技术专家兼 AWS Lambda 用户 Tom Maiaroto 在一篇博文中比较了这两个服务，他认为，“Azure Functions 的底层结构与 Lambda 有很大的不同”。

一个“应用服务”是一个容器或环境，可以运行一组 Azure 云函数。这与 Lambda 有很大的不同。实际上，这两个服务是截然不同的。

Lambdas 是单独组织的，而 ACF 在逻辑上分组成“应用程序”。

…

Azure 更像是 [EC2 Container Service]Tasks 和 Lambda 的混合。例如，你可以在应用服务上设置环境变量，然后在 ACF 中使用。AWS Lambda 无法持久化环境变量，但 ECS Tasks 可以。

整个的容器架构不同。Lambdas 会根据一个“冷请求（cold request）”准备一个全新的容器，并（从 zip 文件）部署代码。后续请求可以受益于容器重用，处理速度更快。不过，你需要了解的是，它没有提供持久化，而且，使用 Node.js Lambdas 时需要注意变量作用域，因为容器会被重用。

不过，ACF 受冷 / 暖请求的影响较小。Azure 仍会按需准备资源，但文件不会“冻结”到存储在某个地方的 zip 文件中。它们在 Azure 的 WebJobs 上运行。

…

如果启用，那么每个函数都会自动映射到一个 HTTP 端点。然而，使用 Lambda，你必须分别配置 API 网关。API 网关很好，但非常复杂耗时。此外，某些无服务器框架通过自动为 Lambdas 设置 API 来缓解这个痛点。微软在 UX 方面得分了，因为你需要配置的东西少很多。

Azure Functions在预览期间是免费的，但之后微软会根据计算利用率和每百万请求收费。 UX 已经在 GitHub 上开源， WebJobs SDK 也是。接下来，微软表示，他们将致力于支持更多的语言、本地开发选项及集成其他微软服务，如Azure 服务总线。

查看英文原文： Microsoft Gets into Serverless Apps with Azure Functions