統統透透看無服務器計算：由來、場景和問題

1、 無服務器（Serverless）計算是什麼

雲計算涌現出不少改變傳統IT架構和運維方式的新技術，好比虛擬機、容器、微服務，不管這些技術應用在哪些場景，下降成本、提高效率是雲服務永恆的主題。過去十年來，咱們已經把應用和環境中不少通用的部分變成了服務。Serverless的出現，帶來了跨越式變革。Serverless把主機管理、操做系統管理、資源分配、擴容，甚至是應用邏輯的所有組件都外包出去，把它們看做某種形式的商品——廠商提供服務，咱們掏錢購買。過去是「構建一個框架運行在一臺服務器上，對多個事件進行響應」，Serverless則變爲「構建或使用一個微服務或微功能來響應一個事件」，作到當訪問時，調入相關資源開始運行，運行完成後，卸載全部開銷，真正作到按需按次計費。這是雲計算向縱深發展的一種天然而然的過程。
Serverless是一種構建和管理基於微服務架構的完整流程，容許你在服務部署級別而不是服務器部署級別來管理你的應用部署。它與傳統架構的不一樣之處在於，徹底由第三方管理，由事件觸發，存在於無狀態（Stateless）、暫存（可能只存在於一次調用的過程當中）計算容器內。構建無服務器應用程序意味着開發者能夠專一在產品代碼上，而無須管理和操做雲端或本地的服務器或運行時。Serverless真正作到了部署應用無需涉及基礎設施的建設，自動構建、部署和啓動服務。
國內外的各大雲廠商 Amazon、微軟、Google、IBM、阿里雲、騰訊雲、華爲雲相繼推出Serverless產品，Serverless也從概念、願景逐步走向落地，在各企業、公司應用開來。

2、 理解Serverless技術---FaaS和BaaS
Serverless由開發者實現的服務端邏輯運行在無狀態的計算容器中，它由事件觸發， 徹底被第三方管理，其業務層面的狀態則被開發者使用的數據庫和存儲資源所記錄。
Serverless涵蓋了不少技術，分爲兩類：FaaS和BaaS。
1）Function-as-a-Service (FaaS)
• 小段代碼，按需執⾏，按需擴展，無需管理任何基礎實施相關的部分。
• 事件驅動型計算。函數被事件觸發或者被HTTP請求調用。
2）Backend-as-a-Service (BaaS)
• 第三方基於API的服務，實現應用開發中的基礎功能模塊。
• 這些API像服務同樣，自動擴展，無需管理。

1.Faas
FaaS意在無須自行管理服務器系統或本身的服務器應用程序，便可直接運行後端代碼。其中所指的服務器應用程序，是該技術與容器和PaaS（平臺即服務）等其餘現代化架構最大的差別。
FaaS能夠取代一些服務處理服務器（多是物理計算機，但絕對須要運行某種應用程序），這樣不只不須要自行供應服務器，也不須要全時運行應用程序。
FaaS產品不要求必須使用特定框架或庫進行開發。在語言和環境方面，FaaS函數就是常規的應用程序。例如AWS Lambda的函數能夠經過Javascript、Python以及任何JVM語言（Java、Clojure、Scala）等實現。然而Lambda函數也能夠執行任何捆綁有所需部署構件的進程，所以可使用任何語言，只要能編譯爲Unix進程便可。FaaS函數在架構方面確實存在必定的侷限，尤爲是在狀態和執行時間方面。
在遷往FaaS的過程當中，惟一須要修改的代碼是「主方法/啓動」代碼，其中可能須要刪除頂級消息處理程序的相關代碼（「消息監聽器接口」的實現），但這可能只須要更改方法簽名便可。在FaaS的世界中，代碼的其他全部部分（例如向數據庫執行寫入的代碼）無須任何變化。
相比傳統系統，部署方法會有較大變化 – 將代碼上傳至FaaS供應商，其餘事情都可由供應商完成。目前這種方式一般意味着須要上傳代碼的全新定義（例如上傳zip或JAR文件），隨後調用一個專有API發起更新過程。
FaaS中的函數能夠經過供應商定義的事件類型觸發。對於亞馬遜AWS，此類觸發事件能夠包括S3（文件）更新、時間（計劃任務），以及加入消息總線的消息（例如Kinesis）。一般你的函數須要經過參數指定本身須要綁定到的事件源。
大部分供應商還容許函數做爲對傳入Http請求的響應來觸發，一般這類請求來自某種該類型的API網關（例如AWS API網關、Webtask）。

