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的版本控制，持續整合，持續部署，監控和日誌記錄。版本控制是我們對程式碼進行版本化的過程，以便我們可以對其進行分支，打包，部署和回滾到以前的版本。持續整合是開發人員使用自動構建將程式碼整合在一起以在早期檢測和緩解問題的實踐。持續部署基本上是一個匯流排或管道，其中程式碼使用自動化測試不斷改進，然後部署到環境中。該管道平穩地向生產方向移動，只需極少的人工干預。