在云中全天候24/7运行服务器是一种资源浪费，因此只要有可能，企业都希望能够在不需要时关闭大部分容量。如果从逻辑思维推断，那么更好的方案应该是在需要的时候按需启动服务器，只根据负载需求提供相应的容量资源。这就是Serverless，也就是Serverless计算的展示空间。无服务器计算是一种云执行模型，云服务提供商根据执行特定代码段所需的计算资源和存储进行动态资源分配和计费。换句话说，无服务器计算是一种按需、按需付费的后端计算形式。当请求进入无服务器端点时，后端要么重用已包含正确代码的现有端点，从资源池分配和自定义资源，要么实例化和自定义新端点。基础设施通常根据需要运行尽可能多的实例来处理传入的请求，并在冷却期后释放任何空闲实例。Serverless其实也使用服务器，只是用户不需要承担服务器的管理工作。运行无服务器代码的容器或其他资源通常在云中运行，但也可以在指定的边缘位置运行。功能即服务（FaaS）是各种无服务器架构的基本总结。在FaaS中，用户为一个功能编写代码，基础设施负责提供必要的运行环境，加载运行代码，控制运行生命周期。FaaS模块可以与Webhook、HTTP请求、流、存储桶、数据库和其他构建块顺利集成，以构建无服务器应用程序。下面我们就来看看几款比较流行的Serverless计算平台，希望能为企业的平台选择提供一些帮助。Platform1AWSLambda及其他相关服务AWSLambda是一种常见的FaaS解决方案。除了AWSLambda，亚马逊云科技目前还提供十余种Serverless产品。诞生于2014年的AWSLambda并不是世界上第一个FaaS服务。在它之前，有2006年的Zimki，2008年的GoogleAppEngine，2010年的PiCloud。AWSLambda支持用Python、Node.js、Ruby、Java、C#、PowerShell、Go等语言编写的无状态函数代码。Lambda函数可以在运行后响应事件，例如上传到AmazonS3的对象、AmazonSNS通知或API操作。Lambda函数自动接收一个500MB的临时暂存目录，并且可以使用AmazonS3、AmazonDynamoDB或其他在线存储服务来实现持久状态。Lambda函数还可以使用AmazonLinux支持的所有语言来启动进程并灵活地调用库。此外，Lambda目前在所有AWS区域可用。其他几款AWS无服务器产品也值得关注。Lambda@Edge允许在200多个AWS边缘站点运行Lambda函数，灵活响应AmazonCloudFront内容交付网络上的各种事件。AmazonDynamoDB是一种快速、敏捷的键值和文档数据库服务，可提供一致的个位数毫秒延迟。AmazonKinesis是一个在AWS上进行流式数据传输的平台。此外，Lambda函数可以在本地连接的设备上运行，例如使用AWSGreengrass的IoT控制器。开源AWS无服务器应用程序模型(AWSSAM)用于建模和部署无服务器应用程序和服务。除了SAM，AWSLambda还支持八个开源和第三方框架。AWSServerlessApplicationRepository有助于为各种用例查找和重用无服务器应用程序和相关组件。组织可以使用AmazonCloudWatch监控无服务器应用程序，并使用AWSX-Ray进行分析和调试。最后，AWSLambda最近还发布了LambdaExtensions的预览版——一组新的解决方案，可轻松将Lambda与监控、可观察性、安全性和治理工具集成。Platform2MicrosoftAzureFunctionsMicrosoftAzureFunctions是一个事件驱动的无服务器计算平台，可以解决各种复杂的编排问题。无需额外设置，您可以在本地构建和调试AzureFunctions，在云端大规模部署和运行结果，然后使用相应的触发器和绑定机制来集成更多其他服务。开发人员可以使用C#、F#、Java、JavaScript(Node.js)、PowerShell或Python编写AzureFunctions代码。但在单个AzureFunctions应用中，我们只能选择使用一种编程语言。AzureFunctions的本地开发可以在VisualStudio、VisualStudioCode、IntelliJ、Eclipse和AzureFunctionsCoreTools中完成。或者，可以直接通过Azure门户编辑各种小型Azure功能。DurableFunctions是AzureFunctions的扩展，用于在无服务器计算环境中编写有状态函数。此扩展允许使用AzureFunctions编程模型编写实体函数，从而开发包含协调器函数和有状态实体的有状态工作流。触发器是引导函数运行的关键，同时也定义了函数的具体调用方式。一个函数必须只对应一个触发器。触发器还包含关联数据，这些数据通常作为函数的有效负载存在。绑定到函数是一种将资源声明为函数的方式；绑定具体分为输入绑定，输出绑定，或者两者兼而有之。来自绑定的数据作为参数传递给函数。Platform3GoogleCloudFunctionsGoogleCloudFunctions是一个可扩展的按需付费的FaaS平台。提供集成的监控、日志和调试功能，在每个角色和功能级别提供内置的安全机制，并具有适应混合云和多云场景所需的关键网络功能。在它的帮助下，开发者可以通过触发器轻松访问谷歌云或第三方云服务，大大简化了之前难以解决的编排问题。GoogleCloudFunctions支持使用Go、Java、Node.js和Python编写的代码。CloudFunctions支持各种常见的HTTP请求方法（包括GET、PUT、POST、DELETE和OPTIONS），以及负责处理来自云基础设施的各种事件的后台函数。您可以使用CloudBuild或其他CI/CD（持续集成/持续部署）平台实现CloudFunctions的自动化测试和部署，灵活匹配GitHub、Bitbucket、CloudSourceRepositories等源码仓库。最后，开发者还可以在本地计算机上开发和部署CloudFunctions。Platform4IBMCloudFunctionsIBMCloudFunctions基于ApacheOpenWhisk，属于一组多语言函数即服务编程平台，可用于开发按需执行和扩展的轻量级代码。开发人员可以使用Node.js、Python、Swift和PHP语言开发IBMCloudFunctions。IBM一直在努力引导客户在典型的“事件-触发-操作”工作流中将CloudFunctions与WatsonAPI集成，从而将应用程序数据的认知分析集成到无服务器工作流中。平台五ApacheOpenWhiskOpenWhisk是一个用于构建云应用程序的开源无服务器功能平台。OpenWhisk提供了丰富的编程模型，可以使用函数构建无服务器API，将函数组合添加到无服务器工作流，并使用规则和触发器将事件连接到函数。企业可以在本地运行OpenWhisk堆栈，或者将其部署到Kubernetes集群（可以是企业自己的集群，也可以是公有云服务商托管的Kubernetes集群），或者使用其他完全支持OpenWhisk的云服务商（如IBM云）。OpenWhisk目前支持使用Ballerina、Go、Java、JavaScript、PHP、Python、Ruby、Rust、Swift和.NETCore编写的代码；它还可以使用自己的Docker容器。OpenWhisk项目包括多种开发人员工具，例如用于轻松创建、运行和管理OpenWhisk实体对象的wsk命令行界面；使用应用程序清单通过单个命令wskdeploy部署和管理所有OpenWhisk包、操作、触发器、规则和API；OpenWhiskRESTAPI；以及JavaScript和Go版本的OpenWHiskAPI客户端等。Platform6KnativeKnative项目由Google发起，已收到50多家公司的贡献，用于在Kubernetes上构建和运行无服务器应用程序。Knative的组件专注于解决常见但棘手的任务，例如容器部署、使用蓝/绿部署的流量路由和管理、根据需求自动扩展和调整工作负载，以及将运行的服务绑定到事件生态系统等。值得一提的是，GoogleCloudRun是基于Knative构建的。Platform7KubelessKubeless是一套开源的Kubernetes原生serverless框架，强调Kubernetes集群的部署环境。Kubeless重现了AWSLambda、MicrosoftAzureFunctions和GoogleCloudFunctions上的大部分功能。开发人员可以使用Python、Node.js、Ruby、PHP、Golang、.NET和Ballerina等语言编写Kubeless功能。Kubeless事件触发器使用Kafka消息系统和HTTP事件。Kubeless还使用Kubernetes自定义资源定义来创建作为自定义Kubernetes资源的函数。之后，它运行一个集群内控制器来监控各个自定义资源并根据需要启动运行时。控制器通过HTTP或发布/订阅机制将功能代码动态注入运行时以供实际使用。Platform8OpenFaaSOpenFaaS是Kubernetes的开源无服务器框架。项目口号是“让无服务器功能更简单”。OpenFaaS是云原生技术堆栈“PLONK”的一部分，即Prometheus（监控系统和时间序列数据库）、Linkerd（服务网格）、OpenFaaS、NATS（安全消息传递和流媒体）和Kubernetes。您可以使用OpenFaaS中的模板存储或Dockerfile，将相应的事件驱动功能和微服务部署到Kubernetes中。Serverless平台选型原则解释了这么多选项，我们应该如何选择呢？与所有软件架构选择问题一样，问题的答案与具体需求密切相关。首先，企业需要评估现有的软件资产和发展目标。在大型机上运行大量Cobol遗留程序的组织肯定无法遵循与已经拥有大规模云软件资产的组织相同的增长路径。如果企业已经有很多云资产，请清楚列出现有的部署方案，使用了哪些云服务提供商，以及对应的可用区。此外，总结客户和用户的位置和服务使用模式也很重要。例如，需要保持24/7全天候统一负载水平的应用程序不适合无服务器部署——相反，合适的服务器、虚拟机或容器集群可能更便宜且更易于管理。另一方面，具有明确定义的零星运行时特征、灵活的负载规模并且经常由特定操作（例如源代码签入）触发的应用程序非常适合无服务器架构。此外，分布在世界各地且对延迟要求严格的服务特别适合部署在多可用区或边缘端点上。因为原本在华盛顿特区使用的服务可以完美迁移到弗吉尼亚州的目标可用区。如果你的企业已经有丰富的Kubernetes使用经验，不妨考虑选择Kubernetes的各种开源serverless平台。但如果你没有Kubernetes经验，还是选择云原生的FaaS基础设施更好。这时候，开源（如无服务器框架）或专有（包括AWSLambda、GoogleCloudFunctions或AzureFunctions）就不那么重要了。构建依赖于云数据库或流服务的无服务器应用程序的企业应考虑将它们部署在同一云环境中，以最大限度地减少应用程序内组件之间的延迟。请放心，这不会对您的无服务器框架选择产生太大影响。例如，使用GoogleCloudBigtable数据存储的应用可以选择GoogleCloudFunctions、GoogleCloudRun、ServerlessFramework、OpenWhisk、Kubeless、OpenFaaS、Fission或Knative等解决方案，并持续保持稳定的最低延迟水平。在大多数情况下，您的应用程序可能与常见用例相似甚至相同。这时候你应该仔细评估目标serverless平台的例子和库资源，看看有没有参考架构可以使用。事实上，大多数FaaS系统不需要大量编码：FaaS具有丰富的可重用代码源，并且架构本身经过了充分的测试和验证。无需大量调试，企业即可自用，大大提高工作效率。
