php nodejs php nodejs 性能 收藏 0

我对Node作为中间层的一些想法

在互联网诞生之初，网页还只是一个承载静态信息的载具，只能显示一些纯静态的文本和图片。这种静态页面不能读取后台数据库中的数据，是一个完全封闭的生态，我们姑且称这是 Web 发展的“青铜时代”。

而为了使 Web 更加充满活力，开发者们一次又一次的对动态网页这一高地发起进攻，主要目标是允许网络开发人员快速编写动态页面。这一个阶段，以 PHP、JSP、ASP.NET 为代表的动态页面技术相继诞生。在这些动态页面技术面前，网页不再是静止的，可以根据不同的人，不同的地域，不同的时间段呈现出不同的数据结果，从这时开始，Web 发展进入了其“白银时代”。

随后，各种各样的网站如雨后春笋般出现，网站的复杂程度也呈爆炸式增长，程序员既绘制页面又控制业务逻辑的难度也越来越大，这时，前后端分离的概念被提出来了。核心理念是「让专业的人做专业的事」。于是，程序员的职业发展来到了一个分叉点，是选择专门绘制页面的程序员还是专门控制业务逻辑的程序员成为了一个争论点，直至今日。

在这个阶段，前端是完全不需要参与后台的数据处理，他只需要利用约定好的接口拿到合适的数据，然后渲染页面即可。而且这么做的一个好处是，开发进度不会堵塞，后端开发不需要等待前端完成之后才能继续，只要 Mock 完整数据之后前后端联调即可。

那这个阶段，是 Web 发展的“黄金时代”吗？

私以为不是。

前后端分离是一个非常好的思想，让专业的人做专业的事情这一美好愿景，在实际的过程中却受到了很多挑战。 举个例子，前端的接口通常是按照逻辑来展现数据的，有时候为了提高效率，后端会根据前端需要的数据结构做数据封装。这就意味着后端还是做了 view 层的工作，违背了前后端分离的初衷。

为了解决上述问题，有人提议干脆把 Controller 和 View 的工作都转移到前端，后端只负责处理 Model 的数据与底层逻辑。于是 Node 中间层这个解决方案就被提出来了，这种方案好不好我们暂且按下不表，先来说说这一个中间层的职能是什么以及架构是什么样的。

其实中间层要做的事很简单。

原来客户端直接向 Server 发送请求，Server 层收到请求后经过计算处理将结果返回给浏览器。如今浏览器将请求发送给 node 层，node 层经过一轮处理后再向 Server 层发起请求。Server 层处理完毕将响应结果返回给 node 层，node 层最后将数据返回给浏览器。因为 node 层的出现，Server 层可以只用关注业务本身，而不必理会前端对字段的特殊要求。

而且，由于增加了 NodeJS 层，每种前端的界面展示逻辑由 NodeJS 层自己维护。产品经理在中途如果想要改动界面，可以由前端自己维护，无需后端操心。前后端各司其职，后端专注于自己的业务逻辑开发，前端专注于产品效果开发。这样就实现了更彻底的前后端分离。

乍一看是不是觉得这个方案很完美呢？但事实真的是这样吗？

细心留意文章里的图，就会发现整个系统越来越复杂，系统复杂会带来很多问题，比如人员沟通成本增加，系统整体性能下降，安全隐患增加等等。这些都是老生常谈的，只要是增加系统的层级就一定会出现这些问题，还有什么其他的问题吗？

我们先思考一个事情，这些东西是不是非 Node 不能做？

显然不是。在 Node 做中间层之前，这些工作本来就是由传统的后端去统一做的，理论上只要在服务层做好分层架构的设计，这些问题都会迎刃而解，那么为什么这几年还会有人鼓吹 Node 中间层呢？

有人会说 Node 很适合做 SSR（服务端渲染）。的确这是 Node 的一个优势，但还是那个问题，这件事是不是非 Node 不可？

现在使用 Node 做 SSR 的，是不是觉得设计理念和多年前的 JSP 很相似呢？

那么究竟是什么原因，让这么多人去探索这条道路呢？

下面是我的私货环节。

事先申明，以下内容，纯属个人观点，不喜勿喷。

我们先来看一个段子：「PHP 是世界上最好的语言」

相信听到这句话的人一定会觉得很好笑，虽然这已经成为了一个段子，但是反应的却是一个客观存在的情况——鄙视链。

鄙视像条食物链，是个绕不开的怪圈。在这个怪圈中，每一个人，都在链条的最末端。

而之所以会有这样的鄙视链出现，和工作难度及待遇有很大关系。

一个好的系统应该是 高可用的、高并发以及高性能 的，而这三者，通常是后端程序员的事情，前端程序员所能发挥的作用有限。干的活不重要，待遇自然提不起来，鄙视链也应运而生了。

于是，为了反击，学习成本低、可以迅速上手的 NodeJS 便被前端程序员们寄予厚望，开始接管一些后端程序员不愿意去做的边角活（数据格式转换，字段校验），想着前端负责的职能不再是绘制页面这种基础的事情，重要性就会逐渐凸显出来。

