Serverless 的喧哗与骚动（一）附Serverless行业发展回顾

导读：从 2016 年 AWS 发布 Lambda 以来，全世界的开发者和云厂商对 Serverless 的热情在不断高涨。假设不想在开发应用程序并将其部署在服务器上的过程细节上花费精力，是否有一种简单的架构模型可以知足咱们这种想法呢？答案已经存在，这就是今天软件架构世界中新鲜可是很热门的一个话题——Serverless（无服务器）架构。本文做者将利用自身多年的研发经验，带领咱们深刻了解 Serverless 行业的发展！

《喧哗与骚动》是我喜欢的做家威廉·福克纳的一部小说，小说用多个家庭成员的意识流，从不一样的视角描绘了一家三代的悲剧。这部小说有意思的地方在于：对于一样一件事情，从不一样人跳跃的意识中能看到迥然相异的景象。

今天你们理解  Serverless 也有点这个意思，所以我以此为题，展开分析。文章只表明做者本人观点。

Serverless is like teenage sex

不知道你们有没有听过这样的话：

Big data is like teenage sex: Everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it.

咱们把 Big data 换一下：
AI is like teenage sex: Everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it.

咱们把 AI 换成 Serverless：
Serverless is like teenage sex: Everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it.

从中能够总结出如下几点：

1. 全部人都在说 Serverless；
2. 几乎没人知道怎么落地 Serverless；
3. 可是你们都以为其余人在大力作 Serverless；
4. 因此你们都宣称本身在作 Serverless。

Serverless 和不少词如微服务同样，是没有精肯定义的，也没有事实的标准。什么是事实标准？Kubernetes 是事实标准；对 Java 程序员来讲 Spring Boot / Spring Cloud 是事实标准。

事实标准就是一种思想/方法论获得了普遍落地，占领了市场。落地一般意味着两个点：

• 它是开放（开源）的。所以不会有 vendor lock-in，全部人能够放心用；
• 有大量的成功案例。不少人将其用到关键的商业系统中，所以获得了普遍验证。

今天 Serverless/FaaS 领域有这个东西吗？尚未。

Serverless 的愿景

下面是来自 Google Trends 的一个图，其中红色是 Microservices，蓝色是 Serverless。

从 2016 年 AWS 发布 Lambda 以来，全世界的开发者和云厂商对 Serverless 的热情在不断高涨，这说明你们对 Serverless 所描绘的愿景都很是 buy in。这个愿景是什么呢？

愿景是无服务器？但工程师们都知道服务器本质上是存在的，最可能是加一层抽象，让咱们看不到服务器，但它依旧很好的发挥做用。

我我的以为有关 Serverless 愿景，描绘最清楚的是一个比喻，这个比喻来自 UC Berkeley 在今年2月发表的那篇论文：

简单来讲就是：咱们今天对云资源的操做方式，就相似于几十年前早期程序员写汇编的方式。

若是你没写过/学过汇编语言，或者已经忘了汇编语言，我特意找了本书拍了一段内容下来：

是否是对图中的这些寄存器、栈、程序计数器、以及相关的汇编指令感到很陌生了？若是让你用这样的语言写业务逻辑，那效率必然会变得很是低。幸亏咱们有 Java，Go，JavaScript 这样的高级语言，而这些高级语言还配套了相关的编译器/虚拟机，编译器/虚拟机可以高效地把面向业务的高级语言翻译成面向机器的汇编/机器码。

今天，虽然基本的计算机体系结构没有发生本质的变化，但咱们的程序所运行的环境，相比较20年前，已经发生了本质的变化。20 年前的程序大都跑在单机上，今天咱们的程序都要为了跑在云上而设计了。为了让程序跑在云上，咱们就须要配套的工做，包括云资源（容器、缓存、队列）的申请和回收、包括弹性伸缩的控制，等等。这些事情和业务逻辑没有任何关系，但研发/运维同窗却为此花费了大量的时间。

我想作一个不太成熟的类比：单机时代，操做系统管理了硬件资源，贴着资源层，高级语言让程序员描述业务，贴着业务层，编译器/VM 把高级语言翻译成机器码，交给操做系统；今天的云时代，资源的单位再也不是 CPU、内存、硬盘了，而是容器、分布式队列、分布式缓存、分布式文件系统，而云上的 OS 这个角色，基本上能够说是被 Kubernetes 生态给占了，那么云上的编译器/VM 呢？开发语言和框架呢？好像尚未。

今天咱们把应用程序往云上搬的时候（a.k.a Cloud Native)，每每都会作两件事情：

• 第一是把巨型应用拆小，微服务化；
• 第二就是摇身一变成为 yaml 工程师，写不少 yaml 文件来管理云上的资源。

本质上你们都在把面向单机体系架构编写的应用程序，硬搬到云体系架构上。我认为这里存在两个巨大的 gap，这两个 gap 在图中用灰色的框表示了：

1.编程语言和框架；

