关于node的架构问题
发布于 13 天前 作者 acodercat 803 次浏览 来自 问答

看见一个架构思路是这样的,前端请求node,node再去调用java或者php的接口。为啥前端不直接调用java或者php呢,中间干嘛要加上一个node,node这个时候的作用在哪?

23 回复

做模板渲染。其他一些访问控制、

node 控制 view data,java/php 提供 data servie,职责不一样

你也可以直接用node作为后端啊,但是有很多场景可能node是不擅长的,就需要用其它语言来做,然后用node去调,node作为中间层,对前后端分离比较友好,你可以自行百度node 中间层

微服务中API网关的作用,做外网统一的入口,也可以加入很多功能。

你可以先按你的想法做,网上的不一定都适合你的情况。

看你的具体场景,一些页面涉及比较多不同服务的情况下,用API网关会有一些优势,如果是很简单的需求,就没必要了

不谈场景聊架构是耍流氓。

为啥前端不直接调用java或者php呢

举几个场景:

  • 如果你需要 SEO,服务端渲染?
  • 如果你的后端是微服务的,他们坚持原子化,提供几十个接口,而且接口里面还有很多用不到的字段,你在前端如何处理?

关键问题在于,你要有一个服务自治的 BFF 粘合层,至于它是什么语言,无所谓。

image.png


image.png

Node.js作为一个“后端服务聚合平台”。在Node.js的后面,能够有

  1. 数据库
  2. Solr
  3. Redis
  4. 第三方服务商。比如,百度API,CNode的web API,或阿里的大数据API。
  5. 你们公司自己的 特色 后端服务组件。比如说,基于OpenCV的《人脸识别》。

中间干嘛要加上一个node

  1. 这个人不会 java / php 。
  2. node 在某些方面,开发效率比 java 高。

现实中,大部分是第 1 种情况。

node这个时候的作用在哪?

作用在于你想怎么用它,或者不用它。没什么特别的啦,别想太多。

@atian25 哥,这图是哪里来的,分享一下来源,好呗?太有逼格了。

@yszou 还有一种情况,使用Node.js的话,一般就把前端也一起都做了(技术相通)。就天津的公司来说,还没有只做中间件的岗位。

@stuartZhang

你想多了,没有什么“技术相通”的,语言语法这点东西,跟领域知识比起来,是微不足道的。 能把前端一起做的,是因为本来就会前端,而不是因为后端用了 nodejs ,换句话来说,即使后端用 java / php ,前端一起做也是一样的。 我一直觉得,能从前到后做出完整的“网站”,是一名 web 领域开发者的基本素质吧。(后来这玩意儿被称为“全栈”,变得好像很稀缺了,扯远了)

@yszou 完整是一回儿事儿 质量和效率又是另外一回儿事儿。。。

@yszou 你们公司牛人多。我单位的JAVA程序员对html5技术栈(包括Node.js,他们认为这是同一锅里的肉)从 不屑一顾,到后来的 “很抵触”。让我很失望。他们对CSS几乎一无所知(为此还感觉很光荣),对GLSL从来没有听说过。写js从来都只使用var,也从不Babel预编译。 所以,我之前也发过一个贴子,提到过,他们以“过客”心态写出来的(仅)js代码,还不够,我后面给打补丁,与重构的。更重要的是,团队里,这样的开发者的人数比重还很重。你可以相像我的工作压力。 所以,我一直都很推崇node.js + html5。至少,对js少了一份“过客”心态。也会带有更多责任心地写的代码。 至于,node.js与html5中的js的相通程度,我以《Node.js技术资格认证》的考纲为例来说明。其中有三分之二,不仅对后端开发,对前端编程也同样很重要。

