BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

我为什么反对用Node

| 作者 许令波 关注 0 他的粉丝 发布于 2015年8月31日. 估计阅读时间: 20 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

随着无线端的快速普及,前后端分离技术走上前台,而Node由于它的一些特性被工程师快速接受尤其是前端工程师,所以产生了很多Node是否会引起新的技术变革的讨论。我本人是淘系的一个Web开发人员,基本上经历了淘系关于Node和Java技术选型讨论的过程,所以今天我给大家推演一下在像淘系这个环境下Node能否会成为主流的Web开发技术,当然后面也给出了我认为比较适合的场景。

Node火了

在百度中搜索Node可以得到105w个结果,图书出版方面13年3月到15年6月2年时间有近20种相关的Node书出版,实践方面国外公司PayPal、LinkedIn、groupon也都在使用,国内大公司阿里、腾讯、百度也都有实践项目在尝试。这让我想起了当初Nosql新出来是一样的场景,大家都一窝蜂的涌上去拥抱新技术,获取新技术带来的红利。

Node很火的另一个推手是当前的无线技术流行,很多应用从传统的PC开发要转到无线等多端,这种情况下渲染层和逻辑层的分离变得重要起来,而Node刚好可以很好的渲染前端页面,所以我们的开发同学不遗余力的在推广Node技术。

Node能够火起来最重要的原因还是它的确给我们的开发带来了很多好处:

  • 基于事件驱动
  • 无阻塞I/O

Node还有其它一些优点如单线程,总体来说Node是为轻量级的分布式的实时数据服务这类应用提供运行容器而设计的,这类应用很容易想到微博、Facebook这类典型场景,需要非常实时化、个性化、高并发的数据服务。

为什么火了

今年由于无线终端的兴起,后端要提供基于JSON API的数据接口非常普遍。目前来看公司还存在两种形态:一个是无线作为新系统独立存在于传统PC系统;另外一种是将无线系统合并到老的PC系统,在一个系统里同时支持多端服务。长期来看无线和PC系统的合并是必然,业务上以无线为主,PC仅仅作为一个终端而已,不可能存在无线和PC两套业务逻辑。

那基于无线和PC业务合并,由一个系统提供多终端、多语言适配的角度来看,Node能否在其中扮演传统服务端 MVC中的V角色?

要回答这个问题,我们再设想一下,在多端情形下,需要怎样的交互:PC、手机端、Pad、TV、Car、Watch等其它移动终端。

是Native还是H5

当前移动端主要还是以Native实现为主,从用户体验角度来考虑Native的实现要比H5更流畅,同时Native还可以基于本地做很多在浏览器里不能做的优化,如大数据的存储、可以定制的通信协议、更方便的保持长连接以及更容易实现的实时消息推送。

当然H5也有其无法比拟的优势,客户端更轻量级,服务端发布更迅速,不需要用户升级版本等。长期来看移动端能否会向早期PC那样也从富客户端转向浏览器呢?

我的判断是未必,有几个因素,首先Native实现性能优势相比H5会好很多,当前移动端都在追求极致体验的时代,无疑APP会比H5有很多的优势;其次,移动端屏幕较小,基于网页的交互和APP相比还有很多限制。最重要的是不同的商家是主推带有品牌标识的APP还是向统一的浏览器靠拢,从目前的趋势看,APP 会是手机端上争夺的重点。所以推测直接基于手机端的浏览器的应用不会成为主流前端。

如何实现快速迭代

基于APP的Native如何解决客户端更新和服务端的快速迭代,这个问题是当前正在着力解决的,目前为止有两种思路:一种是客户端用同一种技术开发,然后通过工具编译技术把它编译成不同平台上能够执行的代码,如当前的React Native;另一种思路是将客户端中经常需要更新的模块做成动态推送的,用模板+数据的方式,在不同的客户端平台上实现一个小的解析引擎来实现快速个性化的定制,目前手淘主要采用后面一种实现方式,当然前一种也正在尝试。

那么再说回来,基于前面的这些推断,多终端和服务端交互主要是数据+模板的方式为主,那么服务端提供格式化的数据将成为必然选项。所以涉及到的问题就是服务端既要提供格式化的数据(Http JSON数据),又要支持传统的PC的方式:基于JSON数据渲染出HTML页面,所以很容易想到将渲染层独立出来用Node完成。

真的靠谱吗

