理解serverless無服務架構原理(一)

閱讀目錄

• 一：什麼是serverless無服務？
• 二：與傳統模式架構區別？
• 三：serverless優缺點？
• 四：使用serverless的應用場景有哪些？

回到頂部

一：什麼是serverless無服務？

serverless中文的含義是 "無服務器"，可是它真正的含義是開發者不再用過多考慮服務器的問題，可是並不表明徹底去除服務器，而是咱們依靠第三方資源服務器後端，好比使用 Amazon Web Services(AWS) Lambda. 計算服務來執行代碼，那麼Serverless架構分爲 Backend as a Service(BaaS) 和 Functions as a Service(FaaS) 兩種技術，Serverless 它是由開發者實現的服務端邏輯運行在無狀態的計算容器中，它是由事件觸發，徹底被第三方管理的。

什麼是BaaS?

Baas 的英文翻譯成中文的含義：後端即服務，它的應用架構由大量第三方雲服務器和API組成的，使應用中關於服務器的邏輯和狀態都由服務提供方來管理的。好比咱們的典型的單頁應用SPA和移動APP富客戶端應用，先後端交互主要是以RestAPI調用爲主。只須要調用服務提供方的API便可完成相應的功能，好比常見的身份驗證，雲端數據/文件存儲，消息推送，應用數據分析等。

什麼是FaaS?

FaaS能夠被叫作：函數即服務。開發者能夠直接將服務業務邏輯代碼部署，運行在第三方提供的無狀態計算容器中，開發者只須要編寫業務代碼便可，無需關注服務器，而且代碼的執行它是由事件觸發的。其中AWS Lambda是目前最佳的FaaS實現之一。

Serverless的應用架構是將BaaS和FaaS組合在一塊兒的應用，用戶只須要關注應用的業務邏輯代碼，編寫函數爲粒度將其運行在FaaS平臺上，而且和BaaS第三方服務整合在一塊兒，最後就搭建了一個完整的系統。整個系統過程當中徹底無需關注服務器。

回到頂部

二：與傳統模式架構區別？

傳統的架構模式是使用C/S架構的，在典型的web應用程序中，服務器接收前端的HTTP請求處理，在保存或查詢數據庫以前，數據可能會通過多個應用層，最終後端會返回一個響應。好比它能夠是JSON形式或其餘格式等。而後他會將響應返回給客戶端，好比以下圖所示：

在傳統開發模式中，開發流程：設計師設計頁面 -> 服務端開發 和 前端分別開發，服務器開發完成後，-> 服務部署 ->服務部署完成後，就是先後端聯調 -> 先後端聯調 -> 先後端聯調完成後就是測試了，-> 測試， 測試完成須要上線，所以 -> 上線，上線完成後，須要運維維護，所以 -> 運維。在傳統開發模式中，開發一個應用程序，從開始到上線須要不一樣的角色來作不一樣的事情，溝通成本很是大，而且運維過程當中須要考慮到 服務器的負載均衡、事務、集羣、緩存、
消息傳遞和數據冗餘等等這些事情，在目前傳統模式中存在如上問題。可使用以下示意圖來看下如上流程。以下圖所示：

在Serverless架構中，應用業務邏輯是基於FaaS架構造成多個相互獨立的功能組件的。而且以API服務的形式向外提供服務，在FaaS中，後端的應用被拆分紅爲一個個函數，咱們只須要編寫完成函數後部署到serverless服務便可。後續咱們也不用關心任何服務器的操做。那麼整個流程就只須要咱們一個前端工程師的角色來完成全部的開發工做，那麼溝通成本下降了。所以咱們可使用以下示意圖來表示項目流程，以下所示：

前端工程師是居於serverless去寫後端服務的，典型的就是居於 AWS Lambda 中編寫代碼，AWS中支持不一樣的語言。
Lambda計算服務它可以以大規模並行的方式執行代碼來響應事件。經過使用Lambda以及使用各類功能強大的API和Web服務，開發者能夠快速的構建鬆耦合，可擴展性及高效的架構體系。

