作者 | 江昱（阿里雲 Serverless 產品經理）

拋磚引玉：從雲端計算到 Serverless

2009 年，UC Berkeley發表了：Above the Clouds: A Berkeley View of Cloud Computing 一文，在該文章中首次對雲端計算做出定義：雲端計算包含網際網路上的應用服務及在資料中心提供這些服務的軟硬體設施。居諸不息，隨著雲端計算飛速發展，雲端計算的形態也在不斷的演進，從 IaaS 到 PaaS，再到 SaaS，雲端計算也逐漸地 “找到了正確的發展方向”。

（雲端計算髮展形態）

2012 年由 Iron.io 的副總裁 Ken Form 所寫的一篇名為 Why The Future of Softwareand Apps is Serverless 的文章中，提出了一個新的觀點：即使雲端計算已經逐漸的興起，但是大家仍然在圍繞著伺服器轉。不過，這不會持續太久，雲應用正在朝著無伺服器方向發展，這將對應用程式的建立和分發產生重大影響。並首次將 “Serverless” 這個詞帶進了大眾的視野。

到了 2017 年，各大雲廠商基本上都已經在 Serverless 進行了基礎的佈局，尤其是國內的幾大雲廠商，也都先後在這一年邁入 “Serverless時代”。

從下圖我們可以看到，在 IaaS 到 PaaS 再到 SaaS 的演進過程中，雲端計算所表現出的去伺服器化越來越明顯，那麼前文中 Ken Form 所提出來的 Serverless 又是什麼，它在雲端計算髮展的過程中，又在扮演什麼角色呢，它的去伺服器化又到了什麼程度呢？

What is Serverless？

Serverless 翻譯成中文是無伺服器，所謂的無伺服器並非是說不需要依靠伺服器等資源，而是說開發者再也不用過多考慮伺服器的問題，可以更專注在產品程式碼上，同時計算資源也開始作為服務出現，而不是作為伺服器的概念出現。

Serverless 是一種構建和管理基於微服務架構的完整流程，允許使用者在服務部署級別而不是伺服器部署級別來管理使用者的應用部署。與傳統架構的不同之處在於，它完全由第三方管理，由事件觸發，存在於無狀態 （Stateless），暫存 （可能只存在於一次呼叫的過程中） 在計算容器內，Serverless 部署應用無需涉及更多的基礎設施建設，就可以基本實現自動構建、部署和啟動服務。

近些年來，微服務 （Micro Service）是軟體架構領域另一個熱門的話題，如果說微服務是以專注於單一責任與功能的小型功能塊為基礎，利用模組化的方式組合出複雜的大型應用程式，那麼可以進一步認為 Serverless 架構可以提供一種更加 “程式碼碎片化” 的軟體架構正規化，而這一部分稱之為 Function as a Services （FaaS）。而所謂的 “函式” 提供的是相比微服務更加細小的程式單元。

例如，可以通過微服務代表為某個客戶執行所有 CRUD 操作所需的程式碼，而 FaaS 中的函式可以代表客戶所要執行的每個操作：建立、讀取、更新以及刪除。當觸發 “建立賬戶” 事件後，將通過函式的方式執行相應的 “函式”。單就這一層意思來說，可以簡單地將 Serverless 架構與 FaaS 概念等同起來。但是就具體的概念深刻探索的話，Serverless 和 FaaS 還是不同的，Serverless 和 FaaS 被廣為接受的關係是：

Serverless= FaaS + BaaS （+ .....）

在這個關係中，可以看到 Serverless 的組成除了 FaaS 和 BaaS （Backend as a Service） 之外，還有一系列的省略號，其實這是 Serverless 給予給大家的遐想空間，給予這個時代的一些期待。

在前人的描述中 Serverless 架構從結構上，行為上以及特性上的定義，可以總結歸納成下圖的形式：

「從組成定義來看」

Martin Fowler 認為，在 Serverless 架構中，應用的一部分服務端邏輯依然由開發者完成，但是和傳統架構不同，它執行在一個無狀態的計算容器中，由事件驅動、生命週期很短（甚至只有一次呼叫）、完全由第三方管理，這種情況稱為 FaaS。除此之外，Serverless 架構還要有部分依賴於第三方 （雲端） 應用或服務來管理伺服器端邏輯和狀態的應用，而這些服務即是所認為的 “BaaS” 部分。

「從行為定義來看」

CNCF 在以上基礎對 Serverless 架構的定義，進一步的完善描述：

Serverless 是指構建和執行不需要伺服器管理的應用程式概念。它描述了一種更細粒度的部署模型，其中將應用程式打包為一個或多個功能，上傳到平臺，然後執行、擴充套件和計費，以響應當時確切的需求。

「從特性定義來看」

