AWS AppSync事件功能——真正方便的无服务器WebSocket，还是只是有所不同？

API网关WebSocket 或者 AppSync事件？

2024年10月30日，AWS 宣布 推出了一项新功能：AppSync 事件。这项功能让开发人员可以轻松通过安全且高性能的无服务器WebSocket API，将实时事件数据广播给少量或数百万订阅者。但这不是已经有API Gateway WebSocket API实现了无服务器WebSocket了吗？是的，但这次有些不一样。

在这篇文章里，你会学到关于AppSync Events的知识。我会首先介绍一下它的基本知识，并谈谈我对它的未来、应用场景、使用方法以及它与API Gateway WebSocket的不同之处的看法。我还将提供一个你可以亲自尝试的“GitHub仓库”GitHub仓库，让你自己动手操作。

你可以访问https://www.ranthebuilder.cloud/获取更多信息。

这篇博客文章最早发表在我的网站上，“Ran The Builder…”

一个WebSocket是什么？改为“什么是WebSocket？”

根据以上修改，最终翻译为：

什么是WebSocket？

WebSocket 是一种计算机 通信协议 ，提供了一个 双向同时 的通信通道，通过单一的 传输控制协议 (TCP) 连接。 维基

WebSockets 并不新鲜。它们被用于你手机上的每个社交应用程序，以及显示实时比分和实时更新的众多网站上。你有没有想过你的 Chrome 标签页是如何神奇地自动更新新信息的？不是轮询，而是通过 WebSockets。应用程序的后端会通过 WebSocket 将更新（无论是广播、单播还是多播）推送到你的浏览器。

虽然该协议有自己的基于TCP的实现，但握手过程最初在HTTP协议上开始，然后“升级”到WebSocket协议，在此之后按照RFC的规定进行自己的事情。

https://www.youtube.com/watch?v=G0_e02DdH7I （观看这个视频）

如果你想了解更多关于这个协议的内容，请参阅下面的视频。

让我们继续来看看 AppSync。

什么是AppSync事件功能？

AWS AppSync Events 允许你创建安全且高效的无服务器的 WebSocket API，可以实时向数百万订阅者广播事件数据，而无需你手动管理连接或调整资源。 — AWS

（去掉结尾的破折号“— AWS”，改为：）

AWS AppSync Events 允许你创建安全且高效的无服务器的 WebSocket API，可以实时向数百万订阅者广播事件数据，而无需你手动管理连接或调整资源。

首先，咱们先把话说开，这跟 GraphQL 和 AppSync 没半毛钱关系。

这不过是这种新的无服务器 websocket 的糟糕品牌形象。

核心概念和术语

核心概念和术语是指我们将在本章节中探讨的基本思想和专业词汇。

在 WebSocket 上，AppSync 事件的处理方式有所不同，包括协议层面以及无服务器管理和消息处理层面。

据我理解，根据 AWS 的文档，他们增加了一层抽象的概念，在单个 WebSocket 之上添加了一个内部子协议，称为 AppSync-y，用于管理新的通道实体。这在 AWS 开发者指南中的图示中有所体现。参考 AWS 开发者指南中的图示，可以看到这个新的设置。

握手 - 初始化 - 订阅 - 事件 - 取消订阅 - 断开连接

一旦客户端连接到AppSync端点他们就可以试着订阅一个频道。

这里的酷地方是可以通过同一个WebSocket连接多个频道。这让人感觉像是有多个“pub-sub”主题/频道，但实际上都是同一个WebSocket。真棒！

订阅需要验证，这里有五个选择：

添加授权向导

这些选项涵盖了每一种标准的认证方法。我通常选择一个Lambda函数来检查网络应用的安全cookie及JWT以及其他额外的检查。

文档非常详细，甚至提供了Lambda函数的输入模式示例和实现样例——这真是非常棒！

回到通道主题上，有默认通道，但你可以添加更多通道，例如。通道命名空间最多可以有五个部分，提供了很高的灵活性。可以把这看作是面向UI的发布-订阅主题。

例如，你可以创建一个用于日常用户更新的频道，或者按类别创建，比如NBA、足球等类别。你可以使用多达五个部分，这样你就可以发布关于不同体育项目的更新：例如/users/nba和/users/football。

