《喧譁與騷動》是我喜歡的作家威廉·福克納的一部小說，小說用多個家庭成員的意識流，從不同的視角描繪了一家三代的悲劇。這部小說有意思的地方在於：對於同樣一件事情，從不同人跳躍的意識中能看到迥然相異的景象。
今天大家理解 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；
- 幾乎沒人知道怎麼落地 Serverless；
- 但是大家都覺得其他人在大力做 Serverless；
- 所以大家都宣稱自己在做 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 領域做的事情分了三個層，自下而上分別是資源層、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 這個領域看起來極其美好，一旦深入去做了才發現實際非常複雜。這個複雜體現在涉及的工程技術比較廣，也體現在用戶的期望差異很大，更體現在大家對未來的判斷還有很大的差異。
在和團隊一起深入這個領域的時候，我也需要不斷整理自己的所聞所見、所思所想，因此我計劃產出一系列文章，拿出來和大家分享，和大家探討，這是第一篇，有興趣的同學可以一起討論。