2.Baas
BaaS（Backend as a Service，後端即服務）是指咱們再也不編寫或管理全部服務端組件，可使用領域通用的遠程組件（而不是進程內的庫）來提供服務。理解BaaS，須要搞清楚它與PaaS的區別。
首先BaaS並不是PaaS，它們的區別在於：PaaS須要參與應用的生命週期管理，BaaS則僅僅提供應用依賴的第三方服務。典型的PaaS平臺須要提供手段讓開發者部署和配置應用，例如自動將應用部署到Tomcat容器中，並管理應用的生命週期。BaaS不包含這些內容，BaaS只以API的方式提供應用依賴的後端服務，例如數據庫和對象存儲。BaaS能夠是公共雲服務商提供的，也能夠是第三方廠商提供的。其次從功能上講，BaaS能夠看做PaaS的一個子集，即提供第三方依賴組件的部分。

BaaS服務還容許咱們依賴其餘人已經實現的應用邏輯。對於這點，認證就是一個很好的例子。不少應用都要本身編寫實現註冊、登陸、密碼管理等邏輯的代碼，而對於不一樣的應用這些代碼每每大同小異。徹底能夠把這些重複性的工做提取出來，再作成外部服務，而這正是Auth0和Amazon Cognito等產品的目標。它們能實現全面的認證和用戶管理，開發團隊不再用本身編寫或者管理實現這些功能的代碼。

3、 無服務器（Serverless）計算如何工做？
與使用虛擬機或一些底層的技術來部署和管理應用程序相比，無服務器計算提供了一種更高級別的抽象。由於它們有不一樣的抽象和「觸發器」的集合。
拿計算來說，這種抽象有一個特定函數和抽象的觸發器，它一般是一個事件。以數據庫爲例，這種抽象也許是一個表，而觸發器至關於表的查詢或搜索，或者經過在表中作一些事情而生成的事件。
好比一款手機遊戲，容許用戶在不一樣的平臺上爲全球頂級玩家使用高分數表。當請求此信息時，請求從應用程序到API接口。API接口或許會觸發AWS的Lambda函數，或者無服務器函數，這些函數再從數據庫表中獲取到數據流，返回包含前五名分數的必定格式的數據。
一旦構建完成，應用程序的功能就能夠在基於移動和基於 Web 的遊戲版本中重用。
這跟設置服務器不一樣，不是必需要有Amazon EC2實例或服務器，而後等待請求。環境由事件觸發，而響應事件所需的邏輯只在響應時執行。這意味着，運行函數的資源只有在函數運行時被建立，產生一種很是高效的方法來構建應用程序。

4、 無服務器（Serverless）適用於哪些場景？

在現階段，Serverless主要應用在如下幾個場景。首先在Web及移動端服務中，能夠整合API網關和Serverles服務構建Web及移動後端，幫助開發者構建可彈性擴展、高可用的移動或 Web後端應用服務。在IoT場景下可高效的處理實時流數據，由設備產生海量的實時信息流數據，經過Serverles服務分類處理並寫入後端處理。另外在實時媒體資訊內容處理場景裏，用戶上傳的音視頻到對象存儲OBS，經過上傳事件觸發多個函數，分別完成高清轉碼、音頻轉碼等功能，知足用戶對實時性和併發能力的高要求。無服務器計算還適合於任何事件驅動的各類不一樣的用例，這包括物聯網，移動應用，基於網絡的應用程序和聊天機器人等。這裏簡單說兩個場景，方便你們思考。
場景一：應用負載有顯著的波峯波谷
Serverless 應用成功與否的評判標準並非公司規模的大小，而是其業務背後的具體技術問題，好比業務波峯波谷明顯，如何實現削峯填谷。一個公司的業務負載具備波峯波谷時，機器資源要按照峯值需求預估；而在波谷時期機器利用率則明顯降低，由於不能進行資源複用而致使浪費。

業界廣泛共識是，當自有機器的利用率小於 30%，使用 Serverless 後會有顯著的效率提高。對於雲服務廠商，在具有了足夠多的用戶以後，各類波峯波谷疊加後平穩化，聚合以後資源複用性更高。好比，外賣企業負載高峯是在用餐時期，安防行業的負載高峯則是夜間，這是受各個企業業務定位所限的；而對於一個成熟的雲服務廠商，若是其平臺足夠大，用戶足夠多，是不該該有明顯的波峯波谷現象的。

