无服务器架构是应用软件架构的未来吗？

Serverless已经在软件世界掀起了一场革命，业界普遍认为它是云计算和软件架构的未来，但还有很多伙伴，并不了解Serverless。所以呢，今天我就带大家来彻底认识一下Serverless，以免大家错过这波浪潮。内容分为四部分：

全文约12800字，读完之后你对Serverless的历史、现状和未来，会有清晰的认知，有助于你评估公司的业务要不要采用Serverless架构、采用哪家的Serverless方案，也有助于你评估自己要不要学习实践Serverless。

让我们开始挑战吧！

应用软件架构和托管模型的演变史

在过去的几十年里，应用软件架构和托管模型经历了从中央主机到无服务器的重大转变。

20世纪70~80年代，是中央主机时代。

由于中央主机非常昂贵（IBM650小型机要价就高达50万美金），企业的一般做法是，买一台大型机或小型机，“供奉”在自建机房中，安排一名主机管理员，集中控制和管理中央主机，其他人员要通过计算机做某种操作，必须经过相关人员批准才可以。

这个时代，计算机和信息技术的主要用途就是为了达成商业策略而为业务建造各种系统，比如财务系统、工资管理系统、核心业务系统等。这些系统的核心功能，都运行在中央主机上，而客户端终端只具备基础功能，通常是用来在屏幕上输入和显示数据。

1984年，IBM公司推出了以80286处理器为核心组成的16位增强型个人计算机IBM PC/AT，并采取技术开放策略，个人计算机开始风靡，PC时代来临。

随着PC时代的发展，客户端/服务器架构（即Client/Server架构，C/S架构）兴起。在C/S架构中，服务器负责数据的管理，客户端负责完成与用户的交互任务，承载大量的业务逻辑和展示逻辑。

C/S架构的主要特点是交互性强、具有安全的存取模式、响应速度快、方便处理大量数据。但是C/S架构缺少通用性，系统维护、升级往往需要重新设计和开发，维护和管理难度高。C/S架构在局域网中应用较多。

20世纪90年代中期发生了互联网革命，Web兴起，浏览器普及，基于浏览器构建Web应用成为现实，B/S架构（即Browser/Server架构，浏览器/服务器架构）开始兴起。在B/S架构中，服务器承担主要的事务逻辑实现，基于浏览器的Web应用成了客户端，负责显示逻辑，压力很小，并且因为浏览器的通用性，Web应用无需安装，打开网页就能使用，非常方便。

C/S架构和B/S架构的迅猛发展，推动着x86服务器赢得了时代的青睐，取代大型机和小型机，成了服务器的行业标准。

随着互联网的发展，IT公司纷纷基于B/S架构对外提供Web服务，他们把买来的x86服务器放进互联网服务提供商（Internet Service Provider，ISP）的机房内，由ISP负责维护，比如分配IP、网络带宽，免去申请商业化宽带以及管理服务器的麻烦，于是服务器托管业务开始蓬勃发展。

后来ISP又发展出服务器租赁业务——客户自己不买服务器，而是租用ISP的服务器。

ISP服务器租赁模式，算是后来云计算的雏形了，但它有比较多的缺陷：

市场需要更好的资源分配与管理模式。

缘起于20世纪50年代末的虚拟化技术，在20世纪末、21世纪初，随着全虚拟化、半虚拟化及硬件辅助虚拟化等技术的涌现，迅速发展成熟，x86服务器的虚拟化随之完成，一台物理服务器上，可以构建出几台甚至几十台虚拟主机，物理主机托管所遇到的资源分配与管理难题，迎刃而解，主机托管服务从物理机托管转向虚拟机托管，云计算1.0时代拉开序幕。

2000年，亚马逊开始基于Xen虚拟化技术开发EC2（Elastic Compute Cloud，弹性计算云），产品主要用于内部基础设置。2005年，亚马逊将这一技术提供给签订了保密协议的一些客户。

2006年8月9日，Google首席执行官埃里克·施密特在搜索引擎大会上首次提出“云计算”（Cloud Computing）的概念。

2006年8月25日，亚马逊正式发布EC2，这是历史上第一个商业化的IaaS服务。EC2的发布，宣布云计算时代正式到来。

由于亚马逊率先探索云计算并在内部和客户中获得大量应用，它在这个新兴领域建立了强大的优势，当阿里巴巴、Google、IBM、微软等公司开始发力云计算时，亚马逊已经初步形成涵盖IaaS、PaaS的产品体系，确立了在IaaS和云服务领域的全球领导地位。

2008年，云计算的市场认可度越来越高，越来越多的企业，开始基于云来构建自己的业务服务。

互联网流媒体视频内容行业的领导品牌Netflix，2009年时，其所有客户流量都在自己的数据中心，然而到2010年年底，这些流量中的大部分已经运行在亚马逊的公有云解决方案AWS上了。Netflix将服务全面迁移到AWS，让亚马逊来负责基础设置问题，自己则将精力专注于构建和提高业务应用，公司业务得以快速发展。

