原创文章转载请注明出处：@协思, http://zeeman.cnblogs.com
首先本文的目的不是引发语言之争，纯属个人的一些思绪记录。
因为工作原因，用Node.js做过几个项目，基本都是涉及REST方面的。有一个涉及消息转发的服务，分别部署到6台服务器，目前已经成功处理数亿的消息，没有发生消息丢失，总体运行稳定，说明Node用在产线环境是能经受考验的。
今年Node社区发生了一件大事，那就是Express作者TJ大神转投Go的怀抱，理由是大神要做云端程序开发。作为悲催的偏后端码农，开始怀疑Node在后端的表现，有了以下偏见：
1. Node是运行在V8之上的，虽然有的模块已经被改良，但基因没变，而V8是为桌面浏览器设计的，服务端毕竟要求会苛刻一些。
2. Node作为Javascript运行环境，而Javascript的发展受限于ECMA规范，ECMA规范可能是双刃剑。
3. 总感觉event loop比较脆弱, 可以充分利用IO, 但无法执行CPU密集性工作，多核运行需要require cluster，一直觉得这种做法有点山寨。
4. Callback层次的问题，可以用async等库进行改善，但还是觉得山寨。业务逻辑在回调机制下支离破碎，凡人难以理解。
5. 生态的问题，Javascript由于门槛低，github各种node库相当泛滥，质量参差不齐，好在有源代码，踩坑了再回来填坑。
6. 一些第三方库或为了追求性能，或为了突破限制，需要结合Node源码进行编译，总觉得不够环保。特别是产线服务器不能访问外网的情况下，就要抓狂了。
7. 我自己Javascript水平不怎么样，也就认为弱类型语言可维护性不如强类型语言，单元测试可以保证正确性，但难以重构。
基于以上莫须有的理由，我不知道Node 1.0以后的路会怎么走? 往哪方面走?还能走多远? 目前1.0已经有些难产…
建议：暂时不要将Node用于核心业务, 虽然paypal宣称已经这样干了。充分利用Node的优势，做和前端交互性的工作，并且是在规模不大的时候。如果把后端系统想象成一个鸡蛋的话，那蛋黄就不要用Node来做，一家之言。