2019 年 UC Berkeley 在文章 CloudProgramming Simplified: A Berkeley View on Serverless Computing 中從 Serverless 架構特性的角度，對什麼是 Serverless 也進行了補充和描述：簡單地說，Serverless = FaaS + BaaS。在對於被認為是 Serverless 的服務時，它必須具備彈性伸縮和按量付費的特點；

在信通院雲原生產業聯盟所釋出的《雲原生髮展白皮書（2020 年）》中對 Serverless 的概念也有相關的描述：無伺服器（即 Serverless）是一種架構理念，其核心思想是將提供服務資源的基礎設施抽象成各種服務，以 API 介面的方式供給使用者按需呼叫，真正做到按需伸縮、按使用收費。這種架構體系結構消除了對傳統的海量持續線上伺服器元件的需求，降低了開發和運維的複雜性，降低運營成本並縮短了業務系統的交付週期，使得使用者能夠專注在價值密度更高的業務邏輯的開發上。

隨著各大廠商逐漸佈局 Serverless 領域，Serverless 逐漸地從啟蒙階段，市場教育階段邁向更深一步的生產應用與最佳實踐階段的方向前進，下文中我們會詳細介紹。

Serverless 的發展歷程

在 2017 年，CNCF Serverless WG 成立了，並且開始以社群的力量推動 Serverless 快速前行，包括 CNCF Serverless Whitepaper、CloudEvents 等相關的立項研究與探索，2017 年末，eWEEK 的 ChrisJ. Preimesberger 發表文章Predictions 2018: Why ServerlessProcessing May Be Wave of the Future 來表達在 “全新的階段下” 大家對 Serverless 的看法和期盼，在這篇文章中諸多來自知名團隊以及公司的相關負責人對 Serverless 表達了自己的想法：Serverless 可能是繼容器之後的未來，可以預見 Serverless 將不斷擴大影響力；重塑軟體的構建方式。

而到了 2018 年，Serverless 的發展速度要比想象中的更加快速，國內外雲廠商不斷髮力推出新技術，同年 CNCF 也正式釋出了 Serverless 領域的白皮書：CNCF Serverless Whitepaper V1.0，闡明 Serverless 技術概況、生態系統狀態，為 CNCF 的下一步動作做指導。同時 CloudEvnent 規範，進入 CNCF Sandbox。

在這一年，UC Berkeley 發文 Serverless Computing: One Step Forward, Two Steps Back，表達了對 Serverless 的擔憂和挑戰，作者認為 Serverless 會對開源服務創新有所阻塞。其實，任何一個新的技術、概念出現都會遇到一定的挑戰和擔憂，就如同當年雲端計算出現時，也被一些人認為只是又一個商業炒作的概念，當然事實也證明，任何一個新的事物，只有在經歷各種挑戰和質疑之後，才能更茁壯地成長。

從 2019 年開始，Serverless 進入到了一個真正意義上的生產應用，最佳實踐快速發展階段，這一年對 Serverless 而言是具有里程碑式意義的，被很多人定義為 “Serverless 正式發展的元年”。

在這一年不僅有 KubeCon 在中國上海的 CloudNativeCon 中關於 Serverless 的 “海量主題演講”，更有 UC Berkeley 最新的文章，Cloud Programming Simplified: A Berkeley View on Serverless Computing。

在這篇文章中，經歷了一年的發展，UC Berkeley 的學者們也從一年前的質疑，悲觀轉變成了自信與期待，並這篇文章中犀利斷言 Serverless 將會在接下來的十年被採用並得到飛速的發展，認為 Serverless 將引領雲端計算的下一個十年，並且重點闡述了以下新觀點：

• 新的 BaaS 儲存服務會被發明，以擴充套件在 Serverless 計算上能夠執行更加適配的應用程式型別。這樣的儲存能夠與本地塊儲存的效能相匹配，而且具有臨時和持久可供選擇。
• 比現有的 x86 微處理器更多的異構計算機。
• 更加安全、易用的程式設計，不僅具有高階語言的抽象能力，還有很好的細粒度的隔離性。
• 基於 Serverless 計算的價格將低於 Serverful 計算，至少不會高於 Serverful 計算。
• Serverless 將會接入更多的後臺支撐服務，如 OLTP 資料庫、訊息佇列服務等。
• Serverless 計算一旦取得技術上的突破，將會導致 Serverful 服務的下滑。
• Serverless 將會成為雲時代預設的計算正規化，將會取代 Serverful 計算，因此也意味著伺服器 - 客戶端模式的終結。

除了這些斷言，Berkeley 也對什麼是 “Serverless” 給出了自己的想法：

