什么是无服务器计算?

无服务器计算是一种新的基于云的计算形式,类似于在云提供商上运行的 VM 和容器。虽然这并不意味着没有服务器,但服务器的管理、扩展和容量规划由底层云提供商负责。应用程序开发人员只需要关注功能和业务逻辑。

越来越多的开发人员正在为下一代应用程序和 API 采用无服务器技术。无服务器的采用速度已经比 Docker 和容器快 10 倍。本文将提供有关无服务器生态系统以及不同提供商和框架之间差异的一些信息。

微服务入门

在无服务器计算之前,许多企业采用了微服务,这是一种面向服务的架构 (SOA)。微服务使应用程序能够被组织为通过 API 连接在一起的松散耦合服务的集合。每个服务都是在自己的进程/容器/VM 中完全独立的迷你应用程序。主要好处是我们在计算机科学 101 中学到的:模块化和关注点分离。微服务_可以_使复杂的应用程序更容易在大公司中开发和扩展。应用程序可以轻松地跨职能团队划分,每个团队负责单个微服务或一组微服务。代码库可以保持较小并且构建较短,以便快速迭代开发。应用程序的各个部分可以独立于其他微服务进行扩展。

然而,随着微服务的出现,基础设施和运营工作大大增加。突然间,需要跟踪更多的持续集成/持续交付管道。需要考虑服务的每个版本或变体的互操作性以及它依赖的其他服务。有复杂的编排来管理更多移动的部分。日志记录上下文现在分散在许多单独的进程中。更多的负担放在集成测试上。事实上,像 Basecamp这样的公司争辩说,为什么单体架构对某些小公司(如初创公司)有意义。

迈向无服务器

无服务器计算正在将微服务发挥到极致。基础设施、编排层和部署被移除。仍然有服务器和虚拟机,但它们完全由云提供商管理。作为应用程序开发人员,您只需编写业务逻辑和功能,其余的交给 AWS 或 Azure。

无服务器计算还可以降低您的计算成本。虽然大多数云提供商会按小时收费来预留 VM,但无服务器计算可以使用基于消费的定价模型。如果应用程序没有主动使用计算或内存资源,则无需付费。

无服务器计算提供商

云计算供应商正在推动这一领域的大量创新。下面的比较集中在三个方面:构建(支持的语言)、部署(易于设置和管理)和触发器(触发功能)。

AWS Lambda

AWS lambda 是 2014 年推出的首批无服务器计算产品之一。

AWS Lambda 原生支持多种语言,包括 Node.js、Python、Java 和 C# (.NET Core)。通过从 AWS Lambda 沙盒中允许的一种受支持语言生成子进程,可以支持其他语言。 AWS 沙盒隔离不依赖于任何允许这种灵活性的语言结构。

可以使用 AWS 的嵌入式编辑器在线完成开发。但是,一旦您需要为代码添加依赖项才能运行,您需要在本地计算机上进行开发并上传包含您的代码以及任何依赖项的包。如果您开发 Node 函数,AWS Lambda 将不会运行npm install。部署需要创建和上传部署包以将代码和依赖项捆绑在一起。

AWS 将 AWS Lambda 定位在 AWS 的前端和中心,而不仅仅是一个附加的产品,提供非常多的 AWS 服务,可以作为一键式触发器为使用 Lambda 提供很大的灵活性。如果您正在开发 API,可以使用非常流行的 AWS API Gateway 触发器。 API Gateway 使您能够将针对 RESTful API 端点(例如GET /items/{id})的 HTTP 请求映射到 AWS lambda 函数getItem(event, context, callback) { }。在 REST API 之外,AWS 为从事件流的 Amazon Kinesis(类似于 Kafka)到 DynamoDB 或 S3 中的更新的所有内容提供触发器甚至可以从 Alexa 技能应用程序触发。事实上,AWS 正在推动 AWS Lambda 作为开发新 Alexa Skills 的主要方式。

Azure 函数

在 AWS 之后不久,Azure 进入了无服务器领域,并在 2016 年年中推出了 Azure Functions。与 AWS 相比,Azure 支持更广泛的语言。除了 Node.js、C# 和 Python,Azure 还支持 F#、PHP、Bash 和 PowerShell。 2017 年 10 月 4 日,Azure 宣布他们将在旧金山举行的 JavaOne 大会期间支持 Java。此外,他们的逻辑应用程序和流使非开发人员能够为业务流程设置自己的逻辑,就像 Zapier 如何连接多个业务工具一样。

