與傳統的基于云或以服務器為中心的基礎架構相比，無服務器計算具有許多優勢。對于許多開發人員而言，無服務器架構以更低的成本提供了更大的可擴展性、更大的靈活性和更快的發布時間。使用無服務器架構，開發人員無需擔心購買、配置和管理后端服務器。然而，無服務器計算并不是所有 Web 應用程序開發人員的靈丹妙藥。

無服務器計算如何工作？

無服務器計算是一種架構，其中供應商根據需要提供后端服務。要了解有關無服務器計算的更多信息，請參閱什么是無服務器計算？

無服務器計算的優勢是什么？

無需服務器管理

盡管“無服務器”計算確實發生在服務器上，但開發人員永遠不必處理服務器。它們由供應商管理。這可以減少 DevOps 所需的投資，從而降低開支，還可以讓開發人員騰出時間來創建和擴展他們的應用程序，而不受服務器容量的限制。

開發人員只需為其使用的服務器空間付費，從而降低成本

與“即用即付”電話計劃一樣，開發人員只需為他們使用的內容付費。代碼僅在無服務器應用程序需要后端功能時運行，并且代碼會根據需要自動擴展。配置是動態的、精確的和實時的。有些服務非常精確，以至于它們將費用分解為 100 毫秒的增量。相比之下，在傳統的“全服務器”架構中，開發人員必須提前預測他們需要多少服務器容量，然后購買該容量，無論他們最終是否使用它。

無服務器架構本質上是可擴展的

想象一下，如果郵局能夠以某種方式神奇地隨意添加和停用送貨卡車，隨著郵件數量的激增（例如，就在母親節之前）增加其車隊的規模，并在需要較少交付的時候減少其車隊。這基本上是無服務器應用程序能夠做到的。

使用無服務器基礎架構構建的應用程序將隨著用戶群的增長或使用量的增加而自動擴展。如果一個功能需要在多個實例中運行，供應商的服務器將根據需要啟動、運行和結束它們，通常使用容器。（如果最近運行該函數，它將更快地啟動 - 請參閱下面的“性能可能會受到影響”。）因此，無服務器應用程序將能夠處理異常大量的請求，就像它可以處理一樣來自單個用戶的單個請求。具有固定數量服務器空間的傳統結構化應用程序可能會因使用量的突然增加而不堪重負。

可以進行快速部署和更新

使用無服務器基礎架構，無需將代碼上傳到服務器或進行任何后端配置即可發布應用程序的工作版本。開發人員可以非常快速地上傳一些代碼并發布新產品。他們可以一次上傳全部代碼或一次上傳一個函數，因為應用程序不是一個單一的整體堆棧，而是供應商提供的一組函數。這也使得快速更新、修補、修復或向應用程序添加新功能成為可能。無需對整個應用程序進行更改；相反，開發人員可以一次更新應用程序一項功能。

代碼可以更靠近最終用戶運行，從而減少延遲

因為應用程序不是托管在源服務器上，所以它的代碼可以在任何地方運行。因此，根據所使用的供應商，可以在靠近最終用戶的服務器上運行應用程序功能。這減少了延遲，因為來自用戶的請求不再需要一路傳送到源服務器。

無服務器計算的缺點是什么？

測試和調試變得更具挑戰性

很難復制無服務器環境以查看代碼在部署后的實際執行情況。調試更加復雜，因為開發人員無法看到后端進程，并且因為應用程序被分解為單獨的、更小的功能。

無服務器計算引入了新的安全問題

當供應商運行整個后端時，可能無法完全檢查他們的安全性，這對于處理個人或敏感數據的應用程序來說尤其是一個問題。由于公司沒有分配到自己的離散物理服務器，因此無服務器提供商通常會在任何給定時間在單個服務器上運行來自多個客戶的代碼。這種與其他方共享機器的問題被稱為“多租戶”——想想幾家公司試圖同時在一個辦公室租賃和工作。多租戶會影響應用程序性能，如果多租戶服務器配置不正確，可能會導致數據泄露。多租戶對沙盒功能正常且基礎設施足夠強大的網絡幾乎沒有影響。

無服務器架構不是為長時間運行的進程構建的

這限制了可以在無服務器架構中經濟高效地運行的應用程序種類。由于無服務器提供商對代碼運行的時間量收費，因此與傳統基礎架構相比，在無服務器基礎架構中運行具有長時間運行進程的應用程序的成本可能更高。

性能可能會受到影響

因為它不是持續運行的，所以無服務器代碼在使用時可能需要“啟動”。此啟動時間可能會降低性能。但是，如果定期使用一段代碼，無服務器提供程序將保持它準備好被激活——對這個現成代碼的請求稱為“熱啟動”。對一段時間未使用的代碼的請求稱為“冷啟動”。Workers 通過使用 Chrome V8 引擎在很大程度上避免了冷啟動問題，該引擎在大多數情況下能夠在 5 毫秒內啟動和運行 JavaScript 代碼。如果代碼已經在運行，則響應時間不到一毫秒。詳細了解不同無服務器平臺的性能。

供應商鎖定是一種風險

允許供應商為應用程序提供所有后端服務不可避免地會增加對該供應商的依賴。與一個供應商建立無服務器架構可能會使必要時難以切換供應商，特別是因為每個供應商提供的功能和工作流程略有不同。

誰應該使用無服務器架構？

想要縮短上市時間并構建可快速擴展或更新的輕量級、靈活應用程序的開發人員可能會從無服務器計算中受益匪淺。無服務器架構將降低使用不一致的應用程序的成本，高峰期與幾乎沒有流量的時間交替出現。對于此類應用程序，購買持續運行且始終可用（即使未使用）的服務器或服務器塊可能是對資源的浪費。無服務器設置將在需要時立即響應，并且在靜止時不會產生成本。此外，想要將部分或全部應用程序功能推送到靠近最終用戶以減少延遲的開發人員將需要至少部分無服務器架構，因為這樣做需要將一些進程移出源服務器。

開發人員何時應避免使用無服務器架構？

在某些情況下，無論從成本角度還是從系統架構角度來看，使用自我管理或作為服務提供的專用服務器都更有意義。例如，具有相當穩定、可預測的工作負載的大型應用程序可能需要傳統設置，在這種情況下，傳統設置可能更便宜。此外，將遺留應用程序遷移到具有完全不同架構的新基礎架構可能非常困難。