Put simply, Serverless computing = FaaS + BaaS. In our definition,for a service to be considered serverless, it must scale automatically with noneed for explicit provisioning, and be billed based on usage.

可以看到，從 IaaS 到 FaaS 再到 SaaS，再到如今的 Serverless，雲端計算的發展在近十餘年中發生了翻天覆地的變化，相信隨著 5G 時代的到來，Serverless 將會在更多領域發揮至關重要的作用。

Serverless 的最佳應用場景

Serverless 架構作為雲原生技術未來的演進方向，無伺服器架構技術也從觀望逐漸落地，據 Gartner 的過往預測資料顯示：到 2020 年全球將有 20% 的企業部署無伺服器架構。Serverless 將進一步釋放雲端計算的能力，將安全、可靠、可伸縮等需求交由基礎設施實現，使使用者僅需關注業務邏輯而無需關注具體部署和執行，極大地提高應用開發效率。同時這個方式促進了社會分工協作，雲廠商可以進一步通過規模化、集約化實現計算成本大幅優化。

聚焦業務核心價值

隨著雲服務的發展，計算資源被高度抽象化，從物理機到雲伺服器，再到容器服務，計算資源逐漸變得更加細膩化。Serverless 架構將會成為未來雲端計算領域中重要的技術架構，被更多的業務所採納，成為其技術選型，那麼再進一步的深究，Serverless 在什麼場景下可以有非常優秀的表現，在什麼型別的場景下可能表現得並不是很理想呢？或者說，有哪些場景更適合 Serverless 架構呢？

Serverless架構的應用場景，通常是由其特性決定方向，所支援的觸發器決定具體場景。

CNCF Serverless Whitepaper v1.0 所描述的使用者場景

如圖上圖所示，在 CNCFServerless Whitepaper v1.0 關於 Serverless 架構所適合的使用者場景包括：

• 非同步的併發，元件可獨立部署和擴充套件的場景
• 應對突發或服務使用量不可預測的場景
• 短暫、無狀態的應用，對冷啟動時間不敏感的場景
• 需要快速開發迭代的業務，因為無需提前申請資源，因此可以加快業務上線速度

CNCF 基於 Serverless 架構的特性給出了四個使用者場景之外，還結合常見的觸發器提供了詳細的例子：

• 響應資料庫更改 （插入、更新、觸發、刪除） 的執行邏輯
• 對物聯網感測器輸入訊息 （如 MQTT 訊息） 進行分析
• 處理流處理 （分析或修改動態資料）
• 管理單次提取、轉換和儲存需要在短時間內進行大量處理 （ETL）
• 通過聊天機器人介面提供認知計算 （非同步）
• 排程短時間內執行的任務，例如 CRON 或批處理的呼叫
• 機器學習和人工智慧模型
• 持續整合管道，按需為構建作業提供資源，而不是保持一個構建從主機池等待作業分派的任務

以上是從理論上描述了 Serverless 架構適合的場景或業務，雲廠商將會站在自身的業務角度，整體來描述 Serverless 架構的典型場景。通常情況下，物件儲存為觸發器在 Serverless 架構的典型應用場景包括視訊處理、資料 ETL 處理等；API 閘道器更多會為使用者賦能對外的訪問連結以及相關聯的功能等，當以 API 閘道器作為 Serverless 相關產品的觸發器時，常見的應用場景就是後端服務，包括 App 的後端服務，網站的後端服務甚至是微信小程式等相關產品的後端服務，同時像一些智慧音響也會開放相關的介面，這個介面也是可以通過 API 閘道器出發雲函式，獲得相應的服務等；除了物件儲存觸發以及 API 閘道器觸發，常見的觸發器還有訊息佇列觸發器，Kafka 觸發器，日誌觸發器等。

常見應用場景

「Web 應用/移動應用後端」

Serverless 架構和雲廠商所提供的其他雲產品進行結合，開發者能夠構建可彈性擴充套件的移動或 Web 應用程式 – 輕鬆建立豐富的無伺服器後端，而且這些程式可在多個資料中心高可用執行，無須在可擴充套件性、備份冗餘方面執行任何管理工作。例如 Web 應用處理示例：

（Web 應用後端處理示例）

「實時檔案/資料處理」

視訊應用、社交應用等場景下，使用者上傳的圖片、音視訊往往總量大、頻率高，對處理系統的實時性和併發能力都有較高的要求。

例如：對於使用者上傳的圖片，可以使用多個函式對其分別處理，包括圖片的壓縮、格式轉換、鑑黃鑑恐等，以滿足不同場景下的需求。例如：

（實時檔案處理示例）

通過 Serverless 架構所支援的豐富的事件源，通過事件觸發機制，可以通過幾行程式碼和簡單的配置對資料進行實時處理，例如：對物件儲存壓縮包進行解壓、對日誌或資料庫中的資料進行清洗、對 MNS 訊息進行自定義消費等：

