3個有狀態應用程式的無伺服器開發策略 - Twain Taylor

函式和延遲
函式應該可以直接相互訪問。如果無法相互立即連線，函式依賴於慢速儲存介質將資料從一個函式傳輸到另一個函式，從而由此增加了延遲。在實時應用場景中 - 例如24/7監控系統 - 延遲卻是不可接受的。

無伺服器函式主要支援短期工作負載，這意味著資源在請求時分配給它們，並在請求結束後被帶走。在無伺服器函式上開發的有狀態應用程式無法使用傳統機制來工作，例如可以在整個應用程式的生命週期內儲存資料的全域性變數。無狀態函式不可能讀取和寫入磁碟，並且應用程式無法保持與資料庫的持續連線。

要建立有狀態應用程式，無伺服器開發人員可以使用資料庫連線，事件有效負載或後端即服務（BaaS）來管理應用程式狀態，以與應用程式整合。開發人員應該使用這些方法來充分利用無伺服器架構。正確完成後，他們管理應用程式狀態而不降低效能。

直接連線到資料庫
無伺服器開發人員可以將應用程式狀態儲存在資料庫中，然後將這些函式連線到資料庫以進行訪問。

在此設定中，開發人員必須擔心可伸縮性。為避免對資料庫造成壓力並確保頻繁且持續地訪問應用程式狀態，請遵循特定於其雲平臺的無伺服器供應商的資料庫連線指南，例如AWS Lambda到Amazon Relational Database Service。一開始就建立並儲存狀態，以避免不斷呼叫資料庫所產生的成本。

避免物件關係對映（ORM），即在兩個不相容的系統之間轉換資料的過程。ORM需要為應用程式中使用的每個函式提供單獨的模型，這隻會為無伺服器開發建立更多的非特徵程式碼。

資料庫事務成本高，而且擴充套件性不好。不使用事務併發和應用程式開發，而是使用外部連線池代理，例如Java資料庫連線（JDBC）驅動程式。雲供應商提供這些驅動程式，例如用於SQL Server的Microsoft JDBC驅動程式以連線到Azure SQL資料庫。第三方軟體產品（如Progress DataDirect）也可用作池化代理。 

後端即服務連線
後端即服務是有狀態無伺服器開發的另一個主要機制。無伺服器函式使用無狀態HTTP API，BaaS透過抽象整個無伺服器架構和管理狀態來處理併發和效能等問題，而不管工作負載如何。可以透過一行程式碼在無伺服器函式內呼叫BaaS API，這樣可以保持應用程式程式碼庫的清潔，並使函式無狀態。BaaS選項包括Progress Kinvey和Google Firebase等。