如果我正确理解了整个概念，那么“无服务器”架构假定应该使用一堆 aws 服务，而不是使用自己的服务器或容器。通常这种架构包括 Amazon API Gateway、一堆 Lambda 函数和用于存储数据和状态的 DynamoDB（或替代方案），因为 Lambda 无法保持状态。而像 EC2 这样的服务并没有参与这一切，嗯，因为这是一个虚拟服务器，它削弱了无服务器架构的所有好处。
所有这些看起来真的很酷，但我觉得我错过了一些重要的东西，因为现在这似乎不适用于实时应用程序等情况。
说，我有 2 个用户在线。其中一个在应用程序中执行操作，该操作会触发数据库中的更改，而数据库又应触发第二个用户应用程序中的更改。
从服务器向客户端发送一些数据或命令的传统方式是 websocket 连接。但是对于无服务器架构，似乎没有办法建立和维护 websocket 连接。那么......我在哪里误解了这个概念？或者，如果我正确理解了所有内容，那么我该如何实现如上所述的 2 个用户之间的交互？
无服务器不仅仅是 Lambda、API Gateway 和 DynamoDB 的问题，它远不止这些。Serverless 的一大优势是它减轻了您的操作负担。不再需要打补丁，不再需要容量规划，不再需要配置管理。这些可能看起来微不足道，但在大量实例中做好这些事情是复杂、昂贵且耗时的。另一个好处是经济性。公共云利用公用事业计费，这意味着无论您是否实际使用它，您都需要为运行的内容付费。对于 AWS，每项服务的大部分计费是按小时计费，但对于 Lambda，它是每 100 毫秒。运行一整月的最便宜的 EC2 实例约为 10 美元/米（冗余的两倍）。20 美元的 Lambda 定价为您带来数百万次调用，因此在大多数情况下，无服务器要便宜得多。
不过，无服务器并不适用于一切，它有其局限性，例如它不适用于运行二进制文件。您不能在 Lambda 中运行 nginx（例如），它只是作为它支持的编程语言的运行时环境。它还专门用于基于事件的工作负载，非常适合基于微服务的架构。小型独立的离散计算块完成工作后，它们将事件发送给另一个（或多个）以执行其他操作，并在需要时返回响应。
为了解决您对实时处理的担忧，根据您的代码正在执行的操作，您的 Lambda 函数可以在 100 毫秒内一直到 5 分钟内完成。有一些策略可以优化它的持续时间，但一般来说，它适用于短期工作，这有利于实时场景。
在您关于 2 个用户与 Web 应用程序和数据库交互的示例中，可以很容易地使用具有一个或 2 个函数和一个 DynamoDB 表的无服务器技术来构建。如果不是几秒钟，总往返时间可能低至几毫秒，这实际上完全取决于您的代码及其在做什么。这些都是 HTTP 调用，因此不需要 websocket。想想许多 API 相互调用，而您的 Lambda 代码就是编排器。
您可能想查看 SNS（简单通知服务）。在您的示例中，如果应用用户 2 是 SNS 主题的订阅者，那么当应用用户 1 进行更改触发 SNS 消息时，它将被推送给订阅者（应用用户 2）。除了 SMTP 或 SMS 之外，还可以通过多种支持的协议（Amazon、Apple、Google、MS、百度）推送消息。SNS 消息可以由 lambda 函数触发，也可以在更新后直接从 DynamoDB 流触发（数据库触发器）。由应用程序开发人员选择消息协议和格式。该应用程序只需通过其本机渠道接收消息。这可能不完全是毫秒延迟的“实时”，但它对于除对延迟最敏感的应用程序之外的所有应用程序来说已经足够快了。
我已经在 AWS 无服务器应用程序上工作了几个月，并且对可用的各种服务感到惊讶。改进的速度和添加的新功能足以让您喘不过气来。