另外，你可以订阅 /users/nba/ 来获取NBA的常规新闻，或者你可以订阅 /users/nba/*（星号，代表通配符），这表示你会收到例如 /users/nba/bulls 和 /users/nba/lakers 等子分类的所有NBA新闻。

当谈到发布时，这可以通过前端和后端进行，并需要授权。你可以为每个渠道设置不同的授权方式，并使用一个 Lambda 函数（真不错！）。如果你有权向这些频道发布消息，你只需向频道以及其分段的地址发送一个 HTTP 请求。你可以从 Lambda 函数或 Event Bridge（我认为是 API 目的地）发布，使 AppSync 事件成为事件驱动架构的助推器。

初次印象和使用感受

我根据控制台和文档创建了我的第一个Events API。我已经不记得上次看到如此高质量的文档是什么时候了。文档不仅支持多种授权方式，还提供了客户端的代码示例。唯一明显缺失的是更高级别的CDK支持，目前仅支持L1级别。写作本文时，CDK L2的相关问题仍处于开放状态。我从最基础的部分开始——使用不太安全的API密钥进行授权。

我没有使用控制台的发布/订阅功能。我直接开始尝试在一个网页应用上订阅和发布频道，并使用了控制台提供的代码示例。效果很好。

我遇到了一些小问题，因为我是个彻底的前端新手，但在我的同事Afik Grinstein的帮助下，我有了一个运行中的Vite项目。

GitHub的完整仓库位于https://github.com/ran-isenberg/appsync-events-client。

我们来回顾一下我们之前创建的东西:

我们的客户订阅了“default/test”通道和分段。订阅之后，该客户通过发布UI的文本输入框发布事件。

事件日志区显示所有发布到该路径‘/default/test’的消息。

前端软件

确实，它就是一个使用了AppSync协议的WebSocket。

没错，这确实是个WebSocket

还有：

AppSync 的协议

用Amplify SDK写JS代码非常简单，如下所示：

我可以订阅另一个频道，比如‘/users’，并检查通配符订阅功能。确实，这个功能很好用，非常简单。在处理单播或特定用户频道时，需要自定义授权来确认用户能否订阅该租户或用户ID的消息。

总之，说实话，这真的很厉害，就是这么有效。

如果你对完整代码和HTML页面感兴趣，可以在这里点找到这里。

我们来看看见解部分，这里的内容就有点辣。

见解和小贴士

在这里，我将分享一些几个小时的使用后获得的见解，从而得出我的总结和结论——我还会继续用它吗？

安全

我喜欢授权选项的灵活性这一点。初始连接时提供五种授权类型，以及针对特定频道订阅的额外授权选项，已经完全足够。

您也可以添加一个按频道的连接授权方式，并使用您选择的 Lambda 对发布和订阅请求进行微调。这里有一个示例处理器 example。

AWS WAF 支持是有的，而 API Gateway Websockets 没有这项支持。因为我们需要公开一个用于发布消息的 HTTP 端点，所以这一点是必须的。

看看我这篇博客以了解更多关于AWS WAF的信息。这里

没有连接表

无需担心管理数据库连接；这真的就是无服务器架构！

如果你不知道我为什么惊讶，那是因为在使用API Gateway的WebSockets时——当你想要给一个用户发送消息时，你需要知道它的WebSocket连接ID。在用户认证和允许连接的握手过程($connect)中，这个映射是可见的，这意味着你需要把它保存在某个地方供后端服务使用。DynamoDB是一个很好的选择，用来存储这种键值信息，但这是你需要自己编写的代码，并进行维护和测试。这不算什么大问题，但AWS并没有直接提供给我们。这里进行了抽象。你不知道连接ID（我确定是有一个连接ID的），你只关心频道。你甚至不知道谁连接了这些频道，这里假设你根本不在乎。你想发布一条消息到一个频道，所有订阅了这个频道的人都会收到消息。典型的发布订阅模式。

总之，这里的方式不同，是通道和连接ID的区别。

大众广播其实很简单

使用 API Gateway 套接字时，你需要遍历连接表并获取相关的连接 ID，然后使用 AWS SDK 发送消息。你还需要处理错误、重试以及限流，随着目标受众数量的增加，这会变得越来越有挑战。

有了 AppSync 事件，你只需要向一个带有正确授权的 HTTP 端点发起一个 API 调用——简直太简单了！

然而，你无法得知哪些用户收到了消息，哪些用户没有收到消息。使用API网关的WebSocket时，如果你向一个已关闭的连接ID发送消息，会收到一个异常，从而得知连接已关闭。这可能对你当前的使用场景并不重要，但你还是应该注意一下。

亲爱的AppSync事件团队成员们，我的建议是：能否为频道添加一个消息队列机制？通过这个机制，特定的频道（例如，/users）即使在用户注销后也能继续存储数据一段时间。当频道订阅恢复时（例如，/users/<user_id>），就会显示之前错过的消息。

租户隔离需要通道设计

单播稍微难一些（也不是特别难）。假设我需要通过 websocket 发送用户特定的消息，以及每个客户的特定消息，但这些消息是客户特定的，不能发送给其他客户。

我们的命名空间通道可以是这样的形式：用户可以订阅 ‘/tenant/<tenantid>’ 和 ‘/users/<userid>’。请确保在这种情况下不要使用通配符订阅功能，否则这会导致租户和用户之间的隔离被破坏。

注意一下：频道的命名空间配额是50，但这只是一个宽松限制。

此外，每个命名空间的长度限制为50个字符，因此在添加租户ID或用户ID时，请注意，标准的UUID长度为36个字符。

过度的灵活性会带来更多的复杂性

设计渠道并授权用户使用这些渠道会让事情变得更复杂。要记住不同类型的数据（个人数据或非个人数据）放哪里，因为这里没有任何保护措施。你需要自己搭建。你需要将逻辑嵌入到自定义的渠道授权中。你还需要确保前端客户端订阅正确的频道。此外，随着系统中实体数量的增加，你需要进行更多的代码修改。如果你新增了“管理员”角色，可能需要添加一个新命名空间或额外订阅，并处理所有更新的授权处理程序。

这比在 API GW WebSockets 中复杂得多，你只需连接并监听消息就行了。当然，我需要建立一个 DynamoDB 表来映射连接 ID、用户 ID 和会话 ID，但这还是比较简单的。

开发体验

文档虽然不错，但还有改进的空间。CDK的支持方面严重不足。

副编辑的发布订阅功能是一个不错的设计，便于快速测试频道及其权限。不过，我并不期望后台开发人员每天都要使用控制台。这对想要测试新频道并查看其后台生成的数据的开发人员来说是个好选择。

Amplify的代码示例很好，它让我很快就能上手。不过，如果你不用他们的SDK，你仍然可以使用Events API，但你需要在正确的位置添加所有AppSync的头信息。

最后，你必须使用内置的 JavaScript 事件处理程序来处理这些 ‘onSubscribe’ 和 ‘onPublish’ 通道处理器。你不能使用自己的函数或依赖库。在我看来，这并不是最好的体验。

定价：

杰里米·戴利提到过（参见他的推特）：

定价比API Gateway WebSockets连接分钟数便宜300%。AppSync每百万连接分钟$0.08，而API Gateway则为$0.25每百万。消息传输似乎没有区别，但AppSync似乎对每个“操作”都收费。

也有一个非常优惠的免费级别（详情请见 https://aws.amazon.com/appsync/pricing/）。

对我来说，AppSync 在我看来比 API Gateway 更好。

概括 —— 做得好了吗还是只是看起来不同 —— 换句话说，我需要使用它吗？

AppSync 事件是 Serverless WebSocket 的一种新的方式。它使得授权和通道管理更加复杂，但解决了在 Api GW WebSocket 进行大规模广播中的主要缺点。

如果你不需要进行大规模群发，而是总是发送特定用户的消息，那么普通的 API 网关 WebSocket 是一个经过实战考验的可靠选项。很快会写一篇博客文章，也会包含 CDK 代码示例！

该服务拥有光明的前景和巨大的潜力。我强烈推荐给少数族裔或代表性不足的群体 (POCs)、初创企业以及其他愿意率先采用的公司等等。

不过，作为企业架构师，我必须仔细思考这个问题。开发者体验不佳，gov-cloud尚未得到支持，作为早期采用者，可能会遇到服务突然中断或变更的情况。此外，从过去的经验来看，比如，Evidently和AppConfig看似提供了类似的功能集，但存在一些差异，而最终AppConfig保留了下来，Evidently则被淘汰了。顺便说一句，如果你想了解更多关于AppConfig的特性标志，可以参阅我在这篇文章中的介绍这里。

但是谁知道，或许正好相反。或许 API Gateway 的 WebSocket 功能可能会逐渐被淘汰。这完全取决于 AppSync Events 的采用情况以及服务团队能否改进开发者的体验和文档。

简单易懂 🚀

感谢你加入_简单英语_社区！在你走之前：

• 记得为作者👏点赞并关注哦
• 关注我们吧：X | 领英 | YouTube | Discord | Newsletter | Podcast
• 免费在Differ上创建一个AI驱动的博客。Create a free AI-powered blog on Differ.
• 可以去PlainEnglish.io查看更多内容