2010年10月，一款名为Instagram的照片分享应用发布。第一天有25000人注册使用。3个月后，Instagram的用户激增至100万，然后这个数字很快达到1000万。一年半以后，Instagram的用户增长到接近3000万。

Instagram之所以能够如此迅速地发展，是因为它的后台构建在云上，可以按需使用计算资源，他们只用专注于应用架构和用户体验这两项他们所擅长的事情。

随着技术和市场的演进，云服务发展出IaaS、PaaS和SaaS三种模式。

到2013年，云计算的实验性阶段结束，在初创企业和中小型企业中被广为接受，但是大型企业的步伐仍然比较迟缓。

这个阶段，企业的后端服务，运行在云端的虚拟机中，每一个虚拟机使用独立的操作系统内核与运行时。

设想一下，同一个客户租用了多台虚拟机，这些虚拟机的操作系统版本、运行时都一模一样，它们也运行在同一个物理服务器上，可它们无法共用资源。从这样的场景设想就可以看出，这个阶段的虚拟主机托管，仍然存在一定的资源浪费。

2013~2014年，微服务架构流行起来。

2013年3月，dotCloud公司的创始人之一，Docker之父Solomon Hykes正式决定将其容器技术项目Docker开源。之后Docker人气迅速攀升，发展进入快车道，每一个月都会发布一个版本。

2014年6月9日，Docker 1.0版本正式发布。云计算从“云主机托管”进入了容器时代。

Docker在应用程序级别实现虚拟化，直接复用本地主机的操作系统，而传统的虚拟化方式则是硬件虚拟化，要在本地主机上仿真出一台或多台具备各种硬件的虚拟计算机，用户要给每台虚拟机单独安装一个操作系统。

两种方式的对比如下图所示。

Docker以更为轻量级的方式解决了资源分配问题，比如一个VM的大小大概是20GB，而运行着相同应用程序的容器大概只有200MB。

虚拟化技术因为Docker的出现进入了新阶段。

2014年11月，AWS发布了ECS（Amazon EC2 Container Service），一个高性能容器管理服务，支持Docker容器。

Google在Docker项目刚兴起时（2014年6月），开源了与容器技术相关的内部系统Borg，Borg后来演变为Kubernetes（简称为K8S）。

2015年7月22日，K8S迭代到v1.0并正式对外公布。但很长一段时间里，K8S并没有显现出对Docker容器编排的另外两大工具Swarm和Mesos的特别优势。

2015年12月11日，Google、RedHat等开源基础设施领域的玩家们牵头发起的CNCF（Cloud Native Computing Foundation）基金会（即云原生计算基金会）正式成立。云原生计算基金会的口号是，坚持和整合开源技术来让编排容器作为微服务架构的一部分。

Google将Kubernetes托管给了CNCF基金会。Kubernetes社区在 2016 年之后得到了空前的发展。后来，随着Docker在其产品中集成Kubernetes，Kubernetes成了云化容器编排的标准。

Docker解决了资源分配问题，Kubernetes解决了云与容器的结合问题，云计算告别了仅仅租赁服务器的时代，真正成熟，进入2.0时代。

在这个时代，后端服务运行在容器之中，容器即服务（CaaS），云服务形态也演变成下面的形式。

容器化技术进一步降低了服务器与运维成本，但这个时候，企业依然需要运维自己的后端服务，运维成本仍在。运维成本还可以进一步降低吗？

同时，IT企业还有一个更大的成本——研发成本。能否有一种方案，可以简化后端服务的编码从而降低企业成本呢？

答案是无服务器（Serverless）架构。

无服务器架构将服务器基础架构从应用程序开发人员那里完全抽象出来了，开发人员无需关心服务器，只需将业务服务编写为函数，并将这些函数部署到云基础架构中。

这样一来，服务器端开发成本大大降低，同时因为服务器完全由第三方管理，实现了零运维，运维成本接近于零。

历史上第一个Serverless平台可以追溯到2006年，但一直没有获得广泛的关注。2014年，随着Docker和Kubernetes的兴起，Serverless再度成为人们追逐的焦点。

2014年底，AWS Lambda发布，这是第一个成熟的Serverless服务，是Serverless发展史上的里程碑，昭示着无服务器时代的到来。

之前，无论是中央主机、PC时代的物理机托管、云计算1.0时代的虚拟机托管、还是云计算2.0时代的容器技术，应用软件开发商都需要运营并管理“服务器”。

而进入无服务器时代，很多应用软件开发商不需要自己的服务器了，开发和运维复杂度大大降低，开发模式和架构模式也因此发生了巨大变化。

以AWS Lambda开发为例，逻辑上只需要三个步骤，非常简洁。

