Serverless是什么？

原文地址：https://www.toutiao.com/i6727815175841251852/

作者 | 阿里中間件高級(jí)技術(shù)專(zhuān)家 許曉斌

《Maven實(shí)戰(zhàn)》作者，曾負(fù)責(zé) AliExpress 微服務(wù)架構(gòu)演進(jìn)，現(xiàn)在負(fù)責(zé)阿里集團(tuán) Serverless 技術(shù)研發(fā)落地。

導(dǎo)讀：從 2016 年 AWS 發(fā)布 Lambda 以來(lái)，全世界的開(kāi)發(fā)者和云廠商對(duì) Serverless 的熱情在不斷高漲。假設(shè)不想在開(kāi)發(fā)應(yīng)用程序并將其部署在服務(wù)器上的過(guò)程細(xì)節(jié)上花費(fèi)精力，是否有一種簡(jiǎn)單的架構(gòu)模型能夠滿足我們這種想法呢？答案已經(jīng)存在，這就是今天軟件架構(gòu)世界中新鮮但是很熱門(mén)的一個(gè)話題——Serverless（無(wú)服務(wù)器）架構(gòu)。本文作者將利用自身多年的研發(fā)經(jīng)驗(yàn)，帶領(lǐng)我們深入了解 Serverless 行業(yè)的發(fā)展！

《喧嘩與騷動(dòng)》是我喜歡的作家威廉·福克納的一部小說(shuō)，小說(shuō)用多個(gè)家庭成員的意識(shí)流，從不同的視角描繪了一家三代的悲劇。這部小說(shuō)有意思的地方在于：對(duì)于同樣一件事情，從不同人跳躍的意識(shí)中能看到迥然相異的景象。

今天大家理解 Serverless 也有點(diǎn)這個(gè)意思，因此我以此為題，展開(kāi)分析。文章只代表作者本人觀點(diǎn)。

Serverless is like teenage sex

不知道大家有沒(méi)有聽(tīng)過(guò)這樣的話：

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.

從中可以總結(jié)出以下幾點(diǎn)：

所有人都在說(shuō) Serverless；幾乎沒(méi)人知道怎么落地 Serverless；但是大家都覺(jué)得其他人在大力做 Serverless；所以大家都宣稱自己在做 Serverless。

Serverless 和很多詞如微服務(wù)一樣，是沒(méi)有精確定義的，也沒(méi)有事實(shí)的標(biāo)準(zhǔn)。什么是事實(shí)標(biāo)準(zhǔn)？Kubernetes 是事實(shí)標(biāo)準(zhǔn)；對(duì) Java 程序員來(lái)說(shuō) Spring Boot / Spring Cloud 是事實(shí)標(biāo)準(zhǔn)。

事實(shí)標(biāo)準(zhǔn)就是一種思想/方法論得到了廣泛落地，占領(lǐng)了市場(chǎng)。落地通常意味著兩個(gè)點(diǎn)：

它是開(kāi)放（開(kāi)源）的。因此不會(huì)有 vendor lock-in，所有人可以放心用；有大量的成功案例。很多人將其用到關(guān)鍵的商業(yè)系統(tǒng)中，因此得到了廣泛驗(yàn)證。

今天 Serverless/FaaS 領(lǐng)域有這個(gè)東西嗎？還沒(méi)有。

Serverless 的愿景

下面是來(lái)自 Google Trends 的一個(gè)圖，其中紅色是 Microservices，藍(lán)色是 Serverless。

從 2016 年 AWS 發(fā)布 Lambda 以來(lái)，全世界的開(kāi)發(fā)者和云廠商對(duì) Serverless 的熱情在不斷高漲，這說(shuō)明大家對(duì) Serverless 所描繪的愿景都非常 buy in。這個(gè)愿景是什么呢？

愿景是無(wú)服務(wù)器？但工程師們都知道服務(wù)器本質(zhì)上是存在的，最多是加一層抽象，讓我們看不到服務(wù)器，但它依舊很好的發(fā)揮作用。