既然Node可以带来这么多好处,那么我们不妨就继续向下推演,看是否真的很靠谱?下面看下Node在我们的实际的开发环境中如何使用,在引入Node之前我们有必要先介绍下当前Web服务端架构:

(点击放大图像)

图1. 传统的web架构

在当前这种架构下Node怎么融入进去呢?最保守的一种方案是将当前的Java Web中的VIEW层从MVC中独立出来,交给Node来完成,Java Web只提供基于JSON数据接口给Node调用,架构图变成了如下的形式:

(点击放大图像)

图2. Node作为渲染层加入到传统架构中

很明显的差别是在我们当前的访问路径上多增加了一个Web代理层,而这一层和当前的Web服务器层怎么看都有点别扭,两者同时存在始终觉得有一个是多余的,那么Node能否替代掉Nginx成为Web代理服务器呢?理论上是完全没问题的,就像我们用PHP来代替Java Web开发一样,不过你放到具体的公司运维体系中,你会发现目前在Nginx上的防攻击、限流、数据埋点、热点cache等模块都要在Node上重新开发一遍,最重要的是用Node取代Nginx并不能带来额外的好处,如果你说Node可以渲染页面,那么Nginx的开发会和你讨论Nginx lua模块和Node哪个更合适,所以用Node取代Nginx作为代理服务器也不太现实。

那么Node能否取代前端台的Web系统,成为主流的MVC框架呢?

未必

Node和Java Web一样可以提供MVC管理功能,一个系统中同时存在两套MVC框架显然不合理,那么如果用Node 来替换Java Web的话,服务端的架构变成如下的:

(点击放大图像)

图3. Node替代Java Web

从技术实现上这种架构没什么大问题,就是用Node上的MVC框架如express来替代Java Web中Webx,也就是用JavaScript替换Java,以及整个运行容器和中间件都要替换,那么是否真的带来那么大的好处呢?

我们从语言特性、开发效率和成本因素三个方面来看,Node作为后来者能否比我们现在的Java更优秀。

语言特性

JavaScript作为Node上运行的语言和Java相比,优缺点很明显。JavaScript语法简单,很容易编写基于事件的驱动的实现。但是JavaScript基于面向对象的描述能力偏弱,不像Java是真正的面向对象语言 ,同时JavaScript的对数据类型定义也比较单一,要么是数值类型要么是字符类型。很明显Java更擅长构建复杂逻辑的大型应用程序,在这一点上JavaScript明显落于下风。

在语言运行效率上,JavaScript本来是解释执行,而Java是编译执行,但是由于Node做了优化,所以运行效率差别不大。

开发效率

开发效率可以从语言的复杂度、程序员培养、开发工具包的丰富性以及编码效率几个方面比较。

  • 语言的复杂度。Java和JavaScript从开发角度都不需要关心内存的管理,都是基于虚拟机来管理内存,从并发角度来看:JavaScript是基于事件触发的,而Java是基于线程的,JavaScript更占优势。另外JavaScript是无阻塞 I/O的,在I/O效率上JavaScript也更占优势,虽然Java8也将更好的支持异步I/O。
  • 程序员培养。目前Java语言仍然是仅次于c语言的第二大编程语言,而JavaScript排查第10位,Java程序员队伍要比JavaScript大很多,很显然Java程序员招聘要比JavaScript更容易一点。
  • 开发工具包。一个语言的开发效率很多时候要这个语言的支持工具包和组件的丰富性,Java经过这么多年的发展,工具类库已经非常丰富,几乎你想要的工具类库都能在网上找到。JavaScript虽然也发展很长时间,但是基于JavaScript的工具类库主要集中在前端,能够直接用于Node上的仍然很少,当然Node的社区非常活跃,可以预见Node的工具类库增长也会非常迅速。但是短时间内要达到Java的规模尚需时日。
  • 编码效率。Java语言的运行基于JVM,但是Java的部署效率稍差,而JavaScript使测试更加简单,容器重启更快,但是debug机制仍然不完善,所以很难做debug测试。

成本因素