AWS Lambda的推出，宣告了FaaS（Function as a Service，函数即服务）的诞生，云服务形态也随之演变成下面的形式。

如果从应用软件服务端托管的视角来看待应用软件架构和托管模型的演变历史，可以发现，实际上演变史可以分成四个阶段：物理机、虚拟机、容器化和Serverless。

每个阶段对“服务器”等资源的抽象程度不同，企业在不同阶段对业务专注的程度也不同。

下图从抽象程度和业务专注程度这两个维度对比了四个阶段，简要描述了每个阶段的特点。

概览应用软件架构和服务托管的演变历史，抽象程度越来越高、业务专注程度越来越高，是基本规律，从这点出发，可以预见，Serverless将会得到越来越广泛的应用。

所以接下来，我们要来详细了解一下Serverless。

Serverless详解

CNCF（云原生计算基金会）出品的《CNCF Serverless Whitepaperv1.0》，对Serverless computing做出了解释：

“Serverless computing refers to the concept of building and runningapplications that do not require server management. It describes afiner-grained deployment model where applications, bundled as one or morefunctions, are uploaded to a platform and then executed, scaled, and billed inresponse to the exact demand needed at the moment.”

翻译成中文，意思是：

“无服务器计算指的是构建和运行不需要服务器管理的应用程序的概念。它描述了一个细粒度的部署模型——应用被打包成一个或多个函数，上传到一个平台上，然后按需执行，按需进行规模缩放，同时应用也按实际使用量向平台付费。”

在当下语境中，Serverless，通常被称为“无服务器架构”，指开发者无须关心服务器，他们编写的代码不会明确地部署在某些特定的硬件服务器、虚拟主机或容器中，而是托管到类似AWS这样的云计算厂商提供的云服务中，最终达到的效果是，开发者无需配置及扩展基础设施，就可以运行自己的服务。

“无服务器架构”中的无服务器，并不是说真的不需要服务器，实际上它仍然需要服务器及相关环境，只是这些东西由类似亚马逊这样的云计算厂商提供，企业和开发者不用关心。

从技术角度来说，Serverless就是FaaS和BaaS的结合，Serverless = FaaS + BaaS 。

FaaS，即Function as a Service，指云计算厂商提供的帮你运行函数的平台，比如AWS Lambda、Microsoft Azure Functions、阿里云的函数计算、Google Cloud Functions等。

BaaS，即Backend as a Service，指一些后端云服务，比如对象存储、云数据库、消息队列等。有了BaaS，开发者不再编写或管理所有服务端组件，可以使用云计算厂商提供的远程组件（而不是进程内的库）来提供服务，能够极大地简化应用开发难度。

传统的互联网应用，往往是C/S或B/S架构：企业在后端的物理服务器（或虚拟主机或容器）上运行一个超长生命周期的服务进程，处理应用方方面面的逻辑，客户端或浏览器通过访问后端服务进程来获取相应服务。

采用Serverless架构后，原来后端服务进程负责的业务逻辑，被移入客户端，客户端使用FaaS和BaaS来实现这些业务逻辑。

下图展示了C/S架构应用与Serverless架构应用的关系，有助于我们理解什么是Serverless架构。

图片来自martinfowler.com

在CNCF（云原生计算基金会）出品的《CNCF Serverless Whitepaperv1.0》中，有一张图，描述了Serverless的简短历史。

2006年，Zimki平台出现，提供服务端JavaScript应用。Zimki是第一个“按照实际调用付费”的平台，它虽然没有使用Serverless这个名词，但实际上它是历史上第一个Serverless平台。

2012年，云基础设施服务提供商Iron.io的副总裁Ken Fromm在《Why the future of software andapps is serverless》一文中提出，首次提到Serverless名词及概念。Iron.io提供的Serverless产品是IronWorker，一个基于容器技术构建的分布式平台，提供“work-on-demand”服务。

2014年底，亚马逊发布AWS Lambda，把“Serverless”这一范式提高到了一个全新的层面。

AWS Lambda及其配套的各种BaaS，为云中运行的应用程序提供了一种全新的架构模式：企业再也不用在服务器上持续运行进程以等待HTTP请求或API调用，只需要把自己开发的函数（功能）上传到AWS的某台服务器上，就可以通过某种事件机制触发代码的执行，按需完成特定的功能。

亚马逊发布了AWS Lambda之后，Serverless这个概念开始变得流行起来，在很多场合反复出现，国内外的各大云厂商也都争相跟进。

2016年，IBM发布了IBM OpenWhiskon Bluemix，Google发布了GoogleCloud Functions，微软发布了Azure Cloud Functions。

2017年，阿里云发布了函数计算Function Compute（函数计算FC），腾讯云发布了Serverless Clound Function（腾讯云函数SCF），华为发布了Huawei Function Stage。

