無伺服器常見挑戰簡介

什麼是冷啟動問題？

無伺服器的一大賣點是在沒有活動期間能夠縮減到零。如果一個函式沒有被主動執行，其資源就會被關閉，將容量返回給平臺，並降低使用者預留這些元件的成本。從成本角度來看，這是理想的，因為它意味著使用者只需為其程式碼實際執行的時間和資源付費。

這樣做的缺點是，當資源完全關閉後，下次需要執行時會出現可預測的延遲。需要重新分配資源來執行函式，這需要時間。最終，最近使用的“熱”函式有一套效能特徵，而需要等待平臺建立執行環境的“冷”函式則有另一套效能特徵。

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

開發者和平臺已經嘗試了多種方法來解決這個問題。一些開發者會安排“虛擬”請求，以保持與其函式相關的資源處於待機狀態。許多平臺在其服務中增加了額外的層級，以允許開發者自動保持資源處於待機狀態。

這些解決方案開始模糊無伺服器環境的定義。當開發人員在程式碼未主動執行時被迫支付待機資源費用時，這引發了對無伺服器正規化一些基本主張的質疑。

最近一種替代預分配資源的方法是切換到更輕量級的執行時環境來規避這個問題。像 V8 這樣的執行時與傳統無伺服器具有截然不同的執行策略，並且能夠透過使用不同的隔離技術和更精簡的環境來避免冷啟動問題。它們避免了冷啟動問題，但代價是犧牲了與依賴更強大環境的函式之間的相容性。

設計雲友好型架構

應用程式要使用無伺服器平臺，首先必須以雲友好的方式進行設計。在本次討論的背景下，這至少意味著應用程式必須至少部分部署到一個雲服務上，以便其他元件能夠與之通訊。儘管在您的設計中可以實現單體函式，但無伺服器模型最適合微服務架構。

這樣做的結果是，您的應用程式必須部分設計為由無伺服器提供商執行的一系列函式。您必須能夠接受處理發生在您無法控制的基礎設施上。此外，您必須能夠將應用程式的功能分解為可遠端執行的獨立函式。

處理無狀態執行

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

您必須設計您的函式，使其內部擁有執行所需的所有資訊。任何外部狀態都必須在呼叫開始時獲取並在結束前匯出。由於函式可以並行執行，這也限制了哪些型別的狀態可以合理地被操作。總的來說，您的函式需要管理的狀態越少，它們的執行速度就越快，成本就越低，您需要管理的複雜性也就越少。

函式的瞬時性還會帶來其他副作用。如果您的函式需要訪問資料庫系統，您很可能會很快耗盡資料庫的連線池。由於您的函式每次呼叫都可以在不同的上下文中執行，資料庫的連線池可能會在響應不同調用或嘗試將資源返回到其池時迅速耗盡。像 Prisma Accelerate 這樣的解決方案透過管理無伺服器例項的連線資源來幫助緩解這些問題，無論後端是否存在連線池。

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

對於針對特定無伺服器平臺構建的應用程式，許多不同的因素可能會妨礙乾淨地遷移到另一個提供商。這些因素可能源於無伺服器實現本身，或者源於將提供商相關服務整合到應用程式設計中的使用方式。

就實際無伺服器實現造成的鎖定而言，提供商之間最基本的差異之一可能是定義函式所支援的語言。如果您的應用程式函式是用其他候選提供商不支援的語言編寫的，那麼在不使用受支援語言重新實現邏輯的情況下，遷移將是不可能的。一個更微妙的無伺服器不相容性示例是，不同提供商概念化和公開平臺內函式觸發機制的方式存在差異。如果這些機制顯著不同，您可能需要重新定義在新平臺上如何實現您的觸發器。

當無伺服器應用程式使用其提供商生態系統中的其他服務來支援其應用程式時，可能會發生其他型別的鎖定。例如，由於無伺服器函式不處理狀態，因此通常會使用提供商的物件儲存服務來儲存呼叫期間產生的任何工件。雖然物件儲存廣泛使用標準介面實現，但它表明了無伺服器架構的約束如何導致對其他可用服務生態系統的更大采用和依賴。

開發者如何嘗試限制鎖定

開發者可以透過一些方法來儘量減少其應用程式發生鎖定的可能性或影響。

使用像 JavaScript 這樣被廣泛支援的語言編寫函式是避免硬依賴的最簡單方法之一。如果您選擇的語言受到許多提供商的支援，這為您提供了其他可能能夠執行您程式碼的平臺選項。

開發者還可以嘗試將服務的使用限制在那些在每個平臺上幾乎都以相同方式支援的通用產品。例如，我們之前使用的物件儲存示例實際上是一個理想的服務示例，它很可能可以被其他提供商的產品所替代。您所依賴的服務越專業化，就越難脫離該生態系統。這是一個您必須逐案評估的權衡，因為您可能不得不放棄專用工具而選擇更通用的替代品。

開發者可以預見哪些型別的差異？

無伺服器正規化的承諾是將除了程式碼本身之外的所有責任都轉移給平臺提供商。這可以在運維開銷和簡化開發者執行環境方面帶來許多優勢，但它也使得開發者通常依賴的許多技術和工具變得更難或無法使用。

例如，一些開發者習慣於透過直接訪問程式設計環境進行除錯，無論是透過 SSH 連線到主機，還是透過內省程式碼並使用程序暴露的資料。在無伺服器環境中，這通常是不可能或不容易的，因為執行環境對使用者是透明的，只有像函式日誌這樣的特定介面可用於除錯。這使得診斷問題變得困難，特別是當問題無法在本地復現或在管道中呼叫多個函式時。

有哪些可選方案可以提供幫助？

開發者可以採取多種不同的策略來幫助他們在這種更受限的除錯環境中工作。

一些無伺服器功能可以在本地執行或模擬，允許開發者在自己的機器上除錯他們在提供商的生產環境中無法除錯的問題。許多工具旨在模擬常見的無伺服器平臺，以便開發者可以重新獲得他們可能缺失的一些診斷能力。它們可以讓你逐步執行函式、檢視狀態資訊和設定斷點。

要在平臺本身進行除錯，您必須嘗試利用提供商提供的所有工具。這通常意味著在您的函式中進行大量日誌記錄，使用 API 測試工具自動以不同輸入觸發函式，以及使用平臺提供的任何指標來嘗試深入瞭解執行環境中可能發生的情況。