Deno与Node(AWS lambda上的冷启动)

德诺很性感。为了解决Node的一些更痛苦的方面，Deno在社区掀起了一场风暴，很多人都在寻求更换他们基于Node的工作负载。

对我来说，我主要使用Node来实现Lambda函数。我想看看德诺能不能换掉它。因为Deno有一个完全不同的打包系统，这意味着我必须等到编写AWS客户端或自己编写它们。不过，还有一个DynamoDB的Deno库，结合为社区和您创建的Lambda层，我可以很容易地入门。但是，它好吗？

主要是，它是表演性的吗？我首先设置了两个Lambda函数，一个是为Node编写的，另一个是为Deno编写的，每个函数都做同样的事情，写入一条DynamoDB记录，然后读回它。我创建了第三个Lambda，它是为Node编写的，它将以指定的速率执行另外两个lambda。然后，我会监控性能。

让我们把这一点抛诸脑后：Node和AWS SDK都经过了优化。正如你很快就会看到的，它们已经存在很长一段时间了，而且已经相当不错了。Deno和这里使用的库可能没有经历过相同级别的优化，也就是说，我仍然想知道它现在是否值得采用。

我运行了测试仪Lambda，要求每500ms通话5分钟。我假设这将允许运行时在冷启动之后稳定下来，并且我可以看到有代表性的持续时间指标。这是我主要关心的问题：Lambda函数执行的p99持续时间是多少。

Node lambda将执行大约40ms，这是相当可靠的。这是通过AWS_NODEJS_CONNECTION_REUSE_ENABLEDenvironment变量实现的。初始持续时间约为350ms。将内存增加到1024并没有显著改善这两个指标。

Deno Lambda的平均持续时间为250ms。更糟糕的是，初始持续时间在3.5s范围内。主要原因是Deno运行时当前在冷启动时下载外部包。可能有一些机制可以加速这一过程，但这是为另一篇帖子准备的。

所以，很明显，这很糟糕。在从Node迁移到Deno的过程中获得6倍的增长并不是很有吸引力。但是，这是否意味着德诺不应该被收养呢？

德诺很性感。这是有充分理由的。如果您曾经使用过Node和node_module目录，那么您可能已经处理过很多需要的打包系统。此外，它在默认情况下非常不安全，允许任何代码库完全访问文件系统和网络。这是一个反复出现的问题，通常需要工具和勤奋的维护人员在问题发生后才能发现。Deno的目标是通过非集中化的软件包生态系统和默认安全的运行时来解决这两个问题，后者需要显式的参数来启用对网络和文件系统的访问。哦，让我们不要忘记一流的打字支持！

那么，有了这些数字，德诺准备好了吗？对于API Gateway集成，我会说不。冷启动和运行时性能还不足以支持面向客户端的API调用。但是，其他情况又如何呢？支持API Gateway不是Deno的唯一使用案例。在许多情况下，Lambda函数用于侦听事件流、响应StepFunction调用，或者仅用于夜间的后台数据处理过程。在这些情况下，运行时变慢可能不是问题(除了额外的计费成本)。而这正是微服务架构和高度解耦的系统真正闪耀的地方。对于一些不需要低延迟的功能，您可以很容易地采用Deno；习惯于运行时，并围绕它充实您的开发管道，而对整个项目的风险很低(如果它不起作用，它很有希望足够小，您只需用Node重新实现即可)。

就我个人而言，我对德诺感到非常兴奋。Node有行李，有些行李不容易搬运。在Node准备投入生产并在这些环境中采用之前，它花了数年时间。多亏了一个截然不同的景观，我认为Deno将更快地投入生产。因此，现在就跳到您能做到的地方并习惯它，因为如果您现在重新运行Node，我愿意与您打赌2年后会以一定的能力运行Deno。

顺便说一句，如果你想要这些代码，这样你就可以自己运行这些测试了，你可以在这里找到它们，比如(还有什么？！)。一个CDK模块。