将c++作为nodejs addon放到javascript中运行

非常高兴的一件事，我用周末两天完成了chatglm模型的移植，发布了chatglmjs这个包，前端的同学可以在本地运行一个自己的大语言模型了，不必一定要连openai的接口才能体验大模型开发了，只需要安装一个npm包即可立即体验大模型带来的快乐。这篇文章我不会介绍移植完整过程，而是基于这个场景，聊一聊nodejs跑c++的方法，因为我就是用这一方法实现的移植。而在这个过程中，我自己也补充了很多知识，自己上手完成移植之后，很多以前停留在“我知道”层面的技能，变成了“我会”的技能。

阅读本文，我会假设你对c++的开发有一定的了解。如果不了解也没关系，只要有一定的编程基础，临时抱佛脚也不是不行，边操作边学习，起码我就是这样做的。但假使你有c++的开发经验，那么就可以做到无缝掌握，这对当下时代的前端开发者来说，也是一种能力层面的要求。

方案选择

我为什么最终选择了nodejs addon的方案来进行移植呢？我先讲一下为什么要做移植工作。我最近在学习langchain，而langchain需要依赖一个LLM，因此，我不得不自己有一个。在所有开源大模型中，我选定了ChatGLM，因为它对中文友好，而且在众多大模型中，硬件要求是比较低的，量化版在将来可能在手机端有比较大的发展潜力。ChatGPT？对不起，你把门给我关上了，我也暂时不想打开，支持国产大模型，让我们中国的东西也被世人认可。在免费、开源、本地部署的折腾主义思想指导下，我尝试了chatglm的几种部署方式，想到了几种方案，分别如下：

	cpu/gpu	跨平台	优点	缺点
使用python版本先在本地起http服务，再通过远程调用方式从接口拿到预测结果		服务起来之后，应用开发无所为跨平台	python版功能齐全 fastapi起服务方便把LLM服务独立开，可通过升级机器来提升性能	python的部署环境处理麻烦通过网络通信，性能欠佳
使用chatglm.cpp，利用python起http服务		同上	c++性能稍高	在python服务的基础上又多一层，部署更麻烦
使用chatglm.cpp的可执行文件运行模型，再通过子进程运行可执行文件再stdout中获得结果		需要在不同平台编译自己的可执行文件	脱离python，不用考虑环境问题了	通过std来实现交互，性能难说本地运行，对机器要求高
使用chatglm.cpp的cpp源码编译为nodejs addon，作为nodejs的包来运行		通过gyp或cmake可实现跨平台自动编译，用户无感	通过npm装一个包即可，简单便捷

发布一个npm包，提供给nodejs使用，一方面是获得简单，不用考虑部署、环境安装等问题，另一方面是对前端友好，基于核心能力可以让前端开发者无线发挥自己的想象。

Node Addon介绍

简单讲，Node Addon是用c/c++来为nodejs应用开发功能的方案。具体怎么做到的呢？我们都知道，可以讲c++编译为一个动态库，作为其他c++程序的一个外挂，让其他c++程序调用本库的能力。node addon就是一个c++编译出来的动态库文件，我门在require('xxx.node')时，本质上就是在require一个c++动态库，只不过node有一套自己的load动态库的实现。与此同时，这个动态库里面，需要调用Napi（也就是node作为c++源码的第三方库提供的接口）来向node的运行时提供能力。这些能力除了nodejs本身作为c++程序所暴露的接口外，还包含了它的底层驱动v8的接口。

基于node的该机制，我们可以将以前运行在服务端的c++模块直接拿过来用，并且以c++作为中介，去连接其他生态。除了c/c++的addon机制，node还可以运行wasm，这样还可以把其他可以编译到wasm的其他语言的程序也拿到node中使用。而且由于作为c++的动态库，它在性能上还比基于v8运行的js的性能还要高很多。因此，一些需要进行高性能密集计算的程序，使用c++来实现拿到node中使用，是非常不错的选择。另外还有一个原因是，js如果想要和原生系统通信，必须通过v8，而v8不一定提供了对应的平台接口，例如调用系统层面的通知消息，面对这种情况，我门还不得不用c/c++来操作系统，然后再向js层提供接口。这就和用react native进行手机应用开发一样，遇到需要操作系统层面的功能时，不得不找android开发的同学来帮忙。

如何创建自己的Node Addon？

既然node addon有自己的应用场景，那么我门怎么才能创建自己的node addon呢？接下来，我就会从一个小白用户的角度出发去简单介绍一下，毕竟我自己也是一个小白，因此，能切身体会到小白对node addon的畏惧感。

修改c++源码

nodejs无法直接使用原生的c++动态库，即使完成了链接，c++的能力也没有暴露给node，因此，我们需要对c++源码进行修改或封装。封装就是在不修改原始c++代码的基础上，包装出可以被node利用的c++源码。

node-addon-api

本质上，node作为c++程序，可以让动态库调用自身的一些功能。而node-addon-api就是让我们自有的c++调用nodejs的内置功能的中间库，利用node-addon-api，就可以让我们在修改或封装c++源码时，在c++代码中调用node接口，通过这些接口，把自有的功能，注册到node中。

假如我们有如下c++代码：

#include <math.h>

namespace higher_calc {
  int sedout(int a, int b) {
    return math::sqr(a, b, 0.5);
  }
}

现在，我们希望在nodejs中如下使用：

const { sedout } = require('./build/Release/higher_calc.node');
const out = sedout(12, 5);

对于原始的c++代码而言，没有经过任何处理，完成编译之后，是一个纯粹的c++库，无法被node加载和使用。那么怎么才能让node使用呢？我们创建一个新的c++文件

#include <higher_calc.h>
#include <napi.h>

Napi::Value Enter(const Napi::CallbackInfo &info)
{
    Napi::Env env = info.Env();
    Napi::Number a = info[0].As<Napi::Number>();
    Napi::Number b = info[1].As<Napi::Number>();

    return higher_calc::sedout(a, b);
}

Napi::Object Init(Napi::Env env, Napi::Object exports)
{
    exports.Set(Napi::String::New(env, "sedout"), Napi::Function::New(env, Enter));
    return exports;
}

NODE_API_MODULE(NODE_GYP_MODULE_NAME, Init);

上面有4段代码，第1段是头文件include，第2段是对higher_calc::sedout进行封装，第3段是Init（在exports上提供sedout），第4段是注入Init。

在上面代码中，我门通过include napi.h来引入node-addon-api库（在编译时通过编译工具链接），该库以Napi::作为命名空间，里面提供了非常丰富的接口，可在这里查看。NODE_API_MODULE表示向node运行时注入模块，模块名通过NODE_GYP_MODULE_NAME动态生成，其实也可以手动填写。Init函数作为NODE_GYP_MODULE_NAME的参数，接收环境信息env和接口对象exports。在Init中，通过exports.Set让模块向外导出接口sedout，这就是为什么我门可以通过 const { sedout } = require('xxx.node') 使用该接口的原因。该接口的实现由Enter函数完成，在Enter函数中，我门接收了一个Napi::CallbackInfo，它提供了在node运行时接口调用的上下文信息，info[0]和info[1]分别是js代码中sedout(12, 5)的第1个和第2个实际参数。如此一来，你就可以走通整个逻辑了。至于Napi::Env env，其实我也不知道它的实际内容，但可以肯定它和运行时有关。在c++中，如何使用由运行时传入的值，甚至是函数，都可以在napi仓库中找到例子，如果你的c++程序相对复杂，要用到比较多的接口，就必须得去了解一下它。

其他方式

使用node-addon-api时，必须通过npm安装它，它是一个第三方库。

npm i node-addon-api

此外，node自己本身原生提供了c/c++的接口，可以通过官方文档了解，但由于原生接口比较底层，使用起来相对麻烦一些，因此我门大部分情况下都是使用封装好的node-addon-api作为依赖。

编译c++库

前文已经提到了，addon本质上就是一个c/c++动态库，因此，我门需要编译获得链接好的.node库文件（理论上不是.node作为文件后缀也是可以的）。此时编译我门不能直接使用gcc/g++，我们需要提供node的环境，因为在c++代码中，我门使用了node提供的接口。

node-gyp

node提供了node-gyp这个工具，可以作为编译工具，当然，它本身也是要依赖gcc/g++或者windows的vs或macOS的xcode，但是它在这些原始的编译工具基础上进行了再次封装，只要用node-gyp进行编译，就可以让c++代码中调用了node底层接口的地方可以被正确链接。

为了使用node-gyp进行编译，我门需要提供一个binding.gyp文件，里面提供编译的细节。如果我门对c/c++的编译逻辑比较了解，那么就可以很容易理解node-gyp的配置思路，如果不是很了解也没关系，读完文档生搬硬套也是可以的。添加完binding.gyp文件之后，在package.json中，增加 "gypfile": true ，就可以在安装依赖时，自动调用node-gyp（最好全局安装）进行编译。

cmake-js

除了gyp流派，cmake是另外一个流派，而cmake-js就是和node-gyp同层面的东西，只不过是非nodejs官方出品。cmake-js借助cmake的能力，同时封装了node作为基座环境，也可以把node的接口调用编译到动态库中去。之所以推荐cmake-js是因为它可以用c++程序员比较熟悉的CMakeLists.txt作为编译细节提供文件，此时，它的binding.gyp是同层面的东西。使用cmake，可以非常轻松的处理存在add_subdirectory的情况，也就是模块嵌套的情况，而如果使用gyp，就不得不自己想办法把所有文件找出来。此时，在CMakeLists.txt内部，我门还需要一些特殊的处理：

target_link_libraries(mylib PRIVATE ${CMAKE_JS_LIB})
set_target_properties(mylib PROPERTIES PREFIX "" SUFFIX ".node")

# Include Node-API wrappers
execute_process(COMMAND node -p "require('node-addon-api').include"
        WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
        OUTPUT_VARIABLE NODE_ADDON_API_DIR
        )
string(REGEX REPLACE "[\r\n\"]" "" NODE_ADDON_API_DIR ${NODE_ADDON_API_DIR})
target_include_directories(mylib PRIVATE ${NODE_ADDON_API_DIR} ${CMAKE_JS_INC})

# define NAPI_VERSION
add_definitions(-DNAPI_VERSION=3)

上面的代码主要是解决依赖问题，也就是说，编译除了原本的c++文件，还需要加入一些其他文件，类似CMAKE_JS_LIB, NODE_ADDON_API_DIR等。

另外，想要让cmake-js自动运行，我们需要在scripts中加入 "postinstall": "cmake-js rebuild"，这样每次npm install之后，都会自动编译出.node文件。

封装Addon

来到js层面，我们通过编译后，得到.node文件，此时我们可以require它。但是我们最好使用一种动态搜索的能力来加载addon，我门可以使用bindings这个库。我们封装Addon的目的是在js层面屏蔽addon，让终端的开发者感觉跟用常见的npm包一样使用这个addon。

const mylib = require('bindings')('mylib');

function sedout(a, b) {
  return mylib.sedout(a, b);
}

module.exports = { sedout };

通过封装之后，外部用户就像用一个普通js一样使用这个由c++写的模块啦。

结语

本文较为粗浅的介绍了在nodejs中使用c++程序。通过node addon，我们一方面是可以复用以前写好的c/c++模块，避免多次实现带来的问题，另一方面，我们可以让js社区可以品尝到c/c++生态中的一些不错的新事物。由于本文没有用真实的代码来详解，只把这件事讲了个入门，如果读者朋友希望能有一个案例来了解，可以阅读 https://github.com/tangshuang/chatglmjs 的源码来了解我是怎么把chatglm带入js社区的。如果你有什么疑问，可以在本文下方留言一起讨论。

2024-01-07 1210

唐霜的博客