随着Serverless概念的持续发酵，2016年10月，第一届Serverlessconf在伦敦举办，在两天时间里，来自全世界40多位演讲嘉宾为开发者分享了关于这个领域进展。

现在，业界普遍认为，Serverless是云时代的全新计算范式，将引领云计算在下一个十年乘风破浪。

Serverless带来很多好处，典型的有以下10种。

（1）加速研发，缩短产品上市时间

采用Serverless架构，企业无需自主研发后端服务程序，只需聚焦客户侧，专注业务开发，整个研发工作量大幅降低，研发周期大大缩短，产品上市时间将大大缩短。

（2）无运维

企业采用Serverless解决方案，服务器、数据库和应用程序等等方面的管理工作，由委托服务提供商维护，无须企业自己维护，运维工作降低到接近于零。

（3）业务专注程度提升

采用Serverless，企业无须关心基础设施管理和常见的后端服务（BaaS）研发，能够专注在自己擅长的业务上，为用户提供更好的服务。

（4）弹性扩展

Serverless架构一个显而易见的优点是，“横向扩展是完全自动的、有弹性的、且由服务提供者所管理”。所以企业只需要支付应用需要的计算能力，就可以获得由服务提供者保障的扩展能力，既不用担心自己的服务规模倍增时没有资源可用，也不用担心自己的服务收缩时导致资源浪费。

（5）高可用性和容错性

在Serverless架构模式下，云服务商提供的FaaS或BaaS服务，经过大量测试和实践检验，自带高可用性和容错性，企业使用Serverless，省去了自研相关服务所需的研发、测试、验证等等工作，直接可以获得一套具备高可用性与容错性的服务。

（6）降低风险

对于组件越多越复杂的系统，出故障的风险就越大。企业使用Serverless架构，通过FaaS或BaaS将后端组件外包出去，让专业人员来处理可能的故障，往往比企业自己修复更可靠，修复时间也更短，可以有效提升企业的系统稳定性，降低潜在的风险。

（7）降低开发成本

企业采用Serverless架构，基于FaaS和BaaS构建应用程序，后端服务所需的各种应用程序组件作为商品被采购，原本需要后端研发团队进行的大量开发工作，不再需要，开发成本显著降低。

（8）降低基础设施成本

企业采用Serverless结构，无须购买服务器、带宽、存储等基础设置，节省了相关成本。

（9）降低运维成本

使用Serverless，企业无需关心服务器，几乎没有运维工作，运维成本（含人员、运营、开发等）大大降低。

（10）按需付费，降低经营成本

使用Serverless，企业只需要为每次函数的运行付费，是真正的按实际使用量付费，函数不运行，则不花钱。同时，Serverless方案可以根据服务规模的变化自动伸缩，企业无需为潜在的高峰服务预购相关资源。整体来看，经营成本会显著下降。

Serverless目前正在快速发展之中，在现阶段，也存在一些问题。

（1）无状态。

Serverless要实现自由的缩放，无状态是必须的。

在无状态这个背景下，每次函数执行，使用的都可能是不同的容器，函数之间无法进行内存或数据共享。

而很多企业的业务服务是有状态的，采用Serverless架构，就需要通过类似Redis这样的存储服务，以共享数据的方式来实现状态的存储和传递。而与存储交互就不可避免的增加了延迟和复杂性。

（2）本地测试困难。

借助类似SAM这样的工具，AWS Lambda和MicrosoftAzure已经可以本地运行FaaS功能，程序调试相比2018年之前，已经方便了不少。但Serverless应用的本地测试仍然是一个很棘手的问题。

虽然可以在测试环境下使用各种数据库和消息队列来模拟生产环境，但是对于无服务应用的集成或者端到端测试尤其困难，很难在本地模拟应用程序的各种连接，并与性能和缩放的特性结合起来测试，并且Serverless应用本身也是分布式的，简单的将无数的FaaS和BaaS组件粘合起来也是有挑战性的。

（3）冷启动时间可能带来性能问题。

Serverless在收到事件（请求）时才会运行特定的函数（功能）。

这意味着，当某个函数在一段时间内没有被请求时，它的所有实例都可能被运行时移除，这种情况下，对该函数的下一次请求来临时，运行时就需要下载函数代码、启动一个容器、在容器里面再启动一个运行环境，最后再来执行函数代码。这样就会有相对较长的冷启动时间。

如果企业的应用需要特别短的响应时间，这个冷启动时间就可能是一个性能瓶颈。

（4）没有统一标准，容易出现厂商锁定现象。

Serverless还是新兴技术，处于快速发展阶段，缺少统一的标准。

在不同的无服务计算服务商之间，不仅仅是函数的调用语义和打包方式不同，许多无服务应用也依赖于其生态系统的专有 BaaS 服务（例如对象存储、键值数据库、身份验证、日志监控等）。

某一服务商的用户，往往需要针对该服务商的API编程，容易被该厂商锁定。

