nodejs的优点

nodejs主要用于搭建高性能的web服务器，优点如下:

可以解决高并发，它是单线程，当访问量很多时，将访问者分配到不同的内存中，不同的内存区做不同的事，以快速解决这个线程。就像医院的分科室看病人。效率快，但消耗内存大、异步和事件驱动。概扩起来就三点：单线程、异步I/O、事件驱动。nodejs离不开ChormeV8引擎，也就是V8引擎是来解释javascript。用nodejs来搭建高性能的Web服务器，因此node.js是基于服务器端的javascript。

node主要应用场景是在大前端，阿里的思路是比较合适的，但是必须要注意，绝对不能让node做太多的业务逻辑，他只适合接受人家生成好的数据，然后或渲染后，或直接发送到客户端。如果让node做复杂的业务逻辑，那会得不偿失的。这个阿里的人可以来说明一下，你们node主要应用的场景是不是都是比较简单的逻辑。

回调模式下的异步是有明显缺陷的，程序的执行顺序必须依靠回调来保证，没有层层回调，就没有可以保障的逻辑顺序，这也就注定了，node不能做复杂的业务逻辑。javascript语言本身也一直在和回调做斗争，promise，generator都可以将回调包装起来，在代码的某个部分形成形式同步，但是这种模式进化的还不完全，还不能做到与回调完全割裂，做到完全的形式同步。但是形式同步肯定是发展的方向，这种模式即可以获得异步的好处，又可以有效回避回调带来的编程困难，在业务逻辑上可以更简单的表达。

就现在的环境来说，大家的思路还没转过弯，对回调的批评认为都是不好的，这些人是不敢面对现实，javascript都在变，这些人的脑子却不肯变，还以为回调就代表异步。

天猫这么干，主要出发点可能还在于让前端工程师使用最擅长的javascript负责“全栈”javascript工作来提高团队整体工作效率。至于后端接口，可能都是一些java写的已经稳定的功能，谁也不可能决策再用Node.js去全部改造，因此在Node和java间才有了那一层接口层。这样，用Node.js去实现一层完全配置化的适配HTTP/SOAP/…协议的具有缓存策略的接口路由，再通过配置或少量代码实现接口调用聚合即可完成功能，这些工作前端工程师就能干了，完全不需要后端参与。前后端的交互就在”接口文档”，不需要会议、语言、IM来沟通。

Node.js的业务逻辑应用，阿里的淘宝还是天猫里的收藏功能拒说已经在试水，这次改动应该也是一次大的变动，否则也不会把好好的java改成Node.js。如果阿里得出Node.js在性能和开发效率上超过java、在稳定性上不输java之后，会不会有更多的业务逻辑使用Node.js去实现，这些可能会取决于前后端团队的工作负荷。

Node.js的发展给javascript注入了新的生命力，试想一下，如果你是老板，你是愿意雇佣一个javascript全栈工程师搞定全部前后端工作开他30K，天天让他加班成狗；还是愿意雇佣两个工程师，每人开20K，让他们俩天天有空坐下来撸两把？

至于javascript的垢病，个人感觉，不在它的callback而在它的随意性，随意到想怎么写都行，但正是这点给它带来了惊人的开发效率，做好代码规范和文档工作可以减少javascript的随意性带来的负面影响。

WEB端、移动端、桌面端、甚至嵌入式，javascript已经无处不在。接下来，ES6的实现会让众多习惯同步或者不喜欢回调的开发人员能够更快地上手javascript写出符合他们思维习惯的代码，这些开发人员会是更大的群体，那么也许javascript会横扫应用开发也不一定。

所以，javascript很有前途，那Node.js自然就有前途。

但是，必须清楚的看到node的好是相对PHP，java的同步代码而言的，是相对的好。node主体采用单线程回调异步模式，部分采用了线程池，文件系统，dns.lookup（）都是采用了线程池实现的。在关键的网络通信上，node是异步的，所以在通信效率上，node就相对比同步代码效率好。java也有异步接口，但是java不像javascript这样回调函数可以比较简单自然的实现，c也可以，c也存在同样的问题。node这种模式曾经是比较先进的。

node跟nginx比在某些方面又相对不好， 尤其在静态文件处理上，node用的是线程池模拟的异步，nginx则针对不同的文件类型提供了不同的策略，对大量的小文件，直接使用同步的系统调用sendfile，对大文件，使用AIO。而nginx也有自己不擅长的，处理动态的没有node方便，虽然有openresty，但从实际使用中来看，还是没有node方便。

曾经相对先进的回调模式下的异步现在也遇到了挑战者，那就是协程（coroutine），或者叫纤程（fiber），不管叫什么名字，他们本质上都是在用户空间模拟线程，这种线程是非常轻量的，调度完全由用户自己控制（或者用户不直接控制，而是由用户态程序控制）。这种模式有两大好处，一是避免了原生线程的大消耗，原生线程在一定程序上也能实现并行，也能实现异步，但他们的好处很快被线程的切换吞噬掉了。用户空间模拟的线程切换消耗就小得多。fibjs用的是自己实现的ucontext，lua用的是longjmp。解决了切换消耗，接下来就是锁，用户空间模拟的线程本质上是单线程的函数调用，只不过这种函数调用是可控的，没有了锁开销，性能上自然又获得了不少提升。即便是node使用的锁非常轻量，性能如果想再进一步，这也是实实在在的性能杀手。当然这不是node的问题，所有只要涉及多线程的，包括协程，都会面对这个问题。

协程相对原生的线程有很多好处，相对于回调有什么好处呢？首先，他们在异步编程领域的使命是一致的，那就是保证异步编程的执行顺序，回调山大家都不陌生，为什么会出现回调山呢？回调山就是保证异步过程是按照我们所设想的步骤去执行，在需要并行的地方，我可以将异步请求一股脑儿的都发出去，这个时候我对返回的顺序没有要求。在需要顺序执行的地方，我们则需要用一层套一层的回调来保证执行顺序。回调模式下的异步避免了多线程条件下，锁的竞争问题，编程模型跟多线程锁相比简化了，在思维上可以说更接近了人类思维模式。但是回调模式跟协程相比还是存在缺陷的，协程可以通过适当的处理，模拟出同步代码的效果，但本质上还是异步的，fibjs，openresty的代码都实现了这个效果。回调不行，回调是有传染性的，要获得异步的好处，所有异步代码必须全部用回调，某段逻辑上如果存在大量的异步过程，就需要大量的回调来应对，如果正好回调内部关联比较强烈，无法将回调拆分，那么写出的代码将是又长又难调试的，大家回想一下，自己是不是碰到过某些比较复杂的代码，是自己写的，过了一段时间后自己回过头来看，几乎都看不明白了，但是谢天谢地，那段代码还能运行，但是就不知道什么时候会出问题，这种担心大家有没有？有的话，那是正常的。javascript为了应对这个问题，加入了一些类似协程的东西，generator，async/await这些东西都发展的方向。现在的node还在发育，还远没到成熟的阶段，node的发展还是要看javascript的发展，现阶段promise和generator还是太麻烦，回调模式朝形式同步的进化路上还是有坑，这些问题我们都必须要面对，javascript与lua等天生具备协程能力的语言相比，在这场竞赛中谁能出头，最关键的是看javascript能不能迅速的顺应潮流，迅速的协程化，javascript已经在改变，就是步子太过婉约，他必须兼容过去的大量回调代码，但也必须要解决形式同步的问题。说这是生死问题，一点也不夸张，程序员会用脚投票，回调山真不是必须的。

原文博客的链接地址：https://cnblogs.com/qzf/