Azure Functions 是 Azure App Service 系列的最新成员之一，它为开发人员提供了一个简化的编程模型。

为了开发 Azure 函数，我们必须做的就是编写代码来响应我们感兴趣的事件，无论是 HTTP 请求还是队列消息。我们将要编写的所有代码都将这些事件与处理它们的代码联系起来，并从我们这里抽象出来(由框架处理)。

正如我们将很快看到的，这提供了一个非常轻量级的开发平台，特别适合快速开发风格，在这种风格中，您只需专注于满足业务需求的代码，从而消除了大量开销。

与虚拟机或网络应用相比，Azure Functions 的另一个巨大优势是，不需要至少有一台专用服务器持续运行。相反，你只在你的函数运行时才付费。如果你的函数正在监听一个队列，并且没有消息到达，你就不需要支付任何费用。这不是很棒吗？

Azure Functions 将自动扩展运行您的功能的服务器数量，以满足需求。如果没有需求，那么可能没有运行您的代码的服务器。然而，当需要时，框架可以非常快速地启动一个。

因此，现收现付的定价模式可以大幅节省成本。

微软越来越多地使用“无服务器”这个术语来营销像 Azure Functions 这样的服务。在过去的几年里，这个术语开始流行，你可以发现许多云供应商都在使用它。

从某种意义上来说，这个术语并不真正准确——当然，运行 Azure Functions 框架需要服务器以及在其上运行的代码。然而，无服务器背后的一个关键思想是，您基本上将服务器的整体管理和维护委托给第三方提供商，在本例中是微软 Azure，这样您就可以专注于业务需求。

在典型的无服务器架构中，您会选择依赖第三方平台或后端服务，例如，使用 Azure Cosmos DB 作为您的 NoSQL 云数据库，而不是创建自己的虚拟机并在其上安装数据库服务器。

无服务器架构的伟大之处在于，越来越多的第三方服务满足了现代云应用的许多共同需求，无论是记录日志、发送电子邮件、执行文档全文搜索还是接受在线支付。

这些第三方服务不能独立完成所有事情，因此需要编写一些自己的后端代码。这就是像 Azure Functions 这样的服务非常适合无服务器的地方。

您只需告诉 Azure Functions 您需要响应哪些事件，以及当这些事件被触发时您想要做什么，然后让框架担心您需要多少台服务器，而不是提供一台完整的服务器来运行网站或托管一些后台进程。这个轻量级模型也被称为功能即服务(FaaS)。

需要注意的是，Azure Functions 本身并不是一个无服务器框架，但是它实现了无服务器的 FaaS 部分。因此，它可以与其他云产品和服务结合使用，以创建完整的无服务器体系结构。

让我们考虑一个非常简单的现实例子。

前一段时间，我需要创建一个相对简单的网站来销售我制作的一个名为 Pluglock 的软件实用程序。

这个工具背后的整个想法是，它将使用您的笔记本电脑电源线作为安全设备。如果实用程序在安全模式下运行，并且电源线被拔下，该工具将发出警报，阻止音量，锁定会话，并阻止除授权的 Windows 用户之外的任何人重新登录。授权用户重新登录后，计算机将恢复到“安全”状态，关闭警报，让用户再次工作。

我为自己创建了这个工具，因为我过去经常旅行，每次我在机场需要去厕所时，我都不得不打包笔记本电脑并随身携带，这很烦人。所以我对自己说，为什么不创造一个工具，可以在我上厕所的时候保护我的笔记本电脑，让它插上电源呢？

想象一下，一个想拔掉我笔记本电脑插头的人会遇到什么样的意外，然后暴露在所有人的眼前，被满音量的警报提醒——对那个人来说，这不是一个愉快的场景！

该网站只是静态的 HTML，它有一个与支付提供商集成的购买按钮(从技术上讲，这并不复杂)。

然而，每当有人购买工具时，我也需要处理来自支付提供商的 webhook 回调。因此，我所做的是向我的服务器添加一个 web 方法 API 来处理这个问题，它需要生成一个许可证文件并发送一封电子邮件，以便向客户提供该信息。

这需要 web 服务器将消息发布到队列中。然后，我需要添加能够监听这些队列的代码，这些队列最终也会出现在 web 服务器上。这导致越来越多的代码被添加到 web 服务器。

此外，该工具还允许用户选择加入并报告某些事情，例如位置和跟踪信息(IP 地址、纬度和经度)。这称为网络挂钩，它还需要检查许可证是否有效。

最后，一个通宵运行的过程会总结所有的活动，并通过电子邮件向我发送一份详细的报告。

