llrt - 为Serverless应用打造的高性能JavaScript运行时

LLRT（Low Latency Runtime，低延迟运行时）是一个轻量级JavaScript运行时，旨在满足对快速高效的无服务器应用程序日益增长的需求。与在AWS Lambda上运行的其他JavaScript运行时相比，LLRT的启动速度最高可提升10倍，总体成本最多可降低2倍。

它使用Rust构建，采用QuickJS作为JavaScript引擎，确保高效的内存使用和快速启动。

[!警告] LLRT是一个实验性包。它可能会发生变化，仅供评估使用。

_{LLRT - DynamoDB Put, ARM, 128MB：}

_{Node.js 20 - DynamoDB Put, ARM, 128MB：}

HTTP基准测试以冷启动的往返时间为单位（原因请参见为什么？）

配置Lambda函数以使用LLRT

从 https://github.com/awslabs/llrt/releases 下载最新的LLRT版本

选项1：自定义运行时（推荐）

选择"Amazon Linux 2023上的自定义运行时"，并将LLRT的bootstrap二进制文件与您的JS代码一起打包。

选项2：使用层

选择"Amazon Linux 2023上的自定义运行时"，上传llrt-lambda-arm64.zip或llrt-lambda-x64.zip作为层，并添加到您的函数中。

选项3：将LLRT打包到容器镜像中

参见我们的AWS SAM示例或：

FROM --platform=arm64 busybox
WORKDIR /var/task/
COPY app.mjs ./
ADD https://github.com/awslabs/llrt/releases/latest/download/llrt-container-arm64 /usr/bin/llrt
RUN chmod +x /usr/bin/llrt

ENV LAMBDA_HANDLER "app.handler"

CMD [ "llrt" ]

选项4：AWS SAM

以下示例项目设置了一个包含llrt运行时层的lambda函数。

选项5：AWS CDK

您可以使用cdk-lambda-llrt构造库通过AWS CDK部署LLRT Lambda函数。

import { LlrtFunction } from "cdk-lambda-llrt";

const handler = new LlrtFunction(this, "Handler", {
  entry: "lambda/index.ts",
});

有关更多详情，请参阅Construct Hub和其示例。

就是这样 🎉

[!重要] 尽管LLRT支持ES2023，但它不是Node.js的直接替代品。请参阅兼容性矩阵和API了解更多详情。所有依赖项都应该为browser平台打包，并将包含的@aws-sdk包标记为外部依赖。

测试和确保兼容性

确保您的代码与LLRT兼容的最佳方法是编写测试并使用内置的测试运行器执行它们。测试运行器目前支持Jest/Chai断言。您可以创建两种主要类型的测试：

单元测试

用于独立验证特定模块和函数
允许集中测试单个组件

端到端（E2E）测试

验证与AWS SDK的整体兼容性和WinterCG合规性
测试所有组件之间的集成
确认从最终用户角度的预期行为

有关E2E测试的更多信息及如何运行它们，请参见此处。

测试运行器

测试运行器使用轻量级的Jest风格API，并支持Jest/Chai断言。有关如何为LLRT实现测试的示例，请参见本仓库的/tests文件夹。

要运行测试，请执行llrt test命令。LLRT会扫描当前目录及子目录中以*.test.js或*.test.mjs结尾的文件。您也可以使用llrt test -d <directory>选项指定要扫描的特定测试目录。

测试运行器还支持过滤器。使用过滤器非常简单，只需添加额外的命令行参数，例如：llrt test crypto将只运行文件名包含crypto的测试。

兼容性矩阵

