無伺服器並不是物理上沒有伺服器。 這不是容器殺手，也不是曇花一現的趨勢。 這是在雲端中建構系統的新方法。 今天的文章我們將介紹Serverless應用程式的架構，讓我們來看看Serverless服務提供者和開源專案扮演什麼角色。 最後說一下使用Serverless的問題。
我想編寫應用程式（甚至在線商店）的伺服器部分。 這可以是聊天、內容發佈服務或負載平衡器。 無論如何，都會有很多令人頭痛的問題：您必須準備基礎設施，確定應用程式依賴項，並考慮主機作業系統。 然後，您將需要更新不影響整體其餘部分操作的小組件。 好吧，我們不要忘記負載下的擴展。
如果我們採用臨時容器，其中已預先安裝了所需的依賴項，並且容器本身彼此隔離並與主機作業系統隔離，該怎麼辦？ 我們將把整體劃分為微服務，每個微服務都可以獨立於其他服務進行更新和擴展。 透過將程式碼放入這樣的容器中，我可以在任何基礎設施上運行它。 已經好多了。
如果您不想配置容器怎麼辦？ 我不想考慮擴展應用程式。 當服務負載最小時，我不想為空閒運行的容器付費。 我想寫程式碼。 專注於業務邏輯，以光速將產品推向市場。
這些想法引導我走向無伺服器運算。 在這種情況下，無伺服器意味著 不是伺服器的實體缺失，而是基礎設施管理問題的缺失。
這個想法是將應用程式邏輯分解為獨立的功能。 他們有一個事件結構。 每個函數執行一個「微任務」。 開發人員所需要做的就是將功能載入到雲端提供者提供的控制台中，並將它們與事件來源關聯起來。 程式碼將在自動準備的容器中按需執行，我只需為執行時間付費。
現在讓我們看看應用程式開發過程會是什麼樣子。
從開發商方面
早些時候我們開始討論在線商店的應用程式。 在傳統方法中，系統的主要邏輯由單一應用程式執行。 即使沒有負載，具有應用程式的伺服器也會持續運作。
為了轉向無伺服器，我們將應用程式分解為微任務。 我們為每個函數編寫自己的函數。 函數之間相互獨立，不儲存狀態資訊（無狀態）。 它們甚至可能是用不同的語言編寫的。 如果其中一個“倒下”，整個應用程式將不會停止。 應用程式架構將如下所示：
無伺服器中的功能劃分類似微服務。 但一個微服務可以執行多項任務，而一個函數理想情況下應該執行一項任務。 讓我們假設任務是收集統計資料並根據使用者的請求顯示它們。 在微服務方法中，一項任務由具有兩個入口點的一個服務執行：寫入和讀取。 在無伺服器運算中，這將是兩個彼此不相關的不同功能。 例如，如果統計資料的更新頻率高於下載頻率，則開發人員可以節省運算資源。
Serverless 函數必須在很短的時間內（逾時）執行，這是由服務提供者決定的。 例如，對於 AWS，逾時為 15 分鐘。 這意味著必須更改長期存在的功能才能滿足要求 - 這就是無伺服器與當今其他流行技術（容器和平台即服務）的區別。
我們為每個函數分配一個事件。 事件是動作的觸發器：
事件
該函數執行的操作
產品圖片已上傳至儲存庫。
壓縮圖片並上傳到目錄
實體店地址已在資料庫中更新
將新位置載入到地圖中
顧客支付貨款
開始付款處理
事件可以是 HTTP 請求、流資料、訊息佇列等。 事件來源是資料的變更或發生。 此外，功能可以由定時器觸發。
架構已經制定出來，應用程式幾乎變成了無伺服器。 接下來我們就去服務提供者。
從提供者方面
通常，無伺服器運算由雲端服務提供者提供。 它們的名稱不同：Azure Functions、AWS Lambda、Google Cloud Functions、IBM Cloud Functions。
我們將透過提供者的控制台或個人帳戶使用本服務。 可以透過以下方式之一下載功能代碼：
- 透過 Web 控制台在內建編輯器中編寫程式碼，
- 下載包含程式碼的存檔，
- 使用公共或私人 git 儲存庫。
這裡我們設定呼叫該函數的事件。 對於不同的提供者，事件集可能不同。
供應商在其基礎設施上建置並自動化了功能即服務 (FaaS) 系統：
- 函數程式碼最終儲存在提供者端。
- 當事件發生時，已準備好環境的容器會自動部署到伺服器上。 每個函數實例都有自己獨立的容器。
- 該函數從儲存中傳送到容器，進行計算並傳回結果。
- 並行事件的數量正在增加——容器的數量也在增加。 系統自動縮放。 如果使用者不存取該功能，則該功能將處於非活動狀態。
- 提供者為容器設定空閒時間 - 如果在此期間容器中沒有出現功能，則容器將被銷毀。
這樣我們就可以開箱即用的無伺服器。 我們將使用即用即付模式為服務付費，並且僅針對使用的功能以及使用時的時間付費。
為了向開發人員介紹該服務，提供者提供長達 12 個月的免費測試，但限制總計算時間、每月請求數量、資金或功耗。
與供應商合作的主要優勢是能夠不用擔心基礎架構（伺服器、虛擬機器、容器）。 就其本身而言，提供者可以使用自己的開發和開源工具來實作 FaaS。 讓我們進一步討論它們。
從開源方面來說
過去幾年，開源社群一直在積極致力於無伺服器工具的開發。 最大的市場參與者也為無伺服器平台的發展做出了貢獻：
- 谷歌 為開發人員提供開源工具 - 。 IBM、RedHat、Pivotal 和 SAP 參與了其開發；
- IBM 在無伺服器平台上工作 ，隨後成為 Apache 基金會的一個專案；
- Microsoft微軟 部分開放平台程式碼 .
無伺服器框架的開發也在進行中。 и 部署在預先準備好的 Kubernetes 叢集內， 可與 Kubernetes 和 Docker Swarm 搭配使用。 該框架充當一種控制器 - 根據請求，它在叢集內準備一個運行時環境，然後在那裡啟動一個功能。
框架為配置工具留出了空間以滿足您的需求。 因此，在 Kubeless 中，開發人員可以配置函數執行逾時（預設值為 180 秒）。 Fission 試圖解決冷啟動問題，建議保持某些容器始終運作（儘管這會帶來資源停機成本）。 OpenFaaS 提供了一組適合各種口味和風格的觸發器：HTTP、Kafka、Redis、MQTT、Cron、AWS SQS、NAT 等。
入門說明可以在框架的官方文件中找到。 與他們合作需要比與提供者合作更多的技能 - 這至少是透過 CLI 啟動 Kubernetes 叢集的能力。 最多包括其他開源工具（例如 Kafka 佇列管理器）。
無論我們如何使用無伺服器 - 透過提供者或使用開源，我們都會收到無伺服器方法的許多優點和缺點。
從優點和缺點來看
無伺服器開發了容器基礎設施和微服務方法的想法，其中團隊可以在多語言模式下工作，而無需綁定到一個平台。 建置系統變得更加簡單，錯誤也更容易修正。 微服務架構可讓您比單體應用程式更快地為系統添加新功能。
無伺服器進一步縮短了開發時間， 允許開發人員專注於應用程式的業務邏輯和編碼。 因此，開發的上市時間縮短了。
作為獎勵，我們可以自動縮放負載， 我們只為使用的資源付費，並且只在使用資源時付費。
與任何技術一樣，無伺服器也有缺點。
例如，這樣的缺點可能是冷啟動時間（JavaScript、Python、Go、Java、Ruby 等語言平均長達 1 秒）。
一方面，實際上，冷啟動時間取決於許多變數：編寫函數的語言、庫的數量、程式碼量、與其他資源（相同的資料庫或身份驗證伺服器）的通訊。 由於開發人員可以控制這些變量，因此他可以減少啟動時間。 但另一方面，開發者無法控制容器的啟動時間——這一切都取決於提供者。
當函數重複使用先前事件啟動的容器時，冷啟動可以變成熱啟動。 這種情況會在三種情況下出現：
- 如果客戶經常使用該服務且對該功能的呼叫次數增加；
- 提供者、平台或框架是否允許您保持某些容器始終運作；
- 如果開發人員在計時器上執行函數（例如每 3 分鐘）。
對於許多應用程式來說，冷啟動不是問題。 在這裡，您需要建立服務的類型和任務。 一秒鐘的啟動延遲對於業務應用程式來說並不總是至關重要，但對於醫療服務來說卻可能變得至關重要。 在這種情況下，無伺服器方法可能不再適合。
無伺服器的下一個缺點是函數的生命週期短（函數必須執行逾時）。
但是，如果您必須處理長期任務，則可以使用混合架構 - 將無伺服器與其他技術結合。
並非所有系統都能夠使用無伺服器方案工作。
某些應用程式在執行期間仍會儲存資料和狀態。 一些架構將保持整體性，一些功能將長期存在。 然而（就像雲端技術和容器一樣），Serverless 是一項前景廣闊的技術。
本著這種精神，我想順利地轉向使用無伺服器方法的問題。
從應用端來看
2018 年，Serverless 使用百分比 。 Twitter、PayPal、Netflix、T-Mobile、可口可樂等市場巨頭已經在其服務中實施了該技術。 同時，你要明白Serverless並不是萬能的，而是解決某個範圍問題的工具：
- 減少資源停機時間。 沒有必要為呼叫很少的服務持續保留虛擬機器。
- 動態處理資料。 壓縮圖片、剪切背景、更改視訊編碼、使用物聯網感測器、執行數學運算。
- 將其他服務「黏合」在一起。 包含內部程式的 Git 儲存庫、帶有 Jira 和日曆的 Slack 中的聊天機器人。
- 平衡負載。 讓我們仔細看看這裡。
假設有一項服務吸引了 50 人。 其下方有一個硬體較弱的虛擬機器。 有時，服務負載會顯著增加。 那麼薄弱的硬體就無法應付。
您可以在系統中包含一個平衡器，該平衡器將在三個虛擬機器之間分配負載。 在這個階段，我們無法準確預測負載，因此我們保留一定程度的資源「儲備」運作。 而且我們為停機時間支付了過高的費用。
在這種情況下，我們可以透過混合方法優化系統：我們在負載平衡器後面留下一個虛擬機，並放置一個到具有功能的無伺服器端點的連結。 如果負載超過閾值，平衡器將啟動接管部分請求處理的函數實例。
因此，無伺服器可以用在需要處理大量請求但不是太頻繁但密集的地方。 在這種情況下，運行多個功能 15 分鐘比一直維護虛擬機器或伺服器更有利可圖。
憑藉無伺服器運算的所有優勢，在實施之前，您應該先評估應用程式邏輯並了解無伺服器在特定情況下可以解決哪些問題。
無伺服器和 Selectel
在 Selectel，我們已經 透過我們的控制面板。 現在我們正在建立自己的FaaS平台。 我們希望開發人員能夠透過方便、靈活的介面使用無伺服器解決他們的問題。
如果您對理想的 FaaS 平台應該是什麼以及希望如何在專案中使用 Serverless 有想法，請在評論中分享。 我們在開發平台時會考慮您的意願。
文章中使用的資料：
來源： www.habr.com