Javascript

【Node.js】一篇文章带你彻底理解Node.js及其特性

本文主要是介绍【Node.js】一篇文章带你彻底理解Node.js及其特性,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

什么是Node.js

简单的说,Node.js就是运行在服务端的JavaScript,它打破了JavaScript只能在浏览器运行的局面,并且让JavaScript的生态建设走向正轨。

Node.js最初的开发者,是想要写一个基于事件驱动的、非阻塞I/O的Web服务器,提供ApacheTomcat之外的选择。其实,我们完全将Node.js看作是一个极其轻量的Web服务器

Node.js不是开发者无中生有得来的,当我们把Chrome和Node的架构图摆在一起时,不难发现它们有着惊人的相似之处——尤其是那个无比卓越的执行引擎,V8。

 
 

特点特性

1)异步I/O

并发已经是编程的标配,因为串行执行的效率实在太低。但我们知道,JavaScript是单线程的。

这是JS的用途决定的:交互,就是操作DOM。如果是多线程的,那么难免会出现一个线程还在操作DOM,而另一个线程却删掉DOM的危险情况。

Node在两者之间给出了它的方案:利用单线程,远离线程死锁、状态同步等问题;利用异步I/O,解决单线程阻塞的问题,提升性能。

2)事件驱动

事件的编程方式具有轻量级、松耦合、只关注事务点等优势,但是在多个异步任务的场景下,事件与事件之间各自独立,如何协作是一个问题。

3)回调函数

纵观下来,回调函数也是最好的接受异步调用返回数据的方式。

但是这种编程方式对于很多习惯同步思路编程的人来说,也许是十分不习惯的。代码的编写顺序与执行顺序并无关系,这对他们可能造成阅读上的障碍。在流程控制方面,因为穿插了异步方法和回调函数,与常规的同步方式相比,变得不那么一目了然了。

异步I/O、事件驱动、回调函数,这些不都是JavaScript的特性吗?
没错,Node.js没有改变语言本身的任何特性,且依旧基于作用域和原型链,区别在于它将前端中广泛运用的思想,迁移到了服务器端而已。
因此,这部分的内容完全可以结合JavaScript本身的【执行栈-任务队列–事件循环机制】进行理解。

 
 

应用场景

在技术选型时,什么技术适合什么场景十分重要。下面,对于Node.js,我们探讨一下它在I/O密集型和CPU密集型两种场景的表现。

I/O密集型

如果把所有的脚本语言叫到一起,并预设单线程的前提条件,那么Node处理I/O的能力绝对会脱颖而出。我们通常这么说:Node擅长I/O密集型的应用场景。

这是因为Node利用了loop循环和事件驱动。而不是为每一个请求开启一个线程,一直占用着。

CPU密集型

Node足以胜任有大量计算需求的CPU密集型场景。为什么呢?还是因为那至今仍变态的V8执行引擎。单单从计算的执行效率上看,Node表现非常不错。

但问题在于,JavaScript是单线程的。对于一些大型的计算,会占用大量的时间片,阻塞了后续的I/O任务的发起。通俗地说,一个长度为10的线程(前9个是计算任务,后1个是I/O任务),前9个计算任务完成了,才轮到最后1个I/O任务,这就导致这个I/O任务的响应时间特别长。

如何解决?如果JavaScript是多线程的,那么我们把计算任务和I/O任务放到两个线程上就好了,通过CPU调度,I/O也能相对公平的上CPU,但我们无法这么做。其实,我们还可以把这个大的计算任务,分解为多个小计算任务,从而在可接受时间内完成计算并释放CPU。

 
 

彻底理解Node.js

下面的内容原创于国外的一篇文章(文末附网址),把node.js、非阻塞、事件驱动、长轮询等概念用人话讲了出来,循序渐进、通俗易懂。网上有已有翻译版本,我对其进行了更加简略的翻译,希望能让大家读的更加明明白白。

你一定不止一次听说过Node.js,你或许会问:“What is it?”。

有些人会告诉你,这是一种用JavaScript语言写服务端的方式。如果你没有被这种晦涩的解释吓走,或许会接着问:为什么要使用它?他们又会这样回答:Node.js的优点是非阻塞(non-blockin)、事件驱动(event-driven)、长轮询(long polling)

这时你可能已经放弃,闭嘴不问了。这不怪你,这篇文章就是要避开这些术语,通俗来向你解释这一切。

B/S模型没怎么变过——用户从浏览器发出请求,服务器收到请求后,开始去找对应的资源;如果有需要,还会去查一下数据库;最后,把响应结果传回浏览器。在传统的web服务器中(比如ApacheTomcat),每一个HTTP请求都会让服务器创建一个新的线程。

随着Ajax技术的兴起,用户与服务器之间的长轮询技术出现了。我们知道,普通的请求就是浏览器发出一次、服务器响应一次就结束了——这不是一个连续的过程,但我们可以通过小技巧来模拟出一个看似连续的状态,就像上面那种时刻保持的连接一样。具体的实现是,就算现在无事可做,你依旧要发给服务器一个Ajax请求。这个Ajax请求不同与一般的请求,它并不要求服务器立即做出响应,而是可以hold住,等到服务器想要响应了再响应。当服务器给出的响应返回后,你在此发送一个这样的Ajax请求,如此反复。这样,就用一个个不连续Ajax请求,模拟出了持续连接的状态——这就是长轮询

我们想象这样一个需求。你建立了一个类似微信朋友圈功能的社交网站,你的朋友们会把新鲜事分享出来,这时你的朋友圈界面要实时刷新这些新鲜事。要达成这个需求,需要让用户一直与服务器保持一个有效的连接。如果是传统的ApacheTomcat服务器,一个用户就要占用这样一个进程,那你的服务器早就爆炸了。

如何解决这种场景?非阻塞事件驱动。你可以把非阻塞的服务器想象成一个Loop环,这个Loop环会一直跑下去。当有一个事件发生,触发了一个请求,Loop环接受了这个请求并从环主体上脱离出一个回调(callback)来处理这个请求,Loop环依旧在跑。如果更严谨的说,回调函数的第一阶段会占用环的时间(去查数据库的动作),但回调函数的第二阶段已经与环脱离(回调函数自己会等待数据库查询结果,并将其作为响应返回)。

上面这两段话可以看图理解。在这里插入图片描述

像Tornado框架、nginx服务器都是按上面的原理工作的,但Node.js就更妙了——Node.js将JavaScript作为实现语言,而JavaScript本身就天天在搞回调、本身就是事件驱动的脚本语言。用事件驱动的语言去搭建事件驱动的服务器端,用四个字可以形容:天作之合

 

—— —— 翻译自https://www.sitepoint.com/node-js-is-the-new-black,有删减和改编

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

JS Saikou!!!

这篇关于【Node.js】一篇文章带你彻底理解Node.js及其特性的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!