常見無伺服器挑戰簡介

什麼是冷啟動問題？

無伺服器的一大賣點是能夠在沒有活動的期間縮減為零。如果函式未主動執行，則函式的資源會縮減，將容量返回到平台，並降低使用者保留這些元件的成本。從成本角度來看，這非常理想，因為這表示使用者只需支付程式碼實際執行的時間和資源費用。

這樣做的缺點是，當資源完全縮減時，下次需要執行時會出現可預測的延遲。需要重新分配資源以執行函式，這需要時間。最終，您會得到一組「熱」函式的效能特性（最近使用過的函式），以及另一組「冷」函式的效能特性（需要等待平台建立執行環境的函式）。

開發人員如何嘗試解決冷啟動問題？

開發人員和平台已嘗試多種方法來解決此問題。有些開發人員會排程「虛擬」請求，以保持與其函式關聯的資源處於待命狀態。許多平台已在其服務中新增額外層級，以允許開發人員自動保持資源處於待命狀態。

這些解決方案開始稍微模糊了什麼構成無伺服器環境的界線。當開發人員被迫在程式碼未主動執行時支付待命資源費用時，這會引發一些關於無伺服器範例基本主張的問題。

最近一種替代預先分配資源的方法是透過切換到更輕型的執行階段環境來規避問題。V8 等執行階段的執行策略與傳統無伺服器截然不同，並且能夠透過使用不同的隔離技術和更精簡的環境來避免冷啟動問題。它們以犧牲與依賴更強大環境的函式的相容性為代價，來避免冷啟動問題。

設計雲端友善架構

應用程式必須滿足才能使用無伺服器平台的第一個要求是以雲端友善的方式設計。在此討論的背景下，至少這表示應用程式必須至少部分可部署到其他元件能夠與之通訊的雲端服務。雖然可以在設計中實作巨石函式，但無伺服器模型最適合微服務架構。

這樣做的結果是，您的應用程式必須部分設計為一系列由無伺服器供應商執行的函式。您必須對在您無法控制的基礎架構上發生的處理感到安心。此外，您必須能夠將應用程式的功能分解為可以遠端執行的離散函式。

處理無狀態執行

無伺服器函式在設計上是無狀態的。這表示，雖然如果函式使用相同的資源執行，則可能會快取某些資訊，但您不能依賴函式調用之間共用的任何狀態。

您必須將函式設計為具有內部執行所需的所有資訊。任何外部狀態都必須在調用開始時提取，並在完成之前匯出。由於函式可能會並行執行，這也限制了可以合理作用的狀態類型。一般而言，您的函式必須管理的狀態越少，它們的執行速度和成本就越低，而且您必須管理的複雜性也越低。

函式的短暫性也有其他副作用。如果您的函式需要連線到資料庫系統，則很可能很快就會耗盡資料庫的連線池。由於函式的每次調用都可以在不同的環境中執行，因此資料庫的連線池可能會在回應不同的調用或嘗試將資源返回到其池時迅速耗盡。Prisma Accelerate 等解決方案透過管理無伺服器執行個體的連線資源（在任何現有的連線池之前），來協助減輕這些問題。

可能發生哪些類型的鎖定？

對於針對特定無伺服器平台建置的應用程式，許多不同的因素可能會干擾順利遷移到另一個供應商。這些因素可能來自無伺服器實作本身，或來自使用可能整合到應用程式設計中的供應商相關服務。

就實際無伺服器實作造成的鎖定而言，供應商之間最基本的差異之一可能是定義函式所支援的語言。如果您的應用程式函式是以其他候選供應商不支援的語言撰寫，則在不以支援的語言重新實作邏輯的情況下，將無法進行遷移。無伺服器不相容性的一個更細微的例子是不同供應商概念化和公開平台內函式觸發機制的方式的差異。如果這些機制差異很大，您可能需要重新定義觸發器在新平台上的實作方式。

當無伺服器應用程式使用其供應商生態系統中的其他服務來支援其應用程式時，可能會發生其他類型的鎖定。例如，由於無伺服器函式不處理狀態，因此通常使用供應商的物件儲存產品來儲存調用期間產生的任何成品。雖然物件儲存已使用標準介面廣泛實作，但它展示了無伺服器架構的限制如何導致更多地採用和依賴其他可用服務的生態系統。

開發人員如何嘗試限制鎖定

開發人員可以採取一些方法來盡量減少其應用程式鎖定的可能性或影響。

以廣泛支援的語言（如 JavaScript）撰寫函式是避免硬依賴性最簡單的方法之一。如果您的選擇語言受到許多供應商的支援，它會為您提供其他平台選項，這些平台可能能夠執行您的程式碼。

開發人員也可以嘗試將其服務使用限制在幾乎在每個平台上都以相同方式支援的商品產品。例如，我們之前使用的物件儲存範例實際上是一個理想的範例，說明服務很可能可以被另一個供應商的產品取代。您依賴的服務越專業化，就越難擺脫生態系統。這是您必須根據具體情況評估的權衡，因為您可能必須放棄專業工具，改用更通用的工具。

開發人員可以預期哪些類型的差異？

無伺服器範例的承諾是將除程式碼本身之外的所有責任轉移給平台供應商。這可以在營運管理費用和簡化開發人員的執行環境方面產生許多優勢，但也使得開發人員通常可能依賴的許多技術和工具更難或不可能使用。

例如，有些開發人員習慣於能夠透過直接存取程式設計環境來進行偵錯，方法是使用 SSH 連線到主機，或透過內省程式碼並使用程序公開的資料。這些在無伺服器環境中通常不可能或不容易實現，因為執行環境對使用者而言是不透明的，並且只有特定的介面（如函式日誌）可用於偵錯。這可能會使診斷問題變得困難，尤其是在無法在本機重現或在管道中調用多個函式時。

有哪些可用的選項可提供協助？

開發人員可以採用許多不同的策略來協助他們在這個更受限的偵錯環境中工作。

有些無伺服器功能可以在本機執行或模擬，讓開發人員能夠在本機偵錯他們無法在其供應商的生產環境中偵錯的內容。許多工具旨在模擬常見的無伺服器平台，以便開發人員可以重新獲得他們可能遺失的某些診斷功能。它們可讓您逐步執行函式、查看狀態資訊和設定中斷點。

對於在平台本身上進行偵錯，您必須嘗試利用供應商提供的所有工具。這通常表示在函式內大量記錄日誌、使用 API 測試工具以不同的輸入自動觸發函式，以及使用平台提供的任何指標來嘗試深入了解執行環境中可能發生的情況。