为无服务器的Web应用程序带来实时性 - ITNEXT


在Web应用程序中,通常会有一个前端与REST API进行通信,以便在后端完成工作。通常,API会返回一个结果,表示您要从系统中检索成功或某些值。
但是在无服务器基础设施中有一种棘手的类型的呼叫,其中返回值“消失”或者很难推回到前端,因为它需要太长时间或者 - 由于事件的链接性质 - 来自调用者需要更长时间才可以访问最终结果。

看看这个例子:

在此图中,一些前端代码调用API网关,从而在DynamoDB中生成一个条目,该条目生成一个流,触发Lambda函数。但是最后一个Lambda函数的返回值无处可去。因此,如果出现错误,问题或需要原始前端代码知道的问题,我们就会陷入困境。

实际上,每当您将函数附加到从S3,DynamoDB或任何其他AWS服务生成的事件时,返回值都不能被推回到链中。例如,如果使用Rekognition分析放入S3 Bucket的照片,则需要将响应发送到函数返回值以外的其他位置。
这些问题有几种解决方案,每种方法都有各自的优缺点,具体取决于您的使用情况。

选项1:等待
在最简单的情况下,你有一个需要一段时间的功能,你可以等待。您受限于API网关的30秒超时,因此对于长期存在的进程,这是行不通的。从成本的角度来看,这也不是很好,因为你在为等待付出代价。但对于简单,临时,低使用率的应用程序,这是最简单的解决方案。
示例:每月一次,前端请求将大对象从一个S3存储桶复制到另一个区域,并等待3-5秒,直到S3确认成功完成。在这种情况下,设计更复杂的东西可能不值得。

选项2:轮询
这适用于后端进程花费的时间超过几秒钟,或者执行的长度可能超过API网关上的30秒超时的情况。
这里前端提出了API的请求,发生了两件事:

  • 被叫函数立即响应,确认已成功接收请求(但不是工作结果)。此响应可能包括稍后引用的前端ID(如果前端未首先生成ID)。
  • 接下来,有一个用于检查工作状态的第二个API,并且前端将定期轮询,直到工作报告为完成,并且该函数返回响应。在AWS中,此状态函数通常会检查DynamoDB表,其中包含管理请求状态的ID。

这种方法易于实现,但会产生许多不必要的请求,并且不是很实时。例如,如果事务需要20秒并且前端每秒轮询一次,则在前端收到完成的响应之前需要20-21个轮询请求。
在无服务器方面,从成本的角度来看,这可能仍然是优选的 - 20 x 100ms的请求成本低于等待20秒,但是有一个开销,而且代码相当于在车后面让孩子们反复询问“我们还在那里吗? ?”。

选项3:物联网
虽然IoT会让人联想到硬件设备的图像,但它也可以用于无服务器的Web应用程序。物联网使用称为MQTT的轻量级消息传递协议,这是一种简单有效的推送消息的方法。

发布 - 订阅方法通常保留给实时应用程序,但可以很好地解决此问题。好处是您不需要编写轮询功能或发出多个必要的请求,并且您不受API网关30秒超时的限制。更好的是,无论过程需要5秒还是5分钟,前端都会立即知道任务何时完成,因为通信是实时的。
对于诸如仪表板之类的前端而言,这是一个很好的解决方案,其中网页加载一次但希望与后端数据的更改保持同步。但它对于任何时间要求严格的前端应用程序也很有效,因为您希望最大限度地减少等待时间。
在表面下,发布 - 订阅是复杂的,它是一个繁琐的过程,定期保持活跃的ping,以确保各方仍然存在。幸运的是,AWS IoT设备SDK将这一切抽象出来,使我们可以轻松构建一个前端,该前端正在侦听后端某些远程进程生成的消息。

成本角度来看,AWS通过连接分钟和消息数量向您收费(还有一个慷慨的免费等级补贴)。连接一年的单个客户将花费4.2美分(不包括数据费用),因此如果您有数千名用户,美元很重要,那么它仍然相对便宜。