Serverless 架構到底要不要服務器？

做者 | aoho
來源 | Serverless 公衆號

Serverless 是什麼？

Serverless 架構是否是就不要服務器了？回答這個問題，咱們須要瞭解下 Serverless 是什麼。

Serverless 架構近幾年頻繁出如今一些技術架構大會的演講標題中，不少人對於 Serverless，只是從字面意義上理解——無服務器架構，可是它真正的含義是開發者不再用過多考慮服務器的問題，固然，這並不表明徹底去除服務器，而是咱們依靠第三方資源服務器後端，從 2014 年開始，通過這麼多年的發展，各大雲服務商基本都提供了 Serverless 服務。好比使用 Amazon Web Services(AWS) Lambda 計算服務來執行代碼。

國內 Serverless 服務的發展相對 AWS 要晚一點，目前也都有對 Serverless 的支持。比較著名的雲服務商有阿里雲、騰訊雲。它們提供的服務也大同小異：函數計算、對象存儲、API 網關等，很是容易上手。

架構是如何演進到 Serverless ？

看看過去幾十年間，雲計算領域的發展演進歷程。總的來講，雲計算的發展分爲三個階段：虛擬化的出現、虛擬化在雲計算中的應用以及容器化的出現。雲計算的高速發展，則集中在近十幾年。

總結來講有以下的里程碑事件：

• 經過虛擬化技術將大型物理機虛擬成單個的 VM 資源。
• 將虛擬化集羣搬到雲計算平臺上，只作簡單運維。
• 把每個 VM 按照運行空間最小化的原則切分紅更細的 Docker 容器。
• 基於 Docker 容器構建不用管理任何運行環境、僅需編寫核心代碼的 Serverless 架構。

從裸金屬機器的部署應用，到 Openstack 架構和虛擬機的劃分，再到容器化部署，這其中典型的就是近些年 Docker 和 Kubernetes 的流行，進一步發展爲使用一個微服務或微功能來響應一個客戶端的請求 ，這種方式是雲計算髮展的天然過程。

這個發展歷程也是一場 IT 架構的演進，期間經歷了一系列代際的技術變革，把資源切分得更細，讓運行效率更高，讓硬件軟件維護更簡單。IT 架構的演進主要有如下幾個特色：

• 硬件資源使用顆粒度變小
• 資源利用率愈來愈高
• 運維工做逐步減小
• 業務更聚焦在代碼層面

1. Serverless 架構的組成

Serverless架構分爲 Backend as a Service(BaaS) 和 Functions as a Service(FaaS) 兩種技術，Serverless 是由開發者實現的服務端邏輯運行在無狀態的計算容器中，它是由事件觸發、徹底被第三方管理的。

2. 什麼是 BaaS?

Baas 的英文翻譯成中文的含義：後端即服務，它的應用架構由大量第三方雲服務器和 API 組成，使應用中關於服務器的邏輯和狀態都由服務提供方來管理。好比咱們的典型的單頁應用 SPA 和移動 APP 富客戶端應用，先後端交互主要是以 RestAPI 調用爲主。只須要調用服務提供方的 API 便可完成相應的功能，好比常見的身份驗證、雲端數據/文件存儲、消息推送、應用數據分析等。

3. 什麼是 FaaS?

FaaS 能夠被叫作：函數即服務。開發者能夠直接將服務業務邏輯代碼部署，運行在第三方提供的無狀態計算容器中，開發者只須要編寫業務代碼便可，無需關注服務器，而且代碼的執行是由事件觸發的。其中 AWS Lambda 是目前最佳的 FaaS 實現之一。

Serverless 的應用架構是將 BaaS 和 FaaS 組合在一塊兒的應用，用戶只須要關注應用的業務邏輯代碼，編寫函數爲粒度將其運行在 FaaS 平臺上，而且和 BaaS 第三方服務整合在一塊兒，最後就搭建了一個完整的系統。整個系統過程當中徹底無需關注服務器。

Serverless 架構的特色

