Jangda等人由於在“無伺服器計算的形式基礎”方面的工作而在今年獲得了OOPSLA的傑出論文獎。本文的中心是他們觀察到無伺服器執行環境具有許多獨特的屬性（例如執行環境的熱啟動/重用），這會使構建正確的應用程式變得更加困難。它們顯示了無伺服器功能可以安全地忽略這些特性的條件，因此變得更容易推論。他們還介紹了一種基於箭頭的合成語言，用於函式合成。

無伺服器時要注意的事項：

儘管無伺服器計算抽象有很多優點，但它暴露了一些低階別的操作細節，使程式設計師難以編寫程式碼和推理程式碼。例如，為了減少延遲，無伺服器平臺嘗試重用同一功能例項來處理多個請求。但是，此行為不是透明的，很容易編寫無伺服器函式，該函式在重新使用時會產生錯誤的結果或洩露機密資料。一個相關的問題是無伺服器平臺在空閒時突然終止函式例項…

這個問題與無伺服器環境中的誤用/誤解狀態有關。無伺服器功能是無狀態的，但是可以在呼叫之間適當地重用快取的狀態以加快啟動時間。

“做錯事”的示例有一個程式碼樣本：

let accounts = new Map(); // account_name -> balance
exports.bank = function(req, res) {
  if (req.body.type == ‘deposit’) {
    ...
  }
}

如果您試圖將“持久”狀態保持在無法正常執行的無伺服器函式中！不要那樣做！更有可能陷入困境的是快取某些狀態以在函式執行之間進行機會性重用，但是這種狀態只能與指定使用者相關聯，根本無法保證下一次執行鍼對的還是同一使用者。

第二個考慮因素是函式的許多例項可以並行執行（這不是重點嗎？！）。沒有函式相似性的概念，因此來自同一源的請求也可能由不同的函式例項處理。因此，您可能需要一種在函式執行環境之外的共享狀態的協調機制（例如，具有事務支援的永續性儲存）。

第三個考慮因素肯定會更加棘手。考慮到至少執行一次的語義（即事件可以重試，具體取決於您配置重試策略的方式），它涉及對等冪性的需求。

大多數平臺響應單個事件至少執行一次函式，當函式產生副作用時，這可能會導致問題。

如果您的函式不是自然冪等的，則可能需要採取一些策略，例如記住以前看到的事件ID。作者在這裡沒有提到的是，只有當非冪等性涉及事務資源管理器所執行的操作（您還用於儲存已處理的事件ID）並且正在使用事務時，這才真正起作用。如果函式是傳送電子郵件，那麼副作用很顯然無法收回這些郵件，祝您好運！

更多有關數學形式推理可點選標題見原文