【译文】NginScript – 为什么我们要实现自己的JS引擎？

在上周的nginx.conf 2015用户大会上，我们发布了全新的JavaScript引擎nginscript的预览版。历史上，JavaScript语言已经应用在许多方面，首先是作为客户端脚本，然后又被用于服务器后台开发。至于nginscript，我们要介绍的是第一种"代理端"的使用情况，用于满足我们在会上提出的一系列独特的要求。消息公布后，许多人对我们决定要实现一个新的JavaScript引擎，而不是使用V8，SpiderMonkey，或其他的已有引擎而感到好奇，所以这篇文章用于解释我们为什么这么做。

我们正在做什么？
我们正在编写自己的JavaScript引擎，称为nginscript。nginscript目前支持解析器ECMAScript 5的一个子集（我们将在未来进行扩展），采用基于寄存器的虚拟机（VM），运行时将把代码编译成字节码，同时支持 nginx和nginx plus。在目前的预览阶段，nginx可以编译JavaScript代码并用在两个场景：产生nginx的配置，或者在nginx执行阶段生成内容。未来的版本将支持更多的使用场景。

为什么要创建自己的JavaScript运行时？
Nginx有一些特别的需求导致我们要去创造属于我们自己的引擎。为了扩展请求应的处理流程，我们需要nginx在处理一个请求时可以运行nginscript片段。我们不寻求创造一个后端JavaScript应用程序执行环境–因为Node.js已经做的很好。目前的JavaScript引擎被设计为运行在一个Web浏览器中，他们依靠垃圾收集器的管理内存。如果耗尽内存，JavaScript VM会异常退出；这种行为对于浏览器是可以容忍的。但是对于持有数千个连接的服务器却不行，总的来说，专门为浏览器设计的引擎不适合服务器，包括v8，SpiderMonkey它们没有供简单的方法来控制执行（即预防奔溃和恢复虚拟机的机制），同时支持JIT的能力有限。我们希望能有一种引擎将nginscript的脚本简单并快速的执行。同时，由此产生的状态被保存在虚拟机外部。因为脚本简单，所以全面支持JavaScript语言没有必要。同时，nginx已经拥有非常精细的事件驱动架构，我们不想nginx的性能受到垃圾收器的影响。

相反，我们正在创建一个非常简单的引擎以满足我们的要求：
架构 – 使用单线程，字节码的执行部分将会非常快速。为每个请求分配虚拟机。因为没有复杂的状态需要初始化，这种简单的虚拟机可以快速启动，同时使用简单的缓存池管理内存。这种内存管理方案，无需跟踪和释放单个对象或使用垃圾回收器，可以大大提高性能。
辅助功能
–Nginx实现了许多内置操作。例如，复杂的数学运算，哈希函数，当nginscript与nginx结合时，这些操作也会是本地的。你可以使用nginscript以编程的方式来驱动nginx的本地方法。
和nginx配合
– nginx的事件驱动模型可以用于调度nginscript VMS的执行。当一个nginscript正在执行阻塞操作（如读取网络数据），nginx可以暂停该VM的执行，当该VM的事件完成后再恢复。这意味着你可以在编写一个简单的脚本， nginx会调度脚本不造成阻塞。最后，用我们自己的引擎，我们可以保证API统一，同时确保我们的VM和nginx支持的平台范围一致。

 

关于性能
现在谈论性能还过早，目前我们正在专注于功能的实现。nginscript编译为内部的字节码并且运行在一个基于寄存器的虚拟机；这种机制使得它和其他解释性语言（PHP，Ruby，等等）性能相当。所以为了提高性能，我们想在一些地方增加JIT编译，但这可能会限制支持的平台范围。nginscript只是被设计用来执行一些简单的内部脚本，我们不想让它来执行计算密集型操作，因为nginx内部基于C语言的模块已经解决这个问题。

未来
nginscript目前处于其发展的早期阶段，我们称当前版本是"预览"版。我们将重点放在核心语言的实现（如增加闭包），并实施许多内置的JavaScript对象（日期，数学，等等）。
我们还将重点放在如何整合资源，比如nginx的配置如何集成脚本，在哪些方面nginscript可以访问和控制nginx内部？如何在脚本之间共享数据，以及跨集群？用户如何调试nginscript脚本？
对于长时间运行的脚本（如WebSocket），我们甚至可以添加一个垃圾收集器，但那是在未来很久以后。
对于nginscript未来如何发展目前还没有定论。我们希望得到您的反馈。请在我们的邮件列表中分享您的想法和见解，我们将共同开发这个功能。谢谢你。