【原创】   2021-08-05 17:55:49

关键字： FaaS 选型 Serverless

这么多Serverless 平台，我们到底该如何选择？其实与一切软件架构选择难题一样，问题的答案还是跟具体的需求密切相关。

在云端以24/7全天候方式全容量运行服务器十分浪费资源，所以只要可能，企业当然希望能在不需要时关停大部分容量。如果以合乎逻辑的思路来推断，那么更好的方案应该是在必要时按需启动服务器，而且只根据负载需求提供对应的容量资源。

这就是Serverless，即无服务器计算的施展空间了。无服务器计算是一种云执行模型，云服务商会在模型当中根据执行特定代码段所需要的计算资源与存储进行动态资源分配和计费。

换句话说，无服务器计算是一种按需且即用即付的后端计算形式。当请求进入无服务器端点时，后端要么重用已经包含正确代码的既有端点、要么从资源池中分配并自定义资源，或者实例化并自定义新端点。基础设施通常会根据需求运行尽可能多个实例以处理传入请求，并在一段时间的冷却期后释放掉全部闲置实例。

其实，Serverless也要使用服务器，只是用户无需承担服务器管理工作。运行无服务器代码的容器或其他资源通常运行在云端，但也可以运行在指定的边缘点位置。函数即服务（FaaS）是对各类无服务器架构的基本总结。在FaaS中，用户为一条函数编写代码，基础设施则负责提供必要的运行时环境、加载与运行代码并控制运行时生命周期。FaaS模块能够与Webhook、HTTP请求、流、存储桶、数据库以及其他构建单元顺畅集成，共同建立起无服务器应用程序。

下面我们来看几种流行的无服务器计算平台，希望能对企业的平台选型提供一定帮助。

平台一 AWS Lambda与其他相关服务

AWS Lambda是一种常见的FaaS解决方案。除AWS Lambda之外，亚马逊云科技目前提供十余种无服务器产品。诞生于2014年的AWS Lambda并非全球首例FaaS服务，在它之前还有2006年的Zimki、2008年的Google App Engine以及2010年的PiCloud。

AWS Lambda支持以Python、Node.js、Ruby、Java、C#、PowerShell以及Go等语言编写的无状态函数代码。Lambda函数在运行之后即可响应事件，例如对象被上传至Amazon S3、Amazon SNS通知或者API操作等。Lambda函数会自动接收一个500 MB的临时暂存目录，而且可以使用Amazon S3、Amazon DynamoDB或其他线上存储服务实现持久状态。Lambda函数还可以使用Amazon Linux支持的一切语言启动进程，并灵活调用库。此外，Lambda目前已经在全体AWS区域内上线。

其他几款AWS无服务器产品同样值得关注。Lambda@Edge允许在200多个AWS边缘站点运行Lambda函数，灵活响应Amazon CloudFront内容交付网络上的各类事件。Amazon DynamoDB则是一项快速且敏捷的键值与文档数据库服务，能够提供稳定的个位数毫秒级延迟。Amazon Kinesis则是一套用于在AWS上实现流式数据传输的平台。此外，可以使用AWS Greengrass在本地联网设备（例如物联网控制器）上运行Lambda函数。

开源AWS Serverless Application Model（AWS SAM）用于建模并部署无服务器应用程序及服务。除了SAM之外，AWS Lambda还支持八种开源及第三方框架。

AWS Serverless Application Repository则帮助为各种用例查找并重用无服务器应用程序与相关组件。企业可以使用Amazon CloudWatch监控无服务器应用程序，并使用AWS X-Ray实现分析与调试。最后，AWS Lambda最近还发布了Lambda Extensions的预览版——这是一套用于将Lambda同监控、可观察性、安全性及治理工具轻松集成起来的全新解决方案。

平台二 微软Azure Functions

微软Azure Functions是一套事件驱动型无服务器计算平台，能够解决种种复杂的编排问题。无需额外设置，大家就能在本地构建并调试Azure Functions，将成果大规模部署并运行在云端，而后使用相应的触发器与绑定机制集成更多其他服务。