我個(gè)人覺(jué)得有關(guān) Serverless 愿景，描繪最清楚的是一個(gè)比喻，這個(gè)比喻來(lái)自 UC Berkeley 在今年2月發(fā)表的那篇論文：

簡(jiǎn)單來(lái)說(shuō)就是：我們今天對(duì)云資源的操作方式，就類(lèi)似于幾十年前早期程序員寫(xiě)匯編的方式。

如果你沒(méi)寫(xiě)過(guò)/學(xué)過(guò)匯編語(yǔ)言，或者已經(jīng)忘了匯編語(yǔ)言，我特地找了本書(shū)拍了一段內(nèi)容下來(lái)：

是不是對(duì)圖中的這些寄存器、棧、程序計(jì)數(shù)器、以及相關(guān)的匯編指令感到很陌生了？如果讓你用這樣的語(yǔ)言寫(xiě)業(yè)務(wù)邏輯，那效率必然會(huì)變得非常低。幸好我們有 Java，Go，JavaScript 這樣的高級(jí)語(yǔ)言，而這些高級(jí)語(yǔ)言還配套了相關(guān)的編譯器/虛擬機(jī)，編譯器/虛擬機(jī)能夠高效地把面向業(yè)務(wù)的高級(jí)語(yǔ)言翻譯成面向機(jī)器的匯編/機(jī)器碼。

今天，雖然基本的計(jì)算機(jī)體系結(jié)構(gòu)沒(méi)有發(fā)生本質(zhì)的變化，但我們的程序所運(yùn)行的環(huán)境，相比較20年前，已經(jīng)發(fā)生了本質(zhì)的變化。20 年前的程序大都跑在單機(jī)上，今天我們的程序都要為了跑在云上而設(shè)計(jì)了。為了讓程序跑在云上，我們就需要配套的工作，包括云資源（容器、緩存、隊(duì)列）的申請(qǐng)和回收、包括彈性伸縮的控制，等等。這些事情和業(yè)務(wù)邏輯沒(méi)有任何關(guān)系，但研發(fā)/運(yùn)維同學(xué)卻為此花費(fèi)了大量的時(shí)間。

我想做一個(gè)不太成熟的類(lèi)比：?jiǎn)螜C(jī)時(shí)代，操作系統(tǒng)管理了硬件資源，貼著資源層，高級(jí)語(yǔ)言讓程序員描述業(yè)務(wù)，貼著業(yè)務(wù)層，編譯器/VM 把高級(jí)語(yǔ)言翻譯成機(jī)器碼，交給操作系統(tǒng)；今天的云時(shí)代，資源的單位不再是 CPU、內(nèi)存、硬盤(pán)了，而是容器、分布式隊(duì)列、分布式緩存、分布式文件系統(tǒng)，而云上的 OS 這個(gè)角色，基本上可以說(shuō)是被 Kubernetes 生態(tài)給占了，那么云上的編譯器/VM 呢？開(kāi)發(fā)語(yǔ)言和框架呢？好像還沒(méi)有。

今天我們把應(yīng)用程序往云上搬的時(shí)候（a.k.a Cloud Native)，往往都會(huì)做兩件事情：

第一是把巨型應(yīng)用拆小，微服務(wù)化；第二就是搖身一變成為 yaml 工程師，寫(xiě)很多 yaml 文件來(lái)管理云上的資源。

本質(zhì)上大家都在把面向單機(jī)體系架構(gòu)編寫(xiě)的應(yīng)用程序，硬搬到云體系架構(gòu)上。我認(rèn)為這里存在兩個(gè)巨大的 gap，這兩個(gè) gap 在圖中用灰色的框表示了：

1.編程語(yǔ)言和框架；

目前主流的編程語(yǔ)言基本都是假設(shè)單機(jī)體系架構(gòu)運(yùn)行的，面對(duì)分布式問(wèn)題的時(shí)候，再疊一層框架上去。其對(duì)應(yīng)的資源也依舊停留在單機(jī)體系結(jié)構(gòu)的那些資源上（當(dāng)然這里是有例外的，比如 erlang/OTP 天生就是為分布式設(shè)計(jì)的）。

