要定義無伺服器架構（以下稱SA），請考慮它不是什麼。SA並不意味著沒有物理基礎設施或機器。SA實際上是一個從企業角度來看的術語。

建立後端基礎設施需要時間和持續維護。設定物理機或虛擬裝置，安裝應用程式，版本控制，配置，擴充套件，負載平衡，故障安全機制，訪問限制......列表是無止境的。一般而言，後端即服務（BaaS）或雲端計算通過繁重的工作來緩解大部分任務，因此，毫不奇怪，它在軟體開發中的受歡迎程度。但任何問題都沒有銀彈。

BaaS / Cloud面臨著自身的挑戰。想象一下，在任何流行的BaaS平臺上執行的服務每隔“M”分鐘處理“N”個請求。我們假設這導致CPU使用率為5％。如果您將服務處理的時間與24小時，一週，一個月等進行比較，則使用此費率......使用成本效率極低。輸入FaaS（功能即服務）或無伺服器體系結構。

FaaS或SA使企業能夠“按需”執行伺服器元件

1. 短暫的
2. 無狀態
3. 自動擴充套件

無伺服器體系結構基本上包括執行一小段時間並由事件作為公共HTTP請求或有時間限制（Timer）觸發或呼叫的函式。當這樣的請求上升時，FaaS平臺啟動，初始化（如果還沒有）並執行該功能。執行完成後，系統將關閉，直到下一次執行。因此，與傳統的BaaS“永遠線上”設定不同，我們有一個“並不總是”無伺服器架構。請注意，此過程因提供商而異！

無狀態

SA最適合無狀態執行。由於伺服器配置和基礎架構現在由雲提供商管理，因此無法保證將保留先前呼叫服務所維護的狀態。這並不意味著FaaS不支援有狀態操作，而只是宣告任何狀態都需要在FaaS例項之外處理。作為無伺服器的狀態完整操作的一個非常好的示例是通過AWS Lambda上傳到S3

自動縮放

在擴充套件方面，SA的好處是巨大的。水平擴充套件是自動的，由底層平臺處理。如果在特定時間點傳入流量很高，則呼叫FaaS的多個例項。如果流量暫停，則例項會自動減少。該平臺甚至可以處理底層資源管理和分配

實施/部署

FaaS函式可以在各種語言中實現，並且不需要對任何特定框架或任何庫進行編碼。例如，所有主要提供商都支援JS，Go等語言。程式碼/功能是編寫的，只需上傳即可。通過AWS lambda等服務，可以在AWS控制檯本身編寫程式碼。需要零配置。對於像產品創業這樣的中小型組織來說，這是一件非常重要的事情.

優點

1. 與我們在前面的示例中看到的現有云基礎架構相比，FaaS非常經濟。執行FaaS設定的成本僅取決於使用頻率和使用時間。
2. 由於擴充套件是自動且可靠的，因此企業不必擔心配置新伺服器例項或刪除未使用的伺服器例項的經濟性。一切都由服務提供商提供
3. 隨著規模經濟的重視，企業或開發人員可以專注於構建更好的解決方案。此外，降低成本使企業能夠以更短的開發週期進行創新和測試更新的產品

缺點

1. FaaS完全依賴於服務提供商，因此提供商端的問題就像停電，停機，維護，安全性將對企業服務產生重大影響
2. 由於FaaS本質上是一個無狀態伺服器，因此維護狀態的責任落在客戶端上。這可能導致多個客戶端的邏輯和資料的重新填充
3. FaaS本質上是一個時間實體。例如，Google Cloud Functions會在一分鐘後超時（也可以擴充套件）。AWS Lambda函式持續五分鐘。與“永遠線上”的BaaS例項不同，FaaS只能持續很短的時間

結論

無伺服器架構只是一種正規化，其中設定，擴充套件，配置伺服器端系統的責任被委託給另一個實體。它提供成本效益，更精簡的開發時間，可以為企業帶來連帶效應。同時，它根本無法取代構建在不同架構模型上的所有現有系統。可以作為FaaS實現的是依賴於上下文的！