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/