云時(shí)代，首先基本的資源單位發(fā)生了變化，從原來(lái)的 cpu、內(nèi)存變成了容器、函數(shù)、分布式隊(duì)列等等；其次，云天生分布式，因此單機(jī)時(shí)代大行其道的同步模型就不再適合。

2.編譯器。

程序員不應(yīng)該花大量時(shí)間去寫(xiě) yaml 文件，這些面向資源的 yaml 文件應(yīng)該是由機(jī)器生成的，我稱之為云編譯器，高級(jí)編程語(yǔ)言用來(lái)表達(dá)業(yè)務(wù)的領(lǐng)域模型和邏輯，云編譯器負(fù)責(zé)將語(yǔ)言編譯成資源描述。

我個(gè)人很看好 Erlang 的 Actor 模型，這個(gè)模型在其他語(yǔ)言上也有實(shí)現(xiàn)，例如語(yǔ)法參考 Ruby 并運(yùn)行在 Erlang OTP 上的 Elixir，JVM 上的 Akka，以及 .NET 上的 Orleans。不同于其他語(yǔ)言的設(shè)計(jì)，Actor 模型從一開(kāi)始就是基于分布式的前提做的設(shè)計(jì)，因此這種模型如果把其對(duì)應(yīng)的資源管理?yè)Q成純粹的云資源管理，我覺(jué)得是有極大可行性的。

如果用一句話來(lái)總結(jié)，我覺(jué)得 Serverless 的愿景應(yīng)該是：

Write locally, compile to the cloud.大家在忙什么

除了抬頭看天，說(shuō)了一大堆美好的愿景，還得低頭走路，先看看這條路上其他人在做什么。我整理了一下最近一年 Serverless 領(lǐng)域行業(yè)發(fā)生的一些比較重要的事件。回復(fù)關(guān)鍵字 serverless 獲取 Serverless 領(lǐng)域近一年行業(yè)發(fā)展回顧。

為了能夠稍微清晰一點(diǎn)地去看這一大堆的產(chǎn)品和技術(shù)，我簡(jiǎn)單的把 Serverless 領(lǐng)域做的事情分了三個(gè)層，自下而上分別是資源層、DevOps 層和框架及運(yùn)行時(shí)層。

資源層關(guān)注的是資源（如容器）的生命周期管理，以及安全隔離。這里是 Kubernetes 的天下，F(xiàn)irecracker，gVisor 等產(chǎn)品在做輕量級(jí)安全沙箱。這一層關(guān)注的是如何能夠更快地生產(chǎn)資源，以及保證好安全性。

DevOps 層關(guān)注的是變更管理、流量調(diào)配以及彈性伸縮，還包括基于事件模型和云生態(tài)打通。這一層的核心目標(biāo)是如何把運(yùn)維這件事情給做沒(méi)了（NoOps）。雖然所有云廠商都有自己的產(chǎn)品（各種 FaaS），但是我個(gè)人比較看好 Knative 這個(gè)開(kāi)源產(chǎn)品，原因有二：

第一是其模型非常完備；第二是其生態(tài)發(fā)展非常迅速和健康。很有可能未來(lái)所有云廠商都要去兼容 Knative 的標(biāo)準(zhǔn)，就像今天所有云廠商都在兼容 Kubernetes 一樣。

以下是 Knative 近一年的貢獻(xiàn)者及貢獻(xiàn)數(shù)量的增長(zhǎng)情況，數(shù)據(jù)來(lái)自演講「Knative a Year Later: Serverless, Kubernetes and You」。

框架和運(yùn)行時(shí)層呢，由于個(gè)人經(jīng)驗(yàn)所限，我看的僅僅是 Java 領(lǐng)域，其實(shí)核心的還是在解決 Java 應(yīng)用程序啟動(dòng)慢的問(wèn)題（GraalVM）。當(dāng)然框架如何避免 vendor lock-in 也很重要，誰(shuí)都怕被一家云廠商綁定，怕?lián)Q個(gè)云廠商要改代碼，這方面主要是 Spring Cloud Function 在做。

剛需在哪里