前面主要是从技术角度考虑,但是如果往Node迁移的话,成本也是一个考虑因素。

  • 首先是学习成本。公司大部分是Java程序员要往Node迁移很明显这个学习成本会非常巨大,即使这个迁移是逐渐的,长期来看仍然是要将一部分Java程序员替换成JavaScript程序员,不管这个程序员是公司内培养的还是从外部招聘的,我们可以算一下帐,公司招聘一个程序员的成本有多大:一个普通的工程师的年薪假定有10w以上,猎头费一般是年薪的20%以上,也就是2w,再加上一个月的实习成本1w,加在一起约3w,对于一个有1w以上开发的大公司成本可想而知,即使是招聘应届生,由于应届生的培养周期更长,所以学习成本会更高。
  • 其次是环境成本。公司的基础服务产品,如中间件都是基于Java开发的,如果要替换成JavaScript 必然要再开发一套,还有配套的运维工具等,这个成本也可想而知。
  • 最后是维护成本。Java和JavaScript都是基于容器运行,JVM和v8引擎相比,程序员显然对JVM更熟悉。另外从排查问题的难易程度来看针对JVM的工具显然更完善。

从上面几个方面来看,当前在阿里要让JavaScript完全取代Java作为后端开发语言,基于Node用JavaScript 实现整个服务层逻辑显然成本会比较高。

换个角度

我们再换一种角度推演一下,假如我们现在的Web系统都用Node实现,那必然有很多Java工程师会做Node的开发,因为我们现有的前端工程师人数肯定是支撑不了现有的业务发展的。我们假定一部分Java工程师愿意学习JavaScript成为全栈工程师,但是是否同一个人愿意用两种不同的语言完成同一个任务呢,正常来说,如果我能用同一个方式完成全部工作,我为什么要把一个任务分成两种不同的方式来完成,这显然也不太合理。

怎么办

基于前面的分析,Node不管是在现有基础上单独增加一层还是要整个替换Java Web层都不太合理,那是否意味着这种前后端分离的思路有没有合理之处?有没有更好的实现呢?

传统的MVC Web软件架构将渲染层独立出来交由前端同学控制有其合理性,在当前的多终端开发模式下,将业务逻辑层和前端渲染层分离有利于提升后端的开发效率,后端只需要关注后端的业务逻辑和数据的输出,因为在Native开发下服务端只需要输出JSON数据,客户端的页面渲染有客户端同学完成。H5和PC需要的HTML渲染统一交给前端同学完成有利于前端更好的开发模板,从以往的先画好模板(HTML),给后端同学转化成相应的模板(如Velocity或JSP),然后再基于复杂的Java Web工程下调试页面(前端要独立的运行整个Java Web工程还是相当的困难)。而渲染层全部交给前端的话,前端同学和后端只需要约定好数据后,页面完全由前端同学完成,减少了不少交流成本(不过从淘宝的基于Node实践来看,整个效率提升还不是那么明显,大部分是把原本是后端的开发工作量转嫁给前端了)。

还有一个重要的理由是前端有了渲染层的控制权,前端的开发体验有了不小的提升,说白了就是前端从以往的配合角色转变成一个Web渲染层的Owner,更加有了主人翁角色,如果再维护Node的话,和以往的后端Java开发几乎一样了,而这种前端职责的提升恰恰是从后端削弱过来的,所以第一个出来反对的肯定是后端同学,当前在阿里Node发展比较缓慢我想也有一点关系吧。

再说回来,我们一直讨论的基于Node实现的前端分离方案,可以把他分解一下Node技术和前后端分离。很明显前后端分离在当前多终端背景下有其合理性,但是是否一定要用Node来实现呢?答案是不一定。当前还有两种方案:

将Node层代码抛到Java体系上,如下图:

(点击放大图像)

图4. Node嵌入到Java中

当前的Java8(Nashorn)已经可以支持JavaScript的解析,而Avatar.JS可以将Node无缝迁移过来,但是经过测试,Nashorn+Avatar.JS的执行效率太差,有4到10倍的性能下降,最好也有一半的下降,这样很难达到工程级别的使用。

另外一种就是仍然在基于Java Web体系下,而是将渲染层独立出来,渲染层和业务逻辑层仍然通过JSON(或者大对象)数据交互,使得渲染层既可以在Java上渲染也可以在Node上执行。如下图所示:

(点击放大图像)

图5. Java Web兼容Node的模板层

这种方式与前一种的区别是只做渲染引擎的适配,即模板在Node和Java上都可以解析,而不是把Node的整个MVC都搬过来,由于Node和Java Web上都有控制逻辑(即MVC中的C),所以如果Node和Java中逻辑不一致会导致两边渲染出来的HTML不一致,所以需要把URL改造成满足RESTFULL的格式,尽量把C的逻辑简单化。