前后端共通部分

  1. Unit Testing 5%
  2. Diagnostics (Basics, Debugging, Performance) 5%
  3. HTTP(S)/TCP 11%
  4. Events 9%
  5. Error Handling 7%
  6. Control flow (Async tasks, Callbacks) 10%
  7. Package.json 5% (写gulp或webpack脚本时,也需要呀)
  8. Javascript Prerequisites (Closures, prototypes, var/let/const) 6%
  9. Security 5%
  10. Module system (Scope) 6% (重点是CMD;这个主要看项目中的模块化技术选型了:CMD, AMD,ES6 Module)

仅微服务端部分:

  1. Child Processes (Basics, no IPC/fork) 7% (前端对应技术是web worker)
  2. Buffer and Streams 9% (前端对应技术是ArrayBuffer与Blob)
  3. File System 7%
  4. CLI (-E, -R, etc) 3%
  5. Process/Operating System (no IPC) 5%

此外,只要不涉及“后端领域”的核心技术。比如,大数据,人脸识别,文本检索,等等。而仅只做一些添删改查操作。使用node.js与使用JAVA, Python没有什么区别。所谓的后端领域知识对“后端中间层 胶水代码”的权重是很低。因为“胶水代码”技术层次比较低,还远远达不到被领域知识影响的水平呢。要知道,目前就连内联数据库SQL语言都不用写了,直接上ORM了。于是,就一个胶水代码的开发者来说,DB就是一个(只能被间接接触的)黑盒子。我还真不感觉,缺DBA人才。至少,我单位里的JAVA程序员都挤破头地想转型做DBA。

另一方面,node.js程序员具有着更多得多的被公司进一步培养的潜质:前端开发呀。

@stuartZhang

所以,我一直都很推崇node.js + html5。至少,对js少了一份“过客”心态。也会带有更多责任心地写的代码。

好吧,如果是因为“人”的问题,那总是有道理。因为我确实没有“因使用的技术方案去改变一个人的态度”这样的经历。

同时,我不认为,因为后端用了 nodejs ,一个原来不会前端的人,让他去写前端,就会有更好的效果(领域知识更重要,而不是语言)。相反,针对 java 换成 nodejs 的后端,也许还有效率的好处,但是对 php 这种则完全没有任何好处了,对于一个不熟悉 nodejs 的原 php 开发人员来说的话。

所以,基于“改变人的态度”,去改变技术方案,我不认同的。

只要不涉及“后端领域”的核心技术。比如,大数据,人脸识别,文本检索,等等。

我理解的“后端领域”,其实不是这些,而是“网络编程”方面的东西, HTTP 协议, Socket API ,网络模型,ER 模型 这些,与应用层开发直接相关的东西。你提到这几个,对于一般的开发人员而言,仅仅是“使用工具”层面的要求吧,就像“会写 SQL” 与“了解 MySQL”之间的区别。

这方面,使用 node.js 与其它动态语言是没有什么区别的(使用是与静态类的语言,还是有些区别的),所以我说“语言不重要”。

另一方面,node.js程序员具有着更多得多的被公司进一步培养的潜质:前端开发呀。

这话是没错,不过我还真没碰到过这种例子就是了—— 从 nodejs 作后端开发入行。


重审一下,我说的是,因为后端用了 nodejs ,而认为前后端就更容易让一个人给都做了的想法,是不对的。一个人能前后都做,与后端用什么没关系,只是在于那个人原本会什么。引审一下,就是,前端去学了 nodejs 做后端,与后端学前端的一些东西,这两者没什么区别的,跟什么技术,语言也没有必然关系。

@yuu2lee4

不要想当然了。

前端独立,要体现质量与效率的前提,是多出来的人,说白了是资源的投入换取的回报。并且这个投入与产出比并不是太高,以至于并不是小团队玩得起的。

后端用的是动态语言 php / ruby / python 什么的,效率最高的方式就是一个人前后端一起做,直接套模板。(特殊情况是那种定制编辑器的重交互页面,基本上都是前端逻辑,不过这种场景不多)。

至于质量,其实不太好说的,没什么客观的标准。我自己的一个标准就是,一套代码维护个半年一年就要抛弃重来的,就别谈质量了。一套代码能持续维护三年到五年,再说吧。基于这个标准,你会发现,前端独立的,质量“惨不忍睹”。