（5）无服务器计算可能存在成本不可预测的情况。

对于一些用户来说，无服务计算采用即付即用的计费模型的一个缺点是成本不可预测。这与许多组织管理预算的方式不太一致，当公司想要知道下一年无服务计算的成本预算是多少，并来批准预算时就不太好制定预算。

这种需求是合理的，云服务商可能会通过提供基于 bucket 的定价方式来缓解这个问题，类似于电话公司为特定使用量提供固定费率计费方式一样。

我们还相信，随着越来越多的组织使用无服务计算，他们将能够基于历史来预测他们的成本，就像当今公共事业服务（如电力）所使用的办法。

（6）运行时间的限制

当前各云平台对于FaaS的运行时间都有10-15分钟的限制，这种限制影响了许多场景的实现，尤其是一些强状态依赖的场景，例如长时间保持数据库连接的情况等。

（7）多租户问题

多租户是指几个不同客户（或租户）的多个软件实例在同一台计算机上运行，并且可能在同一托管应用程序中运行。这会带来安全性（一个客户可以查看另一人的数据）、健壮性（一个客户的软件错误导致另一个客户的软件失败）和性能（高负载的客户导致另一个客户放慢速度）等各方面的问题。

目前，AWS Lambda已经足够成熟，没有此类问题。但对于不那么成熟的服务平台，应该注意这些问题。

以上是Serverless在现阶段存在的一些问题，会在一定程度上影响服务体验，但这些都是暂时的，相信随着Serverless实践的不断深入和Serverless生态的持续进化，它们很快就会得到改善或解决。

使用Serverless，企业几乎可以为任何类型的应用程序或后端服务运行代码。下面是一些典型的应用场景说明。

（1）Web应用

在Web应用中，可以整合API网关和Serverles服务构建Web后端，帮助开发者构建可弹性扩展、高可用的Web后端应用服务。

（2）移动应用后端

使用Serverless作为移动应用（包括小程序）的后端非常有吸引力，这种方案使得开发者可以通过REST API访问BaaS来实现后端功能，而他们可以专注在移动业务上。典型的应用包括音视频处理、图形优化、批量通知、离线异步任务、认证、人脸识别等。

（3）IoT场景

在IoT场景下，可高效的处理实时流数据，由设备产生海量的实时信息流数据，通过Serverless服务分类处理并写入后端处理。

（4）机器学习及AI模型处理

当前其实在云端已经提供了应用层面的Serverless机器学习服务，例如AWS的Sagemaker服务，用户只要输入数据，设置好模型，Sagemaker就会帮忙做训练，并按照模型的训练时间来计费。

Berkeley的研究人员也开发了一个基于Serverless的更为通用的机器学习库Cirrus。

另外，企业也可以使用类似AWS Lambda这样的服务，对即将输入到机器学习模型的数据做预处理。

关于如何将Serverless和机器学习结合起来，目前有很多研究者正在进行各式各样的探索。

（5）工作流（业务逻辑）

有一些业务逻辑由一系列的步骤组成，比如订单请求和批准、库存交易处理等，这些步骤和环节可以采用Serverless架构实现，在客户端事件和有状态管理器的协作下，整个业务逻辑都可以很好的实现。股票交易系统，就是一个典型的例子。

Amazon提供了AWS Step Functions，专门用来支持快速工作流，算是相当友好了。

（6）多媒体处理

在实时多媒体场景下，用户将图像、音视频等上传到对象存储中，可以通过上传事件触发多个函数，分别完成图像处理、高清转码、音频转码等功能，满足用户对实时性和并发能力的高要求。

（7）持续集成

在传统的持续集成系统中，构建工作往往是在新代码提交或Pull Request触发后执行，但却通常需要配置一系列构建主机随时待命，这就带来资源浪费，采用Serverless，可以消除预配置主机，降低成本。

（8）数据处理

企业可以使用类似AWS Lambda这样的FaaS服务来执行代码以响应数据更改、系统状态变化或用户操作等触发器，并借此构建各种实时的无服务器数据处理系统。

（9）事件驱动的各种场景

无服务器计算适合于任何事件驱动的各种不同的用例，这包括物联网、移动应用、基于网络的应用程序、聊天机器人、实时翻译、数据更改审计、定时任务、批处理任务、机器学习及AI模型处理等。

从2014年AWS Lambda发布到现在，时间过去了7年，Serverless已经走过了最初的新兴阶段，种种迹象表明，Serverless的成熟度已经非常之高。

首先，提供Serverless服务的云供应商越来越多，Amazon、Google、Microsoft、IBM、Alibaba、Tencent、Cloudflare、Huawei、Oracle等9大供应商，都有了自己的成熟产品。

其次，开发工具和框架已经相对完整、完善。

比如Serverless兴起的前两年，FaaS相关的开发，还不支持本地运行，现在普遍都支持了。

