传统上，Web应用程序通常部署在Web服务器上。为了使应用程序在服务器上运行，可能需要花费数小时来下载、编译、安装、配置和连接各种组件。计算机的操作系统也需要不断进行升级和修补，以解决安全漏洞。而管理服务器是一项非常耗时的工作，通常需要专门且经验丰富的系统操作人员，这让很多工程师感觉到身心俱疲。

而过去十年来，云计算发展得如火如荼，涌现出了很多改变传统IT架构和运维方式的新技术，比如虚拟机、容器和微服务等，而Serverless(无服务器)架构的出现，掀起了一场不小的波澜，亚马逊、微软、谷歌等大型厂商已经在无服务器架构领域重资投入，追赶革命的浪潮。有人说Serverless架构的兴起，将云计算的发展拉入了下一个纪元时代。“继OpenStack、Docker、MiscroService、Unikernel、Kubernetes和Mesos之后，Serverless正成为Google、Amazon乃至创业公司暗战的新战场。”那么Serverless到底是什么?

图源科技云报道

What is Serverless?

无服务器计算是一种按需提供后端服务的方法，可将对常见基础结构管理任务(例如扩展，调度，修补，配置等)的责任转移给云提供商和工具，从而使工程师可以将时间和精力集中在针对其应用程序的业务逻辑上或过程。无服务器计算是IaaS演进的下一个阶段，从根本上说，无服务器是要花更多的时间在代码上，而不是在基础架构上。所以很多人将Serverless视为开发人员的“灵丹妙药”。

亚马逊CTO Werner Vogels比喻道:“以前，你的服务器就像宠物一样。如果它们生病了，你就得把它们养好。它们像是牛，你必须放他们去吃草。但在无服务器中没有这样的牛，只有您的应用程序。您甚至不需要考虑恢复其健康或获得新的应用程序，其中的所有的任务都能自动执行。”

1.无服务器计算中是否有服务器?

与无服务器计算相关的最大争议不是围绕它的价值、用例或哪些供应商提供的产品适合于哪些工作，而是“无服务器”这个名称本身。关于无服务器的一个持续争论是该名称到底合不合适，因为无服务器计算中仍然有服务器。就像WIFI在某处有网线一样，无服务器架构仍然在某处有具体的服务器。之所以使用“无服务器”这个名称，是因为该名称描述了最终用户的体验。在一种称为“无服务器”的技术中，底层服务器的管理需求对于最终用户是不可见的。服务器仍然在那里，只是看不到它们或与之交互。

2.Serverless = FaaS + BaaS

Serverless是云平台几次迭代的高潮，从云计算发展的过程来看，早期大多数企业采用的是物理机托管方式，云时代后，随着虚拟化的发展，开始在云环境上托管虚拟机，基础设施即服务(IaaS)开始流行;在容器平台时代到来后，开发者开始去关注应用层所需要的计算资源和存储资源的使用，这也就是平台即服务(PaaS)。但这并不是旅程的终点，因为现在已经转向了无服务器架构。

PaaS 多通过容器平台呈现，运维人员和开发人员已经开始进行抽离，在进一步发展后开始实现函数即服务(FaaS)，此时运营人员并不需要关注底层的能力，而只需要关注业务相关的事情，这就使得整体业务实现了轻量化。

而 Serverless 更关注的就是上层业务的展示，可以将其描述为两种思想的结合：函数即服务(FaaS)和后端即服务(BaaS)。FaaS 将服务器端代码从长期运行的组件移至临时函数实例，而 BaaS 是指我们不再编写或管理所有服务端组件，可以使用领域通用的远程组件来提供服务。由于这些都不需要感知底层服务器架构，所以二者合起来就被称为 Serverless 架构。

3.与传统模式架构的区别

传统的架构模式是使用C/S架构的，在典型的web应用程序中，服务器接收前端的HTTP请求处理，在保存或查询数据库之前，数据可能会经过多个应用层，最终后端会返回一个响应。

在Serverless架构中，应用业务逻辑是基于FaaS架构形成多个相互独立的功能组件的。并且以API服务的形式向外提供服务，在FaaS中，后端的应用被拆分成为一个个函数，我们只需要编写完成函数后部署到serverless服务即可。后续我们无须管理和操作云端或本地的服务器。

Serverless的历史

AWS Lambda 作为Serverless最早的框架产品由亚马逊在2014年推出，但最早Serverless概念的并不是由亚马逊提出的。Serverless这个词首次出现是在2012年，云基础设施服务提供商Iron的副总裁Ken Form所写的一篇名为《Why The Future of Software and Apps is Serverless》的文章。

图源Bk小凯笔记