因此，最初是一个非常简单的带有“购买”按钮的网站，现在已经发展成为一个成熟的后端网络应用，承担了很多责任。

曾经有一段时间，我在考虑从静态 HTML 转移到类似 WordPress 的东西，这将使网站内容的编辑更加容易。然而，很快很明显，不可能将其迁移到 WordPress，因为已经有太多后端了。NET 代码，这需要用 PHP 完全重写，这样 WordPress 就能支持我开发的相同功能。

这种类型的场景对于许多开发人员来说可能听起来非常熟悉——最终一台服务器作为一个整体做所有的事情，这是难以置信的难以扩展。

下图代表了我刚才描述的过程。

图 1-a:单片架构

在我刚才描述的真实例子中，我们见证了所谓的单片 架构—这显然根本不能很好地扩展。

让我们看看无服务器架构和 Azure 函数如何帮助我们。我们所能做的就是将我们整体架构的部分或大部分分解成更小的部分。

假设新购买的 webhook 将由一个将消息发布到队列中的 Azure 函数处理，然后该消息将由另一个生成许可证文件并将其放入 blob 的函数处理。

然后，该 blob 为另一个 Azure 函数创建触发器，该函数通过电子邮件将许可证发送给客户。正如您可能已经猜到的，报告 webhook 是另一个将行写入 Azure Table 存储的 Azure 函数。

许可证验证应用编程接口是另一个 Azure 函数，它执行数据库查找，以及生成报告的夜间过程。

我们仍然有我们的网络服务器，它甚至可以被 blob 存储中托管的一些静态内容所取代。然而，我们已经设法将我们的单体架构分解成一组松散耦合的功能，您甚至可以将其视为纳米服务。

这些功能可以被很好地打包到一个单独的 Azure Functions 应用中，假设它们属于一起并共享配置设置和本地资源。

下面是我们使用 Azure 函数的整体架构。

图 1-b:使用 Azure 函数的无服务器架构

如您所见，这比我们之前描述的单块要容易得多，因为流程中的每个步骤都是一个独立的 Azure 函数。

既然我们已经看到了使用 Azure Functions 如何简化应用的体系结构，那么 Azure Functions 和无服务器对什么样的应用有好处呢？

Azure Functions 不一定适合所有场景，但它很有意义，并在特定情况下增加了价值，例如:

• 实验和快速原型:由于使用 Azure Functions 只需要几分钟就可以启动并运行，因此很有可能很快就有一个完整功能原型的后端。
• 自动化开发流程:使用 Azure Functions 是一种非常便捷的方式，可以自动化您的一些内部开发流程。一个很好的例子是，许多软件团队使用 Slack 进行通信，将它与您的构建服务器集成可能会很方便，以便在构建发生错误或异常时可以向团队成员发送通知。考虑到 Slack 拥有丰富的生态系统和可扩展性模型，您只需要一个它可以调用的 webhook 来将其与 Azure Functions 集成。
• 分解和扩展应用:就像我们之前看到的，Azure Functions 是简化单片系统的理想之选。
• 独立缩放:如果你有很多队列处理程序，都需要不同的缩放需求，那么 Azure Functions 是很棒的。如果您自己管理所有服务器，那么这可能会突然变成一个令人头痛的问题。但是，如果您正在使用 Azure 函数，您只需将这个问题交给框架，让它为您解决问题。
• 集成系统:Azure Functions 最激动人心、最有用的特性之一，就是集成各种系统的能力。有时，您可能需要创建一个中间适配器，将两个系统连接在一起——例如，推特和 Dropbox。使用 Azure 函数是一个很好的方法。
• 变得无服务器:最后，这一切都是为了不用担心管理服务器和基础设施，所以使用一系列松散耦合的 Azure 函数一起通信是简化后端的好方法。

通过解释 Azure Functions 的基本方面并提供无服务器架构的概述，我们已经在这一快速入门章节中介绍了一些基础知识。

无服务器描述了一种编程风格，在这种风格中，服务器、扩展甚至事件的连接都是为您透明管理的，因此您可以专注于编写解决业务需求所需的代码。

Azure 函数只不过是一小段响应事件的代码，所以换句话说: Azure 函数=事件+代码。

Azure 功能框架建立在其他坚实的 Azure 产品之上，如 Azure 网络应用和网络作业。

Azure Functions 的一大优点是它的灵活性——它不会强迫你在无服务器架构上全力以赴。相反，它可以和更传统的体系结构一起使用——我们不要忘记快速原型制作的能力。

在下一章中，我们将创建我们的第一个函数应用，这将允许我们将各种 Azure 函数组合在一起，并直接进入代码。终于，有些乐趣了！