作者 | Emac
杏仁医生架构师兼平台组负责人，关注为服务、DevOps领域。
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
理解了什么是 Serverless，再来看看它和 DevOps 的关系。DevOps 虽然做了很多 Dev 的事，但底牌还是 Ops（好比猫熊虽然长得像猫，但实际上还是熊）。但 Serverless 不同，从本质上说，它是把 Ops 外包给第三方平台，让 Dev 专注于业务逻辑的实现而不用操心 Ops 相关的工作，最终的结果就是绝大多数企业不再需要 Ops 这个岗位。它和 DevOps 最大的共同点就是帮助企业缩短产品上市的时间。
5 参考
Serverless Architectures (https://martinfowler.com/articles/serverless.html)
What makes serverless architectures so attractive? (https://developer.ibm.com/opentech/2016/09/06/what-makes-serverless-attractive/)
InfoQ虚拟研讨会：无服务器计算的实践方法 (http://www.infoq.com/cn/articles/practical-serverless-computing?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=架构%20&%20设计-articles)
姗姗来迟的Serverless如何助力微服务和DevOps (http://www.infoq.com/cn/news/2017/06/tengxun-cloud-serverless?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=DevOps)
全文完
以下文章您可能也会感兴趣：
我们正在招聘 Java 工程师，欢迎有兴趣的同学投递简历到 rd-hr@xingren.com 。
杏仁技术站
长按左侧二维码关注我们，这里有一群热血青年期待着与您相会。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