注意：Lambda是什麼？它是一種計算服務，它在AWS基礎上執行用javascript、node.js、Python、C#或java編寫的代碼，源代碼將被打包並部署到孤立的容器中，該容器有單獨分配的內存、磁盤空間和處理器。代碼、配置和依賴項的組合被稱做爲Lambda函數。

回到頂部

三：serverless優缺點？

優勢有以下：

1. 下降創業公司啓動成本

當一家創業公司的時候，在開發web的時候，咱們須要版本管理服務器、持續集成服務器、測試服務器、應用版本管理倉庫等做爲基礎服務。
線上運行的時候，爲了應對大量的請求，咱們還須要一個好的數據庫服務器。當咱們應用面向普通的用戶時，咱們須要：

1.1 郵件服務，用於發送提醒，註冊等服務。
1.2 短信服務，用於註冊，登陸等用戶受權操做。

如上一些對於大公司來說，都有現成的基礎設施。但是對於創業公司來說。這都須要一些啓動成本。可是若是咱們使用serverless就能夠下降這些成本。

2. 減小運營成本

對於創業公司來說，他們沒有基礎設施，沒有財力，也可能沒有能力去建設基礎設施，採用雲服務是最好的選擇，能夠爲他們節省大量的資金。
他們只要將精力放在對用戶價值的產品之上便可，他們不須要本身去搭建服務器，所以會有更多的時間去開發業務功能。而採用函數計算的serverless與雲服務器最大的區別是：雲服務器須要一直運行，好比說月費或年費要多少錢租，可是serverless是按需計費的，若是有請求到來的時候，才運行函數，不然的話，是不須要錢的。

3. 下降開發成本

serverless會提供一系列的配套服務，好比 咱們只須要在配置文件上寫下數據庫的表名，那麼數據就會存儲到對應的數據庫裏面，而且會提供一系列的函數計算模板，咱們只須要寫好咱們的配置便可，那麼這一系列的東西均可以自動，高效的完成任務。

4. 實現快速上線

對於一些傳統項目來說，咱們在本地開發須要部署環境，到開發環境或測試環境，咱們仍是須要部署環境。可是serverless能夠在部署上有優點，而且很輕鬆的實現上線。由於serverless內部至關於有 內建自動化部署功能，而且在該裏面都是由供應商提供的功能，每次咱們寫完業務代碼後，咱們只須要運行下便可，在AWS Lambda 函數計算裏面，函數通常在上傳後幾秒鐘內，就能作好調用準備。

5. 系統安全性更高。

要保持服務器一直運行不是件容易的事情，而且還須要考慮黑客不一樣類型的攻擊，可是有serverless後，咱們不須要考慮這些問題了，這些問題第三方供應商已經會幫我解決這些問題的。

6. 能適應微服務架構和擴展性能力強

Serverless 的背後是 諸如 AWS Lambda 這樣的 FaaS（Function as a Services）。

對於傳統應用來講，要應對更多的請求的方式，就是部署更多的實例。然而，這個時候每每已經來不及了。而對於 FaaS 來講，咱們並不須要這麼作，FaaS 會自動的擴展。它能夠在須要時儘量多地啓動實例副本，而不會發生冗長的部署和配置延遲。

以亞馬遜的AWS Lambda爲案例，Lambda能讓咱們不用思考任何服務器，也就是說，不用咱們處理服務器上的部署，服務器的容量和服務器的擴展和失敗容錯，還有服務器上選擇什麼OS操做系統，語言的更新，日誌等等問題。你的應用程序只須要和多個第三方的API或服務打交道，也能夠自我建立一個無服務器的
API。

缺點有以下：

1. 不適合長時間運行應用

serverless 在請求到來的時候才運行，當應用不運行的時候會進入 "休眠狀態"，下次當請求來臨時，應用將會須要一個啓動時間，能夠叫 冷啓動，若是咱們的應用須要一直長期不間斷的運行，處理大量的請求，那麼可能就不適合使用serverless來架構了，若是這種狀況下，咱們須要使用像EC2這樣的雲服務器會是一個更好的選擇。