產(chǎn)品想要成功，需要有核心競(jìng)爭(zhēng)力，這個(gè)核心競(jìng)爭(zhēng)力往往就是，你解決了一個(gè)用戶很頭疼、但其他產(chǎn)品沒(méi)有解決的問(wèn)題。我姑且把這樣的問(wèn)題稱為用戶的剛需。那么 Serverless 能解決哪些用戶的什么剛需呢？我先對(duì)用戶做一些簡(jiǎn)單的分析：

很多技術(shù)產(chǎn)品基本都是經(jīng)歷了如下四個(gè)階段：

初創(chuàng)期：一個(gè)小團(tuán)隊(duì)圍繞新的業(yè)務(wù)做試錯(cuò)，從無(wú)到有，技術(shù)上什么能快速上線用什么；

這個(gè)時(shí)候團(tuán)隊(duì)規(guī)模很小，可能兩三個(gè)人，所有代碼放在一個(gè)應(yīng)用內(nèi)，不需要分布式，不需要隔離。

成熟期：業(yè)務(wù)成功了，用戶在不斷增多，業(yè)務(wù)也變得越來(lái)越復(fù)雜；

這個(gè)時(shí)候團(tuán)隊(duì)的規(guī)模增長(zhǎng)到數(shù)十到上百人，團(tuán)隊(duì)還處在一個(gè)部門(mén)，相互之間有足夠的信任，溝通帶寬也有足夠的保證。一個(gè)應(yīng)用的模式已經(jīng)不能滿足協(xié)作的需要，架構(gòu)師開(kāi)始做應(yīng)用拆分，系統(tǒng)成了分布式的，按照業(yè)務(wù)的劃分做了進(jìn)程級(jí)別的隔離。

平臺(tái)期：業(yè)務(wù)太成功了，就希望把已經(jīng)沉淀的能力賦能給其他類(lèi)似的業(yè)務(wù)；

相比較于成熟期，這時(shí)候有了一些新的變化。首先是參與開(kāi)發(fā)的人數(shù)增長(zhǎng)得更多了，往往是數(shù)百上千；其次大多數(shù)參與開(kāi)發(fā)的成員已經(jīng)不再是核心產(chǎn)品團(tuán)隊(duì)的成員，他們往往在不同部門(mén)了，相互之間的信任已經(jīng)大大減弱，溝通帶寬也開(kāi)始顯著變窄。

由于核心團(tuán)隊(duì)對(duì)于其他部門(mén)的開(kāi)發(fā)缺乏組織管控能力，因此技術(shù)上的隔離要求被提上優(yōu)先級(jí)，以避免平臺(tái)上的開(kāi)發(fā)者不小心拖垮平臺(tái)本身。伴隨著隔離，成本的問(wèn)題也被提上日常，當(dāng)平臺(tái)上數(shù)百個(gè)插件和平臺(tái)本身跑在同一個(gè)進(jìn)程內(nèi)的時(shí)候，資源天然是被復(fù)用的，只要模糊地計(jì)算下整體即可；當(dāng)數(shù)百個(gè)插件被隔離到獨(dú)立的容器中運(yùn)行的時(shí)候，他們的資源占用就需要額外的調(diào)度系統(tǒng)去控制和優(yōu)化。

云產(chǎn)品期：平臺(tái)太成功了，就希望做成云服務(wù)，賦能社會(huì)上類(lèi)似的業(yè)務(wù)，發(fā)揮更大的價(jià)值。

如果說(shuō)在平臺(tái)期，隔離還只是個(gè)重要但非必須的要求的話（很多平臺(tái)就沒(méi)有真正做好隔離），云產(chǎn)品期的產(chǎn)品必須具備非常強(qiáng)的隔離能力。平臺(tái)期做隔離最大的訴求是穩(wěn)定性（不被平臺(tái)上的開(kāi)發(fā)者搞垮整個(gè)平臺(tái)），而云產(chǎn)品期做隔離的最大訴求是安全性。正如圖中所示，產(chǎn)品上的開(kāi)發(fā)者已經(jīng)和產(chǎn)品團(tuán)隊(duì)不在一個(gè)組織了，而且這樣的開(kāi)發(fā)者還可能是惡意的，因此除了容器的隔離，還需要虛擬機(jī)級(jí)別的隔離，網(wǎng)絡(luò)的隔離等等。

