無伺服器最佳實踐
該Serverless無伺服器最佳實踐認為：無伺服器是繼承事件驅動EDA和非同步程式設計正規化，其實是一系列FaaS函式服務和佇列的序列。對於一個後端是無伺服器的應用，最好的架構是參考CQRS。
這些無伺服器的最佳實踐主要針對大規模和突發性工作負載而不是相對較低的水平，因此很多這些最佳實踐來自規模角度，例如零售中的Nordstrom和物聯網中的iRobot。如果你的目標不是那麼遠，那麼你可能無需遵循這些最佳實踐。
每個函式應該只做一件事
這是關於功能錯誤和規模縮放的隔離。
換句話說，如果在函式中使用switch語句，那麼你可能做錯了。
許多教程和框架推薦在基於單個代理路由情況下，編制一整塊大的函式並使用switch語句。我不喜歡這種模式。它不能很好地擴充套件，並且往往會產生大而複雜的功能。
如果你的Web應用程式中有一部分接受一百萬次呼叫，有一部分可以接受1千次呼叫，則必須兩者分離，否則的話你無法輕易地優化千次呼叫的程式碼，將它們分開。這裡有很多價值。
函式不會呼叫其他函式
呼叫其他函式的函式是反模式。函式應該將資料推送到資料儲存或佇列，如果需要更多工作，則應該觸發另一個函式。
在函式中使用盡可能少的庫（最好為零）
函式具有冷啟動（當第一次啟動函式時）和熱啟動（它已經啟動，並且準備好從溫池執行）。冷啟動受到許多因素的影響，但是zip檔案的大小（或者程式碼被上傳）是其中的一部分。此外，需要例項化的庫的數量。
你擁有的程式碼越多，冷啟動的速度就越慢。
需要例項化的庫越多，冷啟動的速度就越慢。
例如，Java在一些平臺上的熱情開始是一種出色的高效能語言。但是如果你使用大量的庫，你會發現它需要很多秒才能冷啟動。你幾乎肯定不需要它們，冷啟動效能不僅會阻礙啟動，也會阻礙擴充套件。
作為另一點，我非常相信開發人員只在必要時使用庫，這意味著從無，從無結束，除非我無法構建沒有需要的東西。
像express這樣的東西是為伺服器構建的，無伺服器應用程式不需要這個東西的所有元素。那麼為什麼要介紹所有的程式碼和依賴？為什麼要帶來多餘的程式碼？它不僅僅是永遠無法執行的東西，但它可能帶來安全風險。
這是最佳實踐的原因有很多。當然，如果有一個你已經測試，知道和信任的庫，那麼絕對要把它帶進來，但關鍵元素是測試，瞭解和信任程式碼。遵循教程，是不一樣的。
避免使用基於連線的服務，例如RDBMS
只是不要，除非你必須。
這個會讓我陷入最大的麻煩。很多網路應用程式的人都會跳上“但RDBMS是我們大家都掌握的知識”這趟潮流列車。
我談的不是關於RDBMS，而是關於連線。
無伺服器最適合服務而不是連線。
服務旨在快速返回對請求的響應，並處理服務背後的資料層的複雜性。這在無伺服器空間中具有巨大價值，並且為什麼像DynamoDB這樣的東西在無伺服器範例中非常適合。
說實話，無伺服器的人不反對RDBMS，他們反對連線。連線需要時間，如果您想象一個功能擴充套件，每個功能環境都需要一個連線，並且您在功能的冷啟動中引入了瓶頸和I / O等待。這是不必要的。
因此，如果您必須使用RDBMS，但是放置一個處理中間連線池的服務，可能只是處理一些描述的自動縮放容器會很好。
這裡要做的最重要的一點是，無伺服器架構可能需要您重新考慮資料層。這不是無伺服器的錯。如果您嘗試重用當前的資料層思維並且它不起作用，則可能缺乏對無伺服器架構的理解。
每個路由一個功能（如果使用HTTP）
儘可能避免使用單一功能代理。它不能很好地擴充套件，也無助於隔離問題。在某些情況下，您可以避免這種情況，例如，一系列路由的功能嚴格地繫結到單個表，並且它與應用程式的其餘部分非常分離，但這是我工作的大多數應用程式中的邊緣情況在。
這增加了管理方面的複雜性，但在應用程式擴充套件時，它確實有助於隔離錯誤和問題。從你的意思開始吧。
但是，你使用某種配置管理工具來執行一切都不是你嗎？你已經使用了某種CI和CD工具嗎？你仍然需要無伺服器的DevOps。
學習使用訊息和佇列（非同步FTW）
當應用程式非同步時，無伺服器應用程式往往效果最佳。對於那些傾向於進行請求 - 響應和大量查詢的Web應用程式來說，這種方式並不是直截了當的。
回到”不呼叫其他函式的函式“這個主題，重要的是要指出這是將函式連結在一起的方式。佇列在連結方案中充當斷路器，因此，如果功能失敗，您可以輕鬆地排空由於故障而備份的佇列，或者將失敗的訊息推送到死信佇列。
瞭解分散式系統的工作原理。
對於一個後端是無伺服器的應用程式，最好的架構是參考CQRS 。從輸入資料的角度分離檢索資料的點是這種模式的關鍵。
資料流，而不是資料湖
在無伺服器系統中，您的資料流經您的系統。它可能最終存在於資料湖中，但可能的是，雖然它位於無伺服器系統中，但卻處於某種流動狀態。因此，請將所有資料視為動態，而不是在任何時候休息。
並非總是可行，但儘量避免在無伺服器環境中查詢資料湖。
無伺服器要求您顯著重新考慮資料層。這是最新的問題，新人們無法服務於無伺服器，他們傾向於達到RDBMS而且不會因為縮放問題而將其淘汰，但他們的資料結構變得過於僵化。
您將發現您的流程將隨著您的應用程式更改而更改，並且比例將更改所有內容。如果你所要做的就是重定向一個流程，這很容易。湖泊更加困難。
只是為了縮放編碼是一個錯誤，你必須考慮它如何擴充套件
建立第一個無伺服器應用程式非常容易，並且可以擴充套件它。如果您不瞭解自己已完成的工作，那麼您可以輕鬆陷入其他所有自動擴充套件解決方案的陷阱。
如果您不考慮您的應用程式以及它將如何擴充套件，那麼您可以自行解決問題。如果你使用緩慢的冷啟動（例如許多庫並使用RDBMS）然後獲得高峰使用率，你最終可能會顯著增加函式的併發性，然後最大化你的連線，並減慢你的應用程式下。
所以，不要只是將一個應用程式放入無伺服器，然後想象它將在各種負載下工作執行是相同的。瞭解不同負載下的應用程式表現仍然是你的工作的一部分。