概念
我們把 Serverless 拆解爲 server 和 less 兩個單詞，從字面上推斷詞意即爲“少服務器的，亦或是無服務器的”。當然這並非指應用架構中是沒有服務器資源的，而是通過 Serverless 這種服務形態，用戶在使用對應的服務時，不需要關心或較少關心服務器的硬件資源、軟件資源、穩定性等等，這些通常已經由雲計算廠商提供設施、服務和 SLA 保障，完全託管給雲計算廠商。而用戶只需要專注自己應用代碼本身，上傳執行函數到相應雲計算平臺，按照函數運行的時長按量付費即可。
演進
雲計算誕生之前，大部分計算資源是處於“裸金屬”狀態的物理機，運維人員選擇對應規格的硬件，建設機房的 IDC 網絡，完成服務的提供，投入硬件基礎建設和維護的成本很高。
雲計算誕生後，用戶可以直接購買雲主機（VM），把基礎物理硬件和網絡的管理都交由供應商管理，多用戶租用一臺物理機，但每臺雲主機對用戶來說就像是單獨的一臺物理機，用戶之間相互隔離。這種模式減少了用戶硬件管理成本，站在平臺的角度，我們通常稱之爲 IaaS（Infrastructure-as-a-Service）。
隨着軟件的發展和容器技術的興起，計算環境由 VM 發展到更小粒度的容器，在容器中可以運行不同的軟件服務，PaaS（Platform-as-a-Service） 和 CaaS（Container-as-a-Service） 也開始映入眼簾。用戶使用平臺基礎軟件如 Database、消息等開發自己的應用，使用容器鏡像構建和部署應用，最後託管給平臺。此時基礎設施的運維更加下沉，開發者只需關注基礎軟件和容器。
繼續向前發展，應用的運行演變爲更細粒度函數的運行，用戶開發特定業務的處理函數，託管給函數平臺，按需使用相關的後端服務，通過特定條件的觸發完成開發者業務邏輯函數的計算。用戶無需爲應用持續付費，只需支付函數運行時產生的資源消耗費用，而這，就是 Serverless 服務的模型。
Serverless的歷史
【發軔之始】
2012年雲基礎設施服務提供商Iron.io的副總裁Ken 提出軟件的未來 ，首次提出來Serverless概念， 以下是原文的一段摘錄：
Even with the rise of cloud computing, the world still revolves around servers.
That won’t last, though. Cloud apps are moving into a serverless world, and
that will bring big implications for the creation and distribution of software
and applications.
【初出茅廬】
AWS的Lambda產品發佈，Serverless正式走上雲計算的舞臺
【嶄露頭角】
衆多laaS和Paas廠商相繼入場
【未來已來】
隨着容器技術，IoT，5G，區塊鏈等技術的快速發展， 技術上對去中心化，輕量虛擬化，細粒度計算等技術需求愈發強烈，而Serverless必將借勢迅速發展。
業界產品
架構
如上文的描述，Serverless 架構由兩部分組成，即 Faas 和 BaaS。
Faas
FaaS（Function-as-a-Service）即爲函數運行平臺，用戶無需搭建龐大的服務系統，只需要上傳自己的邏輯函數如一些定時任務、數據處理任務等到雲函數平臺，配置執行條件觸發器、路由等等，完成基礎函數的註冊。
BaaS
BaaS（Backend-as-a-Service）包含了後端服務組件，它是基於 API 的第三方服務，用於實現應用程序中的核心功能，包含常用的數據庫、對象存儲、消息隊列、日誌服務等等。
Baas和Paas的區別
PaaS需要參與應用的生命週期管理，BaaS則僅僅提供應用依賴的第三方服務。典型的PaaS平臺需要提供手段讓開發者部署和配置應用，例如自動將應用部署到Tomcat容器中，並管理應用的生命週期。BaaS不包含這些內容，BaaS只以API的方式提供應用依賴的後端服務，例如數據庫和對象存儲。BaaS可以是公共雲服務商提供的，也可以是第三方廠商提供的。其次從功能上講，BaaS可以看作PaaS的一個子集，即提供第三方依賴組件的部分。
BaaS服務還允許我們依賴其他人已經實現的應用邏輯。對於這點，認證就是一個很好的例子。很多應用都要自己編寫實現註冊、登錄、密碼管理等邏輯的代碼，而對於不同的應用這些代碼往往大同小異。完全可以把這些重複性的工作提取出來，再做成外部服務，而這正是Auth0和Amazon Cognito等產品的目標。它們能實現全面的認證和用戶管理，開發團隊再也不用自己編寫或者管理實現這些功能的代碼。
Serverless工作機制
Serverless 其實是通過事件驅動的，當一個任務被觸發時，比如 HTTP 請求，API Gateway 接受請求、解析和認證，傳遞對應參數給雲函數平臺，平臺中執行對應回調函數，配合 DB、MQ 等 BaaS 服務在特定容器中完成計算，最終將結果返回給用戶。函數執行完成後，一般會被 FaaS 平臺銷燬，釋放對應容器，等待下一個函數運行。
優缺點
講完 Serverless 的基本架構，我們來談談它的優點和缺點。
根據 Serverless 的特性，我們可以總結出以下優點：
同樣，Serverless 是一把雙刃劍，它也有一些缺陷需要我們瞭解，以便取長補短：
-
雲廠商強綁定 當你決定使用公有云的 Serverless產品時，它們常常會和廠商的其他雲產品相綁定，如對象存儲、消息等等，這意味你需要同時開通其他的服務，將導致你的應用與平臺強綁定，遷移成本劇增。
-
不適合長時間任務 雲函數平臺會限制函數執行時間，如阿里雲 Function Compute 最大執行時長爲 10
min，如果你的任務時間超長，那麼你需要拆分編排你的函數執行流程，並在一個函數執行結束時喚起另一個函數執行。這將增加編碼的複雜度，而且花費上可能高於購買一個長時間運行的實例。 -
冷啓動時間 函數運行時，執行容器和環境需要一個準備的時間，尤其是第一次啓動時時間可能會較長。對一個 HTTP請求來講，可能會帶來響應時延的增加，產生性能毛刺。
-
調試與測試 由於本地環境和平臺運行環境的差異性，開發者需要不斷調整代碼，打印日誌，並提交到函數平臺運行測試，會帶來一些開發成本和產生一些費用。
應用場景
結合以上的優缺點，實踐中我們可以發掘 Serverless 的落地場景，目前階段 Serverless 主要適合以下的應用場景：
-
定時任務 通過時間觸發對應的函數任務，完成開發者業務邏輯的處理。
-
數據加工 通過事件驅動件機制，在特定的條件下觸發，對系統的日誌進行整合，或者對多媒體文件進行加工等等。
-
低頻請求 用戶可以按照頻次付費，而無需構建一個應用來應對這些必要的但是量小的請求。
-
IoT 物聯網場景下，大部分是用戶對設備的操控，用戶對時延的容忍度較高，也是典型的事件觸發且低頻場景。
-
認知計算 適用於某些 AI 場景，如聊天機器人。
結語
目前，國內 Serverless 的發展還處於早期階段，一些配套和服務處於待完善階段，而且大型成功案例較少。但這並不妨礙我們對技術革新的熱衷，站在前端工程師的角度看，Serverless 的持續發展，在將來可以使前端更加容易的使用 Node.js 等語言搭建一個完善的應用，只需關注前後端的業務邏輯本身，而較少關心底層龐大的軟硬件系統和運維知識。未來也可能給前後端工作流程帶來一定變革，比如更統一的技術棧、設計規範和數據結構；更高的開發效率——應用搭建、聯調時間的縮短，促使 Web 前端工程師向 Web 應用工程師進化轉型。
參考文章：
https://www.zoo.team/article/serverless
https://www.jianshu.com/p/85d8bcd6ad81
https://blog.csdn.net/cc18868876837/article/details/90672971