無服務器與事件採購相結合可能嗎？

Question

我一直想使用完整的無服務器體系結構實現一段時間的移動應用程序，並最終開始查看細節。到目前爲止，我發現AWS提供了大部分這種設置所需的服務（API網關，Cognito，Lambda，DynamoDB，SQS等），但我還沒有解決一個（可能是理論上的）問題;事件採購。

由於（歷史）數據近來越來越有價值，因此保存有關用戶的歷史數據非常重要（以我的愚見）。當前的事件採購產品（如Akka持久性）通過僅將事件保存到數據庫並將當前狀態保存在內存中（並將快照保存到數據庫等）來實現此目標。

我的問題是，我沒有能力在內存中存儲這樣的狀態，因爲我的Lambda函數在完成單個用途後終止。我的問題歸結爲什麼，目前有一個框架支持事件採購（在Java上），它將ElastiCache（Redis）等當前狀態保存下來。由於我對Akka有很多經驗，這是持久性已經可以做到的事情嗎？結合無服務器後端（此時）是否值得追逐事件採購？還是現在還不是恰當的時機？

我還沒能在Akka Persistence文檔中找到很多有關此（可能的非）問題的文章。請給我一些建議，說明我在無服務器世界的使命中可能錯過了什麼;我仍然在學習，因爲我們都是。

Answer 1

這將主要基於意見，所以不是最適合堆棧溢出，但我會盡量保持儘可能真實。

由於以下原因，akka-persistence不適合無服務器部署策略。它依賴於強有力的假設，即任何時候只有一個PersistentActor用於給定的id。在分佈式環境中，執行此操作意味着節點間協調，通常使用akka-cluster-sharding。這不會讓自己被部署在一個無服務器的環境中，以運行簡單的功能。

一般來說，事件採購意味着從存儲在日誌中的事件（或最新快照+隨後發生的事件）重建狀態，並在無狀態環境的頂部執行該操作意味着每次執行該功能都會產生很多低效率，因爲不能有本地緩存​​。在事件採購之上添加分佈式緩存可以有所緩解。然而，你仍然面臨着協調的挑戰，以防止函數的多個實例之間的競爭條件。這些因素與無服務器提供的操作簡單性相反。

Answer 2

是的，您可以在無服務器中執行事件採購。

使用AWS的一種方法是將DynamoDB用作Event Store。然後，您可以使用DynamoDB Streams和Lambda觸發器將它們實現到您的State Store（可以是任何其他數據庫）。