部署：無伺服器部署模式

weixin_34249678發表於2018-08-27
伺服器模式

背景

你已經採用了微服務架構並且將你的系統架構為一組服務。每個服務為了吞吐量和可用性，部署為一組服務例項。

問題

怎樣將服務打包和部署？

限制

  • 服務採用不同語言，不同框架，不同框架版本編寫
  • 每個服務為了吞吐量和可用性，存在多個服務例項
  • 服務必須獨立部署和擴充套件
  • 服務例項彼此之間應該隔離
  • 你需要可以快速的構建和部署服務
  • 你需要可以限制服務消費的資源（CPU和記憶體）
  • 你需要監控每個服務例項的行為
  • 你想要可靠部署
  • 你必須儘可能小成品的部署應用程式

解決方案

採用一種隱藏了任何伺服器概念-物理機，虛擬機器，容器-的基礎設施（例如，預留資源或者預分配資源）。這個基礎設施獲取你的程式碼並執行。根據每個請求的資源消耗向你收費。

使用這種方法部署你的服務，你將程式碼打包（例如，打包成ZIP檔案），將它上傳到部署基礎設施，並描述期待的效能特點。

部署基礎設施是公有云提供商操作的工具。它通常採用容器或者虛擬機器隔離服務。然而，這些細節對你是隱藏的。不止是你，你的公司的其他任何人都無須對操作底層基礎設施，例如作業系統，虛擬機器等等負責。

示例

有少數幾個不同的無伺服器部署環境：

他們提供類似的功能，但是AWS Lambda有更豐富的特性。一個AWS Lambda是個無狀態元件，執行和處理的事件。建立AWS Lambda函式，你需要打包你的NodeJS，Java或者Python程式碼為ZIP檔案，上傳到AWS Lambda。你還需要指定函式名字和資源限制。

當一個事件觸發，AWS Lambda找到函式的一個空閒例項，如果沒有可用的就啟動一個，然後呼叫函式。AWS Lambda執行足夠多的例項來應對負載。隱藏的細節是，它用容器來隔離lambda function的例項。像你可能期待的那樣，AWS Lambda在EC2例項上執行這些容器。

有四種方法可以執行lamda函式。一個選擇是配置你的lamda函式在AWS服務，例如S3，DynamoDB或者Kinesis產生事件時呼叫。事件的例子包括如下幾種：

  • S3 bucket裡建立了一個物件
  • DynamoDB表裡，一個物件被建立，更新或者刪除
  • Kinesis流裡，一個訊息可以閱讀
  • 簡單郵件服務裡，收到了一封郵件

另外一種執行lambda函式的方法，是配置AWS Lambda閘道器，將HTTP請求路由到你的lambda。AWS閘道器將HTTP請求轉換為事件物件，執行lambda函式，從lambda函式返回結果中生成HTTP響應。

你可以通過AWS Lambda Web Service API直接執行你的lambda函式。你的應用提供一個JSON物件，傳遞到lambda函式。Web Service返回lambda返回的結果。

第四種方法是通過cron類似的機制定時呼叫。舉個例子，你可以讓AWS每五分鐘執行你的lambda函式。

每種執行方式的開銷，是函式執行的時間，以100毫秒增量度量，和記憶體消耗。

結果

無伺服器部署的優勢包括：

  • 它不用花費時間去管理低階別的基礎設施。相反，你可以更關注你的程式碼。
  • 無伺服器部署基礎設施極其彈性。它可以自動基於複雜擴充套件你的服務。
  • 你為每次請求付費，而不是提供虛擬機器和容器

無伺服器部署的弊端包括：

  • 重要的限制和約束 - 無伺服器部署環境通常比基於虛擬機器或者容器的基礎設施有更多約束。比如，AWS Lambda僅支援少數幾種語言。僅僅適合於部署基於請求響應模式的無狀態服務。你不能部署一個長時間執行的狀態服務，比如資料庫或者訊息佇列。
  • 限制了“請求來源” - lambda僅能響應少數的請求來源。AWS Lambda不打算執行，舉個例子，從RabbitMQ消費訊息的服務。
  • 應用必須啟動快速 - 如果你的服務需要長時間啟動，無伺服器部署並不適合
  • 高延遲的風險 - 基礎設施花費在準備例項和初始化函式的時間，會帶來明顯的延遲。而且，無伺服器部署僅僅可以在執行時響應並擴容。你不能主動的提前準備容量。後果是，當你的應用遇到突然大量的請求高峰時，會遇到高延遲。

部署基礎設施將在內部採用其他一種模式部署你的應用。它很可能採用每主機單個服務例項。

相關模式

相關文章