说到底，还是因为前端要提升在业务中的比重，由此提升自己的地位。至于 NodeJS 和传统服务端语言相比究竟有没有一战之力，似乎也就没那么重要了。说不定未来 Node 中间层发展好了之后，再进行解耦拆分也说不定呢。

于是你会发现，公司里的前端同学往往会以架构设计为理由推动后端人员在整个系统设计时增加一个 Node 中间层，好让他们大展拳脚，至于后端人员愿不愿意去把这些边角工作交由 Node 层人员去做就值得商榷了（毕竟后端也有很多方案处理这种数据需求，比如 GraphQL 就是其中一种)。

套用盗墓笔记里的一句话，「最复杂的不是软件系统，是人心」。

NodeJs(一)我对NodeJs的认知

欢迎来到我的NodeJs专题系列，更多精彩内容持续更新中，敬请关注！

前面我已经分享了100+篇前端相关的技术文章，都是自己平时工作中遇到的一些问题的问题，还有是我平时自学的内容。但是那些前端文章99%都是要基于浏览器。其实在大前端时代，还有一个很重要的组成部分，那就是NodeJs了。接下来的专题，我们就来分享一下NodeJs的基本和高级应用吧

本章，我将从以下几个方面来分享一下NodeJs的相关知识点。

• NodeJs是什么？
• NodeJs有什么优势和不足
• NodeJs有哪些应用

前端开发在2009年之前，应该说都是基于浏览器的，也就是说，前端程序员能控制的就只有浏览器了。

比如我们想操作一下我们本地的文件，连接一下数据库等，基于安全机制，这些都是不被允许的。

这也就导致了前端一直是在程序员的鄙视链的最底端了。好像那时候，ajax好像是前端程序员唯一的“遮羞布”了。

然后，我们依然脱离不了后端的支持。

直到2009年，NodeJs横空出世。彻底巅覆了前端的技术分支，NodeJs也可以像Java,php等后端语言一样进行服务端的开发了。

根据官网的介绍，NodeJs是基于Google的chrome V8引擎开发的。

先来简单说一下，chrome v8是啥？它是google公司基于C++编写的，它可以用一解析JavaScript,v8的性能是非常高效的。

NodeJs并不是一门新的语言，它是一个js的一个运行环境，这个运行环境可以理解就是可以开发服务器端的程序。它的语法和普通的JS没什么区别。因此对于前端程序员来说，是非常友好的。

NodeJs的最大特点就是它 基于事件驱动异步非阻塞I/O

基于事件驱动是什么意思呢？事件这个概念在我们传统的dom中应该很常见了吧，举个例子

比如我们要读取一个本地大文件。我们只需要传入一个文件路径，然后加上一个回调函数，当文件读取完成后，将会触发一个成功的回调的函数，从而我们可以继续处理后面的逻辑。而读取文件的过程本身就是一个耗时的过程。异步将不再阻塞后面的程序继续运行

如果这个过程是一个同步的过程，那个后面的操作将要等到文件读取完成后再去执行了，这就造成了阻塞。像java php,他们都是同步的操作。

所以Nodejs的优势就已经体现出来了，对于高并发的网站，用NodeJs来处理用户的请求将比java和php都要高效。

哇，感觉NodeJs太牛了，那它有缺点吗？能把java,php它们干趴下吗？答案也很明确：不能。

既然NodeJs处理并发的能力要远远优于java,php,那为什么现在很多网站或者App的后台还是基于Java呢？

前段时间，面试的过程一般都会问面试官他们公司的后端用的是什么语言，答案都是java,只有一家是python。

NodeJs有一个缺点（痛点），那就是NodeJs计算能力远远不如java这样的编译型语言。

NodeJs的地位好像有点尴尬，有高并发，但是后台一般又不用它。一般来说，一个大型的网站的后台可以使用多种语言，会结合每个语言的优势发挥各自的优势。

比如现在很多网站，都是用NodeJs来处理高并发，然后用Java这种稳定型的去后端的服务。Node就是我们常说的中间层了。

那。。除了作网站的中间层，还能做什么呢？大家不要忘了，自从NodeJs出来了，前端开发越来越复杂，也在慢慢的走向工程化了。

这其中最流行的打包工具就属webpack了，webpack本身，基于webpack的插件，loader都是基于Nodejs,如果没有NodeJs作为底层服务，这些将不复存在了。

当然，基于Nodejs的应用远远不止这些。更多Nodejs的知识点，后续将为大家一一分享。

• 我们可以通过JS语法可以实现java实现的任何功能。他们各自有自己的优势。没有谁优于谁。
• Nodejs为前端开疆拓土。为前端注入了新的血液。
• NodeJs在前端工程化的应用。

这里是【畅哥聊技术】的《NodeJs》专题系列。更多内容持续更新中。

下期我们接着聊，未完待续。。

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com