这几天看见几位业内人士在批Node.js,我也谈一下自己的看法。我是坚持技术多元理念的人,就是从不过分鼓吹、贬低某项技术或相关体系,坚定认为,每项技术都应该用在合适的地方,不要老拿一把锤子包打天下。研发人员要善于学习,理解不同语言、技术的特色和适用场景,灵活选型。

Node.js

Node.js

去年我用Node.js为客户做过一个服务。因为做了技术选型后,认为它适合这个应用场景。我有10多年开发经验,常用的几个语言都能自如切换,第一次用它并没觉得Node.js有多难,但是仍然踩了一些坑。我觉得Node.js编程里面,最难的或者说痛苦的地方在于业务逻辑控制。如果你的服务有很多顺序性的要求:1-2-3-4-5…这种顺序的操作链条很长,而且必须严格顺序操作,就会面临控制难题,而且特别容易出现bug。这对其它顺序执行的语言来说,原本不是问题。但是Node全部是异步回调,它的特点和缺陷都在这里。如果你能很熟练的控制顺序执行问题,那么其它的就没啥了,不是事儿。

假如你的系统比较简单,就是查询数据库,然后返回数据给客户端,提供API接口,也可以考虑Node.js。开发速度真是很快的,而且性能也不错。

另外有个应用场景是适合Node.js的,长链接+Web。PHP开发部署应用的模式,基本是Nginx+FPM,全是短链接,因为这就是Web的设计。可有应用场景,就是需要用Web控制长链接,这个时候用Node.js就很方便了。用Websocket就是很好的方案,它还支持浏览器。

为什么可以这样?这是部署模式的差异,其实用常驻内存的部署模型都能做到,比如Python。PHP的常用模式是:Nginx接受外部的浏览器请求,通过FastCGI协议发给PHP-FPM,PHP处理完毕后返回数据给Nginx,它再送给前面等着数据的浏览器。

这个应用模式里面,PHP没有办法得到长链接,因为它前面是Nginx。如果要控制长链接请求,只能去请求另外的一个处理长链接的服务器程序,协议自定。可是,这不是又多了一个服务程序嘛。Node.js就可以2合1,让Web服务和其它应用服务结合着一起。

可能有人会问:这种需求有应用场景吗?有的。举个例子:你开发了一套服务系统,有各种客户端或浏览器链接进来,但是你又想用Web界面去查询、控制、管理,Node.js干这种活也挺合适的。它可以同时支持Web服务和其它应用请求,相互操作。

有个同行指出,用Nginx也可以支持WebSocket的长连接,有对应的模块可以配置。这个其实我知道,文章在这里:https://www.nginx.com/blog/websocket-nginx/

它跟我说的Node.js可以2合1不是一回事。如果使用Nginx,你还得单独开一个WebSocket服务器进程,比如这个PHP的实现:

Ratchet http://socketo.me/ 你必须单独启动一个进程,类似:

php bin/chat-server.php

你的Web服务与它完全是两个进程,如何与它进行互动通信?就需要额外的进程间通信手段了。而Node.js就不用了,它可以让Web的Http请求与WebSocket的实时信息相互操作,因为它们是一体的。

还有朋友提到,可以采用基于PHP语言的Swoole – http://www.swoole.com 这是个可选项。不过,要么把Swoole部署在Nginx后面,跟Ratchet类似,单起一个服务进程,要么使用Swoole内置的Http Server。但Swoole内置的Server对Http协议的支持不完整。另外,Node.js有相当不错的Web开发框架 – Express/Koa,Swoole只能靠手工了,跟框架的开发速度如何相比。

此外,PHP这种依赖于外部Web服务器的系统,自己内部没法实现定时器。举个例子:用户提交了一个请求,你想等1分钟后再告诉他处理结果。Node.js很轻松,PHP就头大了,没有外部系统、程序等支持,自己是做不到的。究其原因,是PHP使用方式的问题:短链接、非常驻内存。这种技术架构下,一次性执行的脚本代码,使用定时器是没有意义的,可确实有这样的应用场景。

​没有什么技术十全十美,只要把它们的特色用的合适,解决了问题就是好技术。

一部微软手机的溃败史-Lumia手机中国官网被撤
由大漠穷秋对vue的攻击说说技术和开源精神