（實時資料處理示例）

「離線資料處理」

通常要對大資料進行處理，需要搭建 Hadoop 或者 Spark 等相關大資料的框架，同時要有一個處理資料的叢集。通過 Serverless 技術，只需要將獲得到的資料不斷的儲存到物件儲存，並且通過物件儲存相關觸發器觸發資料拆分函式進行相關資料或者任務的拆分，然後再呼叫相關處理函式，處理完成之後，儲存到雲資料庫中。

例如：某證券公司每 12 小時統計一次該時段的交易情況並整理出該時段交易量 Top 5；每天處理一遍秒殺網站的交易流日誌獲取因售罄而導致的錯誤從而分析商品熱度和趨勢等。函式計算近乎無限擴容的能力可以使使用者輕鬆地進行大容量資料的計算。

利用 Serverless 架構可以對源資料併發執行多個 mapper 和 reducer 函式，在短時間內完成工作；相比傳統的工作方式，使用 Serverless 架構更能避免資源的閒置浪費從而節省成本，整個流程可以簡化為：

（資料 ETL 處理示例）

「人工智慧領域」

在 AI 模型完成訓練後，對外提供推理服務時，可以使用 Serverless 架構，通過將資料模型包裝在呼叫函式中，在實際使用者請求到達時再執行程式碼。相對於傳統的推理預測，這樣做的好處是無論是函式模組還是後端的 GPU 伺服器，以及對接的其他相關的機器學習服務，都是可以進行按量付費以及自動伸縮，從而保證效能的同時也確保了服務的穩定：

「IoT 等物聯網領域」

目前很多廠商都在推出自己的智慧音響產品，使用者可以對智慧音響說出一句話，智慧音響可以通過網際網路將這句話傳遞給後端服務，然後獲得到反饋結果，再返回給使用者。通過 Serverless 架構，可以將 API 閘道器、雲函式以及資料庫產品進行結合來替代傳統的伺服器或者是虛擬機器等。

通過這樣的一個架構，一方面，可以確保資源的按量付費，只有在使用的時候，函式部分才會計費，另一方面當使用者量增加之後，通過 Serverless 實現的智慧音響系統的後端，也會進行彈性伸縮，可以保證使用者側的服務穩定，當要對其中某個功能進行維護，相當於對單個函式進行維護，並不會對主流程產生額外風險。相對來說會更加安全、穩定等：

（IoT 後端處理示例）

「監控與自動化運維」

在實際生產中，經常需要做一些監控指令碼來監控網站服務或者 API 服務是否健康，包括是否可用、響應速度等。傳統的方法是通過一些網站監控平臺 （如阿里雲監控等）來進行監控和告警服務，這些監控平臺的原理是通過使用者自己設定要監控的網址和預期的時間閾值，由監控平臺部署在各地區的伺服器定期發起請求對網站或服務的可用性進行判斷。

當然，這些服務很多都是大眾化的，雖然說通用性很強，但是實際上並不一定適合。例如，現在需要監控某網站狀態碼，不同區域的延時，並且設定一個延時閾值，當網站狀態異常或者延時過大時，通過郵件等進行通知告警，針對這樣一個定製化需求，目前來說大部分的監控平臺很難直接實現，所以定製開發一個網站狀態監控工具就顯得尤為重要。

除此之外，在實際的生產運維中，還非常有必要對所使用的雲服務進行監控和告警，例如在使用 Hadoop、Spark 的時候要對節點的健康進行監控；在使用 K8S 的時候要對 API Server、ETCD 等多維度的指標進行監控；在使用 Kafka 的時候，也要對資料積壓量，以及Topic、Consumer等指標進行監控；這些服務的監控，往往不能通過簡單的 URL 以及某些狀態來進行判斷，在傳統的運維中，通常會在額外的機器上設定一個定時任務，對相關的服務進行旁路監控。

Serverless 架構的一個很重要應用場景就是運維、監控與告警，通過與定時觸發器進行結合使用，可以非常簡單地實現某些資源健康狀態監控與感知，並進行一些告警功能建設、自動化運維能力建設：

（網站監控告警示例）

結語

從虛擬空間到雲主機，從自建資料庫等業務，到雲資料庫等服務，雲端計算的發展是迅速地，未來的方向和形態卻是模糊的，沒人知道雲端計算的終態是什麼。誠然，現在有人說 Serverless 實現了當初了雲端計算目標，Serverless才是真正的雲端計算，但是沒人可以肯定地說，Serverless 就是雲端計算的終態表現，客觀地說，或許，Serverless 也僅僅是一個過渡的產物，但是這就要交給時間去驗證了。