圖解 Serverless！秒懂！

作者 | 江昱（阿里雲 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 又是什麼，它在雲計算發展的過程中，又在扮演什麼角色呢，它的去服務器化又到了什麼程度呢？

「01」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 逐漸地從啓蒙階段，市場教育階段邁向更深一步的生產應用與最佳實踐階段的方向前進，下文中我們會詳細介紹。

「02」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 將引領雲計算的下一個十年，並且重點闡述了以下新觀點：

除了這些斷言，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 將進一步釋放雲計算的能力，將安全、可靠、可伸縮等需求交由基礎設施實現，使用戶僅需關注業務邏輯而無需關注具體部署和運行，極大地提高應用開發效率。同時這個方式促進了社會分工協作，雲廠商可以進一步通過規模化、集約化實現計算成本大幅優化。

「01」聚焦業務核心價值

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

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

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

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

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

以上是從理論上描述了 Serverless 架構適合的場景或業務，雲廠商將會站在自身的業務角度，整體來描述 Serverless 架構的典型場景。通常情況下，對象存儲爲觸發器在 Serverless 架構的典型應用場景包括視頻處理、數據 ETL 處理等；API 網關更多會爲用戶賦能對外的訪問鏈接以及相關聯的功能等，當以 API 網關作爲 Serverless 相關產品的觸發器時，常見的應用場景就是後端服務，包括 App 的後端服務，網站的後端服務甚至是微信小程序等相關產品的後端服務，同時像一些智能音箱也會開放相關的接口，這個接口也是可以通過 API 網關出發雲函數，獲得相應的服務等；除了對象存儲觸發以及 API 網關觸發，常見的觸發器還有消息隊列觸發器，Kafka 觸發器，日誌觸發器等。

「02」常見應用場景

「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 也僅僅是一個過渡的產物，但是這就要交給時間去驗證了。

架構師社區 架構師社區，專注分享架構師技術乾貨，架構師行業祕聞，彙集各類奇妙好玩的架構師話題和流行的架構師動向！

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/GLdWHFF7NPdO38qpIFcNnw

猜你喜歡