比如，前几年工具匮乏，现在云服务商自己就提供了从Web IDE到命令行工具到既有IDE插件到监控等多种形式的工具，比如AWS，就提供了AWS Cloud9、AWSCodePipeline、AWS Config、AWSLambda Power Tuning、AWS X-Ray、AWSCloudFormation、AWS Toolkit for JetBrains、Amazon CloudWatch、AWS Serverless ApplicationRepository等各种形式各种用途的工具.

另外，还有很多第三方工具，如Serverless、Thundra、Datadog、Amplify、Architect、Claudia.js等。

然后，Serverless已经能够支持市面上的各种主流开发语言和框架，包括Python、JavaScript、Java、Golang、C#、Ruby、F#、TypeScript、PHP、Node.js、C++、Visual Basic等。

最重要的是，经过几年的发展，已经有数量众多的来自各行各业的企业，采用了Serverless架构。

O’REILLY在2019年11月份发布了一份Serverless使用情况的调研报告，关于采用Serverless的行业数据分析如下图所示。

可以看到，像软件、金融、银行、咨询和专业服务、计算机、电子、通信、医疗、教育、政府、媒体与娱乐、制造等等行业都有在用Serverless。

同时，这份调研报告也指出，只有三分之一的受访者在规模小于100人的公司工作，其中企业规模大于10000人的受访者占据了差不多五分之一的份额。这在一定程度上表明，2019年关注Serverless的不仅是没有技术债务或管理费用的初创公司，大型企业也很重视Serverless。

2020年2月份，Datadog发布的一份关于Serverless的报告，再次验证了这个趋势。

Datadog的报告指出，使用Amazon Web Services的 Datadog 客户中有近一半已经采用了 Lambda。

同时，令人意外的是，AWS Lambda 的广泛采用并不是由更新、更小的公司所驱动的。相反，在基础设施规模最大的那些公司中，超过四分之三的公司都采用了AWS Lambda。

从Amazon官网上，也可以看到很多来自较大规模公司的案例，比如齐心集团、可口可乐、景泰科技、iRobot、汤森路透、Benchling、Financial Engines、Square Enix、Localytics、华夏航空、涂鸦智能、FINRA等。

这些案例覆盖的行业和领域也相当广泛，包括人工智能、物联网、航空、医疗、快消、工业自动化、金融、咨询、游戏、办公用品、非营利组织等。这也印证了O’REILLY和Datadog报告的有效性。

不仅有很多客户采用了云服务商的Serverless方案，云服务商本身，自己也有非常深入的实践。

比如阿里云推出了函数计算FC，淘宝、支付宝、钉钉等阿里系的公司，都已经将函数计算应用于生产业务。

比如Amazon推出了基于AWS Lambda的无服务器计算方案，亚马逊电商也进行了广泛深入的实践。

在reInvent 2021大会，亚马逊创始人兼CEO Andy Jassy提到，亚马逊电商一半的新应用都已经跑在AWS Lambda上，Lambda现在每月会处理上万亿次调用，换成每秒的话，已经在百万每秒的数量级，这已经相当于天猫双十一的量级。

这是非常有说服力的实践和数据。

综合以上这些情况，我们可以看到，Serverless的生态和商业成熟度，都已经达到了就绪状态，可以支持企业完成各种商业化服务的开发了。

《CNCF Serverless Whitepaper v1.0》指出，当一个业务系统的负载符合以下条件时，应该优先选择Serverless架构：

近几年，各个行业已经在这些原则的指引下进行了很多的Serverless实践。总结来看，如下三类客户很适合选择Serverless：

目前提供Serverless服务的云供应商很多，比如Amazon、Microsoft、IBM、Google、Alibaba、Tencent、Cloudflare、Huawei等，但能在国内提供良好服务并且处于市场前列的，只有Amazon、Microsoft、Alibaba和Tencent。

接下来我们就这四家服务商做一些介绍，并对比他们的解决方案。

（1）Amazon

我们在介绍Serverless历史时已经提到，Amazon Web Services（AWS）在2014年推出了AWS Lambda产品，把FaaS带入市场。

自发布以来，AWS Lambda已经成了无服务器架构的代名词。凭借着最广泛的服务类别，AWS Lambda一直保持着市场领先地位，它最著名的案例，莫过于Netflix的无服务器公有云应用。在国内，齐心集团、涂鸦智能、华夏航空等，是AWS的典型案例。

（2）Microsoft

2016年，Microsoft推出了MicrosoftAzure Cloud Functions，是AWS Lambda的重要竞争对手。Microsoft Azure Cloud Functions提供了一组与Amazon类似的服务，它更关注于Microsoft体系产品的语言和工具。Azure Functions 的一个案例是Have I Been Pwned。

（3）阿里巴巴（Alibaba）