上图的架构正是目前我们在详情系统上做的一个实践,成功的关键是将XTPL的模板从Node上无缝迁移到Java上,另外就是保持页面的路由尽量简单,这样前端在Node上开发的重点只是XTPL模板。这种解决方案达到几个目的:

  1. 我们的后端系统完成的组件化改造,PC和无线逻辑统一起来了;
  2. 将渲染层独立,渲染层后业务量逻辑层通过JSON数据对象交互;
  3. 前端开发同学完全掌握了XTPL+JS逻辑,有更多的掌控力;
  4. 前端开发页面不需要依赖后端的Java系统,调试页面可以在Node中完成;
  5. 系统的架构并没有增加一层,运维上也没有引入新的Node系统。

没有无往不能的神器

前面介绍了在现有Java体系下,要将Node替换Java Web其实是比较困难的,所以没有一个技术是无往不能的神器,但是是否意味着Node就没有应用场景了呢?肯定不是,下面这些情况下Node很有用武之地。

创业公司很合适,尤其当创始人之一是熟悉前端的同学的话,用Node实现Web系统很合适,Node和PHP一样具备快速发布的优势,代码copy上去就生效,甚至不需要重启服务器,这一点相比Java有很大的优势。当业务逻辑还没有非常复杂时,JavaScript语言的弱点也没有暴露的那么明显,从系统的维护角度来说,不需要一个工作有两个角色的工程师完成,可以提升开发效率。

重页面交互轻业务逻辑的系统也适合Node来开发,说白了如果Web系统如有一半以上的 工作量都是需要前端同学来完成的话,那还不如把整个系统都交给前端同学来维护。

如果公司的工程师都是全栈工程师能在不同语言之间自由切换,那么也就没有所为的成本一说了。当然这个仍然要受到公司基础环境的约束,如运维和中间件产品仍然不会同时开发两套。

小结

随着技术的不断进步我们的开发模式也在一直发生着变化,早期的页面渲染和业务逻辑全部集中在一起,如ASP、PHP、JSP技术,后来由于业务逻辑不断变得复杂,出现了MVC的开发框架,前后端工程师分工也越发清楚。中间也有过前端工程师负责整个渲染层和控制层的实现如Extjs+Ajax的开发模式,但是由于整个渲染是在浏览器端完成的受制于客户端渲染性能和搜索引擎的收录页面的硬缺陷很难成为主流。一直到今天前后端开发模式仍然是后端工程师管理M和C,而由前端来实现V,开发环境和运行环境是一套,所以开发上的耦合导致沟通和调试成本增加。直到Node的出现缓解了前后端开发上的耦合,但是这种分离仍然是以增加运行时的维护成本来换取开发时的便利,所以我觉得还不是最佳实践。

本文给出的解决方案也是想兼顾开发时的便利而同时也不增加运行时的维护成本为出发点,当然每种方案都不是完美的,找到适合才是最重要的,随着Java中执行JS技术的不断成熟,我想开发环境和运行环境的分离肯定不久就将实现,前后端开发的耦合度也就最终解决。

作者简介

许令波,2009年毕业加入淘宝,目前负责商品详情业务和稳定性相关工作,长期关注性能优化领域,参与了淘宝高访问量Web系统主要的优化项目,著有《深入分析Java Web技术内幕》一书。 @淘宝君山、http://www.xulingbo.net、xulingbo0201@163.com可以联系到我。

 

感谢崔康对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入InfoQ读者交流群InfoQ好读者)。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

一点观点 by test test

语言没有好坏,只问你会不会用。
熟悉Java的人会反对Node.js,而熟悉Javascript的人会支持Node.js。
是不是可以这么理解?

Re: 一点观点 by Li Jinggang

应该从引入node后对架构上带来的变化,不应该从语言的角度上看待。什么语言适合什么环境,什么样的应用环境决定了语言的取舍

二点观点 by su sin

你画的那些图对吗? 误人子弟.

图中内容改进 by bo b

不好意思! 图中的“用户浏览器”是要改成“用户终端”

Re: 二点观点 by bo b

不对的地方,可以指出来,我可以改掉的

Re: 二点观点 by 王 辉

求正确的图

Re: 一点观点 by Jane simon

同意。取其精华就行了。

图片 by see sai

图片放大了都不清晰

