这几天看见几位业内人士在批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使用方式的问题：短链接、非常驻内存。这种技术架构下，一次性执行的脚本代码，使用定时器是没有意义的，可确实有这样的应用场景。

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