2017年4月，阿里云发布了FaaS产品——函数计算Function Compute（FC），后续基于阿里云生态，不断完善功能。目前，阿里系的淘宝、支付宝、钉钉等已经将Serverless应用于生产业务。新浪微博、世纪联华是阿里云函数计算FC的典型客户。

（4）腾讯（Tencent）

2017年4月，Tencent发布了FaaS类型的产品——Serverless Cloud Function（腾讯云函数，SCF）。腾讯云函数与腾讯云生态整合，形成了自己的解决方案。腾讯云将全球流行的ServerlessFramework平台引入中国，还将ServerlessDays社区大会引入中国，推动了中国的Serverless技术发展。芒果TV、蘑菇街等是腾讯云函数的典型客户。

总的说来，上面提到的各大服务商都能够提供相似的服务，也都能够在托管式架构上运行各种应用，可以给用户带来Serverless的各种优势。

为了帮助你找出最适合自己的供应商，接下来我将从五个方面深入比较它们的服务：

1）方案完整性

AWS Lambda或者Alibaba函数计算FC这样的FaaS服务，仅仅是Serverless的一部分，单靠它们，难以构建真实的、复杂的业务。所以，各家云服务商，往往还会结合自己的云生态，提供各种BaaS，与FaaS集成，形成对客户更有价值的解决方案。

Amazon的方案如下图所示：

Microsoft Azure Functions的方案集如下图所示：

Microsoft的方案集，更像是应用场景的罗列，我根据网站上的信息，未能找到它所说的“一系列云服务”的列表。

Alibaba的Serverless产品家族如下图所示：

Tencent的Serverless产品家族：

综合四家云服务商官网上对自己Serverless产品的介绍，对比之后可以发现，Amazon的方案完整性最高，远超其它几家。

这跟Amazon在云服务领域的战略有很强的相关性——Amazon在IaaS领域和Serverless方面，推出商业化产品的时间，都比其它厂商领先两年，这使得它在产品研发、市场验证、客户积累、服务体系搭建等方面赢得了优势。

2）支持的编程语言

为了让用户可以在托管的环境中运行自己的应用，Serverless提供商往往会在它们所提供的公有云环境里支持多种编程语言。

Amazon：Python、C#、F#、Node.js、VisualBasic、Golang、Java、Ruby、PHP、PowerShell、Rust、C++、Custom Runtime；

Microsoft：Python、C#、F#、Node.js、PHP、Java、Bash、Batch、PowerShell、Java、JavaScript、TypeScript、Golang、Rust；

Alibaba：Python、Node.js、Golang、Java、PHP、C#、F#、PowerShell、PHP、C++、Ruby、Lua、Dart、TypeScript、Custom Runtime；

Tencent：Python、Node.js、Golang、Java、PHP、Custom Runtime；

四家供应商都支持了常见的主流编程语言，相互之间没有太大差别。

另外，Amazon、Alibaba、Tencent都支持定制运行时（Custom Runtime），客户可以根据自己的需求来支持惯用的编程语言。（我在Microsoft的官网上没有查到Azure Functions对Custom Runtime的支持。）

3）工具支持

为了方便用户开发、调试、部署、监控基于Serverless架构的应用，各家服务商必须要提供针对Serverless的各种工具。

Amazon：AWS CLI、AWS Cloud9、AWS CodePipeline、AWS Config、AWS Lambda Power Tuning、AWS X-Ray、AWS CloudFormation、AWS Toolkit for JetBrains、Amazon CloudWatch、AWS Serverless ApplicationRepository、Amazon Inspector、AWSWAF、AWS CloudTrail、AWS SSO、Amazon GuardDuty、AWS Shield、Amazon Cognito、AWS SAM。

Microsoft：VS Code、VisualStudio、Azure CLI、Azure Devops、Azure Functions Core Tools、Azure Jenkins插件、Github。

Alibaba：Funcraft、fcli、Serverless Devs Tool、Aliyun Serverless VSCode插件、Midway Serverless。

Tencent：Serverless Web IDE、Serverless Framework CLI（命令行工具）、SCF VSCode插件、ASW 工作流、CloudBase。

目前各家云服务商给出的工具链，结合开源工具，可以满足基本的Serverless应用开发与部署。

相比之下， Amazon的工具链最为完整、丰富，涵盖开发、部署、监控、迁移、安全控制与管理等各个维度。

4）开源生态

下面是一些常见的与Serverless相关的开源项目及工具，我搜集了它们和四家云服务商的融合关系。

Serverless Framework：Amazon AWS、Microsoft Azure、Google Cloud、Knative、Tencent Clound。

Midway：Amazon AWS、AlibabaCloud、Tencent Cloud

Serverless Devs：Amazon AWS、Alibaba Cloud、Tencent Cloud

Datadog：Amazon AWS、MicrosoftAzure

Triggermesh：Amazon、Google、Oracle

Claudia.js：Amazon

Zappa：Amazon