[!注意] LLRT仅支持Node.js API的一小部分。它不是Node.js的直接替代品，也永远不会是。以下是部分支持的API和模块的高级概述。更多详情请参阅API文档 | | Node.js | LLRT ⚠️ | | ------------- | ------- | ------- | | buffer | ✔︎ | ✔︎️ | | streams | ✔︎ | ✔︎* | | child_process | ✔︎ | ✔︎⏱ | | net:sockets | ✔︎ | ✔︎⏱ | | net:server | ✔︎ | ✔︎ | | tls | ✔︎ | ✘⏱ | | fetch | ✔︎ | ✔︎ | | http | ✔︎ | ✘⏱** | | https | ✔︎ | ✘⏱** | | fs/promises | ✔︎ | ✔︎ | | fs | ✔︎ | ✘⏱ | | path | ✔︎ | ✔︎ | | timers | ✔︎ | ✔︎ | | crypto | ✔︎ | ✔︎ | | process | ✔︎ | ✔︎ | | encoding | ✔︎ | ✔︎ | | console | ✔︎ | ✔︎ | | events | ✔︎ | ✔︎ | | zlib | ✔︎ | ✔︎ | | ESM | ✔︎ | ✔︎ | | CJS | ✔︎ | ✔︎ | | async/await | ✔︎ | ✔︎ | | Other modules | ✔︎ | ✘ |

⚠️ = LLRT 部分支持 ⏱ = 计划部分支持 * = 非原生 ** = 请使用 fetch 替代

在 LLRT 中使用 node_modules（依赖项）

由于 LLRT 旨在用于性能关键的应用程序，因此不建议在没有打包、压缩和树摇优化的情况下部署 node_modules。

LLRT 可以与任何您选择的打包工具一起使用。以下是一些流行打包工具的配置：

[!警告] LLRT 实现了与以下外部包在很大程度上兼容的原生模块。通过在打包工具的别名函数中实现以下转换，您的应用程序可能会更快，但我们建议您进行彻底测试，因为它们并非完全兼容。

Node.js	LLRT
fast-xml-parser	llrt:xml
uuid	llrt:uuid

ESBuild

esbuild index.js --platform=node --target=es2023 --format=esm --bundle --minify --external:@aws-sdk --external:@smithy

Rollup

import resolve from "@rollup/plugin-node-resolve";
import commonjs from "@rollup/plugin-commonjs";
import terser from "@rollup/plugin-terser";

export default {
  input: "index.js",
  output: {
    file: "dist/bundle.js",
    format: "esm",
    sourcemap: true,
    target: "es2023",
  },
  plugins: [resolve(), commonjs(), terser()],
  external: ["@aws-sdk", "@smithy"],
};

Webpack

import TerserPlugin from "terser-webpack-plugin";
import nodeExternals from "webpack-node-externals";

export default {
  entry: "./index.js",
  output: {
    path: "dist",
    filename: "bundle.js",
    libraryTarget: "module",
  },
  target: "web",
  mode: "production",
  resolve: {
    extensions: [".js"],
  },
  externals: [nodeExternals(), "@aws-sdk", "@smithy"],
  optimization: {
    minimize: true,
    minimizer: [
      new TerserPlugin({
        terserOptions: {
          ecma: 2023,
        },
      }),
    ],
  },
};

在 LLRT 中使用 AWS SDK (v3)

LLRT 在运行时中包含了许多 AWS SDK 客户端和工具，它们已内置到可执行文件中。这些 SDK 客户端经过专门优化，以提供最佳性能，同时不影响兼容性。LLRT 用原生实现替换了 AWS SDK 使用的一些 JavaScript 依赖项，如哈希计算和 XML 解析。下面列表中未包含的 V3 SDK 包需要与您的源代码一起打包。有关如何使用未包含的 SDK 的示例，请参阅此示例构建脚本 (buildExternalSdkFunction)

已打包的 AWS SDK 包
@aws-sdk/client-cloudwatch-events
@aws-sdk/client-cloudwatch-logs
@aws-sdk/client-cognito-identity
@aws-sdk/client-cognito-identity-provider
@aws-sdk/client-dynamodb
@aws-sdk/client-eventbridge
@aws-sdk/client-kms
@aws-sdk/client-lambda
@aws-sdk/client-s3
@aws-sdk/client-secrets-manager
@aws-sdk/client-ses
@aws-sdk/client-sfn
@aws-sdk/client-sns
@aws-sdk/client-sqs
@aws-sdk/client-ssm
@aws-sdk/client-sts
@aws-sdk/client-xray
@aws-sdk/credential-providers
@aws-sdk/lib-dynamodb
@aws-sdk/lib-storage
@aws-sdk/s3-presigned-post
@aws-sdk/s3-request-presigner
@aws-sdk/util-dynamodb
@aws-sdk/util-user-agent-browser
@smithy
@aws-crypto