EC2至關於咱們本身買了一輛車，在Lambda 至關於咱們租了一輛車。若是咱們長期租車的話，那麼確定比買車更貴，可是租車能夠減小一部分車維護成本。

2. 徹底會依賴於第三方服務

若是咱們全部和應用相關的服務放在第三方服務上的話，就可能會涉及到安全性問題，所以咱們能夠將不重要的API或服務放在serverless上。
固然若是咱們本身有服務設施的話，那確定使用本身的設施服務的，當咱們本身使用serverless架構的時候，那麼咱們就已經和供應商綁定了。
若是這個時候咱們將服務遷到別的雲服務商上就沒有那麼容易了。

3. 缺少調式和開發工具，排查問題困難。

4. 沒法用於高併發運用。

爲每一個請求啓動一個進程開銷過高，流量瞬間爆發容易超時。好比淘寶的雙十一支付寶高峯期，每秒處理交易筆數8萬多筆，也就意味着咱們的系統內每秒有8萬多個進程建立又被銷燬。那麼這樣就會形成系統開銷很大。解釋和第一點同樣的原理。

回到頂部

四：使用serverless的應用場景有哪些？

Serverless 適合構建比較簡單的應用，好比上傳一張圖片，對一段音頻/視頻進行編碼或解碼，對請求返回一小段數據等。

Serverless架構主要有如下特色：

1. 實現了細粒度的計算資源分配。
2. 不須要預分配資源。
3. 具有真正意義上的高度擴容和彈性。
4. 按需使用，按需計費。

所以如下應用將可能使用serverless架構：

1. 靜態網站的管理。
2. 替代WordPress(Serverless Blog Project)
3. 我的媒體服務器(less!)
4. 物聯網Iot或家庭自動框架或項目 (使用 AWS IoT)

具體的應用基本以下：

發送通知：

諸如 PUSH Notification、郵件通知接口、短信，這一類服務來講，他們都須要基礎設施來搭建。而且，他們對實時性的要求相對沒有那麼高。
即便在時間上晚來幾秒鐘，用戶仍是能接受的。在咱們所見到的短信發送的例子裏，通常都會假設用戶能在 60 秒內收到短信。所以，在這種時間 1s 的偏差，用戶也不會惱火的。而對於 APP 的消息推送而言，這種要求就更低了，用戶反而不太但願能收到這樣的推送。

WebHook

當咱們沒有服務器，又想要一個 Webhook 來觸發咱們一系列的操做的時候。咱們就能夠考慮使用 Serverless，咱們不須要一直就這麼支付一個服務器的費用。經過 Serverless，咱們就能夠輕鬆完成這樣的工做，而且節省大量的費用。

數據統計分析

數據統計自己只須要不多的計算量，可是生成圖表，則能夠按期生成。

在接收數據的時候，咱們不須要考慮任何延時帶來的問題。50~200 ms 的延時，並不會對咱們的系統形成什麼影響。

Trigger 及定時任務

對於哪些須要爬蟲來抓取和生成的程序來講，Serverless 多是一個不錯的舞臺。

儘管，這樣的工做也能夠由雲服務器來作，咱們只須要定時的啓動一下服務器。經過服務器中的自啓動腳原本作相應的事，可是當咱們完成了一系列的工做以後。咱們須要將數據存儲在一個遠程的服務器上。而爲了讓系統中的其它應用，也能直接訪問這些數據。那麼，咱們可能會考慮使用一個雲數據庫。這個時候，Serverless 應用看上去更具備吸引力。

Chat 機器人

聊天機器人，也是一個至關好的應用場景。

But，因爲國內的條件限制（信息監管），這並非一件容易的事。所以，從渠道（如微信、blabla）上，都在儘量地下降這方面的可能性。

可是，咱們還能夠作一個微信公衆號的服務。當用戶輸入一個關鍵詞時，作出相應的回覆，這實質上和聊天機器人是差很少的。