开发者可以使用C#、F#、Java、JavaScript（Node.js）、PowerShell或者Python语言编写Azure Functions代码。但在单一Azure Functions应用程序中，我们只能选择使用一种编程语言。可以在Visual Studio、Visual Studio Code、IntelliJ、Eclipse以及Azure Functions Core Tools当中完成Azure Functions的本地开发。或者，也可以直接通过Azure门户编辑各种小型Azure函数。

Durable Functions是Azure Functions的一种扩展，以供在无服务器计算环境中编写有状态函数。该扩展允许使用Azure Functions编程模型编写实体函数，由此开发出包含有编排器函数及有状态实体的有状态工作流。

触发器是引导函数运行的关键，也定义着函数的具体调用方式。一条函数必须只能对应一个触发器。触发器中还包含关联数据，这些数据通常作为函数的有效负载存在。绑定至函数，则是一种将资源接入函数的声明方式；绑定具体分为输入绑定、输出绑定或者二者皆有。来自绑定的数据会以参数的形式被交付至函数当中。

平台三 Google Cloud Functions

Google Cloud Functions是一套可扩展的即用即付FaaS平台。它提供集成化的监控、日志记录与调试功能，在各角色及函数层级提供内置安全机制，同时具备适配混合云及多云场景所必需的关键网络功能。在它的帮助下，开发者可以通过触发器轻松接入Google Cloud或第三方云服务，大大简化以往难度颇高的编排问题。

Google Cloud Functions支持Go、Java、Node.js以及Python等语言编写的代码。Cloud Functions则支持各类常见的HTTP请求方法（包括GET、PUT、POST、DELETE以及OPTIONS），也能支持负责处理来自云基础设施的各类事件的后台函数。大家可以使用Cloud Build或其他CI/CD（持续集成/持续部署）平台实现Cloud Functions的自动测试与部署，并灵活匹配GitHub、Bitbucket或者Cloud Source Repositories等源代码存储库。最后，开发者也可以在本地计算机上开发并部署Cloud Functions。

平台四 IBM Cloud Functions

IBM Cloud Functions以Apache OpenWhisk为基础，属于一套多语言的函数即服务编程平台，可用于开发按需执行并扩展的轻量级代码。开发者可以使用Node.js、Python、Swift及PHP语言开发IBM Cloud Functions。IBM一直在努力引导客户在“事件-触发-操作”这一典型工作流中将Cloud Functions与Watson API集成使用，借此将应用程序数据的认知分析融入无服务器工作流当中。

平台五 Apache OpenWhisk

OpenWhisk是一套用于构建云应用程序的开源无服务器函数平台。OpenWhisk提供丰富的编程模型，能够使用函数构建无服务器API、将函数组合添加至无服务器工作流内，并使用规则与触发器将事件与函数相对接。

企业可以在本地运行OpenWhisk堆栈，或将其部署至Kubernetes集群（可以是企业自己的集群，也可以是由公有云服务商托管的Kubernetes集群），或者使用完全支持OpenWhisk的其他云服务商（例如IBM Cloud）。OpenWhisk目前可支持使用Ballerina、Go、Java、JavaScript、PHP、Python、Ruby、Rust、Swift以及.NET Core编写的代码；也可以使用自己的Docker容器。

OpenWhisk项目中包含多种开发者工具，例如用于轻松创建、运行并管理OpenWhisk实体对象的wsk命令行界面；使用应用程序清单通过单项命令部署并管理所有OpenWhisk包、操作、触发器、规则与API的wskdeploy；OpenWhisk REST API；以及JavaScript及Go版本的OpenWHisk API客户端等。

平台六 Knative

