無伺服器模式 -Davide Taibi

banq發表於2020-04-03

我們收集了從業者在技術講座,部落格和白皮書中提出的無伺服器模式。目的是透過對分類進行分類並報告可能的收益和問題,以支援從業人員理解不同的模式。我們採用了多語言文獻複審過程,調查了同行評議和灰色文獻,並對模式(解決常見問題的通用解決方案)進行了分類,並附帶了收益和問題。在24部精選作品中,我們確定了32種模式,分別被編排為業務流程,聚合,事件管理,可用性,溝通和授權。
在本文中,我們總結了已識別的模式以及它們的好處和問題。有關總結模式的方法和結果的更多資訊,請參見我們的論文(Taibi2020
從業者提出的模式
我們確定了32種模式,我們將其分為五類:
  • 編排和聚合
  • 事件管理
  • 可用性
  • 通訊
  • 授權

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

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:透過請求特殊的授權者無伺服器功能的首次訪問,它被授予令牌,該令牌在一定時期內有效並且具有訪問許可權。








 

相關文章