没有无往不能的神器 by 段 光锐

根据实际环境和需要,选择合适的

这篇文章解决的问题没踩到点上 by 吴敏琦 七念

你提到的用Java实现xtemplate的渲染不是前后端分离的核心问题,你提到的这种方式4年前淘宝有相似的解决方案,叫做vmarket,是前端实现了一个velocity模板的渲染引擎,达到的效果和你的差不多,提升了一部分的效率,但仍然有如下一些缺陷:

1,开发效率仍然不够高
2,测试效率低
3,发布效率低
4,问题排查效率低


另外,对你推荐的最佳实践,也就是第四个图,个人感觉不太优雅,多终端模块说到底是视图层的犯愁,理论上应该由关注视图的人(前端)来组装,后端的接口应该尽可能的服务化,不要关注视图的东西。而现在淘宝的「中途岛」方案,比这个图要优雅很多


我的观点:不管是不是用Node,前后端分离的价值都非常巨大,这篇文章解决的问题其实没踩到点上,建议把这篇文章先发到阿里内部的ATA上面,方便敞开讨论,这里我不知道是否适合放出一些数据来。

Re: 这篇文章解决的问题没踩到点上 by 吴敏琦 七念

标题不准确,改成「如果是在讨论前后端分离更高效的协作的话,这篇文章解决的问题没踩到点上」

感覺就是java碼農對js的發自內心的抵制 by wen bob

而且還沒有給出什麼有力的證據。。。

覺得js對類型支持不給力,可以用typescript啊。

另外,js工具包真的不夠你用嗎?呵呵,呵呵

建议楼主回到web根本重新学习一遍 by 周 柏民

“传统的MVC Web软件架构将渲染层独立出来交由前端同学控制有其合理性,在当前的多终端开发模式下,将业务逻辑层和前端渲染层分离有利于提升后端的开发效率,后端只需要关注后端的业务逻辑和数据的输出”
——本来都是开宗明义的事情,到很多一知半解的同学像是发现了新道理似的,你去看看2000年前web是如何设计的、http是如何设计的,第一件原则就是各种设备无障碍访问,可是结果早期的实现哪个“大公司”不是私活一堆,畸形发展,现在只不过是正本清源而已。
——对不起,我没有跑题,没有这些“大公司语言”的烂事,也不会有你今天这个话题了!

感觉看起来很乱,跑题了 by Zki Wing

我觉得题目应该是《大家都用node,java就失业了》

web的事web做主 by 周 柏民

web的事由web做,顺带说一句:那些“语言”该在哪待在在哪待着,操操本地应用的心就够了
why?因为它们不是为web设计的

赞同,不反对 by gao gao

java域Node引入后架构变化思考与你雷同,但是我不反对用Node,思考点
页面渲染比较常方式:
1. web服务端渲染
2. 浏览器js渲染
3. 混合方式
Node引入后有点像混合模式,但是又引入了一层,会引入没有必要的复杂性和运维,及一些未知问题。java web端渲具备Node模板渲染能力,整合java成熟的体系这个还是非常有必要。
后端与web端渲染部署在一个容器中(减少传输、序列化、反序列化),后端开发直接通过数据传递给渲染层视图同学快速开发,可以同时发布,也可以单独发布,提高整体效率。

前端开发就应该用node.js, 就应该都会node.js by 光春 罗

目前的nodejs模块之多,已经足够企业级开发使用。前后端分离,最好的模式前端只写静态的代码,比较典型的angular单页面应用,与后端交互只需使用json,而不是什么XTPL模板或者velocity,那些是很多年前的技术了。nodejs目前较流行的项目管理工具 gulp或者grunt,可以较大提高生产力。
一个创业型的公司,只需招会node.js的资深点的前端人员,其实什么事情都可以搞定,移动端用h5+cordova, 桌面程序用node-webkit,web服务使用express,其他的就用云服务了,还有什么事情搞不定的呢?!

错误还是挺多的 by liu daniel

1."Node还有其它一些优点如单线程、RESTful API等" node 和 restful 有什么必然联系么?
2."APP 会是手机端上争夺的重点。所以推测直接基于手机端的浏览器的应用不会成为主流前端" 是否忽略了微信等各种附带浏览器的 APP 以及 原生应用中的 webview 等?好像几年前的观点啊,现在已经很少有人把 原生应用 和 HTML5 应用对立起来了...
3."而这一层和当前的Web服务器层怎么看都有点别扭"、"所以用Node取代Nginx作为代理服务器也不太现实",看着别扭... 建议深入了解下贵厂基于 node 的前后端分离方案.
4. Reactor.js ? react-native ?
5. "代码copy上去就生效" ...
等等 不一一列举了,发到个人博客上更合适