@yszou

  1. 我想通过影响 项目参与者的 知识结构,来间接地 影响 他们对一些 既定事物 的想法 与 态度。至少,能够让项目参与者了解:怎么能写出一套让人接受的JS代码。
  2. 我宁愿后端使用Python与PHP。以我亲身经历,脚本类开发者对html5技术栈的 抵触心理 远比 JAVA要低得多。可能是因为开发体验相近吧。毕竟,JAVA的代码写起来太爽了。至少,从开发体验来说,JAVA开发者 可以认定 目前脚本的开发体验都是 垃圾。
  3. 在我单位《ER 模型》一般都 由项目组的技术Leader都做好了。普通的开发者接触不到那个环节。相反,普通的开发者,直接拿着ER图,创建DAO类,自动化生成数据表了。唉,你看看:现在创建数据表都不用 Mysql客户端了。我都已经N年没有写过SQL了。一组DAO类,就在APP层自动完成了。至少,我单位不需要人人都是Leader水平。也不需要,人人都会画ER图,只要能看明白就行了。
  4. 至于HTTP协议与Web Socket协议与SSE协议,这个是入行WEB基本知识要求,无论前后端开发者。
  5. 现在学习html5,都要首先了解《预编译》与《打包》技术。而,目前哪一款《预编译器》与《打包器》不是基于Node.js命令行小程序的?所以,我说,大部分的html5开发者都 从Node.js开始的。

我认为咱们认知上的差别主要来源于:你们团队的开发者是“技术歧视心态”很少(可能,几乎没有)。另外,就是他们的学习能力更强。但是,我没有你那么幸运。

@stuartZhang 你对《Node.js技术资格认证》的分类是有问题的

@stuartZhang

我想通过影响 项目参与者的 知识结构,来间接地 影响 他们对一些 既定事物 的想法 与 态度。至少,能够让项目参与者了解:怎么能写出一套让人接受的JS代码。

理解的,我前面也说了,人的问题,总是有理的。

我宁愿后端使用Python与PHP。以我亲身经历,脚本类开发者对html5技术栈的 抵触心理 远比 JAVA要低得多。

这点确实,或者准确点说, java only 的人员,可以在你说的现象上比较突出吧。(有多种语言经验的,看待这些都很平淡了)

现在学习html5,都要首先了解《预编译》与《打包》技术。而,目前哪一款《预编译器》与《打包器》不是基于Node.js命令行小程序的?所以,我说,大部分的html5开发者都 从Node.js开始的。

这点我倒不认同,干活的本质是解决问题,我觉得直接在页面中写 js 作为开始比较好啊。前端的那套工程环境的事,不需要一开始就抛出来吓人。以前没有这些东西的时候,一样可以把一个网站,或者说一个页面做得好好的嘛。有一个过程好些。

@yszou 首先,我单位里的那些JAVA从来不承认他们是Java Only的。他们也能写JS的,虽然那个JS写得让我很郁闷。 其次,关于最后一点,与项目的技术选型有关,比如说,

  1. React/Vue.js的选择,
  2. 还有就是:在项目一开始,就需要决定 是否全面使用ES 6/ES 7语法。
  3. 选择哪一种模块管理策略(AMD, CMD或ES6 Module)。

这些都离不开Babel,Webpack甚至Gulp/Grunt。基于Babel预编译的代码,即使不借助任何“类jQuery库”都能轻松兼容到IE 8。当前,前提是:别使用CORS或Service Worker的无法模拟的语言新特性。

至于,在网页里写js代码的事,我们webpack打包之后的代码都被内联到html页里了。但是,直接在html页里手写js代码的事,已经几乎没有了。可能是因为 JS模块化 的全面铺开的原因吧。目前,国内浏览器还没有能够直接认识ES 6 Module的能力,虽然Chrome 61已经能够支持script type="module"了。

@7demo 模板渲染你现在主要用哪个?

回到顶部