你尚未登录,仅允许查看本站部分内容。请登录使用邀请码注册
berg

现在很多公司都想尝试nodejs,抛开尝鲜不谈,你觉得这样是否合适? 13个回答 问答 专栏 @ Nodejs

berg 发布于 3 年前

如果扩展开,这是一个更大的问题:

Nodejs 现在适用于哪些场景,如果不适用,还差什么?

因为是一个比较大的问题,如果回答者不能说全,请在一个点上说清楚,不要含糊其辞。

  • 前端农民工

    个人觉得,目前还只能用于静态资源服务器。

    理由:

    1. 太轻,业务要从server写起,好悲催,session、日志、文件上传、数据库、memcached、gzip、HTTP缓存控制等,虽然都有现成的npm,但总是工作量,而且把各个零散的npm包组合、配置、定制为业务需要的形态,是一个比较细致的过程。
    2. 目前还没出稳定版,想编写一些nodejs的原生扩展还要跟着升级,成本很高
    3. 业务和server环境不隔离,业务中某个点挂了server也就挂了,再加上异步编程模型,为了提高server的稳定性,还要写一大堆的逻辑
    4. nodejs解析query有一个隐蔽的bug,在IE6的地址栏里,输入一段带get参数中文的url,比如 http://www.baidu.com/?kw=你好 ,然后回车,server接收到的时候会解析不了kw的值,因为IE6没有做URI的encode
    5. 业务上线要重启server,不要说什么“删除module的cache做动态加载”——试过了,非常非常容易引起内存泄露,线上出现过一次13G的内存占用。虽然pm的方案也算是可以的思路,但对业务是有影响的。
    6. 确实不够php糙猛快,感觉主要原因还是因为要从server写起,而且对于异步+处处try-catch很是伤心。
      ...

    虽然我对js语言的熟悉程度比php的多,js对我来说亲和力要远高于php,但写nodejs的服务端应用确实没有曾经写php的那种快感。

    nodejs,以一句非常简单的createServer,获得了很多前端同学的芳心,然后也出了各种跑分文章,说nodejs如何高性能。诚然,nodejs作为静态资源服务器还是挺方便的,在静态资源服务器上再加点小功能也ok,但要想做到php、java等语言现在能做到的应用规模,相信还有一段很长的路要走,这不仅仅是语言和性能问题了,还有很多工程问题。

    我相信nodejs的未来一片光明,也对尚未稳定的版本所遇到的各种问题持包容的心态,有越多吃螃蟹的人,螃蟹才能变得越来越肥美。另,每篇文章都有它的时代局限性,本回答发生在2014-06-19,如果过了一阵子nodejs变得非常高大上,请不要过来挖坟,因为那个时候我跟你一样会拥抱变化。

    ==============================
    2014.07.14追加:

    TJ大神都不玩nodejs了

    I’ve been fighting with Node.js long enough in production now that I don’t enjoy working with it anymore unfortunately, so at least for now this my formal farewell! And more importantly I need maintainers!

    见: https://medium.com/code-adventures/farewell-node-js-4ba9e7f3e52b

    回复
    • 3 年前,berg 说:

      我觉得 @前端农民工 的担忧,其实可以归结成:
      1. Nodejs不成熟
      2. Nodejs上层的封装和库不成熟
      3. Nodejs的社区还不成熟

      不过就我看到的,用nodejs跑接入层服务还算性价比高:简单(不容易出问题),性能相对PHP好太多。大家使用 Express 这样的简单框架也乐在其中。

    • 3 年前,前端农民工 说:

      性能跑分参考价值不大,对于express这种上手简单的东西一般后续业务增长都会有一个折磨的过程。就好像css,写demo的时候好happy,上了规模就觉得css怎么这么难管理

  • zenany

    @前端农民工 的答复,补充几点用 node 的体会。
    优点:
    1. 前端人员,有一定的 server 端研发经验,做起来会相当顺手,毕竟省了一门语言
    2. express + 中间件 合起来,就有点类似一个完整的 webserver,一个 package.json 就可以完成整个开发环境的搭建
    3. npm + 各种三方组件,你可以随意 diy
    缺点:
    1. 每次改点东西,就得重启 app,这点远没有 php 方便
    2. 若没有丰富的后端经验, 简单的create server之后将是噩梦的开始
    3. 这么多参差不齐的组件,到底改选啥?看起来似乎可控度灵活度搞了,但实际上筛选和整合成本相当高,远没有 php 、java 的 runtime 省心
    4. 每个应用自身就包含: 静态 server、动态 sever、开发框架、类库、cgi 等等,缺少分层和工程化考虑
    5. 异步模式写起来很崩溃,尤其是数据库操作

    对 node ,我感觉它更多的是将其它优秀的经验或者类库,以 js 为语言,利用社区的力量和全开源的模式,重新实现,走小而美的路子。可关键是很多核心的 server 端技术,目前并不是开放的。目前这个状态,中小应用问题不大,但离工业化程度还有点远。不过我还是很看好这个生机勃勃的社区,相信随着时间的推移,总有一天会催生一个类似 jdk、php、python 一样的完整的 runtime ,迎来 1.0 时代。

    至于合不合适,还得看业务和分工模式,若 前端全面负责数据之上的业务,规模也不大,node 是一个好的选择,因为毕竟对多数码农来说,语言还是障碍,少个语言就少点成本。但在尝鲜前,一定要搞清楚 server 端到底都需要啥,diy 出一个相对稳定的 runtime 和开发框架。

    回复
  • hefangshi

    个人比较看好的Node.js应用场景有

    1. 工具类
    2. 服务聚合胶水层
    3. UI接入层

    工具类的应用场景目前已经取得了很大的成绩,因此略过不提。

    服务聚合胶水层

    这一层更加推荐RD参与来做这个事情,利用Node.js的高并发与异步能力,我们可以将原有的API进行聚合封装,如果这个胶水层是直接与C Server对接,在快速开发能力上拥有和PHP一样的效率,而在性能方面,Node.js至少更加容易实现高并发与异步请求。当然在这方面,我并不认为Node.js比go或者erlang会有多大的优势,但是的确是可行的。

    UI接入层

    收益

    架构升级

    更全面的接管后端模版渲染工作,推动后端服务化,利于独立架构升级。为何一直到Node.js解决方案,FIS才能真正意义上的实现Bigpipe,这就是因为后端模版渲染工作受限于后端开发人员,需要很强的推动和执行能力才能把Bigpipe推广成功,但是在Node.js解决方案中,通过对后端模版渲染层的全面控制,进行这个架构升级毫无阻力。

    加快开发

    通过Node.js层的介入,我们可以对数据有组合调整能力,很多需求变更不再依赖后端开发,减少前后端沟通成本。此外,由于后端服务的解耦,前端的提测环境可以更加简单与独立,提测环境的简化,更利于前端全流程的打通。

    性能提升

    我并不赞同Node.js的性能提升只是跑分上的提升,如Paypal的案例 https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/ 对于real world application,也是有绝对的提升的。

    技术选型

    遗憾的是并非只有使用Node.js才能实现。比如划分PHPUI层,我们一样可以完全解耦前后端,拥有独立的架构升级、加快开发,甚至性能上,PHP也可以通过hhvm和php-ng以及异步请求支撑。

    因此这个问题到这里,实际上是一个UI层技术选型的问题。

    以技术方面的思路总结的话,作为UI层的技术选型,PHP的确更容易让小白FE写出稳定的后端UI层代码,但是对于大部分FE,使用Node.js更容易并且更自然的实现类似Bigpipe以及异步API请求。

    从项目推动上来看,hhvm和php-ng以及PHP异步请求这些技术来看,想要在PHPUI层推动应用这些技术,绝非是几个FE或者RD就能HOLD住的,不得不说,Node.js绝对是一条性能提升和架构升级的捷径。

    Node.js的问题则是目前有很多的坑,但是我认为并不是无法处理的。

    Node.js有坑,不过也不能过于放大,个人认为最主要的几点有

    内存泄露

    内存泄露的主要原因还是全局变量以及闭包变量使用上的问题,如果FE以浏览器端的思维来编写后端逻辑,的确容易出现问题。但是主要还是代码编写上导致的问题,与C++不同,Node.js得内存泄露绝大部分还是在v8管理下的内存泄露,并不是对系统资源的内存泄露,我们可以有多种方式来排查处理这个问题。即使是PHP,也是会有内存泄露问题的,这是值得注意的问题,但是不是解决不了的问题。

    HTTP请求缺乏Context

    无法拿到单一HTTP请求的上下文,如果很多资源可以绑定在Context中,随着请求销毁,那么在内存泄露上的问题实际上可以减少很多。并且缺乏Context导致我们即使想要实现单请求的全局变量需求,比如LogID,都会十分困难。

    注:没有Context不是内存泄露的直接原因,而是会让开发人员产生全局变量绑定或闭包变量的依赖。如果单纯使用req或者res来绑定,不利于Model层的实现。

    异步请求与错误处理

    这里不多说了,说多了都是泪,只能寄希望于v 0.12以及类库封装。

    总结

    想要解决Node.js的UI接入层的坑,我认为整体思路就是做的越少,错的越少。。

    UI层一定要薄,业务逻辑必须少到极致,只有获取数据-组织数据-模版渲染的内容。

    每个请求,都应该尽可能的减少FE使用回调函数的次数,目前只有一个大概的思路,即组件与数据模型绑定,数据模型与服务绑定,将重试以及错误处理都交由类库来处理。

    使用这样的解决方案,只要解决方案的质量过硬,牺牲了部分灵活性,但是带来了API重试机制保证系统稳定,详尽的错误日志用于分析,大量减少回调处理,UI层出现问题的几率也大大减少。

    此外,关于Node.js的部署、监控问题,我的观点是,Node.js并不复杂,之所以大家认为很麻烦,原因主要在于

    1. 即使是PHP、Nginx等环境部署,第一次做的时候也会很麻烦,即使是在厂里,线上机也能只直接运行Node.js的预编译版本
    2. 大部分FE对服务器部署不了解,在没有OP、RD支持下,这个事情的确很难开展

    因此未来UI层的全流程打通势必会包括部署、运维一体化内容,帮助FE建立UI层,不用再趟我们趟过的坑。

    回复
    • 3 年前,fansekey 说:

      建议整理成文章发个专栏

  • jincdream

    如今,Promise已经有了,Node.js作为中间层活现在服务器端也有不少公司进行实践了,~ 各位看官,再来谈谈?。

    回复
  • firedfox

    前面很多同学讲了单进程的问题,其实只要保证无状态,使用PM2等工具很容易实现多进程服务,还友情附送各种管理功能。
    我感觉简单来说node.js适合的业务场景就是:逻辑不是特别复杂,但并发数要求很高。这时基本上性能不输C++,在开发效率上又有非常明显的优势。

    回复
  • fansekey
    • nodejs部署是个大问题
    • nodejs不适合业务太复杂的场景,在移动端搞搞还差不多
    • php依然是开发后端亲和力最好的语言,为web生生死死
    回复
    • 3 年前,atian25 说:

      部署上, 瓶神可以找Hinc等兄弟来分享下UAE的经验

    • 3 年前,Rayi 说:

      @atian25 UAE是什么??求听分享~~~

    • 3 年前,Rayi 说:

      是UC Application Engine么?

    • 3 年前,fansekey 说:

      @atian25 其实我说的部署可能是对于前端人员来说去部署比较难,OP显然不希望自己熟悉的PHP环境被更改为一个还没有广泛被使用的语言。

    • 3 年前,fansekey 说:

      @Rayi 不至于吧,听说BAE都快Over了。

  • atian25

    可以让 @前端农民工 他们组来分享下, 他们现在就是用nodejs作为后端支撑UC导航,UC视频等项目

    回复
  • 三水清

    1、业务逻辑不那么复杂的中间层,比如各种数据接口并行调用,然后模板拼装后输出
    2、静态服务,文件处理,打点统计
    3、前端工具,fe自己的shell

    回复
    • 3 年前,hefangshi 说:

      所以你们要不要迁nodejs

    • 3 年前,fansekey 说:

      用fis-plus应该还是挺爽的吧?

  • looping84

    1、改点代码就需要重启app.js很蛋疼
    2、读写数据库,经常会有漏掉close connection的情况。。。。。

    回复
    • 2 年前,程序猿小卡 说:

      这个不是node的问题吧。第1点可以看下forever,第2点是数据库读写的问题。

    • 2 年前,18109227900 说:

      supervisor?

  • lanpang

    看公司规模,node毕竟是新兴语言,搬到生产上会有很多坑要解决的。
    如果公司能提供出2-3个高级程序不做业务专门研究node框架,那node没什么问题。
    如果不然,还是PHP吧,起点低。

    回复
  • <。)#)))≦

    在公司的新的业务上尝试过后的感觉是:

    优点:
    前后端解耦分离
    JS代码和前端模板共用
    前端灵活部署
    性能提升?(项目比较小,性能不考虑)

    缺点:
    多维护一层带来代码的重复(比如Node这一层也需要一个controller)
    NodeJS的异步模式处理复杂的业务逻辑的时候比起顺序编程要晦涩一些,尤其对于不习惯js事件驱动的后端程序员

    没有结论

    回复
  • jimnox

    异步语言编程还是太难了,虽然有无数种异步方案,比如Promise这类的,算是曙光。
    但终究还是心智负担
    另外就是异步具有传染性,一个API是异步的,那么它就会传染到App层的代码,并且这种传染基本上是不可逆的,这会增加重构压力

    node.js现在的情况我觉得:快糙猛不见得比PHP有优势,工业强度也不见得比Java直流有优势,生态发展虽然非常非常快但也谈不上优势

    说现实点这么复杂的程序招的上人来写不……

    我承认node.js是趋势,但我认为node.js是一个历史趋势,而非技术趋势

    回复
  • igin

    有时候,逼格也是一种需求,同意吗? 它这么火,不玩玩它,不好意思和别人打招呼了。一部分让有这样的潜在心理。

    回复
登录后回复,如无账号,请使用邀请码注册