Re: 错误还是挺多的 by bo b

1."Node还有其它一些优点如单线程、RESTful API等" node 和 restful 有什么必然联系么?
2."APP 会是手机端上争夺的重点。所以推测直接基于手机端的浏览器的应用不会成为主流前端" 是否忽略了微信等各种附带浏览器的 APP 以及 原生应用中的 webview 等?好像几年前的观点啊,现在已经很少有人把 原生应用 和 HTML5 应用对立起来了...
3."而这一层和当前的Web服务器层怎么看都有点别扭"、"所以用Node取代Nginx作为代理服务器也不太现实",看着别扭... 建议深入了解下贵厂基于 node 的前后端分离方案.
4. Reactor.js ? react-native ?
5. "代码copy上去就生效" ...
等等 不一一列举了,发到个人博客上更合适

没觉得你列的这些有什么错误

Re: 错误还是挺多的 by Tian Jackson

RESTful和node确实没有直接联系。

槽点略多 by Dear Nazimi

光是看看开发效率和成本因素里面的几句话……按照楼主的理论所有公司是不是只用招C 程序员就 Okay 了,反正数量最大而且无所不能嘛。 我建议楼主真的要做这方面的调研的时候,最好融入一些实际的使用体验,了解一下这门技术当前的一些比较成熟的体系和解决方案,为什么他们这么做。你讲的这些,有一种站在别人圈子外面抱着自己的宝贝对着别人喊话反对的感觉……

不要误人子弟 by shoyer shoyer

作者明显对node存在偏见。不如说是java的软文来得更合适,"能够直接用于Node上的仍然很少", node的工具库,你觉得不够用吗?有没有用过npm, 有没有系统地研究过node,不懂,就不要乱说,好吗。槽点太多,不想吐了。一门语言肯定有他的不足之处,但评价要客观,你的个人喜好色彩太浓了。

你的反对并不能阻止Node.js继续火 by yangweij weijie

作者显然不懂Node.js,而且没有包容心,每种技术诞生都有其优势和特点,通过反对Node并不能带来更多Java web的用户者,技术可以结合改进。

Re: 二点观点 by Ding Alice

图片已经修改。

不存在语言之争, 作者只是站在后端的角度看待node取代view层的可行性问题 by 田 均

js的coder们太敏感了 , 通篇看完作者并不存在偏见, 客观分析问题而已 , 有反对意见的完全可以发表一篇文章逐条反驳, 没必要喷作者. 我是同意作者观点的, 另外还有一点作者没有提到的需要补充: 就是管理问题, 如果前端人员介入服务器端开发, 不仅仅是语言的问题 , 涉及到一系列人员管理, 运维流程和运维体系搭建的问题, 对于技术构架很稳定的大公司, 做这种切换是需要非常谨慎的.一不小心就会让系统一片混乱难以维护 ; 初创的技术选型未稳定之前, 做这方面尝试我是觉得完全没问题的.

Re: 不存在语言之争, 作者只是站在后端的角度看待node取代view层的可行性问题 by shoyer shoyer

很多人自以为是,以为自己看了几篇node文章,写过几个hello world一样的程序,就对这门技术了解了。写出的文章错误百出,还不让人点评,不指出来,难道继续误导后面来阅读的人吗?如果怕别人吐槽,那就不要发出来。

该用还得用 by 秦 佳

用Node不是来取代java,用Node只是来干最适合他干的事

写这篇文章就要做好被喷的准备 by chen jinfa

如果只是做为自己博客或私下写写也就算了,发表在权威平台上,你让那些研究Node.js的同事情何以堪,他们的工作并且没有价值,有时候“创新”可能带来“不稳定”,但只是时间问题,都是可以解决的。
我跟你们团队没半毛关系,只是我希望支持创新,大家相互赞叹,相互支持促进,有问题私下提意见建议,并给出合理的数据证明,先考虑给他人帮助,而后得到认同。

大前端本来就不该有Java什么事 by Deng Jack

如题。前面有同学说的正本清源还真是感概。