目前主流的编程语言基本都是假设单机体系架构运行的，面对分布式问题的时候，再叠一层框架上去。其对应的资源也依旧停留在单机体系结构的那些资源上（固然这里是有例外的，好比 erlang/OTP 天生就是为分布式设计的）。

云时代，首先基本的资源单位发生了变化，从原来的 cpu、内存变成了容器、函数、分布式队列等等；其次，云天生分布式，所以单机时代大行其道的同步模型就再也不适合。

2.编译器。

程序员不该该花大量时间去写 yaml 文件，这些面向资源的 yaml 文件应该是由机器生成的，我称之为云编译器，高级编程语言用来表达业务的领域模型和逻辑，云编译器负责将语言编译成资源描述。

我我的很看好 Erlang 的 Actor 模型，这个模型在其余语言上也有实现，例如语法参考 Ruby 并运行在 Erlang OTP 上的 Elixir，JVM 上的 Akka，以及 .NET 上的 Orleans。不一样于其余语言的设计，Actor 模型从一开始就是基于分布式的前提作的设计，所以这种模型若是把其对应的资源管理换成纯粹的云资源管理，我以为是有极大可行性的。

若是用一句话来总结，我以为 Serverless 的愿景应该是：

Write locally, compile to the cloud.

你们在忙什么

除了抬头看天，说了一大堆美好的愿景，还得低头走路，先看看这条路上其余人在作什么。我整理了一下最近一年 Serverless 领域行业发生的一些比较重要的事件。回复关键字 serverless 获取 Serverless 领域近一年行业发展回顾。

为了可以稍微清晰一点地去看这一大堆的产品和技术，我简单的把 Serverless 领域作的事情分了三个层，自下而上分别是资源层、DevOps 层和框架及运行时层。

资源层关注的是资源（如容器）的生命周期管理，以及安全隔离。这里是 Kubernetes 的天下，Firecracker，gVisor 等产品在作轻量级安全沙箱。这一层关注的是如何可以更快地生产资源，以及保证好安全性。

DevOps 层关注的是变动管理、流量调配以及弹性伸缩，还包括基于事件模型和云生态打通。这一层的核心目标是如何把运维这件事情给作没了（NoOps）。虽然全部云厂商都有本身的产品（各类 FaaS），可是我我的比较看好 Knative 这个开源产品，缘由有二：

• 第一是其模型很是完备；
• 第二是其生态发展很是迅速和健康。颇有可能将来全部云厂商都要去兼容 Knative 的标准，就像今天全部云厂商都在兼容 Kubernetes 同样。

如下是 Knative 近一年的贡献者及贡献数量的增加状况，数据来自演讲「Knative a Year Later: Serverless, Kubernetes and You」。

框架和运行时层呢，因为我的经验所限，我看的仅仅是 Java 领域，其实核心的仍是在解决 Java 应用程序启动慢的问题（GraalVM）。固然框架如何避免 vendor lock-in 也很重要，谁都怕被一家云厂商绑定，怕换个云厂商要改代码，这方面主要是 Spring Cloud Function 在作。

刚需在哪里

产品想要成功，须要有核心竞争力，这个核心竞争力每每就是，你解决了一个用户很头疼、但其余产品没有解决的问题。我姑且把这样的问题称为用户的刚需。那么 Serverless 能解决哪些用户的什么刚需呢？我先对用户作一些简单的分析：

不少技术产品基本都是经历了以下四个阶段：

• 初创期：一个小团队围绕新的业务作试错，从无到有，技术上什么能快速上线用什么；

这个时候团队规模很小，可能两三我的，全部代码放在一个应用内，不须要分布式，不须要隔离。

• 成熟期：业务成功了，用户在不断增多，业务也变得愈来愈复杂；

这个时候团队的规模增加到数十到上百人，团队还处在一个部门，相互之间有足够的信任，沟通带宽也有足够的保证。一个应用的模式已经不能知足协做的须要，架构师开始作应用拆分，系统成了分布式的，按照业务的划分作了进程级别的隔离。

• 平台期：业务太成功了，就但愿把已经沉淀的能力赋能给其余相似的业务；

相比较于成熟期，这时候有了一些新的变化。首先是参与开发的人数增加得更多了，每每是数百上千；其次大多数参与开发的成员已经再也不是核心产品团队的成员，他们每每在不一样部门了，相互之间的信任已经大大减弱，沟通带宽也开始显著变窄。

因为核心团队对于其余部门的开发缺少组织管控能力，所以技术上的隔离要求被提上优先级，以免平台上的开发者不当心拖垮平台自己。伴随着隔离，成本的问题也被提上平常，当平台上数百个插件和平台自己跑在同一个进程内的时候，资源自然是被复用的，只要模糊地计算下总体便可；当数百个插件被隔离到独立的容器中运行的时候，他们的资源占用就须要额外的调度系统去控制和优化。

• 云产品期：平台太成功了，就但愿作成云服务，赋能社会上相似的业务，发挥更大的价值。