[!重要] LLRT 目前不支持从 SDK 响应中返回流。请使用 response.Body.transformToString(); 或 response.Body.transformToByteArray();，如下所示。
const response = await client.send(command);
// 或 'transformToByteArray()'
const str = await response.Body.transformToString();

在 LLRT 中运行 TypeScript

使用 TypeScript 时适用与依赖项相同的原则。TypeScript 必须打包并转译为 ES2023 JavaScript。

[!注意] LLRT 不会支持在不进行转译的情况下运行 TypeScript。这是出于性能考虑而设计的。转译需要 CPU 和内存，这会在执行过程中增加延迟和成本。如果在部署期间提前完成，就可以避免这种情况。

理由

鉴于现有的选项如 Node.js、Bun 和 Deno，是什么原因证明引入另一个 JavaScript 运行时是合理的？ Node.js、Bun和Deno是性能卓越的JavaScript运行时。然而，它们设计初衷是用于通用应用场景。这些运行时并非专门为短暂运行实例的Serverless环境需求而定制。它们都依赖于即时编译器(JIT)在执行过程中进行动态代码编译和优化。尽管JIT编译提供了显著的长期性能优势，但它也带来了计算和内存开销。

相比之下，LLRT的独特之处在于不包含JIT编译器，这一策略性决定带来了两个重要优势：

A) JIT编译是一项非常复杂的技术组件，增加了系统复杂性，并显著增加了运行时的整体大小。

B) 没有JIT开销，LLRT可以节省CPU和内存资源，这些资源可以更有效地分配给代码执行任务，从而缩短应用启动时间。

局限性

在许多情况下，LLRT相比支持JIT的运行时表现出明显的性能劣势，比如大规模数据处理、蒙特卡洛模拟或执行数十万乃至数百万次迭代的任务。LLRT最适用于较小的Serverless函数，专注于数据转换、实时处理、AWS服务集成、授权、验证等任务。它旨在补充现有组件，而非全面替代一切。值得注意的是，由于其支持的API基于Node.js规范，切换回其他解决方案只需进行最小的代码调整。

从源码构建

克隆代码并进入目录

git clone git@github.com:awslabs/llrt.git --recursive
cd llrt

如果您没有使用--recursive克隆仓库，请安装git子模块

git submodule update --init

安装rust

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | bash -s -- -y
source "$HOME/.cargo/env"

安装依赖

# MacOS
brew install zig make cmake zstd node corepack

# Ubuntu
sudo apt -y install make zstd
sudo snap install zig --classic --beta

# Windows WSL2
sudo apt -y install cmake g++ gcc make zip zstd
sudo snap install zig --classic --beta

# Windows WSL2 (如果尚未安装Node.js)
sudo curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/master/install.sh | bash
nvm install --lts

安装Node.js包

corepack enable
yarn

生成库并设置rust目标和工具链

make stdlib && make libs

[!注意] 如果这些命令退出时报错"can't cd to zstd/lib"，说明您没有递归克隆此仓库。运行git submodule update --init下载子模块，然后重新运行上述命令。

为Lambda构建发布版本

make release-arm64
# 或者对于x86-64，使用
make release-x64

可选地为您的本地机器（Mac或Linux）构建

make release

现在您应该得到了llrt-lambda-arm64.zip或llrt-lambda-x64.zip。您可以手动上传这个文件作为Lambda层，或通过基础设施即代码管道使用它。

运行Lambda模拟器

请注意，要运行示例，您需要：

通过~/.aws/credentials或环境变量提供有效的AWS凭证。

export AWS_ACCESS_KEY_ID=XXX
export AWS_SECRET_ACCESS_KEY=YYY
export AWS_REGION=us-east-1

在us-east-1区域有一个DynamoDB表（以id作为分区键）
对该表有dynamodb:PutItem IAM权限。您可以使用这个策略（别忘了修改<YOUR_ACCOUNT_ID>）：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "putItem",
      "Effect": "Allow",
      "Action": "dynamodb:PutItem",
      "Resource": "arn:aws:dynamodb:us-east-1:<YOUR_ACCOUNT_ID>:table/quickjs-table"
    }
  ]
}

在单独的终端中启动lambda-server.js