如果我正確理解整個概念，「無服務器」體系結構假定不使用自己的服務器或容器，而應該使用一堆aws服務。通常，這樣的體系結構包括Amazon API網關，大量的Lambda函數和用於存儲數據和狀態的DynamoDB（或可選），因爲Lambda無法保持狀態。而像EC2這樣的服務並沒有參與所有這些，好吧，因爲這是一個虛擬服務器，它減少了無服務器體系結構的所有好處。用於實時客戶端 - 服務器消息傳送的AWS「無服務器」體系結構
所有這些看起來非常酷，但我覺得我錯過了一些重要的東西，因爲現在這似乎不適用於實時應用等情況。
說，我有2個用戶在線。其中一人在應用程序中執行操作，這會觸發數據庫中的更改，而這又會觸發第二個用戶應用程序中的更改。
從服務器發送一些數據或命令到客戶端的傳統方式是websocket連接。但是對於無服務器體系結構，似乎沒有辦法建立和維護websocket連接。所以...我誤解了這個概念？或者，如果我正確地理解了一切，那麼如何實現上述2個用戶之間的交互？
無服務器不僅僅是Lambda，API網關和DynamoDB的問題，它遠遠大於此。無服務器的一大優勢就是它爲您帶來的運營負擔。沒有更多的補丁，沒有更多的容量規劃，沒有更多的配置管理。這些可能看起來微不足道，但在大量實例中完成這些工作並不複雜，昂貴且耗時。另一個好處是經濟。公共雲利用公用事業賬單，這意味着無論您是否實際使用它，您都需要支付運行費用。使用AWS，每項服務的大部分計費都是按小時計算的，但Lambda則是每100毫秒計算一次。運行整整一個月的最便宜的EC2實例大約是10美元/米（爲冗餘的兩倍）。 Lambda定價20美元讓您獲得數百萬次的調用，因此大多數情況下無需服務器的服務器便宜得多。
無服務器雖然不是爲了一切，但它有其侷限性，例如它不適用於運行二進制文件。您不能在Lambda中運行nginx（例如），它只是爲它支持的編程語言提供運行時環境。它也專門用於基於事件的工作負載，這對於基於微服務的體系結構非常適用。獨立的小型計算機做了一些工作，當完成後，他們將事件發送給其他人做其他事情，如果需要的話返回響應。
爲了解決您對實時處理的擔憂，根據代碼的作用，您的Lambda函數可以在不到100ms的時間內完成，最長可達5分鐘。有一些策略可以優化持續時間，但總的來說，它適用於短期工作，這有利於實時場景。
在您的關於2個用戶與Web應用程序和數據庫進行交互的示例中，可以非常容易地使用帶有一個或兩個函數的無服務器技術和DynamoDB表進行構建。如果不是幾秒鐘，總的往返時間可能會低至幾毫秒，這完全取決於您的代碼以及它正在做什麼。這些都將是HTTP調用，所以不需要websocket。考慮一些互相調用的API，並且您的Lambda代碼是協調器。
您可能想看看SNS（簡單通知服務）。在您的示例中，如果應用用戶2是SNS主題的訂閱者，則當應用用戶1進行觸發SNS消息的更改時，它將被推送給訂閱者（應用用戶2）。除了SMTP或SMS之外，該消息還可以推送到幾種支持的協議（亞馬遜，蘋果，Google，MS，百度）。 SNS消息可以通過lambda函數觸發，也可以在更新（數據庫觸發器）之後通過DynamoDB流直接觸發。應用程序開發人員需要選擇消息協議和格式。該應用只需通過其原生頻道接收消息。這可能不完全是毫秒級延時的「實時」，但對於除了大多數對延遲敏感的應用程序都足夠快。
我幾個月來一直在研究AWS無服務器應用程序，並對可用的各種服務感到驚訝。改進和新功能的添加速度足以讓你喘不過氣來。
物聯網。物聯網。我有強烈的刻板印象，如果一個名爲IoT的服務，那麼它假設在特定情況下使用。換句話說，它看起來不是爲「常規」移動/網絡應用程序設計的。 – stkvtflw
我經歷了無服務器的例子，並感謝MaiKay，它似乎很適合這個目的。 @stkvtflw我認爲，無論技術名稱如何，該解決方案都適用於您的方案。有時甚至aws發現很難將服務分組，例如Cognito（可以用於Web和移動，我們大量使用它用於Web），但仍列在移動類別下。 – Ashan