寫給前端工程師的 Serverless 入門

原創不易，但願能關注下咱們，再順手點個贊~~

本文首發於政採雲前端團隊博客： 寫給前端工程師的 Serverless 入門

漫談 Serverless

Serverless 是前端圈近兩年比較火熱的詞彙，但其第一次被提出已是 7 年前的事情，那麼什麼是 Serverless 服務，其架構由哪些部分組成，又有什麼優缺點，本文將一一道來。

趨勢

參考《RightScale 2019 年雲狀態報告》，從 2018 年到 2019 年，Serverless 是公有云中使用率增加最快的服務，達到 50% 的增加速度，與 Streaming Process 並列第一。

從谷歌熱詞趨勢來看，Serverless 近兩年來處於穩步上升的趨勢，而且近一年的熱度一直處於較高的水平，熱度地區分佈圖中中國排在了 No.1，由此也能夠看出你們對 Serverless 的熱衷。依託於技術的熱度，Serverless 的發展也必將日益完備。

概念

咱們把 Serverless 拆解爲 server 和 less 兩個單詞，從字面上推斷詞意即爲「少服務器的，亦或是無服務器的」。固然這並不是指應用架構中是沒有服務器資源的，而是經過 Serverless 這種服務形態，用戶在使用對應的服務時，不須要關心或較少關心服務器的硬件資源、軟件資源、穩定性等等，這些一般已經由雲計算廠商提供設施、服務和 SLA 保障，徹底託管給雲計算廠商。而用戶只須要專一本身應用代碼自己，上傳執行函數到相應雲計算平臺，按照函數運行的時長按量付費便可。當前比較成熟的 Serverless 雲產品主要有 Amazon Lambda、Google Cloud Function、Azure Function、AliCloud Function Compute。

演進

雲計算誕生以前，大部分計算資源是處於「裸金屬」狀態的物理機，運維人員選擇對應規格的硬件，建設機房的 IDC 網絡，完成服務的提供，投入硬件基礎建設和維護的成本很高。

雲計算誕生後，用戶能夠直接購買雲主機（VM），把基礎物理硬件和網絡的管理都交由供應商管理，多用戶租用一臺物理機，但每臺雲主機對用戶來講就像是單獨的一臺物理機，用戶之間相互隔離。這種模式減小了用戶硬件管理成本，站在平臺的角度，咱們一般稱之爲 IaaS（Infrastructure-as-a-Service）。

隨着軟件的發展和容器技術的興起，計算環境由 VM 發展到更小粒度的容器，在容器中能夠運行不一樣的軟件服務，PaaS（Platform-as-a-Service） 和 CaaS（Container-as-a-Service） 也開始映入眼簾。用戶使用平臺基礎軟件如 Database、消息等開發本身的應用，使用容器鏡像構建和部署應用，最後託管給平臺。此時基礎設施的運維更加下沉，開發者只需關注基礎軟件和容器。

繼續向前發展，應用的運行演變爲更細粒度函數的運行，用戶開發特定業務的處理函數，託管給函數平臺，按需使用相關的後端服務，經過特定條件的觸發完成開發者業務邏輯函數的計算。用戶無需爲應用持續付費，只需支付函數運行時產生的資源消耗費用，而這，就是 Serverless 服務的模型。

架構

如上文的描述，Serverless 架構由兩部分組成，即 Faas 和 BaaS。

FaaS（Function-as-a-Service）即爲函數運行平臺，用戶無需搭建龐大的服務系統，只須要上傳本身的邏輯函數如一些定時任務、數據處理任務等到雲函數平臺，配置執行條件觸發器、路由等等，完成基礎函數的註冊。

BaaS（Backend-as-a-Service）包含了後端服務組件，它是基於 API 的第三方服務，用於實現應用程序中的核心功能，包含經常使用的數據庫、對象存儲、消息隊列、日誌服務等等。

Serverless 實際上是經過事件驅動的，當一個任務被觸發時，好比 HTTP 請求，API Gateway 接受請求、解析和認證，傳遞對應參數給雲函數平臺，平臺中執行對應回調函數，配合 DB、MQ 等 BaaS 服務在特定容器中完成計算，最終將結果返回給用戶。函數執行完成後，通常會被 FaaS 平臺銷燬，釋放對應容器，等待下一個函數運行。

