Serverless（無伺服器架構）4大優點和缺點

Serverless核心概念在早期，術語無伺服器

是指依賴於第三方應用程序或服務來管理伺服器端邏輯的應用程序。 此類應用程序是基於雲的資料庫（如Google Firebase）或身份驗證服務（如Auth0或AWS Cognito）。 它們被稱為後端即服務（BaaS）服務。 但無伺服器也意味著開發為事件觸發的代碼，並且在無狀態計算容器中執行。 這種架構通常稱為功能即服務（FaaS）。 讓我們更詳細地看一下每種類型的服務。

FaaS(Function as a service 函數作為一種服務) 本質上是一個小程序或函數，它執行由事件觸發的小任務，而不像單個應用程序那樣做很多事情。因此，在FaaS架構中，我們將應用程序分解為小型，自包含的程序或功能，而不是在PaaS上運行並執行多種功能的單一應用程序。例如，API中的每個端點都可以是一個單獨的函數，我們可以按需運行這些函數，而不是全時運行應用程序。

常見的方法是在多層體系結構中編寫API，類似於三層體系結構，其中代碼分解為表??示，業務和數據層。所有路由都將在業務層中觸發相同的處理函數，並且數據將被處理並發送到數據層，數據層可以是資料庫或文件。

在FaaS系統中，預計函數將在幾毫秒內啟動，以便處理各個請求。相比之下，在PaaS系統中，通常有一個應用程序線程可以長時間運行，並處理多個請求。 FaaS服務按功能的每個執行時間收費，而PaaS服務按伺服器應用程序運行的線程的每個運行時間收費。

在微服務架構中，應用程序鬆散耦合，細粒度和輕量級。微服務誕生的原因是將整體應用程序分解為小型服務，以便可以獨立開發，管理和擴展。但FaaS更進一步，將事情分解為甚至更小的稱為功能的單位。

趨勢非常明確：工作單位越來越小。

OpenFaaS支持Windows和Linux上的Node.js，Python，GO和C＃。

我們可以通過雲，本地筆記本電腦或內部部署伺服器進行設置。我們可以為幾乎所有東西編寫函數 - 這就是OpenFaas聲稱的內容。 OpenFaaS是用Golang編寫的。它允許通過HTTP / HTTPS請求的事件。

Fission是無伺服器架構的另一個開源版本 - 底層技術是Kubernetes和Docker容器，可以部署在雲和內部部署基礎架構上。它被設計為一組微服務，其組件是控制器，路由器和池管理器。路由器管理HTTP請求，控制器管理功能，事件觸發器和環境映像，池管理器管理容器池並將功能載入到這些容器中。這些函數是用Python編寫的。

無伺服器優勢使用無伺服器架構有許多優缺點。

為什麼有人會使用無伺服器架構（如AWS Lambda或OpenWhiz）構建應用程序？

主要原因是應用程序的執行效率，擴展速度，以及最重要的成本。讓我們看一些重要的專業人士，然後繼續前進。

1. 更快的上市時間我們可以更快地將應用程序推向市場，因為OPS變得更加簡單，並且將幫助開發人員專註於他們的開發。 OPS團隊無需編寫可以處理擴展或擔心底層基礎架構的代碼。

此外，團隊可以在第三方集成的幫助下更快地構建應用程序，例如OAuth，Twitter和Maps等API服務。

2.高度可擴展性每家公司都希望他們的應用程序能夠更好地運行，零停機時間，並且隨著流量的增加而快速，輕鬆地擴展，但是通過單一的應用程序開發，它可能變得非常困難。隨著應用程序負載的增加，Ops團隊必須在擴展底層基礎架構時保持警惕。由於交通量的增加，停機時間浪費了大量的時間和金錢。

但無伺服器計算具有高度可擴展性，可以在幾秒鐘內對應用程序進行縮放和縮放。

3.低成本在無伺服器計算中，開發人員僅在功能運行時付費，與IaaS和PaaS不同，IaaS和PaaS為每台伺服器24/7收費。這對於擁有龐大的應用程序，API或微服務設置的公司來說非常有用，這些應用程序，API或微服務目前全天候運行並且100％的時間使用資源，無論是否需要。但是對於無伺服器，我們可以按需執行功能並共享資源，而不是全天候運行應用程序，因此我們可以大大減少空閑時間，並使應用程序運行得更快。

4.延遲和地理定位

改進應用程序的可擴展性取決於三個因素：用戶數量，用戶位置和網路延遲。在當今世界，應用程序擁有全球受眾，這可能會增加延遲。但是無伺服器平台可以大大減輕延遲的危險。使用無伺服器時，實例化容器以在每個事件調用時運行函數，並且可以在用戶的??地理區域附近創建此容器，這將自動提高應用程序的性能。

讓我們看一下無伺服器功能的缺點

1.複雜性增加我們使用應用程序越精細，它就越複雜。每個函數的代碼可能會變得更簡單，但整個應用程序將變得更加複雜。比如說，我們將應用程序分解為10個不同的微服務。我們必須管理10個不同的應用程序，而在單個應用程序中，它只是一個必須管理的應用程序。

2.缺乏工具支持 假設我們將單片應用程序分解為50種不同的功能。仍然有各種各樣的流程和工具來管理，記錄，監視和部署整體應用程序。由於無伺服器是市場上的新產品，因此監控或記錄運行幾秒鐘的應用程序是有限的並且具有挑戰性，但是隨著時間的推移，將會有許多有效的方法來實現這一點。

3. 與體系結構的複雜性很難決定函數的粒度，並且評估，實現和測試以檢查我們的首選項是耗時的。

4. 管理太多功能會很麻煩，同時忽略粒度會導致我們設置迷你巨石。

5.實施中的缺點無伺服器的最大挑戰是集成測試難。

我們將為應用程序編寫許多函數，但是如何將它們集成到應用程序中？當然，在此之前，我們如何測試它們如何有效地協同工作？由於無伺服器是新的並且仍在成熟，通過測試添加的選項仍然有限。但是我們將在以後的章節中介紹部署和測試的幾個方面。

無伺服器DevOps的DevOps是另一個流行語很長一段時間。

與無伺服器一樣，DevOps也是一個令人困惑的術語。很多人對DevOps有很多不同的看法。有人說DevOps只是工具，有些人認為DevOps包含一些流程 - 甚至IaaS和PaaS也屬於DevOps的範疇。根據我的理解，DevOps是工具，流程和反饋的協作。它們齊頭並進，以成功實施DevOps。但為什麼我們在這裡談論DevOps？簡而言之，因為我們需要DevOps才能順利過渡到生產，記錄或監控無伺服器功能，並在它們到達用戶之前對其進行測試。

藉助DevOps功能，我將介紹AWS Lambda函數，Azure功能，Google功能和OpenWhiz的版本控制，持續集成，持續部署，監控和日誌記錄。版本控制是我們對代碼進行版本化的過程，以便我們可以對其進行分支，打包，部署和回滾到以前的版本。持續集成是開發人員使用自動構建將代碼集成在一起以在早期檢測和緩解問題的實踐。持續部署基本上是一個匯流排或管道，其中代碼使用自動化測試不斷改進，然後部署到環境中。該管道平穩地向生產方向移動，只需極少的人工干預。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！