Serverless

一、什么是Serverless

Serverless，云计算的一种应用模式。并不是说没有服务器，而是让我们可以不用关心服务器。

为啥说不用关心服务器呢？

Serverless有两个概念，BaaS（Backend as a Service，后端即服务）和FaaS（Functions as a Service，函数即服务）。

1、BaaS，云服务用API的形式提供了基础服务，如云端数据/文件存储（例如Parse、Firebase）、消息推送（例如极光推送、个推）、应用数据分析等等。应用尽有。

2、FaaS，用户写的业务逻辑，通过代码形式提交到云就完事了（注意是提交，而不是部署），云服务商提供的FaaS框架会将它们进行管理，注册成一个个事件，触发即自动执行。（我粗浅地将FaaS理解成类似Tomcat的Web服务器，只要我们将网站打包往里面一丢即可，有人访问就会返回一张张页面）。

可见这种模式，对用户而言，要基础服务，可以直接调用；自己独特的业务逻辑，提交即可直接运行在云端，根本没有也无须有服务器的概念。

使用BaaS和FaaS是Serverless应用的基本特征，符合这两个基本特征的应用可称为Serverless应用。

二、Serverless有什么优点？

1、让我们可以专注于业务

因为无须考虑任何主机、操作系统、数据库、甚至像tomcat之类的web服务器，我们可以将精力集中在业务上。

2、业务更敏捷

我们可以只编写核心业务代码，像加载资源、配置等辅助功能都不再有。

其实这个有时可能会很不方便。配置很多时对于一个完整的程序而言，是必不可少的。从Serverless的应用特点来看，我估计一个系统，极少会完全采用Serverless架构，而是将核心代码采用Serverless，而相关辅助功能采用其他架构的混合模式。

3、利于水平扩展

Serverless 的FaaS会为每一个事件、每一个API请求都启动一份新的进程，而不是线程，因此没有内存等资源共享。最大进程数目只取决于FaaS框架。

4、省钱

由于无须维护一个虚拟机，或者云服务器，使用者只须为代码的执行时间付费；而代码通过事件触发，且每次请求的生命周期都很短（太长的不适宜用Serverless），所以直接的花费大大节省了。如果是虚拟机，云主机，空间租用则不然，即使夜深人静，系统无人访问，我们也要为这部分时间付费。

节省的间接花费就更多了：

水平扩展的粒度从原来的云主机细化到进程，不用再购买闲置的云主机来抵消Auto-Scaling的配置不精确带来的影响。业务的敏捷性提高也降低了营运成本，我们不再需要精通操作系统配置和管理的营运人员，不仅节省了人力成本，也节省了应用从开发到上线的时间。

三、Serverless的缺点

1、启动速度慢

FaaS并不像虚拟机一样随时处于待机状态，因此需要花费额外的时间进行代码加载；同时，目前Serverless应用通常运行在公共云的多租户环境中，启动延时还受系统负载影响，很难保证应用在规定时间内被运行。这对实时系统是无法接受的。

2、无法用于高并发应用

为每个请求启动一个进程开销太高。

3、运行时间受限

Serverless应用无法常驻内存，运行的时间是受限的。如果你的应用无法在数分钟内完成的工作，那Serverless不是你的选择，例如AWS Lambda给予进程的最长运行时间是5分钟，超时后进程将被强制终止。这对程序设计提出了挑战。

4、Serverless调用之间不能共享状态让编写复杂程序变得极度困难。

5、代码要使用云服务商提供的FaaS框架进行改写，比如AWS Lambda，一方面增加了工作量，另一方面可能每个云服务商的框架都不一样，移植不便；且运行这些框架还可能需要使用云服务商指定的服务，与云服务商绑定太紧。

上面都是Serverless架构的一些固有局限，它们源于Serverless架构的特点，很难随着时间的推移、技术的完善而解决。除此之外，作为一个新的技术，Serverless还面临着集成测试困难、Vendor Lock-in、调试监控困难、版本控制等诸多不足，每一项都会成为采用Serverless架构的阻碍。

由于这些局限性，Serverless架构不会成为复杂应用的架构首选，相反，它应该是后端小程序的未来。

四、Serverless应用场景

例如：

1、低频请求场景

物联网行业中，由于物联网设备传输数据量小，且往往是固定时间间隔进行数据传输，因此经常涉及低频请求场景。例如：物联网应用程序每分钟仅运行一次，每次运行50ms，这意味着CPU的使用率为0.1%/小时，这也意味着其实有1000个相同的应用可以共享计算资源。而Serverless架构下，用户可以购买每分钟100ms的资源来满足计算需求，通过这种方式就能够有效解决效率问题，降低使用成本。

2、流量突发场景

移动互联网应用经常会面对突发流量场景，例如：移动应用的通常流量情况是QPS 20，但每隔五分钟会有一个持续10s的QPS 200流量（10倍于通常流量），传统架构下企业必须扩展QPS 200的硬件能力来应对业务高峰，即使高峰时间仅占整个运行时间的4%；而在Serverless架构下，用户可以利用弹性扩展特性，快速构建新的计算能力来满足当前需求，当业务高峰后，资源能够自动释放，有效节省成本

云端的应用有大量的小程序场景，例如识别一张图片、对一段音频/视频进行编解码、对IOT设备的请求返回一小段数据、将客户提交的工单通过邮件通知客服人员等等。这些基于事件触发的小程序在传统架构中实现起来是相对复杂的，你往往需要为20%的核心业务运营80%的支撑业务。Serverless完美的解决了这些问题，它可以成为复杂应用的一种补充架构。我们可以将无状态的、事件触发的业务拆分成Serverless应用，让整个架构变得更加的简洁和高效。

五、与其他云计算模式的比较

以往，云计算有

IaaS（基础即服务，如VM，即虚拟机，或者存储空间？）

PaaS（平台即服务，例如阿里云，自带操作系统.）

SaaS（软件即服务，成套软件，比如在线CRM，ERP）

三种模式

Serverless则将粒度细分成一个个函数。

1、Serverless VS PaaS

很多人认为Serverless是PaaS的一种，或者是PaaS的一种特殊形态。或者说，Serverless是细粒度的一种PaaS？我可能对PaaS理解得不对，怎么觉得PaaS跟接近虚拟机呢。

2、Serverless VS 微服务

Serverless和微服务没有直接关系，但两者有相似之处，例如都需要做业务拆分、强调无状态、具有敏捷特性等。Serverless在很多方面比微服务粒度更细，要求也更严格。例如微服务以服务为边界拆分业务，Serverless以函数为边界拆分业务；微服务可以有跨调用的内存状态共享，Serverless要求调用彻底无状态。此外，Serverless依赖BaaS提供第三方依赖，而微服务可以自由选择第三方依赖来源，例如使用本地搭建的传统中间件栈（如本地MySql和消息总线）。

3、Serverless VS 容器

Serverless是一种软件设计架构，容器是软件架构的承载者。但是，我觉得FaaS框架能够管理我们提交的代码并执行，具备了容器的功能。

另一种比较：

目前，云服务商向用户提供计算资源服务的架构主要有三种，包括：虚拟机架构（VM）、容器服务架构（Container）、功能函数架构（Function即Serverless）。其主要对比如下图所示：



相关文章

Serverless，后端小程序的未来

Serverless 架构：用服务代替服务器

你需要了解的未来技术趋势——Serverless怎样改变未来架构?

云计算