随着2014年AWS Lambda的发布和流行，近年来有关Serverless的话题和讨论越来越频繁。究竟什么是Serverless？为什么需要Serverless? Serverless是否意味着从此不再需要服务器了？Serverless究竟能为开发运维带来哪些便利呢？
回溯本源
让我们先来回顾一下常见的应用服务开发上线流程。
一、直接使用物理设备：
开发者将应用程序开发测试完毕后，直接将程序和相关软件部署在物理设备上。服务器直接使用物理机。直接使用物理设备部署应用程序不可避免地需要大量人工运维和重复劳动。比方说，用户数量逐渐增长时，我们需要扩容物理设备以应对更高的网站访问压力。
这时候我们需要购置更多的物理服务器，并且搬运到机房的对应机架机柜中。然后，我们需要手动为新购置的物理服务器安装各种运行软件，填写好配置文件，手动部署启动好需要运行的应用程序。这些大量的重复运维劳动造成产品上线慢，迭代周期长。其次，使用物理设备直接部署应用程序将导致资源浪费。如今的物理服务器的配置越来越强大，64核128G在今天看来也不过是普通配置。很难想象你买了一台32核的物理机，却只想搭建个人博客。此外，电商行业经常为了应对促销秒杀等活动准备大量的物理资源，然而在非促销等流量低谷时段，大量物理资源处理闲置状态，不利于节约成本。
最后，为了解决资源浪费的问题，我们很容易想到，可以将多个应用程序部署在同一台服务器上来充分利用资源。但由此又导致了新的麻烦，不同的应用程序经常会抢占CPU，磁盘IO，内存，难以做到隔离资源，各行其是，互不干扰。
二、IaaS托管硬件
虚拟化技术的成熟直接解决了上述直接使用物理设备的几个痛点。
首先，使用IaaS平台，服务器由物理机变成了虚拟机。申请服务器资源仅需要调用IaaS平台的API或者点击控制台页面就可以轻松完成。CPU个数，内存大小，网络带宽，存储磁盘大小都可以按需指定，随心所欲。虚拟机被玩坏了也不需要重装系统修复，删除重建新虚拟机即可。扩容服务器不再需要大量的重复人工运维劳动，加速了产品上线和迭代。
其次，使用IaaS平台一定程度上减轻了资源浪费。在IaaS平台上很容易得申请和删除虚拟机，升降带宽配置等操作，这样当业务低谷时段直接删除多余的虚拟机，降低带宽购买配额，就能节约不少成本。
最后，IaaS平台解决了资源隔离的问题。不同虚拟机之前有独立CPU，内存，磁盘，网卡，不同虚拟机之前的程序不会进行资源抢占。
然而，IaaS平台仅仅为开发者做好了硬件托管的工作。开发者依然需要为虚拟机安装操作系统和各种软件，填写配置并部署应用；依然需要关注服务器，带宽，存储等资源的使用量和扩容缩容。此外，IaaS平台没有完全解决资源浪费的问题，实际上，大量虚拟机在日常运行中依然存在超低负载运行的情况。
三、 PaaS托管应用
使用PaaS平台，开发者无需关注服务器的申请采购、系统安装和资源容量。PaaS服务提供商为开发者提供好了操作系统和开发环境以及支持的SDK和API，还能自动调整资源来帮助应用服务更好的应对突发流量。有了PaaS平台，开发者仅仅需要把应用开发好，然后在PaaS平台完成服务部署，应用服务即可上线。
相比IaaS平台，PaaS平台能更加精准的为应用程序所消耗的资源计费。IaaS平台仅仅依据用户申请的资源量，如CPU核心数，网络带宽来计费，而不关注用户是否实际真正充分使用了其所申请到的资源。PaaS平台则可以通过统计应用程序所占用的CPU使用率和内存使用率来做的更精准的计费，甚至可以实现应用层面的计费，比如服务响应时间，或者应用所消耗的事务。
什么是Serverless？
图1：互联网应用传统架构的模型和Serverless架构模型
Serverless指的是由开发者实现的服务端逻辑运行在无状态的计算容器中，它由事件触发， 完全被第三方管理，其业务层面的状态则被开发者使用的数据库和存储资源所记录。
以上图1为例，图中上半部分描述的是互联网应用传统架构的模型：用户客户端APP与部署在服务器端的常驻进程通信，服务端进程处理该应用的大部分业务逻辑流程。下半部分则描述了Serverless架构模型。与传统架构模型大的不同在于，互联网应用的大部分业务逻辑流程被转移到客户端上，客户端通过调用第三方服务接口来完成诸如登录，鉴权，读取数据库等通用业务场景；高度定制化的业务逻辑则通过调用第三方FaaS平台执行自定义代码来完成。总体上看，Serverless架构将传统架构中的服务器端的整串总体流程拆分成在客户端上执行一个个第三方服务调用或FaaS调用。
回顾之前所述，无论是直接使用物理服务器设备部署程序，还是基于IaaS平台托管硬件，或者使用PaaS平台托管应用，开发部署互联网应用都离不开传统的客户端-服务器模式，即客户端向服务端发送请求，服务器运行处理各种业务逻辑，并响应来自客户端的请求。至于物理机，IaaS乃至PaaS，归根结底只是服务器程序的部署模式不同。
而在Serverless架构中，软件开发者和运维工程师们不在需要关心服务器的部署，架设，伸缩，这些问题交给云平台商来解决，程序员们得以将精力投入用代码来实现业务逻辑中，而不是管理服务器。Serverless并不意味着不再需要服务器了，只是服务器资源的申请，使用，调度伸缩由云服务商自动实现，应用开发者无需关心。
Serverless如何工作？
以一个简单需求为例，论坛网站需要对用户上传的图片生成一个缩略图。
我们使用我们自研的通用计算(UGC)来实现该功能。
图2：UGC上传图片生成一个缩略图
如上图2所示，使用UGC实现这一功能操作步骤如下：
1.用户将缩略图算法代码打包推送到UGC算法仓库中。
2.用户从UFile中读取原始图片作为输入数据，调用UGC
3.SubmitTask API，指定缩略图算法，执行缩略图转换任务。
4.UGC平台执行缩略图转换算法，将转换后的缩略图返回给用户。
用户将得到的结果缩略图存储到UFile中。
整个过程中，开发者仅仅需要将缩略图算法实现函数代码镜像提交到UGC算法仓库中，然后调用UGC的提交任务API，输入源图片数据，即可获得计算结果。
从以上过程可以总结出：使用Serverless，开发者无需考虑服务器细节，只需要负责编写发生某些事件后所需执行的代码。云供应商将负责提供用于运行这些代码的服务器，并在必要时对服务器进行缩放。执行完毕后，承担这些功能的容器会立刻停用，用户只需为运行代码过程中所消耗的资源付费。这种模式也被称为做函数即服务（Function-as-a-Service，FaaS）。
与非Serverless方案的对比
上述场景如果使用非Serverless方案，大体架构如下图3所示：
图3：非Serverless方案架构图
该方案需要维护一组UHost服务集群，服务器中部署图片缩略转换程序。UHost的服务程序先从UFile中读取源图片，使用图形库将其转换成缩略图并再存回UFile中。相比之前的Serverless方案，有以下几点对比：
开发者需要关心服务器端程序开发设计，将图片处理程序部署成服务端程序，并购置服务器部署并运维管理这批UHost服务器。而使用UGC，开发者无需关注服务器端，只需要将图形库函数提交到UGC算法仓库中并调用UGC API完成计算任务即可。
UHost集群无法自动为突发流量自动伸缩扩容，需要运维工程师手动购置更多的UHost并部署上线扩容。而UGC能根据突发的流量自动伸缩，运行更多的函数容器。
UHost服务器只要在运行就必须为之付费，无论请求量和负载的高低。UGC只需要为实际的调用次数和函数实际执行时间付费，真正实现了按需分配付费。
Serverless相比PaaS的特点
相比PaaS，Serverless在以下几个方面更具优势：
开发者无需关注服务器程序设计，部署和运维管理，开代码重心从此转移到调用方而非服务器端。
更精细粒度的计费模式，真正实现了按需付费(Pay as you go)。使用PAAS托管应用，只要将应用部署上去，无论访问量或者负载高低，都需要计费。而使用Serverless，用户仅仅需要为函数真正调用到的次数和执行时间付费。
Serverless的适用场景
使用Serverless前，你需要了解的Serverless的适用场景特点
Serverless平台运行的是代码函数的片段，而不是整个程序。例如生成缩略图场景中，UGC仅仅运行的是用图形库处理图片这段代码。
代码必须做彻底的无状态改造。Serverless平台会自动为突发的流量自动扩展运行函数代码所需要的容器，但用户代码中无法得知其容器的部署环境情况。两次不同的Serverless调用必须是非耦合无关联的。
用户无需关注水平扩展，Serverless平台会自动根据调用量扩展运行代码所需要的容器，轻松做到高并发调用。
仅仅需要上传代码文件或者代码容器镜像即可完成应用部署。
代码运行的生命周期非常短暂。通常Serverless服务商，会限制代码的大运行时间，例如AWS Lambda为5分钟。
每次Serverless调用，Serverless平台都会启动容器来运行对应代码，调用结束后将容器销毁。因为容器创建存在一定开销，所以Serverless不太适合对延迟要求及其苛刻的场景。
不是银弹
Serveless架构在某些场景下拥有明显的优势，但它不是解决一切架构问题的灵丹妙药，更不是传统架构的革命者和替代者。架构上说，Serverless更像是一种粘合剂。以下是一些常见的不适用Serverless的情况。
Serverless平台需要为每次FaaS调用创建一个容器运行对应代码。前面提到过，由于创建容器并初始化代码运行环境存在一定程序的开销和延时（通常在10ms级），Serverless架构难以胜任对延迟要求非常苛刻的场景。
同样的，由于启动容器进程开销较高，Serverless架构难以应对非常高的并发请求场景。通常云服务商会对用户的并发调用数做限制，比如AWS Lambda是1000。
通常FaaS平台会对代码运行时间做大时间限制。如果你的代码需要运行较长时间才能返回结果，需要慎重考虑使用Serverless。例如刚才提到的，AWS Lambda对代码大运行时间限制为5分钟。
由于代码容器在Serverless平台部署位置环境的不确定性，使用Serverless时，我们必须对代码做无状态改造。如果你两次调用存在关联偶合，同样请慎重考虑Serverless。
其他主流公有云服务商Serverless产品
除了众所周知的AWS Lambda，目前常见的Serverless产品还有刚才提到的UCloud的通用计算 (UGC)。
作为分布式大规模并行计算服务，UGC能够充分利用UCloud多个区域内的多个可用区的计算资源，提供基于云平台的高可用性和高并发性，同时满足图片处理、机器学习、大数据处理、生物数据分析等领域的计算需求。它具备以下特性：
1.Serverless属性。用户无需关心计算资源的的交付部署，以用户算法代码为中心；计算资源服务化，用户通过API使用计算资源。
2.按需付费(Pay As You Go)。用户仅需要为实际消耗的计算资源付费。
3.提供十万核级的海量计算资源，轻松支持高并发计算任务请求，自动实现资源分配和扩展。
4.具备高可用和跨可用区自动容灾能力。
作者简介：陈绥，UCloud 高级研发工程师，UCloud创新产品线通用计算(UGC)团队核心成员，负责UCloud通用计算(UGC)产品的研发和运营，具有多年Serverless研发及架构经验。
本文为《程序员》原创文章
热门专题