場景二：典型用例 - 基於事件的數據處理
視頻處理的後端系統，常見功能需求以下：視頻轉碼、抽取數據、人臉識別等，這些均爲通用計算任務，可由函數計算執行。
開發者須要本身寫出實現邏輯，再將任務按照控制流鏈接起來，每一個任務的具體執行由雲廠商來負責。如此，開發變得更便捷，而且構建的系統自然高可用、實時彈性伸縮，用戶不須要關心機器層面問題。

5、Serverless 的問題
對於企業來講，支持Serverless計算的平臺能夠節省大量時間和成本，同時能夠釋放員工，讓開發者得以開展更有價值的工做，而不是管理基礎設施。另外一方面能夠提升敏捷度，更快速地推出新應用和新服務，進而提升客戶滿意度。可是Serverless不是完美的，它也存在一些問題，須要慎重應用在生產環境。
一、不適合長時間運行應用
Serverless 在請求到來時才運行。這意味着，當應用不運行的時候就會進入 「休眠狀態」，下次當請求來臨時，應用將會須要一個啓動時間，即冷啓動時間。若是你的應用須要一直長期不間斷的運行、處理大量的請求，那麼你可能就不適合採用 Serverless 架構。若是你經過 CRON 的方式或者 CloudWatch 來按期喚醒應用，又會比較消耗資源。這就須要咱們對它作優化，若是頻繁調用，這個資源將會常駐內存，第一次冷啓以後，就能夠一直服務，直到一段時間內沒有新的調用請求進來，則會轉入「休眠」狀態，甚至被回收，從而不消耗任何資源。
二、徹底依賴於第三方服務
當你所在的企業雲環境已經有大量的基礎設施的時候，Serverless 對於你來講，並非一個好東西。當咱們採用某雲服務廠商的 Serverless 架構時，咱們就和該服務供應商綁定了，那麼咱們再將服務遷到別的雲服務商上就沒有那麼容易了。

咱們須要修改一下系列的底層代碼，能採起的應對方案，即是創建隔離層。這意味着，在設計應用的時候，就須要隔離 API 網關、隔離數據庫層，考慮到市面上尚未成熟的 ORM 工具，讓你既支持Firebase，又支持 DynamoDB等等。這些也將帶給咱們一些額外的成本，可能帶來的問題會比解決的問題多。

三、缺少調試和開發工具
當我使用 Serverless Framework 的時候，遇到了這樣的問題：缺少調試和開發工具。後來，我發現了 serverless-offline、dynamodb-local 等一系列插件以後，問題有一些改善。然而，對於日誌系統來講，這仍然是一個艱鉅的挑戰。

每次你調試的時候，你須要一遍又一遍地上傳代碼。而每次上傳的時候，你就好像是在部署服務器，並不能老是快速地定位出問題在哪。後來，找了一個相似於 log4j 這樣的能夠分級別記錄日誌的 Node.js 庫 winston。它能夠支持 error、warn、info、verbose、debug、silly 六個不一樣級別的日誌，再結合大數據進行日誌分析過濾，才能快速定位問題。
四、構建複雜
Serverless 很便宜，可是這並不意味着它很簡單。AWS Lambda的 CloudFormation配置是如此的複雜，而且難以閱讀及編寫（JSON 格式），雖然CloudFomation提供了Template模板，但想要使用它的話，須要建立一個Stack，在Stack中指定你要使用的Template,而後aws纔會按照Template中的定義來建立及初始化資源。

而Serverless Framework的配置更加簡單，採用的是 YAML 格式。在部署的時候，Serverless Framework 會根據咱們的配置生成 CloudFormation 配置。然而這也並不是是一個真正用於生產的配置,真實的應用場景遠遠比這複雜。

6、總結
雲計算通過這麼多年的發展，逐漸進化到用戶僅需關注業務和所需的資源。好比，經過K8S這類編排工具，用戶只要關注本身的計算和須要的資源（CPU、內存等）就好了，不須要操心到機器這一層。

Serverless架構讓人們再也不操心運行所需的資源，只需關注本身的業務邏輯，而且爲實際消耗的資源付費。能夠說，隨着Serverless架構的興起，真正的雲計算時代纔算到來了。

任何新概念新技術的落地，本質上都是要和具體業務去結合，去真正解決具體問題。雖然Serverless不少地方不成熟，亟待完善。不過Serverless自身的優越特性，對於開發者來講，吸引力是巨大的。相信隨着技術的飛速發展，Serverless在將來還有無限可能！