《喧嘩與騷動》是我喜歡的作家威廉·福克納的一部小說，小說用多個家庭成員的意識流，從不同的視角描繪了一家三代的悲劇。這部小說有意思的地方在于：對于同樣一件事情，從不同人跳躍的意識中能看到迥然相異的景象。
今天大家了解 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 這個領域看起來極其美好，一旦深入去做了才發現實際非常複雜。這個複雜展現在涉及的工程技術比較廣，也展現在使用者的期望差異很大，更展現在大家對未來的判斷還有很大的差異。
在和團隊一起深入這個領域的時候，我也需要不斷整理自己的所聞所見、所思所想，是以我計劃産出一系列文章，拿出來和大家分享，和大家探讨，這是第一篇，有興趣的同學可以一起讨論。