優缺點

講完 Serverless 的基本架構，咱們來談談它的優勢和缺點。

根據 Serverless 的特性，咱們能夠總結出如下優勢：

一樣，Serverless 是一把雙刃劍，它也有一些缺陷須要咱們瞭解，以便取長補短：

1. 雲廠商強綁定 當你決定使用公有云的 Serverless 產品時，它們經常會和廠商的其餘雲產品相綁定，如對象存儲、消息等等，這意味你須要同時開通其餘的服務，將致使你的應用與平臺強綁定，遷移成本劇增。
2. 不適合長時間任務 雲函數平臺會限制函數執行時間，如阿里雲 Function Compute 最大執行時長爲 10 min，若是你的任務時間超長，那麼你須要拆分編排你的函數執行流程，並在一個函數執行結束時喚起另外一個函數執行。這將增長編碼的複雜度，並且花費上可能高於購買一個長時間運行的實例。
3. 冷啓動時間 函數運行時，執行容器和環境須要一個準備的時間，尤爲是第一次啓動時時間可能會較長。對一個 HTTP 請求來說，可能會帶來響應時延的增長，產生性能毛刺。
4. 調試與測試 因爲本地環境和平臺運行環境的差別性，開發者須要不斷調整代碼，打印日誌，並提交到函數平臺運行測試，會帶來一些開發成本和產生一些費用。

應用場景

結合以上的優缺點，實踐中咱們能夠發掘 Serverless 的落地場景，目前階段 Serverless 主要適合如下的應用場景：

1. 定時任務 經過時間觸發對應的函數任務，完成開發者業務邏輯的處理。
2. 數據加工 經過事驅動件機制，在特定的條件下觸發，對系統的日誌進行整合，或者對多媒體文件進行加工等等。
3. 低頻請求 用戶能夠按照頻次付費，而無需構建一個應用來應對這些必要的可是量小的請求。
4. IoT 物聯網場景下，大部分是用戶對設備的操控，用戶對時延的容忍度較高，也是典型的事件觸發且低頻場景。
5. 認知計算 適用於某些 AI 場景，如聊天機器人。

結語

目前，國內 Serverless 的發展還處於早期階段，一些配套和服務處於待完善階段，並且大型成功案例較少。但這並不妨礙咱們對技術革新的熱衷，站在前端工程師的角度看，Serverless 的持續發展，在未來可使前端更加容易的使用 Node.js 等語言搭建一個完善的應用，只需關注先後端的業務邏輯自己，而較少關心底層龐大的軟硬件系統和運維知識。將來也可能給先後端工做流程帶來必定變革，好比更統一的技術棧、設計規範和數據結構；更高的開發效率——應用搭建、聯調時間的縮短，促使 Web 前端工程師向 Web 應用工程師進化轉型。

參考資料

CNCF WG-Serverless Whitepaper v1.0

RightScale 2019 STATE OF THE CLOUD REPORT

函數計算

招賢納士

招人，前端，隸屬政採雲前端大團隊（ZooTeam），50 餘個小夥伴正等你加入一塊兒浪～ 若是你想改變一直被事折騰，但願開始能折騰事；若是你想改變一直被告誡須要多些想法，卻無從破局；若是你想改變你有能力去作成那個結果，卻不須要你；若是你想改變你想作成的事須要一個團隊去支撐，但沒你帶人的位置；若是你想改變「5年工做時間3年工做經驗」；若是你想改變原本悟性不錯，但老是有那一層窗戶紙的模糊… 若是你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的本身。若是你但願參與到隨着業務騰飛的過程，親手參與一個有着深刻的業務理解、完善的技術體系、技術創造價值、影響力外溢的前端團隊的成長曆程，我以爲咱們該聊聊。任什麼時候間，等着你寫點什麼，發給ZooTeam@cai-inc.com

推薦閱讀

前端工程實踐之可視化搭建系統（一）

看完這篇，你也能把 React Hooks 玩出花

自動化 Web 性能優化分析方案