共計 5190 個字符，預計需要花費 13 分鐘才能閱讀完成。
這篇文章給大家介紹什么是 Serverless，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
什么是 Serverless?
今天我就帶你深入地了解下 Serverless，看看這到底是什么?
Serverless 能解決什么問題?
從字面意思理解，Serverless 包含 server 和 less 兩部分，Server 這里指服務端，它是 Serverless 解決問題的邊界; 而 less 我們可以理解為較少關心，它是 Serverless 解決問題的目的，因此，組合在一起，Serverless 就是“較少關心服務端”。
什么是服務端?
我們先看 Server，這里我用 Web 應用經典的 MVC 架構來舉例。
MVC 架構主要分為前端和后端，前端負責客戶終端的體驗，也就是 View 層; 后端負責商業的業務邏輯和數據處理，也就是 Control 層和 Model 層。如果你有過一些開發經驗，應該會了解自己的代碼在本地開發和調試時的數據流。
通常我們會在自己電腦上啟動一個端口號，例如 127.0.0.1:3001。瀏覽器訪問這個地址，就可以調用和調試自己的代碼。但如果我們要將這個 Web 應用部署到互聯網上，提供給互聯網用戶訪問，就需要服務端的運維知識了。
如果要考慮容災和容錯，可以部署多個 Web 應用實例，以保障異地多活。而為了使多個 Web 應用實例在容災和容錯的場景下穩定地切換流量，我們需要使用負載均衡服務和反向代理服務。負載均衡服務，正如其名是負責將流量均衡地分配到各個應用機器上; 反向代理常見的就是 Nginx，它的任務是從請求中解析出域名信息，并將請求轉發到上游 upstream 的監聽地址。
服務端的邊界，就是上圖中的整個藍色部分，它是負責應用或代碼的線上運維。Serverless 解決問題的邊界，就是服務端的邊界，即服務端運維。
服務端運維發展史，從 Serverfull 到 Serverless
我們可以先看看 Serverfull 的概念，然后對比一下 Serverfull 和 Serverless 之間的差別，相信這樣可以加深你的理解。Serverfull 就是服務端運維全由我們自己負責，Serverless 則是服務端運維較少由我們自己負責，大多數的運維工作交給自動化工具負責。
可能這么說比較抽象，我舉個例子來說吧。
假設我有一家互聯網公司，我的產品是“待辦任務(ToDoList)”Web 應用 mdash; mdash; 即記錄管理每個用戶的待辦任務列表。針對這個網站的研發，我們簡化為兩個獨立角色：研發工程師小程和運維工程師小服。
做研發的小程，他是個精通前后端的全棧工程師，但他只關心應用的業務邏輯。具體來說就是，整個 MVC 架構的 Web 應用的開發、升級和問題修復都歸小程負責。負責運維的小服，則只關心應用的服務端運維事務。比如負責部署上線小程的 Web 應用，綁定域名以及日志監控。在用戶訪問量大的時候，給這個應用擴容; 在用戶訪問量小的時候，給這個應用縮容; 在服務器掛了的時候，重啟或者換一臺服務器等。
史前時代，Serverfull
最開始運維工程師小服承諾將運維的事情全包了，小程不用關心任何部署運維相關的事情。于是，小程每次發布新的應用，都會打電話給小服，讓小服部署上線最新的代碼。小服要管理好迭代版本的發布，分支合并，將應用上線，遇到問題回滾。如果線上出了故障，還要抓取線上的日志發給小程解決。
小程和小服通過工作職責任務上的安排，將研發和運維完全隔離開來了。好處很明顯：分工明確，小程可以專心做好自己的業務; 缺陷也很明顯：小服成了工具人，被困在了大量的運維工作中，處理各種發布相關的瑣碎雜事。
這個時代研發和運維隔離，服務端運維都交給小服一個人，純人力處理，也就是 Serverfull。
農耕時代，DevOps
我們可以停下來想想，其實像發布版本和處理線上故障這種工作，應該小程的職責，而不應該全部由小服協助，對不對?
實際上，后來小服也漸漸發現，日常其實有很多事情都是重復性的工作，尤其是發布新版本的時候，與其每次都等小程電話，線上出故障了還要自己抓日志發過去，效率很低，不如干脆自己做一套運維控制臺 OpsConsole，將部署上線和日志抓取的工作讓小程自己處理。
說干就干，OpsConsole 上線后，小服確實稍微輕松了一些，但是優化架構節省資源和擴縮容資源方案，還是需要小服定期審查。而小程除了開發的任務，每次發布新版本或解決線上故障，還要自己到 OpsConsole 平臺上去處理。
這個時代就是研發兼運維 DevOps，小程兼任了小服的部分工作，小服將部分服務端運維的工作工具化了，自己可以去做更加專業的事情。
相對史前時代，農耕時代小服已經將部分人力的工作工具化了，其結果是效率變高了。此時，已經有 Serverless 的趨勢了。
我們再想想能否進一步提升效率，讓小程連 OpsConsole 平臺都可以不用?
工業時代，Serverless
小服發現資源優化和擴縮容方案也可以利用性能監控 + 流量估算解決，于是小服又基于小程的開發流程，將 OpsConsole 系統再進一步優化，幫小程做了一套代碼自動化發布的流水線：代碼掃描 mdash; mdash; 測試 mdash; mdash; 灰度驗證 mdash; mdash; 上線?，F在的小程連 OpsConsole 都可以不用登陸操作，只要將最新的代碼合并到 Git 倉庫指定的 develop 分支，剩下的就都由流水線自動化處理發布上線了。
這個時代研發不需要運維了，免運維 NoOps。小服的服務端運維工作全部自動化了，小程也變回到最初，只需要關心自己的應用業務就可以了。
我們不難看出，在服務端運維的發展歷史中，對于小程來說，小服的角色存在感越來越弱，需要小服參與的事情越來越少，都由自動化工具替代了。
到這里你一定會想，既然服務端都做到免運維了，小服是不是就自己革了自己的命，失業了?
未來
實現了免運維 NoOps，并不意味著小服要失業了，而是小服要轉型，轉型去做更底層的服務，做基礎架構的建設，提供更加智能、更加節省資源、更加周到的服務。小程則可以完全不被運維的事情困擾，放心大膽地依賴 Serverless 服務，專注做好自己的業務，提升用戶體驗，思考業務價值。
免運維 NoOps 并不是說服務端運維就不存在了，而是通過全知全能的服務，覆蓋研發部署需要的所有需求，讓研發同學小程對它的感知越來越少。另外，NoOps 是理想狀態，因為我們只能無限逼近 NoOps。
另外，你需要知道的是，目前大多數互聯網公司，包括一線互聯網公司，都還在 DevOps 時代。只是 Serverless 的概念已經提出，NoOps 的時代正在到來。
按照上面的分解，Serverless 可以叫做服務端免運維，這也就是 Serverless 要解決的問題。
到底什么是 Serverless?
總結來說 Serverless 的含義有這樣兩種：
第一種：狹義 Serverless(最常見)= Serverless computing 架構 = FaaS 架構 = Trigger(事件驅動)+ FaaS(函數即服務)+ BaaS(后端即服務，持久化或第三方服務)= FaaS + BaaS
第二種：廣義 Serverless = 服務端免運維 = 具備 Serverless 特性的云服務
我用圖片來闡明一下這兩種概念。
雖然你可以看到，廣義 Serverless 包含的東西更多，適用范圍更廣，但我們經常在工作中提到的 Serverless 一般都是指狹義的 Serverless。這是有歷史原因的，2014 年 11 月份，亞馬遜推出真正意義上的第一款 Serverless FaaS 服務：Lambda。Serverless 的概念才進入了大多數人的視野，也因此 Serverless 曾經一度就等于 FaaS。
圖中有幾個陌生的名詞，我先來給你解釋下。FaaS(Function as a Service) 就是函數即服務，BaaS(Backend as a Service) 就是后端即服務。XaaS(X as a Service) 就是 X 即服務，這是云服務商喜歡使用的一種命名方式，比如，我們熟悉的 SaaS、PaaS、IaaS 都是這樣。
先說 FaaS，函數即服務，它還有個名字叫作 Serverless Computing，它可以讓我們隨時隨地創建、使用、銷毀一個函數。
你可以想一下通常函數的使用過程：它需要先從代碼加載到內存，也就是實例化，然后被其它函數調用時執行。在 FaaS 中也是一樣的，函數需要實例化，然后被觸發器 Trigger 或者被其他的函數調用。二者最大的區別就是在 Runtime，也就是函數的上下文，函數執行時的語境。
FaaS 的 Runtime 是預先設置好的，Runtime 里面加載的函數和資源都是云服務商提供的，我們可以使用卻無法控制。你可以理解為 FaaS 的 Runtime 是臨時的，函數調用完后，這個臨時 Runtime 和函數一起銷毀。
FaaS 的函數調用完后，云服務商會銷毀實例，回收資源，所以 FaaS 推薦無狀態的函數。如果你是一位前端工程師的話，可能很好理解，就是函數不可改變 Immutable。簡單解釋一下，就是說一個函數只要參數固定，返回的結果也必須是固定的。
用我們上面的 MVC 架構的 Web 應用舉例，View 層是客戶端展現的內容，通常并不需要函數算力;Control 層，就是函數的典型使用場景。MVC 架構里面，一個 HTTP 的數據請求，就會對應一個 Control 函數，我們完全可以用 FaaS 函數來代替 Control 函數。在 HTTP 的數據請求量大的時候，FaaS 函數會自動擴容多實例同時運行; 在 HTTP 的數據請求量小時，又會自動縮容; 當沒有 HTTP 數據請求時，還會縮容到 0 實例，節省開支。
此刻或許你會有點疑惑，Runtime 不可控，FaaS 函數無狀態，函數的實例又不停地擴容縮容，那我需要持久化存儲一些數據怎么辦，MVC 里面的 Model 層怎么解決?
此時我就要介紹另一位嘉賓 mdash; mdash; BaaS 了。
BaaS 其實是一個集合，是指具備高可用性和彈性，而且免運維的后端服務。說簡單點，就是專門支撐 FaaS 的服務。FaaS 就像高鐵的車頭，如果我們的后端服務還是老舊的綠皮火車車廂，那肯定是要散架的，而 BaaS 就是專門為 FaaS 準備的高鐵車廂。
MVC 架構中的 Model 層，就需要我們用 BaaS 來解決。Model 層我們以 MySQL 為例，后端服務最好是將 FaaS 操作的數據庫的命令，封裝成 HTTP 的 OpenAPI，提供給 FaaS 調用，自己控制這個 API 的請求頻率以及限流降級。這個后端服務本身則可以通過連接池、MySQL 集群等方式去優化。各大云服務商自身也在改造自己的后端服務，BaaS 這個集合也在日漸壯大。
基于 Serverless 架構，我們完全可以把傳統的 MVC 架構轉換為 BaaS+View+FaaS 的組合，重構或實現。
這樣看下來的話，狹義 Serverless 的含義也就不難理解了。
第一種：狹義 Serverless(最常見)= Serverless computing 架構 = FaaS 架構 = Trigger(事件驅動)+ FaaS(函數即服務)+ BaaS(后端即服務，持久化或第三方服務)= FaaS + BaaS
Serverless 毋庸置疑正是因為 FaaS 架構才流行起來，進入大家認知的。所以我們最常見的 Serverless 都是指 Serverless Computing 架構，也就是由 Trigger、FaaS 和 BaaS 架構組成的應用。這也是我給出的狹義 Serverless 的定義。
那什么是廣義 Serverless 呢?
將狹義的 Serverless 推升至廣義，具備以下特性的，就是 Serverless 服務。你可以回憶一下小服的工作，要達成 NoOps，都應該具備什么條件?
小服的工作職責：
無需用戶關心服務端的事情(容錯、容災、安全驗證、自動擴縮容、日志調試等等)。
按使用量 (調用次數、時長等) 付費，低費用和高性能并行，大多數場景下節省開支。
快速迭代 試錯能力(多版本控制，灰度，CI CD 等等)。
廣義 Serverless，其實就是指服務端免運維，也是未來的主要趨勢。
總結來說的話就是，我們日常談 Serverless 的時候，基本都是指狹義的 Serverless，但當我們提到某個服務 Serverless 化的時候，往往都是指廣義的 Serverless。
狹義 Serverless 是指用 FaaS+BaaS 這種 Serverless 架構開發的應用; 廣義 Serverless 則是具備 Serverless 特性的云服務?，F在的云服務商，正在積極地將自己提供的各種云服務 Serverless 化。
關于什么是 Serverless 就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
