云原生Serverless技术深度解析：开启无服务器时代的新篇章

　　在云原生架构的浪潮中，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 很类似，但依旧存在一些区别。

　　付费标准： PaaS 的部署单位是应用，大部分 PaaS 还是将应用部署直接在服务器(虚拟机)上。所以我们对 PaaS 付费，依然是按资源付费，而不是按实际使用量付费。

　　弹性伸缩： 有的 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或许也仅仅是一个过渡的产物，但是这就要交给时间去验证了。