隨著技術(shù)產(chǎn)品由小長(zhǎng)大，不斷成功，參與的開(kāi)發(fā)者不斷增長(zhǎng)，核心團(tuán)隊(duì)對(duì)這些開(kāi)發(fā)者的控制力越來(lái)越弱，溝通帶寬不斷縮減，信任不斷降低，進(jìn)而導(dǎo)致了穩(wěn)定性和安全的風(fēng)險(xiǎn)不斷上升，這就要求隔離能力不斷加強(qiáng)。而隨著隔離的引入，以及使用資源的不斷增長(zhǎng)，成本就成了一個(gè)不得不面對(duì)的問(wèn)題，為了更優(yōu)地分配資源，解決成本問(wèn)題，就對(duì)調(diào)度提出了要求。

因此，對(duì)于處在平臺(tái)期和云產(chǎn)品期的產(chǎn)品來(lái)說(shuō)，技術(shù)上的隔離能力及調(diào)度能力是他們的剛需。

框架和運(yùn)行時(shí)的創(chuàng)新

前面所說(shuō)的剛需都是集中在穩(wěn)定性、安全性及資源成本的角度來(lái)討論的。除此之外我們還需要討論另外一個(gè)話題，那就是開(kāi)發(fā)效率，而開(kāi)發(fā)效率具體到技術(shù)是體現(xiàn)在框架上的。

我們可以進(jìn)一步的把框架分成兩類(lèi)：

1.面向技術(shù)問(wèn)題提升開(kāi)發(fā)效率的框架：如 Spring 通過(guò)依賴注入解決對(duì)象組裝問(wèn)題；HSF 解決分布式同步通訊問(wèn)題；RocketMQ 解決分布式異步通訊問(wèn)題；Hystrix 解決分布式通訊引入的網(wǎng)絡(luò)不可靠問(wèn)題等等。通過(guò)使用這些框架，技術(shù)的天然復(fù)雜度在很大程度被屏蔽掉了。

2.面向業(yè)務(wù)問(wèn)題提升開(kāi)發(fā)效率的框架：阿里的很多業(yè)務(wù)平臺(tái)團(tuán)隊(duì)都會(huì)根據(jù)自己的場(chǎng)景（如交易、店鋪、供應(yīng)鏈）開(kāi)發(fā)業(yè)務(wù)型框架，賦能開(kāi)發(fā)快速迭代業(yè)務(wù)。

通常，面向技術(shù)問(wèn)題的框架會(huì)有一個(gè)團(tuán)隊(duì)研發(fā)，而面向業(yè)務(wù)問(wèn)題的框架則由各類(lèi)業(yè)務(wù)平臺(tái)團(tuán)隊(duì)提供，這再一次證明了康威定律的正確性。康威定律翻譯成中國(guó)的土話差不多就是“屁股決定腦袋”，技術(shù)型團(tuán)隊(duì)不愿意碰業(yè)務(wù)問(wèn)題，而業(yè)務(wù)平臺(tái)團(tuán)隊(duì)的框架在解決技術(shù)問(wèn)題方面也顯得沒(méi)有技術(shù)團(tuán)隊(duì)專(zhuān)業(yè)，最終的結(jié)果是：兩種框架割裂得比較厲害。

大家可能聽(tīng)過(guò)這么一個(gè)故事：

有一條惡龍，每年要求村莊獻(xiàn)祭一個(gè)處女，每年這個(gè)村莊都會(huì)有一個(gè)少年英雄去與惡龍搏斗，但無(wú)人生還。又一個(gè)英雄出發(fā)時(shí)，有人悄悄尾隨。龍穴鋪滿金銀財(cái)寶，英雄用劍刺死惡龍，然后坐在尸身上，看著閃爍的珠寶，慢慢地長(zhǎng)出鱗片、尾巴和觸角，最終變成惡龍。