總得來講，Serverless 架構主要有如下特色：

• 實現了細粒度的計算資源分配
• 不須要預先分配資源
• 具有真正意義上的高度擴容和彈性
• 按需使用，按需計費

因爲 Serverless 應用與服務器的解耦，購買的是雲服務商的資源，使得 Serverless 架構下降了運維的壓力，也無需進行服務器硬件等預估和購買。

Serverless 架構使得開發人員更加專一於業務服務的實現，中間件和硬件服務器資源都託管給了雲服務商。這同時下降了開發成本，按需擴展和計費，無需考慮基礎設施。

Serverless 架構給前端也帶來了便利，大前端深刻到業務端的成本下降，開發者只須要關注業務邏輯，前端工程師輕鬆轉爲全棧工程師。

Serverless 有哪些應用場景？

應用場景與 Serverless 架構的特色密切相關，根據 Serverless 的這些通用特色，咱們概括出下面幾種典型使用場景：彈性伸縮、大數據分析、事件觸發等。

1. 彈性伸縮

因爲雲函數事件驅動及單事件處理的特性，雲函數經過自動的伸縮來支持業務的高併發。針對業務的實際事件或請求數，雲函數自動彈性合適的處理實例來承載實際業務量。在沒有事件或請求時，無運行實例，不佔用資源。如視頻直播服務，直播觀衆不固定，須要考慮適度的併發和彈性。直播不可能 24 小時在線，有較爲明顯的業務訪問高峯期和低谷期。直播是事件或者公衆點爆的場景，更新速度較快，版本迭代較快，須要快速完成對新熱點的技術升級。

2. 大數據分析

數據統計自己只須要不多的計算量，離線計算生成圖表。在空閒的時候對數據進行處理，或者不須要考慮任何延時的狀況下。

• 開發者編寫代碼，目前支持的語言 Java、NodeJS、Python 等語言；
• 把代碼上傳到函數計算上，上傳的方式有經過 API 或者 SDK 上傳，也能夠經過控制檯頁面上傳，還能夠經過命令行工具 Fcli 上傳；
• 經過 API&SDK 來觸發函數計算執行，一樣也能夠經過雲產品的事件源來觸發函數計算執行；
• 函數計算在執行過程當中，會根據用戶請請求量動態擴容函數計算來保證請求峯值的執行，這個過程對用戶是透明無感知的；
• 函數執行結束。

3. 事件觸發

事件觸發即雲函數由事件驅動，事件的定義能夠是指定的 http 請求，或者數據庫的 binlog 日誌、消息推送等。經過 Serverless 架構，在控制檯上配置事件源通知，編寫業務代碼。業務邏輯添加到到函數計算裏，業務高峯期函數計算會動態伸縮，這個過程不須要管理軟硬件環境。常見的場景如視頻、OSS 圖片，當上傳以後，經過進行後續的過濾、轉換和分析，觸發一系列的後續處理，如內容不合法、容量告警等。

小結

回到咱們文章的開頭，Serverless 架構不是不要服務器了，而是依託第三方雲服務平臺，服務端邏輯運行在無狀態的計算容器中，其業務層面的狀態則被開發者使用的數據庫和存儲資源所記錄。

Serverless 無服務器架構有其適合應用的場景，可是也存在侷限性。總得來講，Serverless 架構還不夠成熟，不少地方尚不完善。Serverless 依賴雲服務商提供的基礎設施，目前來講雲服務商還作不到真正的平臺高可用。Serverless 資源雖然便宜，可是構建一個生產環境的應用系統卻比較複雜。

雲計算還在不斷髮展，基礎設施服務日趨完善，開發者將會更加專一於業務邏輯的實現。雲計算將平臺、中間件、運維部署的責任進行了轉移，同時也下降了中小企業上雲的成本。讓咱們一塊兒期待 Serverless 架構的將來。

參考：

1. 阿里雲文檔
2. https://blog.csdn.net/cc18868876837/article/details/90672971