Serverless 的喧譁與騷動（一）附Serverless行業發展回顧

做者 | 阿里中間件高級技術專家 許曉斌 《Maven實戰》做者，曾負責 AliExpress 微服務架構演進，如今負責阿里集團 Serverless 技術研發落地。

導讀：從 2016 年 AWS 發佈 Lambda 以來，全世界的開發者和雲廠商對 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.

從中能夠總結出如下幾點：

1. 全部人都在說 Serverless；
2. 幾乎沒人知道怎麼落地 Serverless；
3. 可是你們都以爲其餘人在大力作 Serverless；
4. 因此你們都宣稱本身在作 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 領域作的事情分了三個層，自下而上分別是資源層、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 這個領域看起來極其美好，一旦深刻去作了才發現實際很是複雜。這個複雜體如今涉及的工程技術比較廣，也體如今用戶的指望差別很大，更體如今你們對將來的判斷還有很大的差別。

雲原生實踐峯會即將開幕