無伺服器最佳實踐

每個函式應該只做一件事
這是關於功能錯誤和規模縮放的隔離。
換句話說，如果在函式中使用switch語句，那麼你可能做錯了。
許多教程和框架推薦在基於單個代理路由情況下，編制一整塊大的函式並使用switch語句。我不喜歡這種模式。它不能很好地擴充套件，並且往往會產生大而複雜的功能。
如果你的Web應用程式中有一部分接受一百萬次呼叫，有一部分可以接受1千次呼叫，則必須兩者分離，否則的話你無法輕易地最佳化千次呼叫的程式碼，將它們分開。這裡有很多價值。

函式不會呼叫其他函式
呼叫其他函式的函式是反模式。函式應該將資料推送到資料儲存或佇列，如果需要更多工作，則應該觸發另一個函式。

在函式中使用盡可能少的庫（最好為零）
函式具有冷啟動（當第一次啟動函式時）和熱啟動（它已經啟動，並且準備好從溫池執行）。冷啟動受到許多因素的影響，但是zip檔案的大小（或者程式碼被上傳）是其中的一部分。此外，需要例項化的庫的數量。
你擁有的程式碼越多，冷啟動的速度就越慢。
需要例項化的庫越多，冷啟動的速度就越慢。
例如，Java在一些平臺上的熱情開始是一種出色的高效能語言。但是如果你使用大量的庫，你會發現它需要很多秒才能冷啟動。你幾乎肯定不需要它們，冷啟動效能不僅會阻礙啟動，也會阻礙擴充套件。
作為另一點，我非常相信開發人員只在必要時使用庫，這意味著從無，從無結束，除非我無法構建沒有需要的東西。
像express這樣的東西是為伺服器構建的，無伺服器應用程式不需要這個東西的所有元素。那麼為什麼要介紹所有的程式碼和依賴？為什麼要帶來多餘的程式碼？它不僅僅是永遠無法執行的東西，但它可能帶來安全風險。
這是最佳實踐的原因有很多。當然，如果有一個你已經測試，知道和信任的庫，那麼絕對要把它帶進來，但關鍵元素是測試，瞭解和信任程式碼。遵循教程，是不一樣的。

避免使用基於連線的服務，例如RDBMS​​​​​​​
只是不要，除非你必須。
這個會讓我陷入最大的麻煩。很多網路應用程式的人都會跳上“但RDBMS是我們大家都掌握的知識”這趟潮流列車。
我談的不是關於RDBMS，而是關於連線。
無伺服器最適合服務而不是連線。
服務旨在快速返回對請求的響應，並處理服務背後的資料層的複雜性。這在無伺服器空間中具有巨大價值，並且為什麼像DynamoDB這樣的東西在無伺服器範例中非常適合。
說實話，無伺服器的人不反對RDBMS，他們反對連線。連線需要時間，如果您想象一個功能擴充套件，每個功能環境都需要一個連線，並且您在功能的冷啟動中引入了瓶頸和I / O等待。這是不必要的。
因此，如果您必須使用RDBMS，但是放置一個處理中間連線池的服務，可能只是處理一些描述的自動縮放容器會很好。
這裡要做的最重要的一點是，無伺服器架構可能需要您重新考慮資料層。這不是無伺服器的錯。如果您嘗試重用當前的資料層思維並且它不起作用，則可能缺乏對無伺服器架構的理解。

每個路由一個功能（如果使用HTTP）
儘可能避免使用單一功能代理。它不能很好地擴充套件，也無助於隔離問題。在某些情況下，您可以避免這種情況，例如，一系列路由的功能嚴格地繫結到單個表，並且它與應用程式的其餘部分非常分離，但這是我工作的大多數應用程式中的邊緣情況在。
這增加了管理方面的複雜性，但在應用程式擴充套件時，它確實有助於隔離錯誤和問題。從你的意思開始吧。
但是，你使用某種配置管理工具來執行一切都不是你嗎？你已經使用了某種CI和CD工具嗎？你仍然需要無伺服器的DevOps。

學習使用訊息和佇列（非同步FTW）​​​​​​​
當應用程式非同步時，無伺服器應用程式往往效果最佳。對於那些傾向於進行請求 - 響應和大量查詢的Web應用程式來說，這種方式並不是直截了當的。
回到”不呼叫其他函式的函式“這個主題，重要的是要指出這是將函式連結在一起的方式。佇列在連結方案中充當斷路器，因此，如果功能失敗，您可以輕鬆地排空由於故障而備份的佇列，或者將失敗的訊息推送到死信佇列。
瞭解分散式系統的工作原理。

對於一個後端是無伺服器的應用程式，最好的架構是參考CQRS。從輸入資料的角度分離檢索資料的點是這種模式的關鍵。

資料流，而不是資料湖​​​​​​​
在無伺服器系統中，您的資料流經您的系統。它可能最終存在於資料湖中，但可能的是，雖然它位於無伺服器系統中，但卻處於某種流動狀態。因此，請將所有資料視為動態，而不是在任何時候休息。
並非總是可行，但儘量避免在無伺服器環境中查詢資料湖。
無伺服器要求您顯著重新考慮資料層。這是最新的問題，新人們無法服務於無伺服器，他們傾向於達到RDBMS而且不會因為縮放問題而將其淘汰，但他們的資料結構變得過於僵化。
您將發現您的流程將隨著您的應用程式更改而更改，並且比例將更改所有內容。如果你所要做的就是重定向一個流程，這很容易。湖泊更加困難。

只是為了縮放編碼是一個錯誤，你必須考慮它如何擴充套件
建立第一個無伺服器應用程式非常容易，並且可以擴充套件它。如果您不瞭解自己已完成的工作，那麼您可以輕鬆陷入其他所有自動擴充套件解決方案的陷阱。
如果您不考慮您的應用程式以及它將如何擴充套件，那麼您可以自行解決問題。如果你使用緩慢的冷啟動（例如許多庫並使用RDBMS）然後獲得高峰使用率，你最終可能會顯著增加函式的併發性，然後最大化你的連線，並減慢你的應用程式下。
所以，不要只是將一個應用程式放入無伺服器，然後想象它將在各種負載下工作執行是相同的。瞭解不同負載下的應用程式表現仍然是你的工作的一部分。