各大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年也扩充了不少。我们将这些提供商分为主流和备选两大类。主流类一般是在共有云上提供无服务器架构。下面，我们将对各大主流与备选提供商进行介绍与比较。
Amazon Web Services于2014年推出了此类FaaS产品。自发布以来，Lambda已经成为了无服务器架构的代名词。凭借着最广泛的服务类别，Lambda一直保持着市场的领先地位。其***的案例，莫过于Netflix的无服务器公有云应用。
作为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直到2017年才发布了其解决方案。虽然GCF的起步晚于Azure和Lambda，但是Google在2018年奋起直追，它解决了各种早期错误，并在其官网上进行了公示。
作为无服务器领域的新手，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服务的分布式跟踪系统。不过，它的主要用途是监控微服务类型的应用，而不是功能函数。下面是一些针对无服务器应用监视的第三方工具：
- 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更为完整和多元化一些。因此您在选择时，更多地取决于所用到的环境、对于编程语言和社区的支持要求。