Azure 提供了一个类似于 AWS 的在线编辑器。但是,Azure 的编辑器是基于 Visual Studio Online 构建的。与 AWS 和 Google 不同,Azure 围绕部署提供了更多基础设施。您可以从 Visual Studio Team Services、Bitbucket 和 Github 中的源设置持续构建和部署部署。

在架构上,Azure Functions 与 AWS Lambda 有很大不同,因为 Azure Functions 的许多基础设施都来自 Azure App Service 和 App Service Plans。 Azure 函数在逻辑上分组到称为 _App 服务的应用程序容器或环境中。_应用服务中的所有 Azure Functions 共享相同的资源,例如计算或内存。这还可以部署应用程序而不是单个功能。您可以将 Azure 函数视为 AWS Lambda 和更传统的 Azure Web 应用程序/AWS Elastic Beanstalk 类环境之间的混合体。

与 AWS 不同,更多 HTTP 触发器功能是在 Azure Functions 中本地构建的,无需设置单独的 API 网关。这在很大程度上与 Azure 在应用服务容器下的逻辑分组功能有关。 Azure 支持各种其他触发器。此类触发器可能包括 Azure Blob 存储、Azure 事件中心和队列。

谷歌云函数

相对于 Azure 和 AWS,Google Cloud Functions 在语言方面的限制最大,因为它们只支持 Node.js。不幸的是,相对于 AWS 和 Azure,Google Cloud 功能似乎是最不发达的。部分原因不是谷歌云功能,而是谷歌在谷歌云中可以作为触发器的产品数量最少。 AWS 有 Kinesis,Azure 有 EventHubs,但谷歌没有类似的产品可以充当跳跳虎。与 AWS 不同,谷歌并没有将云功能推向前沿和中心。 Google 的内部开发更多地依赖于 Kubernetes (Borg) 等工具,而不是 Cloud Functions。

从积极的方面来说,谷歌允许在进程被终止之前最多执行 9 分钟。 Google is Google 还有一个单独的产品 Cloud Function for Firebase,如果您是已经依赖 Firebase 的移动应用初创公司,它可能会很有用。 Firebase 使您能够从 Firebase Db 中的更新中生成新的 Cloud Function。与 AWS 不同,Google 直接在 Cloud Functions 中集成了 HTTP 功能,无需设置单独的 API 网关。

对于部署,您可以上传 zip 文件或从 Google 存储库进行部署。

独立无服务器框架

由于无服务器计算是由云提供商进行大量管理的服务,因此存在大量锁定。触发器实现特定于每个提供商,因此您不会在 Google 或 Azure 上找到相同的 AWS Kinesis 触发器。除了不同的触发器之外,传入的上下文和顶级函数签名也不同,具体取决于使用 AWS Lambda、Google Cloud Functions 和 Azure Functions。

虽然锁定的可能性很高,但您可以通过利用可以转换各种服务的供应商中立垫片来缓解这种情况。此类供应商中立 shim 允许您以与 Azure EventHubs 类似的方式使用 AWS Kinesis。此外,无服务器的非常常见的 HTTP API 可以完全开放和透明。

有独立的开源框架可以做到这一点。此外,它们标准化了部署并规范了供应商特定的上下文对象,供您访问。

有很多框架会根据您的需求而有所不同。一些受欢迎的包括:

• 无服务器

• 库贝利斯

• 裂变

• 功能

监控挑战

无服务器计算面临的日益严峻的挑战之一是监控和调试所有这些功能。日志上下文现在分散在比微服务架构中更多的组件中。可能的日志是非常特定于供应商的,不像查看标准 NGINX 或 HaProxy 日志。

此外,很难在本地镜像和运行函数以在同一环境中进行调试。包含尽可能多的上下文以通过故障场景进行调试而不仅仅是在本地重现问题,这一点至关重要。有时您无法从云供应商的环境中重现问题。

在Moesif,我们正在努力提供对此类无服务器函数调用的可见性,并且已经为 AWS Lambda 提供了具有不同触发器的 SDK,例如Moesif 的 API Gateway Lambda 中间件和Moesif 的 Alexa 技能套件 Lambda 中间件.