雖然看起來(lái)很夸張，但在我看來(lái)，這一定程度上體現(xiàn)了一些大中型研發(fā)組織主流框架的現(xiàn)狀：這些框架在組織發(fā)展的歷史上發(fā)揮了極其重要的作用，然而到了今天，隨著云服務(wù)不斷地成熟，大家都在提云原生，都基于云在構(gòu)建業(yè)務(wù)系統(tǒng)的時(shí)候，需要框架還在強(qiáng)制用戶綁定語(yǔ)言（如 Java），還沒(méi)做好服務(wù)化，把邏輯塞進(jìn)用戶的應(yīng)用中。有的甚至要求用戶的代碼必須部署到平臺(tái)的巨型應(yīng)用中。

這些限制短期內(nèi)實(shí)現(xiàn)了業(yè)務(wù)目標(biāo)，交付了業(yè)務(wù)價(jià)值，但從長(zhǎng)期看基本上澆滅了業(yè)務(wù)開(kāi)發(fā)做框架創(chuàng)新的熱情，他們更習(xí)慣于等待“位于正確定位的團(tuán)隊(duì)”去解決問(wèn)題，而“處于正確定位的團(tuán)隊(duì)”同學(xué)呢，可能一時(shí)半會(huì)還沒(méi)感受到那些問(wèn)題。不出意外的話，專(zhuān)注組織內(nèi)短期業(yè)務(wù)價(jià)值的框架，被推到云上、推到社區(qū)、面向更普適通用訴求的時(shí)候，獲得的認(rèn)可就會(huì)差很多。

傳統(tǒng)的框架和運(yùn)行時(shí)，只管理單機(jī)層面的資源，而當(dāng)所有人都用云服務(wù)構(gòu)建自身業(yè)務(wù)的時(shí)候，框架和運(yùn)行時(shí)需要管理的就不再是單機(jī)資源，而是云資源了。在這方面行業(yè)里已經(jīng)有了不少產(chǎn)品，比較知名的有 Terraform 和 Pulumi，但我覺(jué)得還不夠，我覺(jué)得理想的云原生框架應(yīng)該是這樣的：

能夠幫助開(kāi)發(fā)屏蔽云資源的管理。開(kāi)發(fā)都不喜歡像寫(xiě)匯編一樣寫(xiě) yaml，因此框架需要負(fù)責(zé)資源的分配、回收，編排等等；純異步的，事件驅(qū)動(dòng)的。這是云天生的分布式特性決定的，如果編程語(yǔ)言范式還是同步的模型，這個(gè)框架就沒(méi)法實(shí)現(xiàn)了；沒(méi)有 vendor lock-in。不綁定實(shí)際的云廠商，唯有廠商中立的開(kāi)發(fā)框架才能被廣泛使用，框架定義了編程 API，具體的廠商可以提供相關(guān)的 driver；同時(shí)具備云資源管理和大規(guī)模軟件開(kāi)發(fā)必須的編程范式。這里的編程范式可能描述不當(dāng)，但我找不到更好的詞，面向?qū)ο笤O(shè)計(jì)是最主流的編程范式，Spring 就是圍繞這個(gè)編程范式展開(kāi)的。在一個(gè)框架中解決兩個(gè)問(wèn)題，會(huì)給開(kāi)發(fā)極好的體驗(yàn)。小結(jié)

Serverless 這個(gè)領(lǐng)域看起來(lái)極其美好，一旦深入去做了才發(fā)現(xiàn)實(shí)際非常復(fù)雜。這個(gè)復(fù)雜體現(xiàn)在涉及的工程技術(shù)比較廣，也體現(xiàn)在用戶的期望差異很大，更體現(xiàn)在大家對(duì)未來(lái)的判斷還有很大的差異。

在和團(tuán)隊(duì)一起深入這個(gè)領(lǐng)域的時(shí)候，我也需要不斷整理自己的所聞所見(jiàn)、所思所想，因此我計(jì)劃產(chǎn)出一系列文章，拿出來(lái)和大家分享，和大家探討，這是第一篇，有興趣的同學(xué)可以進(jìn)群討論。