Knative项目由谷歌发起，先后获得50多家企业的贡献，用于在Kubernetes上构建并运行无服务器应用程序。Knative的各组件专注于解决常见但又令人头痛的任务，例如容器部署、使用蓝/绿部署进行流量路由与管理、根据需求自动扩展并调整工作负载，以及将运行的服务绑定至事件生态系统等。值得一提的是，Google Cloud Run就是基于Knative构建而成。

平台七 Kubeless

Kubeless是一套开源Kubernetes原生无服务器框架，强调以Kubernetes集群为部署环境。Kubeless重现了AWS Lambda、微软Azure Functions以及Google Cloud Functions上的大部分功能。开发者可以使用Python、Node.js、Ruby、PHP、Golang、.NET以及Ballerina等语言编写Kubeless函数。Kubeless事件触发器使用的则是Kafka消息系统与HTTP事件。

Kubeless还使用Kubernetes定制资源定义（Kubernetes Custom Resource Definition）创建作为自定义Kubernetes资源的函数。在此之后，它会运行集群内控制器以监控各自定义资源，并按需启动运行时。控制器会动态将函数代码注入运行时，并通过HTTP或发布/订阅机制进行实际使用。

平台八 OpenFaaS

OpenFaaS是一套面向Kubernetes的开源无服务器框架，项目口号是“让无服务器函数更简单”。OpenFaaS属于云原生技术堆栈“PLONK”中的一部分，即Prometheus（监控系统与时间序列数据库）、Linkerd（服务网格）、OpenFaaS、NATS（安全消息传递与流媒体）以及Kubernetes。您可以使用OpenFaaS中的模板存储或Dockerfile，将相应的事件驱动函数及微服务部署到Kubernetes。

Serverless 平台选型原则

讲解了这么多选项，我们到底该如何选择？与一切软件架构选择难题一样，问题的答案还是跟具体的需求密切相关。

首先，企业需要评估现有软件资产及发展目标。在大型机上运行着海量Cobol遗留程序的组织，其发展路径当然不可能跟已经拥有规模化云软件资产的组织相同。

如果企业中已经拥有不少云资产，请明确列出现有部署方案、具体使用哪些云服务商以及对应的可用区。此外，总结客户及用户的位置与服务使用模式也非常重要。

例如，需要24/7全天候保持统一负载级别的应用程序就不太适合无服务器部署——相反，合适的服务器、虚拟机或容器集群也许成本更低也更易于管理。另一方面，具有明确偶发运行特征、负载规模灵活多变且往往由特定操作（例如源代码签入）触发的应用程序则是无服务器架构的完美匹配对象。

另外，分布在全球各地而且对延迟要求严苛的服务，则特别适合部署在多可用区或边缘端点之上。因为原本在华盛顿特区使用的服务，可以被完美迁移至弗吉尼亚州的目标可用区内。

如果您的企业已经拥有丰富的Kubernetes使用经验，不妨考虑选择Kubernetes的各类开源无服务器平台。但如果没什么Kubernetes经验，最好还是选择原生云FaaS基础设施，这时候开源（例如无服务器框架）还是专有（包括AWS Lambda、Google Cloud Functions或者Azure Functions）就不那么重要了。

如果企业所构建的无服务器应用程序依赖于云数据库或流媒体服务，则应考虑将它们部署在同一云环境内，最大程度降低应用程序之内各组件间的延迟。请放心，这不会对无服务器框架选择造成太大影响。例如，使用Google Cloud Bigtable数据存储的应用程序完全可以选择Google Cloud Functions、Google Cloud Run、Serverless Framework、OpenWhisk、Kubeless、OpenFaaS、Fission或者Knative等多种方案，且继续保持稳定的最低延迟水平。

在大多数情况下，您的应用程序可能与常见用例颇为相似、甚至完全相同。这时候，大家就应认真评测目标无服务器平台的示例和库资源，看看有没有能够拿来就用的参考架构。事实上，大部分函数即服务系统并不需要编写大量代码：FaaS拥有丰富的可重用代码资源，而且架构本身也经过良好测试及验证。无需大量调试，企业就可以将其化为己用、大大提升工作效率。