各大Serverless架构提供商的较量

【51CTO.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，并按需扩缩容。

• 更快的开发和部署。区别于整体(monolith)结构的构建方式，FaaS提供了更灵活的替代方案。开发人员可以编写一组，由不同功能函数所组成的代码，而不是将整体应用的代码上传到服务器上。因此，这使得整个结构更易于调试、更新和添加新的功能。
• 减少人力资源的支出。企业不必雇用DevOps工程师来进行运维，当然也不必购买特定的硬件。
• 高可用性和自动扩展。只有在客户端发出请求时，功能函数才会被激活并运行，而在不需要的时候，它们处于关闭状态。同时，随着流量的增长，FaaS能够自动扩展，它们通过为特定功能函数分配更多的资源，以实现高可用性，和在高负载下的平稳性能。
• 专注于业务需求。通过让开发人员从服务器端(server-side)的工作抽象出来，您的团队会更专注于应用的业务逻辑。

无服务器架构提供商概述

这两年，随着新玩家持续的入局，无服务器架构提供商的名录在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 就是一款能够专门用来计算，目标应用在四大无服务器架构提供平台上成本开销的工具，不过它目前仍处于测试阶段。当然，上述各大提供商也有着自己的计算工具：

• AWS Lambda S3计算器
• Azure Functions计算器
• GCF计算器
• IBMCloud Functions 计算器

如上图所示，大多数提供商的价格体系基本相同，但由于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服务的分布式跟踪系统。不过，它的主要用途是监控微服务类型的应用，而不是功能函数。下面是一些针对无服务器应用监视的第三方工具：

• Dashbird 是一项免费的AWS监控服务，提供CloudWatch之外的功能，并有着更加友好的用户界面。
• OpenTracing 是一种独立于提供商的监控服务，而并非工具。OpenTracing支持9种语言，包括：Go、JavaScript、Java、Python、 Ruby 、PHP、Objective-C、C++和C#。
• Thundra 聚焦于JavaScript，能够与AWS X-Ray相集成，并在其基础上呈现监控和日志记录。

其他备选考虑

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

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

• IronFunctions 是一款开源的无服务器计算平台，它同时支持私有、共有和混合云。其背后的理念是：为开发人员提供可在任何地方运行的无服务器平台。IronFunctions使用的是 Go 语言，这在其他无服务器选项中并不常见。
• Oracle Fn Project 也是一款开源的无服务器平台，它原生于容器化(containerization)、且独立于语言和云环境。与IronFunctions类似，Fn Project也可被用于私有、共有和混合云。
• Kubeless 是由Kubernetes提供的容器驱动的原生无服务器架构。它能被用于自动化容器化应用的部署、管理和扩展。
• Firebase 是移动应用开发的后端平台，由Google提供托管架构。它能够与Google的其他云服务顺利集成，当然也最适合于Google的产品。
• Webtask 是一款完全免费的FaaS平台。它最适合于不需要繁重后端的移动应用，并能支持各种集成方案。

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

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

【责任编辑：庞桂玉 TEL：（010）68476606】