各大Serverless架构提供商的六项服务较量

发布时间：2025-11-04 19:49:43 来源：创站工坊 作者：数据库

【.com快译】根据RightScale云服务状况报告2018版(请详见：https://www.rightscale.com/lp/state-of-the-cloud)显示，架构无服务器(Serverless)架构的提供市场渗透率已增至75%。而且，项服这个市场里的架构玩家，已不再局限于AWS Lambda或Azure Functions等主流提供商。提供不过，项服在面对众多云服务提供商，架构并需要将现有服务迁移到某个无服务器架构之前，提供您是项服否真正了解他们的不同之处?下面让我们一起来深入探究一番。

无服务器架构的架构发展历史

近十多年来，随着云技术在商业中的提供广泛采用，整个市场也得到了迅速发展。项服我们可以看到，架构每年都有新的提供应用开发方法的出现。从逻辑层面来看：那些使用IaaS(基础设施即服务)的项服企业，主要是通过租用服务器资源，来将其基础设施迁移到云端。但是他们的IT团队仍然需要去动手设置各种服务器。而随着PaaS(平台即服务)的出现，IT团队逐渐摆脱了对服务器的手动操作。源码下载PaaS提供商能够提供更为完整的应用程序栈，包括：由提供商所管理的、运行在云中的操作系统和数据库等。

如上图所示，IaaS也属于另一种后端即服务(Backend-as-a-Service，BaaS)的云服务部署与开发模式。

2014年，一种新的应用程序开发方法：无服务器架构，或称FaaS(功能即服务，Function-as-a-Service)出现了。简而言之，FaaS是一种无服务器的计算形式，它使用的是完全由提供商托管的基础架构，供用户上传和运行他们的功能函数，并按请求付费(pay-per-request)。

与其他云计算方法不同的是，无服务器架构让开发人员完全从服务器中抽象出来，使得他们能够专注于业务的逻辑。如果您想更深入地了解FaaS的免费源码下载相关概念，以及无服务器架构的优缺点，请阅读：https://www.altexsoft.com/blog/cloud/pros-and-cons-of-serverless-architecture/?utm_source=DZone&utm_medium=referral。

无服务器架构的好处

话说回来，尽管无服务器架构已广受欢迎，但是它不一定对每一家公司、每一类产品都合适。在此，我们首先来看看无服务器架构的整体优势。当然，由于服务提供商的不同(如开源或是公有云)，各家的优势也可能略有不同。

u 降低成本和具有可扩展性。如前所述，与传统方法相比，无服务器架构降低了服务器运营和维护的成本。而与其他类型的云计算服务相比，大多数FaaS提供商都能够贯彻按请求付费的定价机制。这就意味着您只需要为调用功能函数的时间和次数买单。此外，您还可以灵活地为功能函数分配一定数量的内存和CPU，企商汇并按需扩缩容。

无服务器架构提供商概述

这两年，随着新玩家持续的入局，无服务器架构提供商的名录在2018年也扩充了不少。我们将这些提供商分为主流和备选两大类。主流类一般是在共有云上提供无服务器架构。下面，我们将对各大主流与备选提供商进行介绍与比较。

AWS Lambda

Amazon Web Services于2014年推出了此类FaaS产品。自发布以来，Lambda已经成为了无服务器架构的代名词。凭借着最广泛的服务类别，Lambda一直保持着市场的领先地位。其***的案例，莫过于Netflix的无服务器公有云应用。

Microsoft的Azure Functions

作为AWS Lambda竞争对手，该服务于2016年被推出。Azure Functions提供了一组与Amazon类似的服务，它更关注于Microsoft体系产品的语言和工具。Azure Functions的一个案例是Have I Been Pwned。如果您对Azure上的应用程序结构、及其执行方式感兴趣的话，您可以通过https://www.troyhunt.com/how-did-have-i-been-pwned-perform-on/，来查看有关该案例的分析和费用详情。

Google Cloud Functions(GCF)

作为四巨头之一，Google直到2017年才发布了其解决方案。虽然GCF的起步晚于Azure和Lambda，但是Google在2018年奋起直追，它解决了各种早期错误，并在其官网上进行了公示。

IBM Cloud Functions

作为无服务器领域的新手，IBM凭借着一系列具有竞争力的服务打入到了该市场。IBM Cloud Functions是Apache OpenWhisk在其云服务中唯一使用到的托管​​式架构方案。当然，如果您更偏好开源方案的话，那么Apache OpenWhisk可能更合适于您。

总的说来，上面提到的各大提供商都能够提供相似的服务，也都能够在托管式架构上运行各种应用。虽然表现形式各有不同，但是它们都能给用户带来FaaS的各种优势。为了帮助您找出最适合于自己提供商，我们将从如下六个方面深入比较它们的服务：

主流FaaS提供商的比较

定价模型和计费因素

如前所述，大多数FaaS提供商使用的是非常划算的按请求付费的定价模型。为了能够计算出某个应用的成本，他们通过各种服务来精准地预测出该应用的潜在费用。例如：Serverlesscalc就是一款能够专门用来计算，目标应用在四大无服务器架构提供平台上成本开销的工具，不过它目前仍处于测试阶段。当然，上述各大提供商也有着自己的计算工具：

如上图所示，大多数提供商的价格体系基本相同，但由于Google对内存与CPU的使用单独计费，因此它是其中最贵的。具体说来：

AWS Lambda提供一种免费套餐，它包括：每月100万个请求和每秒400,000 GB的计算时间(computing time)。而对于超出免费套餐限额的所有请求，均按照0.00001667美元每GB每秒收费，这是市场上的***价格。在实际操作中，免费套餐完全足够您在开始被计费之前完成自己应用的调试。那些分配给用户的资源(内存和CPU)将被视为一个整体单元进行计费，毕竟它们都是等比例增长的。如果您在自己的Lambda功能函数中使用到了其他的AWS服务，那么就可能会产生额外的费用。

Azure的计费方式与Lambda相同，也提供免费的套餐。不过对于超出部分，它按照0.000016美元每GB每秒收费。可见，Azure平台的重负载成本略低于Lambda，而平均负载则与Lambda相同。不过，Microsoft更希望对内存的使用量进行计费，而不是简单地一次性分配给用户。另外，对于用户可能用到Windows和SQL，Azure也提供了较低的价格。

可见，对于上述两个平台的选择，实际上取决于您所使用的环境，而非您所承担的成本。

GCF的免费套餐为：每月200万个请求和每秒400,000 GB的计算时间。而对于超出免费套餐限额的所有请求，均按照0.0000004美元每GB每秒收费，包括网络流量。因此，对于那些运行耗时的功能函数或请求量大的应用来说，Google Cloud Functions的费用明显更高。上面也提到过，GCF会对分配给用户的内存和CPU进行分别计费。

IBM拥有与Lambda及Azure相同的免费套餐，而对于超出免费套餐限额的所有请求，均按照0.000017美元每GB每秒收费。在计费方面，IBM OpenWhisk会记录功能函数处于活动状态时所消费的资源。

总而言之，AWS Lambda的定价适中;Azure的费用取决于所使用的CPU和内存;而对于Windows环境来说，Azure提供了***的价位。

支持的编程语言

为了让用户可以在托管的环境中运行自己的应用，FaaS提供商往往会在它们所提供的共有云环境里支持多种语言。

Lambda涵盖了广泛的编程语言，其中包括：Node.js runtime、Python、Java和其他编译语言、以及.net语言(C#、Visual Basic和F#)。

Azure Functions显然将重点放在了Microsoft的语言系列上，包括：Node.js runtime、C#、F#、Python、PHP、Bash、Batch和PowerShell、以及编译JavaScript语言。

Google Cloud Functions过去只支持JavaScript，如今它已宣布正在测试支持许多其他的语言。不过就目前而言，GCF看起来并不是一个非常可靠的选择。

IBM目前支持Node.js runtime、Swift、Java、PHP和Python。同时，它可以与任何带有Docker容器的编程语言相集成。

上图便是四大提供商所支持的语言列表。目前，GCF的支持类型最为有限。

功能函数触发类型

主流提供商都能够提供用于调用功能函数的，可配置的动态触发器类型。它们支持按需调用分别调度函数，并与其他云服务相集成。您可以在不同提供商的用户文档中找到相关的详细信息。

Lambda和Azure通过API提供已配置的触发器类型。其中，AWS使用API网关作为API触发器，通过Amazon S3作为基于文件的触发器，以及通过DynamoDB来执行动态触发。而Azure则建议使用其他的Microsoft服务、Azure事件中心和Azure存储，来实现Web API触发和计划性调用。

GCF服务在其文档中提供了各种能够支持的触发器列表。GCF触发器类型的主要功能是：让用户的应用能与任何Google服务相集成，进而支持cloud Pub/Sub与各种HTTP回调。

IBM虽然并没有在触发方面与太多的第三方服务相集成，但是它仍然能够支持许多常见的触发器类型，包括：基于浏览器的HTTP工具调用、以及计划性的触发。

因此，若是要根据触发方法来选择提供商的话，Azure与Lambda应该是***选择，而如果您需要通过Google服务来触发某些功能函数的话，也可以选择GCF。

执行时间(Execution Time)和并发数

与功能函数调用相关的另一个重要方面是：执行时间和并发数。此处并发数表示在一段时间内并行执行不同功能函数的数量。

如上图所示，Google具有***并发数，而AWS Lambda却有着最长执行时间。

Lambda的并发数为1,000个，其最长执行时间为15分钟。用户既可以为整个帐户，也能够为单个功能函数配置并发数。

Azure为单个应用提供了***的并发率，但是单个功能函数的最长执行时间被限制为5分钟。如果用户需要长达10分钟则需要进行升级。

GCF只允许对HTTP触发器类型进行***次的调用。而对于其他触发方法，其并发数与Lambda相同，也是一次只能执行1,000个。它将单个功能函数的执行时间限制为60秒，在升级后可达9分钟。值得一提的是：AWS Lambda计算的是单个帐户的并发数，而GCF统计的是项目中的并发数。这意味着：在AWS上，您只能运行一个具有1,000个并发量的调用函数，而在GCF上，您可以使用同一个并发来运行多个功能函数。

IBM对于单个功能函数的调用并不限制时间，但它的并发率并不清楚，当然也不作保证。

因此，如果您希望功能函数的性能平稳，则选择Lambda、GCF和Azure皆可。如果您注重长时间的调用，那么Lambda和IBM将是更好的选择。

部署方法

各大提供商的部署方法似乎没有什么区别。在无服务器框架的部署中，开发人员通常会使用serverless.yml来配置功能函数，然后将函数的代码打包到Zip文件中，进而推送到服务器上。

Lambda能够更新用户应用中的每一个单独的功能函数;而Azure、GCF和IBM服务则倾向于通过插件来解析serverless.yml，当然它们上传各种资源的顺序也略有不同。

监控和记录

由于所有的架构都是由提供商进行管理的，因此为了获悉应用程序的状态和参数指标，它们需要为每一项服务提供监控和日志记录的工具。籍此，用户也能够概览到资源的使用与分配、出现的错误、以及相应的监视日志等方面。

Amazon自家的Lambda服务工具 – CloudWatch，能够观察功能函数的调用与日志。但是，由于CloudWatch是一项付费的服务，因此也受到了一些批评​。其他主流提供商的类似服务包括：Microsoft Monitor、Google Stackdriver、以及IBM logging and monitoring。

Amazon的另一项服务X-Ray，是一种监控多种AWS服务的分布式跟踪系统。不过，它的主要用途是监控微服务类型的应用，而不是功能函数。下面是一些针对无服务器应用监视的第三方工具：

其他备选考虑

如上所述，四大主流无服务器架构提供商都能提供“势均力敌”的基础服务。只是AWS Lambda和Azure Functions更为完整和多元化一些。因此您在选择时，更多地取决于所用到的环境、对于编程语言和社区的支持要求。

如果您不想被上述主流共有云提供商的框架所“绑架”，需要对自己的产品具有更多控制的话，可以考虑如下开源的无服务器框架：

原文标题：Comparing Serverless Architecture Providers: AWS, Azure, Google, IBM, and Other FaaS Vendors，作者：Ihor Lobastov

【译稿，合作站点转载请注明原文译者和出处为.com】

相关文章