Serverless 的喧哗与骚动

发布时间：2025-11-05 05:45:27 来源：码上建站 作者：应用开发

所有人都在说 Serverless;几乎没人知道怎么落地 Serverless;但是喧动大家都觉得其他人在大力做 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.

从中可以总结出以下几点：

Serverless 和很多词如微服务一样，喧动是哗骚没有精确定义的，也没有事实的喧动标准。什么是事实标准?Kubernetes 是事实标准;对 Java 程序员来说 Spring Boot / Spring Cloud 是免费信息发布网事实标准。

事实标准就是一种思想/方法论得到了广泛落地，占领了市场。落地通常意味着两个点：

今天 Serverless/FaaS 领域有这个东西吗?还没有。

Serverless 的愿景

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

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

​

​​

愿景是无服务器?但工程师们都知道服务器本质上是存在的，免费源码下载最多是加一层抽象，让我们看不到服务器，但它依旧很好的发挥作用。

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

​

​​

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

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

​

​​

是不是对图中的这些寄存器、栈、程序计数器、以及相关的汇编指令感到很陌生了?如果让你用这样的语言写业务逻辑，那效率必然会变得非常低。

幸好我们有 Java，Go，JavaScript 这样的高级语言，而这些高级语言还配套了相关的编译器/虚拟机，源码下载编译器/虚拟机能够高效地把面向业务的高级语言翻译成面向机器的汇编/机器码。

今天，虽然基本的计算机体系结构没有发生本质的变化，但我们的程序所运行的环境，相比较 20 年前，已经发生了本质的变化。20 年前的程序大都跑在单机上，今天我们的程序都要为了跑在云上而设计了。

为了让程序跑在云上，我们就需要配套的工作，包括云资源(容器、缓存、队列)的申请和回收、包括弹性伸缩的控制，等等。这些事情和业务逻辑没有任何关系，但研发/运维同学却为此花费了大量的时间。

我想做一个不太成熟的类比：

云上的 OS 这个角色，基本上可以说是被 Kubernetes 生态给占了，那么云上的编译器/VM 呢?开发语言和框架呢?好像还没有。

​

​​

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

本质上大家都在把面向单机体系架构编写的应用程序，硬搬到云体系架构上。我认为这里存在两个巨大的 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 领域做的事情分了三个层，自下而上分别是资源层、DevOps 层和框架及运行时层。

​

​​

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

DevOps 层关注的是变更管理、流量调配以及弹性伸缩，还包括基于事件模型和云生态打通。这一层的核心目标是如何把运维这件事情给做没了(NoOps)。虽然所有云厂商都有自己的产品(各种 FaaS)，但是我个人比较看好 Knative 这个开源产品，原因有二：

以下是 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，但我觉得还不够，我觉得理想的云原生框架应该是这样的：

小结

Serverless 这个领域看起来极其美好，一旦深入去做了才发现实际非常复杂。这个复杂体现在涉及的工程技术比较广，也体现在用户的期望差异很大，更体现在大家对未来的判断还有很大的差异。

【本文为51CTO专栏作者“阿里巴巴官方技术”原创稿件，转载请联系原作者】

​​戳这里，看该作者更多好文​​

相关文章