一言蔽之，Serverless可以理解為“函式即服務”（Function as a Services，FaaS），與大家熟悉的微服務相比，“函式”（Function）的粒度更加細小。當然，這是一種異常簡潔有效的外包操作模式，由服務提供商去負責搞定伺服器、資料庫、應用邏輯，大大降低了基礎設施的成本和人力資源成本。

Serverless ，按中文翻譯，稱為無伺服器。

這究竟是一種什麼樣的形態或產品呢？無伺服器，就是真的沒有伺服器嗎？

其實，在行業內，目前對於 Serverless 有幾種解讀方法：

在某些場景可以解讀為一種軟體系統架構方法，通常稱為 Serverless 架構；而在有些情況下，又可以代表一種產品形態，稱為 Serverless 產品。

在說起 Serverless 架構時，Serverless 代表的是利用 Serverless 形態的產品實現的應用架構，這種架構完全依託於雲廠商或雲平臺提供產品完成系統的組織及構建。在這種架構中，使用者無需關注支撐應用服務執行的主機，而將關注點投入在系統架構，業務開發，業務支撐運維上。

而說起 Serverless 產品時，代表的是無需理解、管理伺服器，按需使用，按使用付費的產品。Serverless 產品中，其實也可以包含儲存、計算等多種型別的產品，而典型的計算產品，就是雲函式這種形態。

雲函式，或者稱為函式即服務 Function as a Service，它和後端即服務 Backend as a Service 一起，都可以稱為 Serverless 產品；而透過組合使用這些產品，開發者可以構建自身的業務 Serverless 架構。

更多檢視：Serverless 基本概念 https://www.toutiao.com/i6794284259960947203/

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

作者 | 阿里中介軟體高階技術專家 許曉斌

《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.

從中可以總結出以下幾點：

所有人都在說 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 領域近一年行業發展回顧。

為了能夠稍微清晰一點地去看這一大堆的產品和技術，我簡單的把 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 這個領域看起來極其美好，一旦深入去做了才發現實際非常複雜。這個複雜體現在涉及的工程技術比較廣，也體現在使用者的期望差異很大，更體現在大家對未來的判斷還有很大的差異。

字面意思：輕服務吧！實際意義是：不需要你管理伺服器！

你只需要按照Serverless提供商指定的方式提供你的業務程式碼，剩下的部署，運維就交給Serverless了！

即：你不需要購買、維護伺服器，但你的程式碼依舊是在伺服器上執行，只是你不知道在什麼樣的伺服器上執行而已！

什麼是無伺服器？

根據MartinFowler.com的定義，無伺服器體系結構是指主要依賴於第三方服務（稱為後端即服務或"BaaS"）的應用程式或在臨時容器中執行的自定義程式碼（功能即服務或"FaaS"）。

如上說述，如果你沒有維護或管理自己的基礎架構來執行應用程式，並根據使用情況付費（或者不付費），同時從供應商那裡自動獲得所需級別的高可用性、可擴充套件性和容錯性，那麼你就正在執行一個無伺服器的應用程式。作為在無伺服器環境中執行應用程式的所有者，你可以將所有的精力放在應用程式業務邏輯上，而不必擔心其執行的基礎架構以及應用程式周圍的其他非功能性需求。

無伺服器只是炒作？

如果你是無伺服器的新手，並且在考慮將其作為架構，那麼這就會成為你需要面對的問題之一。沒錯兒，無伺服器是現在的熱門話題，但是綜合了之前和之後的發展，我個人認為無伺服器並不是一個短期內的炒作，至少在3-5年不是，圍繞無伺服器的技術或許會被改變、替換，但是無伺服器的概念不會。

技術層面如何向無伺服器發展？

俗話說得好，觀往知來、知古鑑今，所以在解釋無伺服器功能如何強大之前，我們先來看看它是如何在過去幾年演變的：

1989 - 1991年 - Sir Tim Berners-Lee發明了全球資訊網

1991 - 1995年 - 裸機時代

1995年 web hosting

1999年 - 軟體即服務（SaaS）概念由Salesforce引入

2001年 - VMWare釋出ESXi，"伺服器虛擬化"成為了一件大事

2002-2006-AWS提出IaaS，人們開始談論"雲計算"

2009年 Heroku提出"平臺即服務"（PaaS）

2011年 - Envolve / Firebase，實時資料庫即服務

2012年 - Parse.com和第一個後端即服務（BaaS）

2013年 - Docker，"容器比虛擬機器好"

2013-2015 - Kubernetes / Swarm / Nomad / CoreOs（containers at scale）

2014年 - AWS Lambda推出（FaaS）

AWS lambda誕生了，無伺服器這個詞與FaaS一起出現在舞臺上，雖然大多數人認為Lambda是無伺服器的起點，但是containerization 將無伺服器遷移推向第一個高潮，隨著containerization的出現，全球領先的雲服務提供商開始向客戶提供"付費即用"的概念以及最需要的非功能性需求，支援使用其基礎架構運營業務。