Amplify-CLI：Amazon

Knative：Amazon（AWS Lambda可以用Triggermesh移植到Knative）

Architect：Amazon AWS Lambda

LambCI：Amazon AWS Lambda

Thundra：Amazon AWS Lambda

从这些开源项目对云厂商的支持情况看，Amazon与开源生态融合程度更高一些。

在GitHub上以“Serverless”为关键字进行检索，结果也是如此，排在前面的大部分开源项目，都和AWSLambda相关。

5）第三方评价

Forrester是全球最权威的IT咨询评测机构之一，它的The Forrester Wave是业界公认最严苛的厂商综合能力评估模型之一，ForresterWave报告在全球范围内受到高度认可。

2020年3月份，Forrester发布了《The Forrester New Wave™: Function-As-A-Service Platforms, Q1 2020》。

在这次的报告中，Amazon和Microsoft处于领导者象限，其中Amazon在市场表现上遥遥领先。腾讯（Tencent）和阿里巴巴（Alibaba）处于强劲表现者象限。

2021年3月，Forrester发布了《The Forrester Wave™: Function-As-A-Service Platforms, Q1 2021》。

在这次的报告中，Amazon、Microsoft、阿里巴巴（Alibaba）处于领导者象限。其中，Alibaba首次获得领导者评价，Amazon一直是领导者，并且市场表现再次依然遥遥领先。腾讯（Tencent）处于强劲表现者象限。

通过方案完整性、支持的编程语言、工具支持、开源生态、第三方评价这五个方面的对比，可以发现，四大主流Serverless提供商，都能提供准备就绪的商业服务。

相较之下，Amazon在方案完整性、工具支持、开源生态融合性和第三方评价这几方面，具有更好的表现，遥遥领先其他几家云供应商。

Serverless的未来发展

了解了Serverless的历史、现状及供应商的情况，让我们再来看一下Serverless在未来几年的可能发展方向。

Serverless仍然处于快速发展阶段，将来Serverless的一个重要发展，就是减轻设计上的固有缺陷并消除或改善实现层面的缺陷。

现在的Serverless，各个厂商都有自己的实现，函数调用语义、打包方式、事件源、支持的编程语言等等都不相同，同时各厂商的无服务应用也依赖于其生态系统的专有 BaaS 服务，这就导致业界没有统一的标准。

目前已经有CloudEvents这样的开源项目，用于制作统一的事件格式，提升不同平台之间的服务互操作能力。未来还会有更多类似的开源或开放项目，促进Serverless平台的标准化，最后会形成业界的统一标准。

目前基于Serverless开发大型项目还比较复杂，未来如果能出现一些强大的开发框架，企业基于这类框架，方便开发大型项目，对Serverless的深入发展会非常有帮助。

目前Midway Serverless、Serverless Framework等框架，已经在做类似的事情，但都还处在基础发展阶段，未来会有具备更复杂功能的、更完善的、更强大的框架出现。

前面我在介绍Serverless的不足时，提到过“厂商锁定”问题。

未来可能会出现一些开发框架或者抽象层级更高的编程语言，能够兼容各大云平台，对云供应商的实现进行抽象和隔离。比如说，开发者要使用FaaS，不用针对AWS Lambda或AzureFunctions编程，只要基于某种新的编程语言编写代码，就可以根据需要，编译成适合AWS Lambda或者Azure Functions的执行码，上传到AWS Lambda或者Azure Functions去运行，这样就实现了一次编写、到处运行的目的，能够大大提升开发效率，同时也解决了厂商锁定问题。

目前Knative、OpenFaaS、OpenWhisk等开源Serverless项目，正在做相关的事情，但还在初级阶段。

现有的云存储服务在访问延迟和IOPS上都有明显的局限，未来可能会有新的 BaaS 存储服务出现，它们的性能与本地块存储相当，并且具有临时性和持久性存储的特性，能帮助无服务器计算扩展更多的应用类型。

Serverless的无状态，限制了很多有状态业务采用Serverless架构，同时也限制了基于Serverless构建复杂的应用。将来的Serverless解决方案，在新的存储服务的协作下，可能会对“状态”有更好的策略，能支撑更多复杂业务。

最后，援引《A Berkeley View on Serverless Computing》一文的预测作为本文的结尾：无服务计算将成为云时代的默认计算范式，在很大程度上取代Serverful 计算，从而结束客户机-服务器时代。

关注“安晓辉生涯”，遇见更好的自己

往

期

回

顾

独立开发者是程序员的好归宿吗？

我就想选择一份真正喜欢的工作，哪里错了？

轻松工资低 VS 很累工资高，怎么选？

这两种选择可以帮你对抗35岁危机

知乎热榜：毕业就失业，想当网红养活自己，靠谱吗？

欢迎添加安晓辉老师微信a32352937

一对一咨询识别上图二维码

文字咨询请戳阅读原文