帶加密狗的軟件破解【電同徽I7I5–4833—762】參考《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 是一把雙刃劍，它也有一些缺陷需要我們瞭解，以便取長補短：
雲廠商強綁定 當你決定使用公有云的 Serverless 產品時，它們常常會和廠商的其他雲產品相綁定，如對象存儲、消息等等，這意味你需要同時開通其他的服務，將導致你的應用與平臺強綁定，遷移成本劇增。
不適合長時間任務 雲函數平臺會限制函數執行時間，如阿里雲 Function Compute 最大執行時長爲 10 min，如果你的任務時間超長，那麼你需要拆分編排你的函數執行流程，並在一個函數執行結束時喚起另一個函數執行。這將增加編碼的複雜度，而且花費上可能高於購買一個長時間運行的實例。
冷啓動時間 函數運行時，執行容器和環境需要一個準備的時間，尤其是第一次啓動時時間可能會較長。對一個 HTTP 請求來講，可能會帶來響應時延的增加，產生性能毛刺。
調試與測試 由於本地環境和平臺運行環境的差異性，開發者需要不斷調整代碼，打印日誌，並提交到函數平臺運行測試，會帶來一些開發成本和產生一些費用。
應用場景
結合以上的優缺點，實踐中我們可以發掘 Serverless 的落地場景，目前階段 Serverless 主要適合以下的應用場景：
定時任務 通過時間觸發對應的函數任務，完成開發者業務邏輯的處理。
數據加工 通過事驅動件機制，在特定的條件下觸發，對系統的日誌進行整合，或者對多媒體文件進行加工等等。
低頻請求 用戶可以按照頻次付費，而無需構建一個應用來應對這些必要的但是量小的請求。
IoT 物聯網場景下，大部分是用戶對設備的操控，用戶對時延的容忍度較高，也是典型的事件觸發且低頻場景。
認知計算 適用於某些 AI 場景，如聊天機器人。
結語
目前，國內 Serverless 的發展還處於早期階段，一些配套和服務處於待完善階段，而且大型成功案例較少。但這並不妨礙我們對技術革新的熱衷，站在前端工程師的角度看，Serverless 的持續發展，在將來可以使前端更加容易的使用 Node.js 等語言搭建一個完善的應用，只需關注前後端的業務邏輯本身，而較少關心底層龐大的軟硬件系統和運維知識。未來也可能給前後端工作流程帶來一定變革，比如更統一的技術棧、設計規範和數據結構；更高的開發效率——應用搭建、聯調時間的縮短，促使 Web 前端工程師向 Web 應用工程師進化轉型。