Serverless 的喧哗与骚动（一）附Serverless行业发展回顾
作者 | 阿里中間件高級技術(shù)專家 許曉斌
《Maven實戰(zhàn)》作者，曾負責 AliExpress 微服務架構(gòu)演進，現(xiàn)在負責阿里集團 Serverless 技術(shù)研發(fā)落地。
導讀：從 2016 年 AWS 發(fā)布 Lambda 以來，全世界的開發(fā)者和云廠商對 Serverless 的熱情在不斷高漲。假設(shè)不想在開發(fā)應用程序并將其部署在服務器上的過程細節(jié)上花費精力，是否有一種簡單的架構(gòu)模型能夠滿足我們這種想法呢？答案已經(jīng)存在，這就是今天軟件架構(gòu)世界中新鮮但是很熱門的一個話題——Serverless（無服務器）架構(gòu)。本文作者將利用自身多年的研發(fā)經(jīng)驗，帶領(lǐng)我們深入了解 Serverless 行業(yè)的發(fā)展！
《喧嘩與騷動》是我喜歡的作家威廉·福克納的一部小說，小說用多個家庭成員的意識流，從不同的視角描繪了一家三代的悲劇。這部小說有意思的地方在于：對于同樣一件事情，從不同人跳躍的意識中能看到迥然相異的景象。
今天大家理解 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.
從中可以總結(jié)出以下幾點：
Serverless 和很多詞如微服務一樣，是沒有精確定義的，也沒有事實的標準。什么是事實標準？Kubernetes 是事實標準；對 Java 程序員來說 Spring Boot / Spring Cloud 是事實標準。
事實標準就是一種思想/方法論得到了廣泛落地，占領(lǐng)了市場。落地通常意味著兩個點：
- 它是開放（開源）的。因此不會有 vendor lock-in，所有人可以放心用；
- 有大量的成功案例。很多人將其用到關(guān)鍵的商業(yè)系統(tǒng)中，因此得到了廣泛驗證。
今天 Serverless/FaaS 領(lǐng)域有這個東西嗎？還沒有。
Serverless 的愿景
下面是來自 Google Trends 的一個圖，其中紅色是 Microservices，藍色是 Serverless。
從 2016 年 AWS 發(fā)布 Lambda 以來，全世界的開發(fā)者和云廠商對 Serverless 的熱情在不斷高漲，這說明大家對 Serverless 所描繪的愿景都非常 buy in。這個愿景是什么呢？
愿景是無服務器？但工程師們都知道服務器本質(zhì)上是存在的，最多是加一層抽象，讓我們看不到服務器，但它依舊很好的發(fā)揮作用。
我個人覺得有關(guān) Serverless 愿景，描繪最清楚的是一個比喻，這個比喻來自 UC Berkeley 在今年2月發(fā)表的那篇論文：
簡單來說就是：我們今天對云資源的操作方式，就類似于幾十年前早期程序員寫匯編的方式。
如果你沒寫過/學過匯編語言，或者已經(jīng)忘了匯編語言，我特地找了本書拍了一段內(nèi)容下來：
是不是對圖中的這些寄存器、棧、程序計數(shù)器、以及相關(guān)的匯編指令感到很陌生了？如果讓你用這樣的語言寫業(yè)務邏輯，那效率必然會變得非常低。幸好我們有 Java，Go，JavaScript 這樣的高級語言，而這些高級語言還配套了相關(guān)的編譯器/虛擬機，編譯器/虛擬機能夠高效地把面向業(yè)務的高級語言翻譯成面向機器的匯編/機器碼。
今天，雖然基本的計算機體系結(jié)構(gòu)沒有發(fā)生本質(zhì)的變化，但我們的程序所運行的環(huán)境，相比較20年前，已經(jīng)發(fā)生了本質(zhì)的變化。20 年前的程序大都跑在單機上，今天我們的程序都要為了跑在云上而設(shè)計了。為了讓程序跑在云上，我們就需要配套的工作，包括云資源（容器、緩存、隊列）的申請和回收、包括彈性伸縮的控制，等等。這些事情和業(yè)務邏輯沒有任何關(guān)系，但研發(fā)/運維同學卻為此花費了大量的時間。
我想做一個不太成熟的類比：單機時代，操作系統(tǒng)管理了硬件資源，貼著資源層，高級語言讓程序員描述業(yè)務，貼著業(yè)務層，編譯器/VM 把高級語言翻譯成機器碼，交給操作系統(tǒng)；今天的云時代，資源的單位不再是 CPU、內(nèi)存、硬盤了，而是容器、分布式隊列、分布式緩存、分布式文件系統(tǒng)，而云上的 OS 這個角色，基本上可以說是被 Kubernetes 生態(tài)給占了，那么云上的編譯器/VM 呢？開發(fā)語言和框架呢？好像還沒有。
今天我們把應用程序往云上搬的時候（a.k.a Cloud Native)，往往都會做兩件事情：
- 第一是把巨型應用拆小，微服務化；
- 第二就是搖身一變成為 yaml 工程師，寫很多 yaml 文件來管理云上的資源。
本質(zhì)上大家都在把面向單機體系架構(gòu)編寫的應用程序，硬搬到云體系架構(gòu)上。我認為這里存在兩個巨大的 gap，這兩個 gap 在圖中用灰色的框表示了：
目前主流的編程語言基本都是假設(shè)單機體系架構(gòu)運行的，面對分布式問題的時候，再疊一層框架上去。其對應的資源也依舊停留在單機體系結(jié)構(gòu)的那些資源上（當然這里是有例外的，比如 erlang/OTP 天生就是為分布式設(shè)計的）。
云時代，首先基本的資源單位發(fā)生了變化，從原來的 cpu、內(nèi)存變成了容器、函數(shù)、分布式隊列等等；其次，云天生分布式，因此單機時代大行其道的同步模型就不再適合。
程序員不應該花大量時間去寫 yaml 文件，這些面向資源的 yaml 文件應該是由機器生成的，我稱之為云編譯器，高級編程語言用來表達業(yè)務的領(lǐng)域模型和邏輯，云編譯器負責將語言編譯成資源描述。
我個人很看好 Erlang 的 Actor 模型，這個模型在其他語言上也有實現(xiàn)，例如語法參考 Ruby 并運行在 Erlang OTP 上的 Elixir，JVM 上的 Akka，以及 .NET 上的 Orleans。不同于其他語言的設(shè)計，Actor 模型從一開始就是基于分布式的前提做的設(shè)計，因此這種模型如果把其對應的資源管理換成純粹的云資源管理，我覺得是有極大可行性的。
如果用一句話來總結(jié)，我覺得 Serverless 的愿景應該是：
Write locally, compile to the cloud.
大家在忙什么
除了抬頭看天，說了一大堆美好的愿景，還得低頭走路，先看看這條路上其他人在做什么。我整理了一下最近一年 Serverless 領(lǐng)域行業(yè)發(fā)生的一些比較重要的事件。回復關(guān)鍵字 serverless 獲取 Serverless 領(lǐng)域近一年行業(yè)發(fā)展回顧。
為了能夠稍微清晰一點地去看這一大堆的產(chǎn)品和技術(shù)，我簡單的把 Serverless 領(lǐng)域做的事情分了三個層，自下而上分別是資源層、DevOps 層和框架及運行時層。
資源層關(guān)注的是資源（如容器）的生命周期管理，以及安全隔離。這里是 Kubernetes 的天下，Firecracker，gVisor 等產(chǎn)品在做輕量級安全沙箱。這一層關(guān)注的是如何能夠更快地生產(chǎn)資源，以及保證好安全性。
DevOps 層關(guān)注的是變更管理、流量調(diào)配以及彈性伸縮，還包括基于事件模型和云生態(tài)打通。這一層的核心目標是如何把運維這件事情給做沒了（NoOps）。雖然所有云廠商都有自己的產(chǎn)品（各種 FaaS），但是我個人比較看好 Knative 這個開源產(chǎn)品，原因有二：
- 第一是其模型非常完備；
- 第二是其生態(tài)發(fā)展非常迅速和健康。很有可能未來所有云廠商都要去兼容 Knative 的標準，就像今天所有云廠商都在兼容 Kubernetes 一樣。
以下是 Knative 近一年的貢獻者及貢獻數(shù)量的增長情況，數(shù)據(jù)來自演講「Knative a Year Later: Serverless, Kubernetes and You」。
框架和運行時層呢，由于個人經(jīng)驗所限，我看的僅僅是 Java 領(lǐng)域，其實核心的還是在解決 Java 應用程序啟動慢的問題（GraalVM）。當然框架如何避免 vendor lock-in 也很重要，誰都怕被一家云廠商綁定，怕?lián)Q個云廠商要改代碼，這方面主要是 Spring Cloud Function 在做。
剛需在哪里
產(chǎn)品想要成功，需要有核心競爭力，這個核心競爭力往往就是，你解決了一個用戶很頭疼、但其他產(chǎn)品沒有解決的問題。我姑且把這樣的問題稱為用戶的剛需。那么 Serverless 能解決哪些用戶的什么剛需呢？我先對用戶做一些簡單的分析：
很多技術(shù)產(chǎn)品基本都是經(jīng)歷了如下四個階段：
- 初創(chuàng)期：一個小團隊圍繞新的業(yè)務做試錯，從無到有，技術(shù)上什么能快速上線用什么；
這個時候團隊規(guī)模很小，可能兩三個人，所有代碼放在一個應用內(nèi)，不需要分布式，不需要隔離。
- 成熟期：業(yè)務成功了，用戶在不斷增多，業(yè)務也變得越來越復雜；
這個時候團隊的規(guī)模增長到數(shù)十到上百人，團隊還處在一個部門，相互之間有足夠的信任，溝通帶寬也有足夠的保證。一個應用的模式已經(jīng)不能滿足協(xié)作的需要，架構(gòu)師開始做應用拆分，系統(tǒng)成了分布式的，按照業(yè)務的劃分做了進程級別的隔離。
- 平臺期：業(yè)務太成功了，就希望把已經(jīng)沉淀的能力賦能給其他類似的業(yè)務；
相比較于成熟期，這時候有了一些新的變化。首先是參與開發(fā)的人數(shù)增長得更多了，往往是數(shù)百上千；其次大多數(shù)參與開發(fā)的成員已經(jīng)不再是核心產(chǎn)品團隊的成員，他們往往在不同部門了，相互之間的信任已經(jīng)大大減弱，溝通帶寬也開始顯著變窄。
由于核心團隊對于其他部門的開發(fā)缺乏組織管控能力，因此技術(shù)上的隔離要求被提上優(yōu)先級，以避免平臺上的開發(fā)者不小心拖垮平臺本身。伴隨著隔離，成本的問題也被提上日常，當平臺上數(shù)百個插件和平臺本身跑在同一個進程內(nèi)的時候，資源天然是被復用的，只要模糊地計算下整體即可；當數(shù)百個插件被隔離到獨立的容器中運行的時候，他們的資源占用就需要額外的調(diào)度系統(tǒng)去控制和優(yōu)化。
- 云產(chǎn)品期：平臺太成功了，就希望做成云服務，賦能社會上類似的業(yè)務，發(fā)揮更大的價值。
如果說在平臺期，隔離還只是個重要但非必須的要求的話（很多平臺就沒有真正做好隔離），云產(chǎn)品期的產(chǎn)品必須具備非常強的隔離能力。平臺期做隔離最大的訴求是穩(wěn)定性（不被平臺上的開發(fā)者搞垮整個平臺），而云產(chǎn)品期做隔離的最大訴求是安全性。正如圖中所示，產(chǎn)品上的開發(fā)者已經(jīng)和產(chǎn)品團隊不在一個組織了，而且這樣的開發(fā)者還可能是惡意的，因此除了容器的隔離，還需要虛擬機級別的隔離，網(wǎng)絡(luò)的隔離等等。
隨著技術(shù)產(chǎn)品由小長大，不斷成功，參與的開發(fā)者不斷增長，核心團隊對這些開發(fā)者的控制力越來越弱，溝通帶寬不斷縮減，信任不斷降低，進而導致了穩(wěn)定性和安全的風險不斷上升，這就要求隔離能力不斷加強。而隨著隔離的引入，以及使用資源的不斷增長，成本就成了一個不得不面對的問題，為了更優(yōu)地分配資源，解決成本問題，就對調(diào)度提出了要求。
因此，對于處在平臺期和云產(chǎn)品期的產(chǎn)品來說，技術(shù)上的隔離能力及調(diào)度能力是他們的剛需。
框架和運行時的創(chuàng)新
前面所說的剛需都是集中在穩(wěn)定性、安全性及資源成本的角度來討論的。除此之外我們還需要討論另外一個話題，那就是開發(fā)效率，而開發(fā)效率具體到技術(shù)是體現(xiàn)在框架上的。
我們可以進一步的把框架分成兩類：
面向技術(shù)問題提升開發(fā)效率的框架：如 Spring 通過依賴注入解決對象組裝問題；HSF 解決分布式同步通訊問題；RocketMQ 解決分布式異步通訊問題；Hystrix 解決分布式通訊引入的網(wǎng)絡(luò)不可靠問題等等。通過使用這些框架，技術(shù)的天然復雜度在很大程度被屏蔽掉了。
面向業(yè)務問題提升開發(fā)效率的框架：阿里的很多業(yè)務平臺團隊都會根據(jù)自己的場景（如交易、店鋪、供應鏈）開發(fā)業(yè)務型框架，賦能開發(fā)快速迭代業(yè)務。
通常，面向技術(shù)問題的框架會有一個團隊研發(fā)，而面向業(yè)務問題的框架則由各類業(yè)務平臺團隊提供，這再一次證明了康威定律的正確性。康威定律翻譯成中國的土話差不多就是“屁股決定腦袋”，技術(shù)型團隊不愿意碰業(yè)務問題，而業(yè)務平臺團隊的框架在解決技術(shù)問題方面也顯得沒有技術(shù)團隊專業(yè)，最終的結(jié)果是：兩種框架割裂得比較厲害。
大家可能聽過這么一個故事：
有一條惡龍，每年要求村莊獻祭一個處女，每年這個村莊都會有一個少年英雄去與惡龍搏斗，但無人生還。又一個英雄出發(fā)時，有人悄悄尾隨。龍穴鋪滿金銀財寶，英雄用劍刺死惡龍，然后坐在尸身上，看著閃爍的珠寶，慢慢地長出鱗片、尾巴和觸角，最終變成惡龍。
雖然看起來很夸張，但在我看來，這一定程度上體現(xiàn)了一些大中型研發(fā)組織主流框架的現(xiàn)狀：這些框架在組織發(fā)展的歷史上發(fā)揮了極其重要的作用，然而到了今天，隨著云服務不斷地成熟，大家都在提云原生，都基于云在構(gòu)建業(yè)務系統(tǒng)的時候，需要框架還在強制用戶綁定語言（如 Java），還沒做好服務化，把邏輯塞進用戶的應用中。有的甚至要求用戶的代碼必須部署到平臺的巨型應用中。
這些限制短期內(nèi)實現(xiàn)了業(yè)務目標，交付了業(yè)務價值，但從長期看基本上澆滅了業(yè)務開發(fā)做框架創(chuàng)新的熱情，他們更習慣于等待“位于正確定位的團隊”去解決問題，而“處于正確定位的團隊”同學呢，可能一時半會還沒感受到那些問題。不出意外的話，專注組織內(nèi)短期業(yè)務價值的框架，被推到云上、推到社區(qū)、面向更普適通用訴求的時候，獲得的認可就會差很多。
傳統(tǒng)的框架和運行時，只管理單機層面的資源，而當所有人都用云服務構(gòu)建自身業(yè)務的時候，框架和運行時需要管理的就不再是單機資源，而是云資源了。在這方面行業(yè)里已經(jīng)有了不少產(chǎn)品，比較知名的有 Terraform 和 Pulumi，但我覺得還不夠，我覺得理想的云原生框架應該是這樣的：
- 能夠幫助開發(fā)屏蔽云資源的管理。開發(fā)都不喜歡像寫匯編一樣寫 yaml，因此框架需要負責資源的分配、回收，編排等等；
- 純異步的，事件驅(qū)動的。這是云天生的分布式特性決定的，如果編程語言范式還是同步的模型，這個框架就沒法實現(xiàn)了；
- 沒有 vendor lock-in。不綁定實際的云廠商，唯有廠商中立的開發(fā)框架才能被廣泛使用，框架定義了編程 API，具體的廠商可以提供相關(guān)的 driver；
- 同時具備云資源管理和大規(guī)模軟件開發(fā)必須的編程范式。這里的編程范式可能描述不當，但我找不到更好的詞，面向?qū)ο笤O(shè)計是最主流的編程范式，Spring 就是圍繞這個編程范式展開的。在一個框架中解決兩個問題，會給開發(fā)極好的體驗。
小結(jié)
Serverless 這個領(lǐng)域看起來極其美好，一旦深入去做了才發(fā)現(xiàn)實際非常復雜。這個復雜體現(xiàn)在涉及的工程技術(shù)比較廣，也體現(xiàn)在用戶的期望差異很大，更體現(xiàn)在大家對未來的判斷還有很大的差異。
在和團隊一起深入這個領(lǐng)域的時候，我也需要不斷整理自己的所聞所見、所思所想，因此我計劃產(chǎn)出一系列文章，拿出來和大家分享，和大家探討，這是第一篇，有興趣的同學可以進群討論。
掃描下方二維碼添加小助手，拉你進群！
總結(jié)
以上是生活随笔為你收集整理的Serverless 的喧哗与骚动（一）附Serverless行业发展回顾的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 云原生生态周报 Vol. 15 | K8
- 下一篇： 基于 K8s 做应用发布的工具那么多,