背景

您已應用微服務架構模式並將系統架構為一組服務。每個服務都部署為一組服務例項，以實現吞吐量和可用性。

問題

如何打包和部署服務？

訴求

• 服務使用各種語言，框架和框架版本編寫
• 每個服務由多個服務例項組成，用於吞吐量和可用性
• 服務必須可獨立部署和擴充套件
• 服務例項需要彼此隔離
• 您需要能夠快速構建和部署服務
• 您需要能夠約束服務所消耗的資源（CPU和記憶體）
• 您需要監視每個服務例項的行為
• 您希望部署可靠
• 您必須儘可能經濟高效地部署應用程式

解決方案

使用隱藏任何伺服器概念（即保留或預分配資源）的部署基礎結構 - 物理或虛擬主機或容器。基礎架構獲取服務的程式碼並執行它。根據消耗的資源，您需要為每個請求付費。

要使用此方法部署服務，請將程式碼打包（例如，作為ZIP檔案），將其上載到部署基礎結構並描述所需的效能特徵。

部署基礎結構是由公共雲提供商運營的實用程式。它通常使用容器或虛擬機器來隔離服務。但是，這些細節對您來說是隱藏的。您或您組織中的任何其他人都不負責管理任何低階基礎架構，如作業系統，虛擬機器等。

例子

有幾種不同的無伺服器部署環境：

• AWS Lambda
• Google Cloud Functions
• Azure功能

它們提供類似的功能，但AWS Lambda具有最豐富的功能集。 AWS Lambda函式是一個無狀態元件，可以呼叫它來處理事件。要建立AWS Lambda函式，請將ZIP服務的NodeJS，Java或Python程式碼打包到ZIP檔案中，然後將其上載到AWS Lambda。您還可以指定處理事件和資源限制的函式的名稱。

發生事件時，AWS Lambda會找到您的函式的空閒例項，如果沒有可用的則啟動一個例項並呼叫處理函式。 AWS Lambda執行足夠的函式例項來處理負載。在封面下，它使用容器來隔離lambda函式的每個例項。正如您所料，AWS Lambda在EC2例項上執行容器。

有四種方法可以呼叫lambda函式。一種選擇是配置要呼叫的lambda函式，以響應由AWS服務（如S3，DynamoDB或Kinesis）生成的事件。事件的示例包括以下內容：

• 在S3儲存桶中建立的物件
• 在DynamoDB表中建立，更新或刪除專案
• 可以從Kinesis流中讀取訊息
• 通過簡單電子郵件服務收到的電子郵件。

呼叫lambda函式的另一種方法是配置AWS Lambda Gateway以將HTTP請求路由到lambda。 AWS Gateway將HTTP請求轉換為事件物件，呼叫lambda函式，並從lambda函式的結果生成HTTP響應。 您還可以使用AWS Lambda Web Service API顯式呼叫lambda函式。呼叫lambda函式的應用程式提供一個JSON物件，該物件將傳遞給lambda函式。 Web服務呼叫返回lambda返回的值。 呼叫lambda函式的第四種方法是定期使用類似cron的機制。例如，您可以告訴AWS每五分鐘呼叫一次lambda函式。 每次呼叫的成本是呼叫持續時間的函式，調整持續時間以100毫秒為增量，並消耗記憶體。、

結果背景

使用無伺服器部署的好處包括：

• 它消除了花費時間在管理低階基礎架構上的無差別的繁重工作的需要。相反，您可以專注於您的程式碼。
• 無伺服器部署基礎架構非常有彈性。它會自動擴充套件您的服務以處理負載。
• 您為每個請求付費，而不是配置可能未充分利用的虛擬機器或容器。

無伺服器部署的缺點包括：

• 顯著的限制和約束 - 無伺服器部署環境通常具有基於VM或基於容器的基礎結構的更多約束。例如，AWS Lambda僅支援幾種語言。它僅適用於部署響應請求而執行的無狀態應用程式。您無法部署長時間執行的有狀態應用程式，例如資料庫或訊息代理。
• 有限的“輸入源” - lambdas只能響應來自有限的一組輸入源的請求。 AWS Lambda無意執行服務，例如，訂閱訊息代理（如RabbitMQ）。
• 應用程式必須快速啟動 - 無伺服器部署不適合您的服務需要很長時間才能啟動
• 高延遲風險 - 基礎架構配置功能例項和初始化功能所需的時間可能會導致嚴重的延遲。此外，無伺服器部署基礎架構只能對負載增加做出反應。您無法主動預先配置容量。因此，當負載突然出現大量峰值時，您的應用程式最初可能會出現高延遲。

部署基礎結構將使用其他模式之一在內部部署您的應用程式。它很可能使用每個主機模式的服務服務。

相關模式

• 每個主機的多個服務例項模式是另一種部署解決方案
• 每個主機單一服務模式是另一種部署解決方案