2014年，亚马逊发布AWS Lambda，在这之后，Serverless开始变得流行起来，它为云中运行的应用程序提供了一种全新的系统体系结构。至此再也不需要在服务器上持续运行进程以等待HTTP请求或API调用，而是可以通过某种事件机制触发代码的执行，通常这只需要在AWS的某台服务器上配置一个简单的功能。

尽管AWS被公认为是第一个使用无服务器计算平台进入市场的公司，但从那时起，其他主要的IaaS公共云提供商也纷纷效仿。亚马逊，谷歌和微软主导着当今的无服务器市场。阿里巴巴，IBM，Oracle和许多较小的供应商正在将自己的无服务器平台和支持技术推向市场。同时，OpenFaas和Kubeless等开源项目正在尝试将无服务器技术从云引入内部部署。主要的无服务器计算供应商包括：

Google Cloud功能，它于2017年由Google发布，支持Node.js JavaScript，Python和Go，但允许无限的函数执行时间。Google Cloud Functions还可以与许多其他Google服务进行交互，从而使开发人员几乎无需考虑基础服务器即可快速创建和管理复杂的企业级应用程序。IBM Cloud 功能，它基于Apache OpenWhisk，支持JavaScript(Node.js)，Swift和Cloudflare Workers，后者运行用JavaScript编写的功能以及可以编译为WebAssembly的任何语言。

AWS Lambda。它于2014年推出，是Amazon Web Services(AWS)的FaaS产品。AWS Lambda函数可以用Java，Go，PowerShell，Node.js JavaScript，C#，Python和Ruby编写。Microsoft Azure功能，微软于2016年推出了Azure Functions，以与AWS Lambda竞争。它支持Bash，批处理，C#，F#，Java，JavaScript(Node.js)，PHP，PowerShell，Python和TypeScript。

现在随着容器技术，IoT，5G，区块链等技术的快速发展，从物理机到云主机，到Serverless架构，去服务器化开始越来越明显。

无服务器计算的优缺点

与传统的基于云或以服务器为中心的基础架构相比，无服务器计算具有许多优势。对于许多开发人员而言，无服务器体系结构可提供更高的可伸缩性，更大的灵活性和更快的发布时间。

1.优点

无需服务器管理：尽管“无服务器”计算实际上是在服务器上进行的，但开发人员无需预置或维护任何服务器。它们由供应商管理。这可以减少在DevOps中的必要投资，从而降低支出，还可以使开发人员腾出空间来创建和扩展其应用程序，而不受服务器容量的限制。

比传统云便宜：开发人员仅需为使用的内容付费，为一致的吞吐量或执行持续时间(而不是服务器单元)付费。相比之下，在传统的“服务器”架构中，开发人员必须预先计划所需的服务器容量，然后购买该容量，而不管最终是否会使用到。

可扩展：试想一下，如果邮局可以以某种方式随意地增加和取消运输车辆，随着邮件数量的增加而扩大运输队的规模，在较少运输的时候缩小规模。从本质上讲，这就是无服务器应用程序能够做到的。使用无服务器基础结构构建的应用程序将随着用户群的增加或使用量的增加而自动扩展。如果某个功能需要在多个实例中运行，则供应商的服务器将根据需要启动，运行并结束它们。

但是，无服务器计算并不是所有开发人员的灵丹妙药，它也有着一定程度上的缺点。

2.缺点

供应商锁定：允许供应商为应用程序提供所有后端服务将不可避免地增加对该供应商的依赖。与一个供应商建立无服务器架构可能会导致在必要时难以切换供应商，尤其是因为每个供应商提供的功能和工作流程都略有不同。

安全问题：当供应商运行整个后端时，可能无法完全审查其安全性，这对于处理个人或敏感数据的应用程序是一个大问题。

性能会受到影响：因为它不是一直在运行，所以使用无服务器代码时可能需要“启动”。启动时间可能会降低性能。但是，如果定期使用一段代码，则无服务器提供程序将使它随时处于激活状态。对此现成代码的请求称为“热启动”，对一段时间未使用的代码的请求称为“冷启动”。

无服务器是未来吗?

无服务器标志着云计算旅程的下一步，在过去的几年里，AWS推出其Lambda平台之后，无服务器已经成为BBC，Airbnb，Netflix，耐克等品牌的主流架构，并且更多采用新方法来处理其后端。事实证明，Lambda在AWS中运行容器的公司中特别受欢迎，截至2020年1月，AWS中近80%的运行容器的组织都采用了Lambda。根据报告显示，到2021年，无服务器市场预计将以32.7%的速度增长。

但相对来说，无服务器仍然是一个新世界，Gartner分析师Lowery表示，市场是如此年轻，以至于还没有赢家和输家。他说，真正的关键在于确定无服务器系统的用途。FaaS可以是一个强大的工具，可以将特定供应商的云中的各种服务“粘合”在一起。另一方面，其他物联网事件驱动的用例可能并不局限于特定供应商的云。