INFOQ什么时候也开始收水文了? by Chen YuGuo

这也太水了吧~ 都懒得喷了

Java fanboy by Chuck King

阿里真是毁了不少人,09 年毕业的小孩居然以为 Java Web 才是主流互联网解决方案…

这个一般来说,无论是 PHP、ROR还是 Node,论纯 Web 开发效率比 Java 高太多了,Web 从来关注的都是新、奇、快,跟 Java 慢、稳、安全的特性格格不入。更别说 JVM 那硬件开销,一般的小公司用起来完全没意义。

国内很多企业之所以看似喜欢 Java,是因为原来国内 it 行业构成以外包为主(这是个很多人都不愿意提起的黑历史),而 it 外包的主要语言是什么还用说吗?国内 BAT 成长之初,靠的就是吸纳传统 IT 行业的资深开发,而这些企业里能挖得动又愿意做互联网的(无贬义)也就是那些 Java 人才了。这些人成就了国内互联网行业,但也扭曲了国内互联网的技术面。

Java 好歹统制企业应用这么多年了,特性比起其它语言来说那是相当之明显。与其说 Java 无所不能,倒不如说 Java 最适合大企业流水线协作。而 PHP 之类的脚本语言,偏重的则是少数人甚至一个人快速实现。有趣的是这其中的效率哲学本应是企业最看重的,尤其是中小企业。所以说很多企业选择 Java 去做 Web 实属无奈。Java 的生命力强在中间件之类的地方,与硬件结合不需要非常紧密(这里有 C/C++把守),又不需要新奇特的功能(PHP、Python、甚至 JVM 上的其它语言等等都做得非常好),只需要方便快捷地写出安全、稳定的功能型应用。Apache 上面那么多 Java 实现的种类工具,不是没有原因的。

话说回来,在 Web 这个大量应用都跑不出 CURD+安全的小圈子里,Java 的优势根本体现不出来。作者非要拿 Java 跟世界上第 X 好的语言对抗,实在是自讨苦吃。就算真要比,也应该是 Groovy 或者 Scala 才能出来一战。

Re: 感觉看起来很乱,跑题了 by 高 克

如果你是指Java语言末路了 ,那我不做评论!
如果你是指java从业者失业,用Java的就不会用nodeJs?语言能限制住人?

Re: 错误还是挺多的 by 高 克

作者也没有说有必然联系。只是举例了Node的一些优点,方便。

Re: 不存在语言之争, 作者只是站在后端的角度看待node取代view层的可行性问题 by 高 克

同意。整体的架构选型没有普适方案,根据实际情况选型。

我也是醉了 by L TE

!!!淘宝的工程师就这个水平,说实话,我是醉了!!!

(1) Node 不是 Java 的补充,而是替代者
(2) Node 不会替代 Java 多线程,从开始就没这个打算
(3) Node 全面替代并发 IO 消息服务器,一切以信息读取为主要目的的服务器
(4) Java 只有 Nio 才有资格跟 Node 对话,并且我怀疑 Nio 对 Linux 的 epoll 以及 Bsd Unix 的 kqueue 是否实现充分
(5) 补充上一条,Java 多线程服务器没有资格跟 Node 服务器谈并发,你选择 Java 只说明一点:你根本就不会 Node ,你也不会纯正的 Unix 网络编程,因为 Node 只是 Unix epoll / kqueue 网络编程的一层包装器
(6) 我非常怀疑中国厂商有能力编写数据库服务器,对于数据库服务器,最好的语言是 C++ 或者 C,既不是 Node 也不是 Java

我现在很有理由怀疑阿里的服务器并发能力 by L TE

丫完全用钱铺出来的服务器嘛,有钱,任性,天真,马云是舍得花钱

nodejs并不是一无是处的 by 刘 刚

果然写 Java 的人认为什么语言都应该和 Java 一样 by Carter Jim

RT

重要的是成本,而非技术 by zeng alex

js的优势是全栈,web开发php、js等比Java web快速、简单、成本低,但php、python等不是全栈,js全栈成本明显低,而且现在js基本补足了web开发需要的基础设施,这对领导非常有吸引力,新团队自然会使用,这和技术无关

Re: 我也是醉了 by yang jun

Play framework 与 Nodejs

java拯救世界,java拯救全宇宙了? by 陈 成

一直在java的世界里面,感觉java是全能神?全世界那么多语言,nodejs惹了你了?抢了你的饭碗了?

