無服務器：它是什麼以及為什麼不同

什麼是無服務器計算？

您可能已經在開發人員社區中看到了最近關於無服務器的所有炒作。 那麼它到底是什麼？ 我的意思是代碼仍然必須在正確的地方運行，那麼它實際上是如何無服務器的？

這意味著開發人員和運營團隊不必監督、管理甚至關心實際的服務器。 這聽起來可能與雲計算非常相似，但有一些關鍵區別。 而這些差異主要在於你所不知道的與其他模型的區別。

操作系統未知！？！？

將無服務器與某種形式的花哨的雲編排（如 Kubernetes）區分開來的簡單方法之一是，您公司中沒有人知道運行您的代碼的服務器正在使用什麼操作系統。 您可能會相信，因為您正在運行一些 .Net 代碼，所以它是 Windows，或者因為它是 Ruby，所以它在 Linux 上，但最終，您不確定，這對您的開發沒有影響。

您可以使用無服務器提供商支持的語言編寫代碼，並且只要您保持在他們提供的範圍內，您就可以完全了解支持該功能的操作系統、版本等。

事實上，無服務器的優勢之一是，在任何給定時間，您的應用程序都可能在多個不同的操作系統上運行。 所有這一切都由您的提供商為您管理和運營。

您需要多少台服務器來處理您的流量？

如果你可以用任何關於 X 服務器的猜測來回答這個問題，或者我們需要 Y CPU，那麼你就不是在進行無服務器開發。

無服務器合約意味著開發人員無需擔心為應用程序提供動力所需的任何計算的數量和強度。 這並不意味著您不會為此付費，只是這不是您或您的團隊將管理或關心的事情。 好的提供商會自動管理您的服務，以保持高可用性和響應能力。

基於計算、存儲和網絡的計費模型。 不是服務器、CPU 和硬盤驅動器

看到您如何不知道在您的應用程序下運行的實際硬件是什麼，隨之而來的是一種新的計費方式。 無服務器雲平台提供商對計算、存儲和網絡傳輸的計量使用收費。 這取代了其他按 CPU、磁盤驅動器和網絡連接收費的計費模式。 在無服務器世界中，他們控制著該部分，您只需為您的應用程序的確切使用付費。

這使計算更接近電力模型。 您的電力公司按計量用電量的 KWH 向您收費。 電力本身是由煤炭、核能、天然氣等創造的。 但是無論來源是什麼，計費都是一樣的。

怠速為零

無服務器的另一個主要變化是，當您的應用程序未使用時，它會自動縮放到零。 由於您不是按 CPU 計費，而是通過使用計算來計費，因此當您不使用它時，您的計費為零。

提供者始終準備好根據需要計量計算，但您無需為服務器在使用時做好準備而付費。 它只是計算應用程序執行時實際消耗的第二次計算的費用。

你可以把它想像成一家雜貨店。 他們的工作是讓商店裡有牛奶，這樣當你作為顧客口渴時，你可以進來，買牛奶喝，然後離開。 你不需要在需要牛奶之前付錢，如果他們的牛奶因為沒有人買而變質了，你也不需要付錢。 這就是雜貨店的全部業務是確保他們有可用的庫存，同時注意不要積壓和浪費變質的牛奶。 您所知道的是，他們在您想要的時候擁有您想要的東西，其餘的都被簡化了，您不必擔心。

無服務器的權衡

所以所有這些簡化聽起來都不錯。 為什麼一個人不想要所有這些東西：更簡單的計費、更少的運營責任、易於擴展。 與所有事物一樣，這確實帶來了一些權衡。 所以讓我們來談談他們。

用雲提供商鎖定代替操作系統鎖定

在其他模型中，由於您的代碼運行所在的操作系統或服務器，您有各種權衡和限制。 既然無服務器框架將此責任轉移給了提供者，那麼您必須遵守新的限制條件。

到目前為止，還沒有一套商定的標準來定義服務提供商之間的約束和保證。 這意味著類似於過去將應用程序從 Windows 遷移到 Linux 的難度。 現在，當您嘗試將無服務器應用程序從 Google 的雲遷移到 Amazon 時，您將面臨這個問題。

這些公司尚未提供任何通用框架來允許客戶在它們之間輕鬆移動無服務器工作負載。 坦率地說，現在這樣做並不符合他們的最佳利益，因為他們更願意盡可能地將您鎖定在他們的產品中。 因此，您需要非常清楚，早期的無服務器產品有許多專有的癥結，使您很難擺脫它們。

對性能和成本的了解較少

用於深入研究代碼性能的工具對於先前的編程模型已經非常完善。 諸如計算給定程序正在使用多少 CPU 或 RAM 之類的事情都是司空見慣的。

使用無服務器模型，優化更改為您的代碼使用多少計算、網絡和 API 調用。 平心而論，這些都與過去的 CPU 和 RAM 有關。 但隨著它們被進一步抽象化，這將阻礙這些工具發揮作用。

我完全相信用於調試和性能優化的新開源工具將會服務於這個市場。 但他們需要更好地了解提供商如何實施無服務器架構。 這可能意味著雲供應商是唯一能夠提供足夠深入的視角以使這些工具有效的供應商。 幫助您使用更少的資源也不符合他們的利益，因為無論您是否有效地使用它們，他們都會為這些資源計費。

長時間運行的應用程序不是最佳選擇

為了獲得無服務器提供的所有靈活性，它通常將應用程序開發人員限制為對這些功能即服務的基於時間的限制。 這意味著它進行了優化，以允許您的代碼響應最多有 1 分鐘響應的 Web 請求。

這些固定的時間最大值有助於提供商能夠履行對您的無服務器承諾。 他們希望能夠根據需要在實際物理 CPU 和位置之間移動工作負載，以便為開發團隊提供自動擴展和修復設備故障的服務。 長時間運行的工作負載打破了這一假設。 事實上，這通常被列為其產品的要求之一。 代碼必須在 X 時間內完成或終止。

對於 Web 請求或移動應用程序 API 之類的東西，這些限制並不是什麼大問題。 但對於其他用例，如編碼視頻、操作實時遊戲服務器或視頻會議解決方案，這些限制是不可行的。 在許多情況下，您可以通過創造性地使用無服務器資源來繞過這些限制，但您通常會硬著頭皮採用一種成本更高且運行速度更慢的解決方案。 雲提供商將很樂意幫助您執行此操作，因為更多的使用對他們來說就是更多的錢。 因此，請確保將無服務器用於最適合的 Web 應用程序和系統。