理解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)