所谓Serverless，你理解对了吗？

随着DevOps和微服务的理念日渐被IT业界所接受，另外一个新名词Serverless也 开始进入人们的视野。尤为在今年4月份国内两大云服务厂商阿里云、腾讯云前后推出各自的Serverless产品以后，Serverless一时洛阳纸贵。那到底什么是Serverless，它跟DevOps和微服务又有什么样的联系呢？本文将尝试揭开Serverless的神秘面纱，让你一睹为快。

1 Serverless != No Server

首先，必须澄清的是Serverless并不能按字面上理解为无服务器，而是说对应用开发者而言，再也不须要操心大部分跟服务器相关的事务，好比服务器选购、应用运行环境配置、负载均衡、日志搜集、系统监控等，这些事情通通交给Serverless平台便可，应用开发者惟一须要作的就是编写应用代码，实现业务逻辑。为了不歧义，本文将保留使用Serverless，而不是其一般的中文翻译无服务器。

Serverless最先由Amazon提出，第一个Serverless平台是2014年年末推出的Amazon Lambda，应用开发者只须要上传代码或者应用包，便可发布一个应用。以后全球各大云服务厂商都纷纷推出各自的Serverless平台，好比Google Cloud Functions，Azure Functions，IBM Cloud Functions，以及前面提到的阿里云函数计算和腾讯云无服务器云函数等。在云服务厂商以外，开源社区也涌现出不少优秀的Serverless框架，好比Apache OpenWhisk，Spring Cloud Function，Lambada Framework，webtask等。

根据Serverless Architectures一文，Serverless应用能够细分为BaaS和FaaS两类，

• BaaS: Backend as a Service，这里的Backend能够指代任何第三方提供的应用和服务，好比提供云数据库服务的Firebase和Parse，提供统一用户身份验证服务的Auth0和Amazon Cognito等。
• FaaS: Functions as a Service，应用以函数的形式存在，并由第三方云平台托管运行，好比以前提到的Amazon Lambda，Google Cloud Functions等。

本文主要讨论的是FaaS，这也是目前各种Serverless平台和框架主要支持的类型。

2 函数即应用

当咱们讨论函数时，咱们到底在讨论什么？

函数，往大了说能够是一个应用的main函数，往小了说也能够是一个简单的加法函数，那到底该如何理解FaaS中的函数呢？先来看张图。

左侧的Monolith即咱们常说的单体应用，中间是微服务，右侧就是FaaS中的函数（为了不歧义，如不特殊指明，下文提到的函数都是指代FaaS中的函数）。如同一个单体应用能够按业务模块拆分红多个微服务，一个微服务也能够按使用场景拆分红多个函数。好比一个广告微服务，至少能够拆分出实时竞价、展现计数、报表查询等多个函数。也就是说，FaaS中的函数和微服务中的API是同一粒度的。但不一样于API，在Serverless架构下，每一个函数都是独立部署，按需执行。那这样的拆分有意义吗？接着往下看。

3 搞懂Serverless的4把钥匙

和其余架构相比，Serverless有如下4个特色。

3.1 运行成本更低

不管是过去的IDC，仍是现在的云主机，本质上都是一种包月计费模式，也就是说，无论有没有用户访问你的应用，也无论你有没有部署应用，你都要付相同的钱。但对于Serverless应用，你只须要根据实际使用的资源量（好比Amazon Lambda是按内存大小*计算时间计算资源量）进行付费，也即用多少，付多少，至关于移动网络的按流量计费模式。那为何说使用这种模式就能下降运行成本呢？

红线如下的长方形面积表明了传统包月计费模式下你所须要支付的成本，而蓝色区域的面积则表明了按流量计费模式下的成本，显而后者要远低于前者。根据福布斯2015年发布的一份研究报告，从整年来看，一个典型的数据中内心的服务器平均资源使用率只有可怜的5%到15%，也就是说若是所有使用Serverless，理论上至少能够节省80%的运行成本。

按流量计费的另外一个隐藏的好处是任何的性能提高均可以直接的反应到运行成本上，这让技术人员的价值也有了更充分的体现。

3.2 自动扩缩容

Serverless第二个常被说起的特色是自动扩缩容。前面说了函数即应用，一个函数只作一件事，能够独立的进行扩缩容，而不用担忧影响其余函数，而且因为粒度更小，扩缩容速度也更快。而对于单体应用和微服务，借助于各类容器编排技术，虽然也能实现自动扩缩容，但因为粒度关系，相比函数，始终会存在必定的资源浪费。好比一个微服务提供两个API，其中一个API须要进行扩容，而另外一个并不须要，那么这时候扩容，对于不须要的API就是一种浪费。

3.3 事件驱动

函数本质上实现的是一种IPO（Input-Process-Output）模型，它是短暂的，是即用即走的。这点是函数区别于单体应用和微服务的另外一个特征。不论是单体应用，仍是微服务，都是系统中的常驻进程，套用一句流行语，就是你来或不来，我都在这里，不舍不弃。而函数不同，既不发布任何服务，没有请求时也不消耗任何资源，只有当请求来了，才会消耗资源进行响应，服务完马上释放资源。正是因为这一点，函数自然的适用于任何事件驱动的业务场景，好比广告竞价，身份验证，定时任务，以及一些新兴的IoT应用。

OpenWhisk给出的一个IoT电冰箱的案例

3.4 无状态性

函数的IPO本质决定了函数的另外一个特征，无状态性。无状态一方面有助于提升函数的可重用性和可迁移性，但另外一方面也带来了一些性能上的损失。第一，函数不是常驻进程，这就意味着每来一个请求，函数都要经历一次冷启动，这对编译型语言编写的应用不啻为一场噩梦（以Spring Boot为例，即使是一个最简单的Hello World应用，至少也须要5秒钟才能启动完毕）。第二，每服务完一个请求，函数所在的进程就会被杀掉，也就是说使用内存进行缓存对函数而言再也不有意义。第三，因为每次启动均可能被调度到新的服务器上，任何基于本地磁盘的缓存技术也就再也不适用。从第二点和第三点可知，函数只能使用外存（好比Redis，数据库）进行缓存，而操做外存都须要经过网络，性能跟内存、本地硬盘相比差了一到两个数量级。

4 DevOps => NoOps

若是说Agile+IaaS促成了DevOps，那么Agile+PaaS就孕育了Serverless。

理解了什么是Serverless，再来看看它和DevOps的关系。DevOps虽然作了不少Dev的事，但底牌仍是Ops（比如猫熊虽然长得像猫，但实际上仍是熊）。但Serverless不一样，从本质上说，它是把Ops外包给第三方平台，让Dev专一于业务逻辑的实现而不用操心Ops相关的工做，最终的结果就是绝大多数企业再也不须要Ops这个岗位。它和DevOps最大的共同点就是帮助企业缩短产品上市的时间。

5 小结

以上就是我对Serverless的一些简单介绍，欢迎你到个人留言板分享，和你们一块儿过过招。下一篇我会手把手教你们如何在Amazon Lambda部署一个基于Spring Cloud Function的Serverless应用，敬请期待。

6 参考

• Serverless Architectures
• What makes serverless architectures so attractive?
• InfoQ虚拟研讨会：无服务器计算的实践方法
• Serverless云函数架构精解
• 姗姗来迟的Serverless如何助力微服务和DevOps