無伺服器運算可為 Web 開發人員提供許多好處，包括可擴充性、加快上市時間，以及更低的費用。但是，在某些情況下，其他擔憂可能會超過這些好處。
閱讀本文後，您將能夠：
相關內容
訂閱 TheNET，這是 Cloudflare 每月對網際網路上最流行見解的總結！
複製文章連結
與傳統的基於雲端或以伺服器為中心的基礎結構相比，無伺服器運算具有諸多優勢。對於許多開發人員而言，無伺服器架構以更低的成本提供了更大的可擴展性、更大的靈活性以及更快的發佈時間。使用無伺服器架構，開發人員無需擔心購買、佈建和管理後端伺服器的事宜。但是，無伺服器運算並不是所有 Web 應用程式開發人員的靈丹妙藥。
無伺服器運算是一種架構，在這種架構中，由廠商來為客戶提供所需的後端服務。要瞭解有關無伺服器運算的更多資訊，請參閱什麼是無伺服器運算？
儘管「無伺服器」運算實際上是在伺服器上進行的，但開發人員無需管理伺服器——它們由廠商管理。這可以減少 DevOps 中的必要投資，從而降低支出，還可以使開發人員專注于建立和擴展應用程式，而不受伺服器容量的限制。
與「隨用隨付」電話方案一樣，開發人員僅需為使用量付費。僅當無伺服器應用程式需要後端功能時，代碼才會執行，並且代碼會根據需要自動擴展。佈建是動態、精確、即時的。一些服務的精確度極高，以至於費用細分到 100 毫秒的增量。相比之下，在傳統的「全套伺服器」架構中，開發人員必須預先計劃所需的伺服器容量，然後購買容量，而不管最終是否會用上。
想像一下，如果郵局能夠以某種方式神奇地隨意增減郵遞卡車，隨著郵件數量的增加（例如，在母親節之前）擴大車隊的規模，並在需要減少送貨次數的時候縮小車隊，會多麼成本高效。從本質上講，無伺服器應用程式就起到這樣的作用。
使用無伺服器基礎結構構建的應用程式將隨著使用者群的增加或使用量的增加而自動擴展。如果一個功能需要在多個執行個體中執行，則廠商的伺服器將根據需要啟動、執行並結束，並且通常使用容器。（如果該功能最近執行過，它的啟動速度會更快——請參閱下文「效能可能受到影響」。）因此，無伺服器應用程式能夠處理異常大量的請求，也能夠處理來自單個使用者的單個請求。具有固定伺服器空間量的傳統結構化應用程式可能會因使用量的突然增加而不堪重負。
使用無伺服器基礎結構，無需將代碼發佈到伺服器或進行任何後端設定即可發佈應用程式的有效版本。開發人員可以非常快速地上傳少量代碼並發佈新產品。他們可以一次上傳全部代碼，也可以一次上傳一個功能，因為應用程式不是單個的單體堆疊，而是廠商佈建的功能的集合。
這也使得開發人員可以快速更新、修補、修復應用程式或向應用程式新增新功能。開發人員不必對整個應用程式進行變更，而是可以一次更新一個功能。
因為應用程式未託管在來源伺服器上，所以它的代碼可以在任何地方執行。因此，根據所使用的廠商，應用程式功能可能在接近終端使用者的伺服器上執行。這減少了等待時間，因為來自使用者的請求不再需要一直傳遞到來源伺服器。Cloudflare Workers 支援這種無伺服器延遲縮減。
複製無伺服器環境以查看代碼在部署後的實際執行情況是非常困難的。偵錯更加複雜，因為開發人員無法查看後端處理序，也因為應用程式被分解為較小的獨立功能。Cloudflare Workers Playground 是一個沙箱，可幫助減少測試和偵錯中的摩擦
當廠商執行整個後端時，可能無法完全審查其安全性，這對於處理個人或敏感性資料的應用程式尤其成問題。
因為公司沒有指派到自己的離散實體伺服器，所以無伺服器提供者在任何給定時間通常是在單個伺服器上執行來自多個客戶的代碼。與其他方共用機械的情況稱為「多租用戶」——想象一下，幾家公司試圖同時租賃一個辦公室並在其中工作會是什麼情況。多租用戶可能會影響應用程式效能，如果多租用戶伺服器設定不正確，可能會導致資料洩露。對於沙箱能夠正確運作並且具有足夠強大的基礎結構的網路，多租用戶幾乎沒有影響。例如，Cloudflare 執行的 15 Tbps 網路具有足夠的額外容量來緩解服務降級，並且 Cloudflare 代管的所有無伺服器功能都在自己的沙箱中執行（透過 Chrome V8 引擎）。
這限制了可以在無伺服器架構中經濟高效地執行的應用程式的種類。由於無伺服器提供者針對代碼的執行時間收費，因此與傳統應用程式相比，在無伺服器基礎結構中執行具有長時間執行處理序的應用程式可能會產生更高費用。
由於無伺服器代碼不是一直在執行，因此在使用時可能需要「啟動」。此啟動時間可能會降低效能。但是，如果經常使用一段代碼，則無伺服器提供者將使其保持啟動狀態——對此現成代碼的請求稱為「暖啟動」。對一段時間未使用的代碼的請求稱為「冷啟動」。
Cloudflare Workers 透過使用 Chrome V8 引擎，在很大程度上避免了冷啟動問題，該引擎在大多數情況下能夠在 5 毫秒內啟動並執行 JavaScript 代碼。如果代碼已經在執行，則回應時間不到一毫秒。詳細瞭解不同伺服器平台的效能。
允許一個廠商為應用程式提供所有後端服務將不可避免地增加對該廠商的依賴。在一家廠商處建立無伺服器架構可能會導致在必要時難以切換廠商，尤其是每個廠商提供的功能和工作流程都略有不同。（Cloudflare Workers 更易於遷移，因為它們是用 JavaScript 編寫的，並且是根據廣泛使用的 Service Worker API 編寫的。）
希望縮短上市時間並構建可快速擴展或更新的輕量、靈活應用程式的開發人員可能會從無伺服器運算中受益匪淺。
如果應用程式使用量變化無常，時而出現高峰，時而很少甚至沒有流量，則無伺服器架構將減少應用程式的成本。對於此類應用程式，購買一台或多台連續執行且始終可用（即使未使用時）的伺服器可能浪費資源。無伺服器設定將在需要時立即回應，並且在不用時不會產生成本。
此外，想要將某些或全部應用程式功能放到終端使用者附近以縮短延遲的開發人員，將至少需要部分無伺服器架構，因為這樣做需要將某些處理序移出來源伺服器。
從成本角度和系統架構角度來看，在某些情況下，使用自行管理或作為服務提供的專用伺服器更合理。例如，具有相當恒定、可預測的工作負載的大型應用程式可能需要傳統設定，在這種情況下，傳統設定產生的成本可能會更低。
另外，將舊版應用程式遷移到具有完全不同架構的新基礎結構可能會非常困難。
Cloudflare Workers 使開發人員能夠編寫 JavaScript 功能並將其部署在 Cloudflare 網路邊緣。這樣就可以在盡可能靠近終端使用者的無伺服器架構中執行應用程式碼，從而最大程度地減少延遲。