在云原生架构的浪潮中，Serverless 技术正逐渐崭露头角， 是最近几年业界很火的技术名词，你可以在国内外各种技术大会上看到它的身影，主流云服务商也不断地推出 Serverless 相关的云产品和新功能（比如 AWS Lambda、阿里云函数计算、腾讯云云函数），各种关于 Serverless 的商业和开源产品也层出不穷（比如 Serverless Framework、OpenFaaS、kubeless）。
IaaS（Infrastructure as a Service，基础设施即服务）和容器技术是云的基础设施，可以为上层应用的运行提供海量低成本的计算资源。以 Kubernetes 为代表的容器编排服务是支撑云原生应用的操作系统，负责高效管理基础设施资源。面向特定领域的后端云服务（Backend as a Service，BaaS）提供了性能高度优化、抽象度更高的 API，成为构建云原生应用的重要元素。随着云原生的发展，存储、数据库、中间件、大数据、AI 等领域出现了越来越多的全托管、Serverless 形态的云服务，而不是自建存储系统和部署数据库软件。
一、Serverless 是什么
1、Serverless的概念
Serverless 架构是一种无需管理服务器的新型架构，它允许开发人员专注于编写代码，而无需关心服务器的运行和维护。Serverless 技术可以自动扩展和缩减资源，降低运营成本，提高开发效率。Serverless 技术真正做到了在部署应用时无须涉及基础设施的建设，自动构建、部署和启动服务。
简单理解就是，开发者在使用的时候不用过多考虑服务器的问题，你就管写代码就好，不需要管理和操作云端或本地的服务器，让开发人员与服务器之间没有了直接交互，仿佛服务器不存在一般，所以才有了“无服务器”的说法。
来看看云原生计算基金会给出了Serverless的官方定义：构建和运行不需要服务器管理的应用程序的概念。
广义上来讲， Serverless 是一种架构思想，即软件构建和运行时不需要关心服务器；
狭义上来讲， Serverless 是 FaaS 和 BaaS 的组合，是当前主流的技术实现。
Serverless 架构的主要特点是按量付费、弹性伸缩、不用运维， 这是区分一个架构是否是 Serverless 架构的关键因素。
2、为什么需要Serverless
程序员一直在寻找更有效的方法来维持软件开发生命周期，而无服务器架构且可以帮助企业专注于应用程序开发，不再需要担心服务器等基础设施的部署建设和运维管理，还可以很好的降低开发成本和缩短开发周期。
![]()
无服务器体系架构的开发建立在虚拟化的成就基础上开始的，虽然这个过程是相当连续的，但还是有几个值得注意的里程碑：
物理机时代：2000 年之前，我们需要通过物理机部署网站。
虚拟机时代：2000 年之后，虚拟化技术发展成熟，云计算行业蓬勃发展，我们可以基于 IaaS 和 PaaS 部署应用，提高稳定性。
容器时代：2013 年云计算进入容器时代，我们可以通过容器技术打包应用及运行依赖，不用关心运行环境。
Serverless 时代：最近几年，云计算进入 Serverless 时代，我们不再需要关心服务器，应用也天然具有弹性。
![]()
如上图，我们可以看出开发底层架构的发展一共经历了5个里程碑的过程，就像人类的演进过程，代表着生产力的解放，极大提升了开发人员的的效率。Serverless来到了开发架构的高级阶段。
可能有人会问，我们为什么一定要Serverless呢？
其实从物理机到 Serverless，就像我们买车一样，如果要买一辆私家车，这个车的车况保险全部要自己关心，然后你要自己开；到了虚拟机之后，我们把业务host 到云上，就像汽车租赁；然后再到网约车，我不用买车，不用关心车况，我们外出办事，只需要打个车，完全按需付费，按需弹性。
![]()
网约车就像Serverless，我们只需要享受服务，不需要关注车的情况，也不用管车的运行，只需要买这个打车服务就行了。
纵观云计算的发展史，从物理机到虚拟机，从 IaaS、PaaS 到 FaaS，从容器到 Serverless，都是一个去服务器的一个过程。有了 IaaS，我们不需要关注物理机；有了 PaaS，我们不需要关注操作系统；有了容器，我们不需要关心运行环境；而 Serverless 技术的出现，能够让我们不再关心传统的运维工作，让我们更专注于业务的实现，把时间精力花在更有意义的事情上，让我们以更快的速度、更低的成本完成应用的开发迭代，进而创造出更大的价值。而这也正是 Serverless 架构兴起的必然因素。
在 Serverles 架构下，用户仅需要关心业务实现，而操作系统、虚拟化和硬件层面的实现则全部交给服务商统一维护，达到了提高软件开发/交付效率、降低成本（资源成本、人力成本）的目的。
3、Serverless特点
Serverless 消除了服务器等底层基础设施的运维复杂度，让开发人员能够更好地专注于业务逻辑的设计与实现，包含以下特点：
全托管的计算服务
客户只需要编写代码构建应用，而无须关注同质化的、负担繁重的服务器等基础设施的开发和运维等工作。
通用性
结合丰富的 BaaS 云服务能力，支持云上所有重要类型的应用。
自动的弹性伸缩
云平台会根据函数的出发事件动态调整资源，以满足应用的需求，大幅度降低用户资源容量规划的难度。
按量计费
开发者只需要为实际使用的资源付费，而不需要预先购买或租用服务器，企业的使用成本得到有效降低，无须为闲置资源付费。
事件驱动
Serverless 函数通常是通过事件触发器来执行的，比如 HTTP 请求、消息队列等。
4、什么不是 Serverless
经常被同学们问到另一个问题，那就是 PaaS、Kubernetes 、云原生等技术是不是 Serverless？如果不是，它们与 Serverless 有什么关系？这个问题很常见，你可以根据我刚刚总结的 Serverless 的特点进行判断。
在01讲中我已经提到了，PaaS （平台即服务）是云计算虚拟机时代的主要形态之一。 它是指云厂商提供开发工具、依赖库、服务和运行平台等能力，开发者可以依赖这些能力将自己的应用直接部署在云平台上，不用关心底层的计算资源、网络、存储等。虽然与Serverless 很类似，但依旧存在一些区别。
Kubernetes 本身也不是 Serverless，只是在概念方面有些类似。 Kubernetes 是一种容器编排技术。在 Kubernetes 中应用运行的基本单位是 Pod（容器组），Pod 是应用及运行环境的集合，所以你也不用关心服务器了。基于 Kubernetes，你能很方便地进行 Pod 的管理，并且实现应用的弹性伸缩。
但从运维的角度来看，主流的 Kubernetes 服务提供商，如 EKS (Amazon Elastic Kubernetes Service) 和 ACK（阿里云容器服务），提供的都是 Kubernetes 集群托管和运维服务，开发者可以方便地管理 Kubernetes 集群中硬件、存储、Pod 等资源，但上层应用的运维和调度还是需要开发者自己进行。
从成本的角度来看，Kubernetes 也无法做到按代码执行次数和实际消耗资源计费，还是和传统的 Serverful 一样，按照资源数量计费。
所以，Kubernetes 是介于 Serverful 和 Serverless 中间的产物。
而云原生指的是原生为云设计的架构模式，就是应用一开始设计开发就按照在云上运行的方式进行，充分利用云的优势。Serverless 几乎封装了所有的底层资源调度和运维工作，让你更容易使用云计算基础设施，极大简化了基于云服务的编程。
因此 Serverless 是云原生的一种实现，云原生的另一种实现是 Kubernetes。
5、Serverless 的优缺点
没有一项技术是十全十美的，Serverless 也一样。了解它的优缺点，可以让你今后更好地进行技术选型，决定是否用 Serverless 进行应用开发。根据 Serverless 的定义，Serverless 的优点主要有：不用运维、弹性伸缩、节省成本、开发简单、降低风险、易于扩展。 但它也存在缺点。
1）依赖第三方服务
要用 Serverless，就要用云厂商提供的 Serverless 产品，比如 FaaS、BaaS，这样业务就和第三方云厂商绑定了。并且一旦你选择了一个云厂商，要想从一个云移到另一个台，成本很高（因为现在 Serverless 还没有一个统一的标准，云厂商各做各的，Serverless 产品也都不一样）。所以，依赖第三方服务是优点也是缺点。当然，我觉得这是大势所趋，让专业的人做专业的事，可以极大提高生产力。
2）底层硬件的多样性
目前 Serverless 的技术实现是 FaaS 和 BaaS。你的应用代码在 FaaS 上运行，但其底层的硬件资源多样，也不确定，云厂商可以灵活地选择服务器来运行你的代码，这就让运行函数的物理环境变得不同，甚至有的函数会运行在不同代的 CPU 上。如果代码不依赖底层 CPU，那影响可能是不同 CPU 性能有差异；如果代码必须运行在某种类型的 CPU 或 GPU 上，那就需要云厂商提供这种能力了。这其实也暴露了云厂商的目的，就是最大化平衡资源利用效率与成本。当然，如果你不是特别关注底层硬件，影响也不大。
3）应用性能瓶颈
基于 Serverless 架构的应用，函数运行前需要现初始化函数运行环境，这个过程需要消耗一定时间。因为函数不是持续“在线”的，而是需要运行的时候才启动（不像传统应用，服务是一直启动的）。
从资源利用率来讲，这种模式可以节省资源，但从应用性能上来讲，这就会降低应用性能，并且还要靠云厂商实现性能优化（让延时只有几毫秒或者几十毫秒，毕竟一个接口最大的耗时是在网络上，可能长达几百毫秒）。但如果你的应用对性能非常敏感，就需要考虑一下怎么去优化应用性能了。
4）函数通信效率低
传统的 MVC（Model-View-Controller） 架构模式中，View 层方法调用 Model 层方法，都是在内存中进行的。而在 Serverless 应用中，函数与函数之间就完全独立了。如果两个函数的数据有依赖，需要进行通信、交换数据，就要进行函数与函数之间的调用（调用方式是 HTTP 调用）。相比之前的内存调用，数据交互效率显然低了很多。而这个问题的本质，是 FaaS 还没有比较好的数据通信协议或方案。
5）开发调试复杂
Serverless 架构正处于飞速发展的阶段，其开发、调试、部署工具链并不完善（基本是每个云厂商各玩各的）。另外，应用依赖的第三方云服务也很难进行调试。要想在本地开发调试 Serverless 应用，还是比较复杂。
不过在我看来，虽然 Serverelss 存在缺点，但随着技术的不断成熟，这些问题在未来都能得到解决。
二、Serverless关键技术
Serverless之所以能实现“按量计费”和“自动扩容”，与其涵盖的诸多技术有关，最关键的两个技术分别为BaaS（Backend as a Service，后端即服务）和FaaS（Function as a Service，函数即服务）。
简单理解，Serverless = Faas+ Baas。
1、FaaS（Function as a Service，函数即服务）
在迁往FaaS的过程中，唯一需要修改的代码是“主方法/启动”代码，其中可能需要删除顶级消息处理程序的相关代码（“消息监听器接口”的实现），但这可能只需要更改方法签名即可。在FaaS的世界中，代码的其余所有部分（例如向数据库执行写入的代码）无须任何变化。
相比传统系统，部署方法会有较大变化 – 将代码上传至FaaS供应商，其他事情均可由供应商完成。目前这种方式通常意味着需要上传代码的全新定义（例如上传zip或JAR文件），随后调用一个专有API发起更新过程。
FaaS中的函数可以通过供应商定义的事件类型触发。对于亚马逊AWS，此类触发事件可以包括S3（文件）更新、时间（计划任务），以及加入消息总线的消息（例如Kinesis）。通常你的函数需要通过参数指定自己需要绑定到的事件源。
大部分供应商还允许函数作为对传入Http请求的响应来触发，通常这类请求来自某种该类型的API网关（例如AWS API网关、Webtask）。
![]()
首先我们来看FaaS函数即服务，也叫Serverless Computing，可让我们随时随地创建、使用、销毁一个函数。
简单来说，FaaS 就是“有事我就干，没事我就躺”。请求多的时候启动多个实例提供服务，没有请求时候则关闭所有实例。
举个例子，有这么一个业务需求：当用户上传一张图片，服务器监听到图片上传，给这个图片打水印，再把加了水印的图片传到oss上，保存了原图和加了水印的图。
上面的图片加水印的服务，就没有状态，它只是读图片、加水印，然后再上传图片，操作都是计算。Serverless服务按量付费，没有用户上传图片时候不会产生服务器租金。
FaaS意在无须自行管理服务器系统或自己的服务器应用程序，即可直接运行后端代码。其中所指的服务器应用程序，是该技术与容器和PaaS（平台即服务）等其他现代化架构最大的差异。
FaaS可以取代一些服务处理服务器（可能是物理计算机，但绝对需要运行某种应用程序），这样不仅不需要自行供应服务器，也不需要全时运行应用程序。
FaaS产品不要求必须使用特定框架或库进行开发。在语言和环境方面，FaaS函数就是常规的应用程序。例如AWS Lambda的函数可以通过Javascript、Python以及任何JVM语言（Java、Clojure、Scala）等实现。然而Lambda函数也可以执行任何捆绑有所需部署构件的进程，因此可以使用任何语言，只要能编译为Unix进程即可。FaaS函数在架构方面确实存在一定的局限，尤其是在状态和执行时间方面。
2、Baas (Backend as a service，后端即服务)
BaaS(Backend as a Service)则是Serverless另一半的重要组成，BaaS即后端即服务，是指具备高可用性和弹性，而且免运维的后端服务。理解BaaS，需要搞清楚它与PaaS的区别。
首先BaaS并非PaaS，它们的区别在于：PaaS需要参与应用的生命周期管理，BaaS则仅仅提供应用依赖的第三方服务。典型的PaaS平台需要提供手段让开发者部署和配置应用，例如自动将应用部署到Tomcat容器中，并管理应用的生命周期。BaaS不包含这些内容，BaaS只以API的方式提供应用依赖的后端服务，例如数据库和对象存储。BaaS可以是公共云服务商提供的，也可以是第三方厂商提供的。其次从功能上讲，BaaS可以看作PaaS的一个子集，即提供第三方依赖组件的部分。
BaaS服务还允许我们依赖其他人已经实现的应用逻辑。对于这点，认证就是一个很好的例子。很多应用都要自己编写实现注册、登录、密码管理等逻辑的代码，而对于不同的应用这些代码往往大同小异。完全可以把这些重复性的工作提取出来，再做成外部服务，而这正是Auth0和Amazon Cognito等产品的目标。它们能实现全面的认证和用户管理，开发团队再也不用自己编写或者管理实现这些功能的代码。
![]()
说简单点，BaaS就是专门支撑FaaS的服务。FaaS就像高铁的车头，如果我们的后端服务还是老旧的绿皮火车车厢，那肯定是要散架的，而BaaS就是专门为FaaS准备的高铁车厢。
微信小程序云开发，就是一种Serverless的应用场景，让前端工程师不仅可以开发页面还可以通过云函数(Faas)来写业务，而且还提供了基础存储(Baas)。
Serverless发展的一个方向，也就是追求这种一体化的开发体验。
Serverless架构的最大优势，显然就是帮助用户彻底摆脱了基础设施管理这样的“杂事”，更加专注于业务开发，从而提升了效率，降低了开发和运营成本。
Serverless的出现，可以让用户按照实际算力使用量进行付费，属于真正的“精确计费”。
换言之，用户的每一分钱，都花在了刀刃上。
3. 无服务器（Serverless）计算如何工作？
与使用虚拟机或一些底层的技术来部署和管理应用程序相比，无服务器计算提供了一种更高级别的抽象。因为它们有不同的抽象和“触发器”的集合。
拿计算来讲，这种抽象有一个特定函数和抽象的触发器，它通常是一个事件。以数据库为例，这种抽象也许是一个表，而触发器相当于表的查询或搜索，或者通过在表中做一些事情而生成的事件。
比如一款手机游戏，允许用户在不同的平台上为全球顶级玩家使用高分数表。当请求此信息时，请求从应用程序到API接口。API接口或许会触发AWS的Lambda函数，或者无服务器函数，这些函数再从数据库表中获取到数据流，返回包含前五名分数的一定格式的数据。
一旦构建完成，应用程序的功能就可以在基于移动和基于 Web 的游戏版本中重用。
这跟设置服务器不同，不是必须要有Amazon EC2实例或服务器，然后等待请求。环境由事件触发，而响应事件所需的逻辑只在响应时执行。这意味着，运行函数的资源只有在函数运行时被创建，产生一种非常高效的方法来构建应用程序。
三、Serverless 的应用场景
在现阶段，Serverless主要应用在以下几个场景。首先在Web及移动端服务中，可以整合API网关和Serverles服务构建Web及移动后端，帮助开发者构建可弹性扩展、高可用的移动或 Web后端应用服务。在IoT场景下可高效的处理实时流数据，由设备产生海量的实时信息流数据，通过Serverles服务分类处理并写入后端处理。另外在实时媒体资讯内容处理场景里，用户上传的音视频到对象存储OBS，通过上传事件触发多个函数，分别完成高清转码、音频转码等功能，满足用户对实时性和并发能力的高要求。无服务器计算还适合于任何事件驱动的各种不同的用例，这包括物联网，移动应用，基于网络的应用程序和聊天机器人等。这里简单说两个场景，方便大家思考。
场景一：应用负载有显著的波峰波谷
Serverless 应用成功与否的评判标准并不是公司规模的大小，而是其业务背后的具体技术问题，比如业务波峰波谷明显，如何实现削峰填谷。一个公司的业务负载具有波峰波谷时，机器资源要按照峰值需求预估；而在波谷时期机器利用率则明显下降，因为不能进行资源复用而导致浪费。
业界普遍共识是，当自有机器的利用率小于 30%，使用 Serverless 后会有显著的效率提升。对于云服务厂商，在具备了足够多的用户之后，各种波峰波谷叠加后平稳化，聚合之后资源复用性更高。比如，外卖企业负载高峰是在用餐时期，安防行业的负载高峰则是夜间，这是受各个企业业务定位所限的；而对于一个成熟的云服务厂商，如果其平台足够大，用户足够多，是不应该有明显的波峰波谷现象的。
场景二：基于事件的数据处理
视频处理的后端系统，常见功能需求如下：视频转码、抽取数据、人脸识别等，这些均为通用计算任务，可由函数计算执行。
开发者需要自己写出实现逻辑，再将任务按照控制流连接起来，每个任务的具体执行由云厂商来负责。如此，开发变得更便捷，并且构建的系统天然高可用、实时弹性伸缩，用户不需要关心机器层面问题。
四、Serverless 的未来展望
Serverless 技术的崛起标志着云原生时代的来临，它将为应用开发带来全新的变革，随着越来越多的开发者和企业采用 Serverless 技术，我相信 Serverless 技术将成为未来云原生架构的重要支柱之一，推动企业数字化转型的进程。
随着云原生技术的不断发展，Serverless 技术也将迎来更广阔的应用场景和发展场景，未来，可以预见 Serverless 将成为云原生架构的重要组成部分，为开发者提供更简单、更灵活、更高效的开发方式。对于企业来说，支持Serverless计算的平台可以节省大量时间和成本，同时可以释放员工，让开发者得以开展更有价值的工作，而不是管理基础设施。另一方面可以提高敏捷度，更快速地推出新应用和新服务，进而提高客户满意度。但是Serverless不是完美的，它也存在一些问题，需要慎重应用在生产环境。毕竟，Serverless或许也仅仅是一个过渡的产物，但是这就要交给时间去验证了。