Re: Java fanboy by Huang Jason

这个说得太偏颇了,至少在大型网站的开发中,Java占了很大比重,最典型的国内最大的电商淘宝,阿里系,还有米帝最大的视频流量网站Netflix等,他们的选择不具备代表性吗?Java有足够的性能优化空间,丰富的框架和组件,完整的开发工具链(包括远程调试,详细的内存,栈分析等)。当开发团队足够大的时候,开发效率会逐渐平衡下来。当然如果只是少量开发人员的初创公司,还是有很多其他选择。

Re: 不存在语言之争, 作者只是站在后端的角度看待node取代view层的可行性问题 by sun shumin

很有道理,管理、组织架构上的确是需要考虑的

还能好好聊天么.. by will cheng

无所谓乱喷的人好多。没有人觉得文章写的很好么

题目偏题了 by Baoorng Li

1.你反对有效了么?反对的前提是在08年的淘宝吧?反对的基础是java这么成熟这么多人用?干嘛引入node?但是事实说明了一切
2.js一定会超越java,这是长江后浪呀

没太看懂 by fan qun

感觉有点没太看懂,Node.js 可以只做自己擅长的前端构建、与Client IO 相关的东西,REST API、实时通信等,确实复杂的业务逻辑或数据处理或CPU密集型等Node不擅长的可以通过其他更合适的语言来实现,然后找到合适的方法能被Node调用就可以。复杂的系统不可能只用 Node.js 就能搞定。
另外Node.js 和 Java,这两个和 Nginx 关系大吗?

Re: 不要误人子弟 by 殊 麒

JAVA其实本身是一个伟大的设计,为什么国内JAVA开发出来的精品不多?就是因为太多类似作者这样的人,进入所谓的大公司,使用着号称全球最好的语言和架构(因为选择安全,起码出了问题也可以推脱到语言设计身上而不是自己学艺不精),对各种技术细节其实一知半解便人云亦云。太多北大青鸟、达内之流培训出来的搬砖JAVA码农充斥市场,写出无数垃圾的JAVA程序。

作者的标题是“我为什么反对用Node” by 天 小陈

每个人的看法不同,不明白大家为什么非要说服作者。用Node的人难道会因为作者的文章就放弃node? 之前使用其他语言的普通开发者,换一种语言显然是不现实的。所以作者即使不发文,他们也不会去用node。而对于基础扎实经验丰富的高级工程师,自己换一种语言当然是小菜一碟,但他们不得不考虑生态环境。

Re: 作者的标题是“我为什么反对用Node” by 天 小陈

我们也用node,但我们不会全部用换成node。每种语言都有自己的优势和劣势。

标题有误导 by x w

主要阐述的是不支持“迁移”到Node

Node有它使用的场景 by Yin James

淘宝工程师的实力真的很一般,我见过API这样的json返回:{url=http://jfjfj.com},格式完全不对。而这篇文章更是没有详读的意义,Node有它的使用场境,不是你说不适合淘宝就不适合全世界,思维太窄了,不知道是不是Team leader逼写的(我有过这样的经历)。Node.js有些并不是弱点的弱点,例如弱类型,它能大大提高开发速度,例如if(1),它不必转换成if(true),你可能会抱怨性能损失,但总会有解决的办法,例如WebAssembly。

天猫前端已经全部用node.js代替java了,只能说楼主预测完全错误。、 by sdfds ddd

天猫前端已经全部用node.js代替java了,只能说楼主预测完全错误。、

不错的文章 by 章 哈维

请问楼主,最后一个图里的web访问层怎么理解?

不错的文章 by 章 哈维

请问楼主,最后一个图里的web访问层怎么理解?

node必将崛起 by to zhui

你们是挡不住的

写得好乱 by ken hu

写得好乱,而且写的理由也没什么说服力啊。。。。

误人子弟的文章 by Li Li

java和nodejs我都用过
只能说楼主这点水平就不要出来高谈阔论了
话说infoq的文章水平什么时候这么低了?

图的顺序是不是错了? by wen river

图1和图4好像没错,但
图2的图应该是"node替代java web",而不是"Node作为渲染层加入到传统架构中"
图3的图应该是“Java Web兼容Node的模板层”,而不是“node替代java web”
图5的图应该是“Node作为渲染层加入到传统架构中”,而不是“Java Web兼容Node的模板层”

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

58 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT