N-API编程之HelloWord

1     技术研究背景
公司产品考虑部署到kubernetes环境中，为了使产品具备云原生应用的一些特性和优点，整个系统需要重构。公司产品原有界面全部基于C/S架构设计，基于云原生的特点，界面逐步实行B/S重构，B/S重构必须选定一种web化技术路线。

1.1   产品特点因素
原有产品大部分使用C/C++语言开发，产品的大部分数据都在共享内存中。因此，总的思路使通过C++写扩展的JavaScript接口，实现对共享内存的读取，实现对数据的读取。并可以对已有的C++模块封装成JavaScript接口，实现模块的复用。

图1

如图1所示，在一个POD中，多个业务容器的数据都在共享内存中，部署了nodejs服务的容器通过读取共享内存中的数据对外提数据，从而实现界面的web化。

1.2   技术路线比较
产品的web化有常用的技术路线有使用java生态体系。图1中nodejs容器理论上可以选用java生态web服务器替换，c++的Java接口也可以使用JNI技术实现。之所以选择图1的技术路线，基于两个方面考虑。

1.2.1     web服务器比较
java体系常用的tomcat与nodejs常用的express都没有深入实践。java体系根据产品特点，需要每个POD部署一个tomcat服务或者其他未知的方案，如果是每个POD部署各个tomcat服务相对与nodejs太重。

相关资料介绍nodesjs是轻量级的，比较适合每个pod启动一个web服务。学习难易程度nodejs比java体系感觉要容易上手些，JavaScript前后端统一更节省了学习成本。

产品的特点界面都是一些实时数据的展示，简单的html页面即可，nodejs使用JavaScript作为开发语言，前后端数据传输会减少数据转换操作。另外，产品主要功能界面特点类似网络游戏页面，这些游戏后台服务nodejs居多，故web服务器倾向与使用nodejs。

1.2.2     JNI与N-API比较
JNI与N-API技术类似，都是进行语言级别的转换和调用。以前用JNI开发过一些模块，没有深入研究，主要是JAVA和C++类似，功能也差不多，JNI的需求场景实在不多，没有太深刻的理解，也不想深入研究。

N-API是随着nodejs而生发展的新技术，市面资料也不多。根据nodejs的实现原理，N-API看上去像是对nodejs原生的扩展，感觉做N-API开发比做JNI开发更有意义。

1.3   N-API知识体系
选用N-API作为产品开发技术之一，开始了解N—API开发需要的知识或者工具。

1.3.1     vscode
N-API开发需要同时使用C/C++和JavaScript，vscode是大多数人的选择，windows，linux平台都支持，比较方便。一些常用插件安装觉得不方便时Google下，我的环境安装了哪些，自己都记不清楚了。

1.3.2     nodejs
nodejs安装参看官网https://nodejs.org/zh-cn/download/，我安装的是V12.16.2，安装完成后使用node –v命令行查看安装是否成功。

在windows和linux平台下安装，windows下安装单纯是开发调试方便，最终服务器运行在linux平台下。下载对应的源代码，这里面有官方示例，学习起来方便些。

1.3.3     node-gyp
node-gyp官网是https://github.com/node