运行时
您正在查看 Deno DeployEA 的文档。 查找 Deploy Classic 的文档？点击这里查看。
:::
在 Deno DeployEA 中，所有应用程序都使用标准的 Deno 运行时在安全、隔离的 Linux 环境中执行。
Deno DeployEA 使用的 Deno 运行时是标准的 Deno 运行时，完全支持 Deno CLI 的所有功能，包括 JSR 和 NPM 依赖、读写文件系统、发起网络请求、生成子进程，以及加载 FFI 和 node 原生插件。
Deno 运行时以 --allow-all 权限运行。
无法向 Deno 运行时传递自定义标志。
运行时环境 Jump to heading
运行时环境是基于 Linux 的环境，运行在 x64 或 ARM64 架构上。运行时环境中可用的具体工具集可能会发生变化，因此无法依赖其稳定性。
目前 Deno DeployEA 运行在 Deno 2.4.0 上。
生命周期 Jump to heading
Deno DeployEA 在无服务器环境中运行应用程序。 这意味着应用程序并不总是运行，只有在收到请求时才会启动。当长时间未收到任何流量时，应用程序将被停止。
应用程序可以随时启动和停止。它们应该快速启动，以便无延迟地响应传入请求。
同一个应用程序的多个实例可以同时运行。例如，一个实例可能运行在美国，另一个在欧洲。每个实例彼此完全隔离，不共享 CPU、内存或磁盘资源。必要时同一地区也可以启动多个实例，比如处理高流量或基础设施更新。
启动 Jump to heading
当系统决定启动一个应用程序时，会为该应用程序预置一个新的沙箱环境。该环境与其他所有应用程序隔离。
然后使用配置的入口点启动应用程序，并等待 HTTP 服务器启动。如果应用程序在 HTTP 服务器启动之前崩溃，触发启动的请求将失败并返回 502 Bad Gateway 错误。
应用程序启动后，传入请求将被路由到该应用程序，并将响应发送回客户端。
关闭 Jump to heading
应用程序会保持运行状态，直到一段时间内没有接收到新的传入请求或未发送响应（包括响应体字节）。具体超时时间介于 5 秒至 10 分钟之间。积极传输数据的 WebSocket 连接（包括 ping/pong 帧）也会保持应用程序存活。
当系统决定停止应用程序时，会向应用程序发送 SIGINT 信号，作为关闭的触发。此后，应用程序有 5 秒的时间优雅关闭，否则将被强制以 SIGKILL 信号终止。
驱逐 Jump to heading
有时即使应用程序仍在接收流量，其 isolate 也可能被关闭。以下是一些可能的情况：
- 应用程序为了应对负载被扩展，但负载已减少回单实例可处理的水平。
- 执行该实例的底层服务器资源紧张，无法继续运行该应用实例。
- 底层基础设施正在更新或发生故障。
当系统决定驱逐一个应用程序时，会尽早尝试将流量从被驱逐的实例分流。有时这意味着请求会等待一个新实例启动，即便现有实例仍在运行。
当应用只处理快速完成的请求时，驱逐一般不易察觉。对于处理长时间请求或 WebSocket 的应用，驱逐可能更明显，因为可能需要在处理请求时驱逐应用。系统会尽力避免这种情况，但并不可避免。
在流量被重定向离开旧实例后，系统发送 SIGINT 信号触发优雅关闭。应用程序应快速完成剩余请求，并关闭 websockets 及其他长连接。发起长时间请求的客户端应准备好处理中断，并在断开时重新连接。
在发送 SIGINT 信号 5 秒后，如果旧实例尚未优雅关闭，将被强制以 SIGKILL 信号终止。
冷启动 Jump to heading
由于应用程序并非一直运行，收到请求时可能需要启动。这称为冷启动。Deno DeployEA 的冷启动经过高度优化，“Hello World” 应用可在 100 毫秒内启动，较大应用则在几百毫秒内启动完成。
Deno DeployEA 使用多项优化来实现快速冷启动：
-
沙箱和 Deno 运行时预先准备，确保启动应用时无需从零创建。
-
应用在客户端发送首个 TCP 包以建立 TLS 连接时立即启动。对于启动迅速的应用，依据网络往返延迟，应用可能在客户端发送 HTTP 请求之前已运行。
-
文件系统访问针对常用启动文件进行了优化。Deno DeployEA 在构建步骤的预热阶段分析文件访问模式，并优化文件系统以加快访问速度。
当冷启动缓慢时，会影响用户体验。为优化应用快速启动：
-
减少应用依赖。
-
使用动态
import()延迟加载不常访问的代码和依赖。 -
启动时尽量减少 I/O 操作，特别是顶层
await和网络请求。
如果您的应用启动缓慢，请联系 Deno 支持 获取帮助调查问题。