若是说在平台期，隔离还只是个重要但非必须的要求的话（不少平台就没有真正作好隔离），云产品期的产品必须具有很是强的隔离能力。平台期作隔离最大的诉求是稳定性（不被平台上的开发者搞垮整个平台），而云产品期作隔离的最大诉求是安全性。正如图中所示，产品上的开发者已经和产品团队不在一个组织了，并且这样的开发者还多是恶意的，所以除了容器的隔离，还须要虚拟机级别的隔离，网络的隔离等等。

随着技术产品由小长大，不断成功，参与的开发者不断增加，核心团队对这些开发者的控制力愈来愈弱，沟通带宽不断缩减，信任不断下降，进而致使了稳定性和安全的风险不断上升，这就要求隔离能力不断增强。而随着隔离的引入，以及使用资源的不断增加，成本就成了一个不得不面对的问题，为了更优地分配资源，解决成本问题，就对调度提出了要求。

所以，对于处在平台期和云产品期的产品来讲，技术上的隔离能力及调度能力是他们的刚需。

框架和运行时的创新

前面所说的刚需都是集中在稳定性、安全性及资源成本的角度来讨论的。除此以外咱们还须要讨论另一个话题，那就是开发效率，而开发效率具体到技术是体如今框架上的。

咱们能够进一步的把框架分红两类：

1. 面向技术问题提高开发效率的框架：如 Spring 经过依赖注入解决对象组装问题；HSF 解决分布式同步通信问题；RocketMQ 解决分布式异步通信问题；Hystrix 解决分布式通信引入的网络不可靠问题等等。经过使用这些框架，技术的自然复杂度在很大程度被屏蔽掉了。
2. 面向业务问题提高开发效率的框架：阿里的不少业务平台团队都会根据本身的场景（如交易、店铺、供应链）开发业务型框架，赋能开发快速迭代业务。

一般，面向技术问题的框架会有一个团队研发，而面向业务问题的框架则由各种业务平台团队提供，这再一次证实了康威定律的正确性。康威定律翻译成中国的土话差很少就是“屁股决定脑壳”，技术型团队不肯意碰业务问题，而业务平台团队的框架在解决技术问题方面也显得没有技术团队专业，最终的结果是：两种框架割裂得比较厉害。

你们可能听过这么一个故事：

有一条恶龙，每一年要求村庄献祭一个处女，每一年这个村庄都会有一个少年英雄去与恶龙搏斗，但无人生还。又一个英雄出发时，有人悄悄尾随。龙穴铺满金银财宝，英雄用剑刺死恶龙，而后坐在尸身上，看着闪烁的珠宝，慢慢地长出鳞片、尾巴和触角，最终变成恶龙。

虽然看起来很夸张，但在我看来，这必定程度上体现了一些大中型研发组织主流框架的现状：这些框架在组织发展的历史上发挥了极其重要的做用，然而到了今天，随着云服务不断地成熟，你们都在提云原生，都基于云在构建业务系统的时候，须要框架还在强制用户绑定语言（如 Java），还没作好服务化，把逻辑塞进用户的应用中。有的甚至要求用户的代码必须部署到平台的巨型应用中。

这些限制短时间内实现了业务目标，交付了业务价值，但从长期看基本上浇灭了业务开发作框架创新的热情，他们更习惯于等待“位于正肯定位的团队”去解决问题，而“处于正肯定位的团队”同窗呢，可能一时半会还没感觉到那些问题。不出意外的话，专一组织内短时间业务价值的框架，被推到云上、推到社区、面向更普适通用诉求的时候，得到的承认就会差不少。

传统的框架和运行时，只管理单机层面的资源，而当全部人都用云服务构建自身业务的时候，框架和运行时须要管理的就再也不是单机资源，而是云资源了。在这方面行业里已经有了很多产品，比较知名的有 Terraform 和 Pulumi，但我以为还不够，我以为理想的云原生框架应该是这样的：

• 可以帮助开发屏蔽云资源的管理。开发都不喜欢像写汇编同样写 yaml，所以框架须要负责资源的分配、回收，编排等等；
• 纯异步的，事件驱动的。这是云天生的分布式特性决定的，若是编程语言范式仍是同步的模型，这个框架就无法实现了；
• 没有 vendor lock-in。不绑定实际的云厂商，惟有厂商中立的开发框架才能被普遍使用，框架定义了编程 API，具体的厂商能够提供相关的 driver；
• 同时具有云资源管理和大规模软件开发必须的编程范式。这里的编程范式可能描述不当，但我找不到更好的词，面向对象设计是最主流的编程范式，Spring 就是围绕这个编程范式展开的。在一个框架中解决两个问题，会给开发极好的体验。

小结

Serverless 这个领域看起来极其美好，一旦深刻去作了才发现实际很是复杂。这个复杂体如今涉及的工程技术比较广，也体如今用户的指望差别很大，更体如今你们对将来的判断还有很大的差别。

原文连接 本文为云栖社区原创内容，未经容许不得转载。