nodejs使用经验总结

Posted 2020-06-28

因为公司项目需要使用了一段时间的node，这是说明一下使用node的一些感受。

优点方面：
1.异步编程，单线程。异步编程使我们不用关心原先认为的阻塞事件，该怎么处理。因为在web开发中肯定会涉及到请求响应超时的问题。现在我们可以不用考虑这些问题直接交个javascript语言去处理。
2.json(JavaScript Object Notation)，JavaScript直接支持的json格式免了我们处理对象序列化，在与前端页面进行交互式根本不用考虑用什么格式进行传输，直接json就OK。
3.内置库，使用内置库可以比较方便的开发web应用，而且对JavaScript语言没有规定的涉及一些类型判断的地方可以直接用util简单解决。内置库的一个问题在于仅适用于web开发，这样对node在其他环境上的应用造成了很大程度的限制。

缺点方面：
1.异步编程引入了业界著名的回调黑洞，为了解决回调黑洞问题commonjs组织引入了promise。promise是一种比较不错的回调黑洞解决办法，而且还解决了代码需要顺序执行的问题。但是promise引入了更难以解决的问题，我将这个问题叫做promise上下文问题。具体过程为标准化需要顺序执行的功能函数，以隔离具体调用promise的细节方便，并方便规模化调用，这样可以方便更换promise实现。标准之后具体的函数定义三个参数，第一个参数表示函数参数，第二个参数表示promise的reslove回调，第三个参数表示promise的reject回调。这样就会造成功能函数的有效参数只有一个。只有一个参数的问题就造成参数的结构，参数结构中的数据必须符合当前。在使用多层的promise时就需要控制上下层关系，上层需要将那些数据写入到参数中，将那些删除都必须根据下层的功能函数所隐性规定的去做，如果不这样做就直接报错。导致整个promise执行过程就变成了一个超级大的执行上下文，这个上下文中的每一步不能从promise的基础上知道它要做那些东西，也不知道上层是否组织好了当前需要的上下文。导致调试5~6层的promise就比较难了，层数在增长那就是不可完成的难度了。所以，使用promise就以为这调试难度指数级上升，简单来说就是不要调试了换其他语言吧。
2.异步编程还有一个比较隐蔽的问题，据我所知在所有介绍node的文章，书籍中都不会告诉你的问题。就是单线程的node也会遇到同步与互斥问题。而且据我所知commonjs，ECMAScript都没有给出解决办法，不过我们可以实现自己的同步与互斥，但是使用了同步互斥之后，node的性能优势可以说就根本不存在了。具体过程，在一个流程中的promise正在执行某个动作，陷入了等待，node会调度另外的事件去处理，如果后调度的事件中处理了先前流程promise中所用的全局资源（数据库，memcache，全局变量等等）就会造成两个执行流同时操作同一块东西，这不就是临界区的概念了吗！所以，单线程的node会有互斥和同步问题。
3.类，这里不讨论JavaScript是不是一种面向对象的语言，这里只说JavaScript的类中的私有变量。JavaScript的类的私有变量应该怎么声明呢？只有一种方式利用闭包，也就是所有使用的私有变量的函数都必须在构造函数中，使用内部函数的方式来实现。只能说好奇怪啊。
4.深度copy，没有对象copy方法，必须自己写。node的库也没有提供方法，解决这个问题。所以，说对象copy根本办法。
5.没有一种方式的远程过程（方法）调用。如果要做复杂业务的话这样的东西是必须有的，但是这里不是原生支持的。只能使用外部库实现soap或者webservice来完成。
6.库。库的安装只支持在线安装，没有离线安装方式，使很多东西根本安装不了，比如说那几个绘图库，需要在线安装并且安装的时候还需要进行本地代码编译。本地代码编译也可以，但是能不能提供离线的方式进行本地代码编译。联网的机器编译不了在其他机器上就都编译不了，这样的设计不知道是怎么想出来的。
7.绘图库，再说一下绘图库，node的几个绘图库真的是都编译不过啊。要不就是依赖太多根本不知道依赖什么非node的开源代码，要不就是根本在win上不能编译。

总结：
所有的技术都有自己的适用的方面在很多node的介绍中都说NodeJS适合运用在高并发、I/O密集、少量业务逻辑的场景。举个例子网页缓存，CDN。网页缓存是在请求量过大是后端服务器无法短时间内响应重复的请求时，可以使用node做中间层。在node中做网页缓存，减少后台服务器的重复请求处理压力。适用于动态，静态形式的CDN服务。

参考：
http://blog.csdn.net/xiaemperor/article/details/38234979
http://www.ituring.com.cn/article/66566