無伺服器模式 -Davide Taibi

• 編排和聚合
• 事件管理
• 可用性
• 通訊
• 授權

編排和聚合
這些模式可用於組成無伺服器函式或協調其執行，從而建立更復雜的功能或微服務。

1. 聚合器API閘道器：為多個API只公開一個端點。函式單獨呼叫API，然後彙總結果並將其公開為單個端點。

2. 資料湖：資料湖是原始資料的物理儲存，在其中資料的處理和刪除最少。為了保持秩序，必須使用明智的後設資料命名進行組織。好處：資料始終保持不變，不受當前需求的影響。可以根據需要及時進行轉換。

3. 扇入/扇出Fan-In/Fan-Out ：也稱為“虛擬角色” ，“資料轉換” ，“處理器” ，“火警觸發器“，拆分並行工作並最終彙總結果。並行執行可加快完成速度。適合執行超過最大執行時間的長任務。缺點：連結函式之間的強耦合。對函式鏈，在函式之間劃分任務可能很複雜

4. 函式鏈：允許執行超過最大執行時間（例如，在Lambda中超過15分鐘）的長任務。將函式組合在一起。初始函式在跟蹤剩餘執行時間的同時開始計算。在達到最大執行時間之前，該函式非同步呼叫另一個函式，並傳遞繼續計算所需的每個引數。然後可以終止初始功能，而不會影響鏈中的下一個功能。缺點：連結函式之間的強耦合，函式數量增加。在函式之間劃分任務可能很複雜

5. 代理：也稱為“命令模式”，“反腐敗層”。建立一個函式來充當其他服務的代理，處理任何必要的協議或資料格式轉換，為客戶提供乾淨且易於訪問的API。

6. 基於佇列的負載均衡 ，也稱為“可伸縮Webhook”，“ Throtler”。透過Webhooks，可以使用自定義回撥來增強或更改網頁或Web應用程式的行為。如何提高Webhooks呼叫的可伸縮性？可以使用觸發服務的佇列服務，該服務允許在高負載下對請求進行排隊。

7. 節儉的消費者：一種函式，用於處理將訊息直接釋出到訊息佇列的多個服務（或函式）的請求。

8. 內部API：由於無法從外部訪問服務，因此提高了安全性。

9. 健壯的API ：也稱為“閘道器” ，使用API​​閘道器為客戶端授予對所選服務的訪問許可權。

10. 路由器：建立一個充當路由器的函式，接收請求並根據有效負載呼叫相關功能。好處：易於實施。問題：路由功能需要維護。此外，它可能會引入效能瓶頸，併成為單點故障。雙重計費，因為路由函式需要等待，直到目標功能終止執行。

11. 胖客戶端 ：允許客戶端直接訪問服務並協調工作流程。好處：提高效能，降低伺服器端成本，增加關注點分離。

12.狀態機：採用無伺服器編排系統（例如AWS Step Functions或IBM Composer）來編排複雜的任務。

事件管理
這些模式有助於解決通訊問題。
13. 職責隔離：隔離用於更新和讀取資料來源的功能。對適當的函式使用“命令和查詢”，以避免這種擁塞。

14. 分散式觸發器 ：可以透過訊息佇列將多個服務耦合到一個通知函式中。如果主題僅具有一個目的並且不需要微服務之外的任何資料，則此設定非常有效。

15. FIFO：使用crontab（例如AWS Cloudwatch）定期週期性地非同步呼叫該函式。然後，將函式的併發性設定為1，這樣就不會嘗試並行執行競爭請求。該函式輪詢佇列（最多10條）排序的訊息，並執行所需的任何處理。處理完成後，該函式將從佇列中刪除訊息，然後再次（非同步）呼叫自身。重複此過程，直到從佇列中刪除了所有專案。

16. 內部切換：函式在執行完成時自動停止，並在需要時自動重試。使用訊息佇列附加死信佇列可以捕獲失敗。

17. 排程：週期性呼叫者，將該函式訂閱到排程程式，例如AWS Cloud Watch，Google Cloud Scheduler或Azure Scheduler。好處：定期執行函式，而無需使其永久處於活動狀態。

18.輪詢事件處理器：使用定期呼叫者模式檢查服務的狀態好處：執行定期執行函式，而無需將功能永久保持為偵聽器。

可用性模式
這組模式有助於解決可用性問題，減少預熱時間和可能的故障。

19.隔板：將工作負載分割槽到不同的池中。可以根據使用者負載或可用性來建立這些池。

20.斷路器：當故障次數達到某個閾值時，“斷開”電路會立即將錯誤傳送回撥用方客戶端，而無需嘗試呼叫API。

21.編譯函式：一種高階的，專門的，預先編譯的無伺服器語言可以減少記憶體佔用和呼叫時間。這可能使雲中的Edge技術可行。

22.函式預熱器：減少冷啟動時間，即呼叫某個函式後函式執行之間的延遲。

23. 函式過大：在Serverless中，無法選擇在哪個CPU上執行。解決方案：即使不需要更多記憶體，要求更大的記憶體也會授予更快的虛擬機器。

24. 過載報表引擎：使用資料快取並建立最常查詢的資料的專用檢視

25. 最終一致：使用資料庫流服務（例如DynamoDB流）來觸發以前功能在資料庫上產生的事件，並根據需要再次使用資料。

26.超時：API閘道器的超時時間為29秒。這對於使用者來說是很長的時間，並給服務帶來不好的體驗。解決方案：將超時時間縮短到較短的時間，最好在3到6秒左右。

通訊模式
在這裡，我們描述了函式之間進行通訊的模式。

27.資料流：也稱為“流和管道”，“我是流媒體 ”和“事件處理器” ，“流資料攝取” ，“流處理”。無伺服器平臺提供了諸如Kinesis（AWS）之類的可能性來處理大量資料流並將其分發到服務。問題：在無伺服器環境中，資料流可能會非常昂貴。在平臺生態系統之外工作也可能很困難。

28.外部狀態：在某些情況下，需要在函式之間共享狀態。通常的解決方案：共享狀態並將其儲存到外部資料庫中。 這個模式：應用連續流處理器捕獲大量事件或資料，並將它們儘快分佈到不同的服務或資料儲存中

29.釋出/訂閱：在訊息佇列中使用獨立主題來分發內部內部服務通知。

授權模式
這些處理使用者授權問題。

30.Gatekeeper ：使用閘道器建立授權者函式，該函式可以處理授權標頭並返回授權策略。


31.Valet key：透過請求特殊的授權者無伺服器功能的首次訪問，它被授予令牌，該令牌在一定時期內有效並且具有訪問許可權。