node作为中间层的一些看法

1  知乎问答

  

我之前多个项目的场景，前端渲染交给node来做，前端团队自己负责整个前端的发布构建，整个工作流使用gulp或者webpack搭建起来。业务团队是典型的java后端，他们有自己成熟的架构，node服务器通过thrift来做rpc调用。实践起来，两个团队配合相对比较和谐，相互独立。

这种场景比较适合前端爱钻研折腾，后端团队比较成熟，或者保守。

一般这种情况下，会将node作为一个中间层，这样传统的"前端-java"架构就变成了"前端-node-java"的架构。

这种架构的好处主要就是实现前后端分离。在传统的web应用中，java同时负责业务逻辑以及页面的服务器端渲染，这种架构下，前后端开发的模式主要是这样的：

1. 前端开发好demo页面（包括css，js，html）

2. 前端将css，js等静态资源交给cdn等静态服务器，而html文件则交给java后端，让后端将demo页面转为vm模板。用户请求时，java首先将vm模板渲染成html，然后再交给浏览器。

这种模式之下，由于后端对于前端知识的不熟悉，导致在html转换vm这一个过程中，前后端交流沟通的成本比较高，同时，这也等于束缚住了前端的手脚，让前端无法随心所欲的对页面进行一些个性化的优化，定制等等。

为了克服这种开发模式的缺点，最理想的情况是，java之负责业务逻辑，对外，它只提供api数据接口，剩余页面渲染相关的工作都交给前端来完成。

目前有一种方案是前端页面完全交给javascript来进行纯异步渲染，也就是说html文件也传到cdn上面作为静态文件，当用户请求的时候，页面中的数据通过js的ajax请求来渲染。这样做确实是实现了前后端分离没有错，但是缺点是，首先这种架构下，页面首屏渲染会比较慢，因为在加载好html之后，还要额外通过ajax请求数据然后才能填充页面；此外，由于搜索引擎的爬虫无法爬下js异步渲染的数据，导致这样的页面，SEO会存在一定的问题。

为了克服上述方案的缺点，业界提出了使用node作为中间层的方案。在这种架构下，模板都放在node端，当用户发起请求时候，请求首先到达node端，然后node向后端的java请求数据，拿到数据后填充渲染html模板，然后再返还给用户。这个架构下，浏览器端和node端都由前端开发人员来负责，java后端只需要处理业务逻辑并提供api接口，这样既实现了前后端分离，由解决了异步渲染中的种种问题。

目前很多公司都在事件这种架构，最知名的，当属淘宝的midway架构，楼主感兴趣可以关注一下。

2 node和java对比

事实上 Node.js 自身依然存在许多问题——就像许多其他竞争对手一样，但是目前在 Web 浪潮的席卷下，它的优势显然更被人们关注，而劣势则尚未在大多数项目中显现。

--------------------------------

注意：下面的内容是我早前写的，关于 Node.js 自身存在的一些问题，已经不符合 2017 年 Node.js 的情况了。我最近会考虑重新修正一下。

你可能看到了 Node.js 的种种优点，但却忽略了它存在的各种问题：

• 在虚拟机层面 Node.js 基于的 v8 VM 看起来很不错，但和 Java 的 VM 一比，差距甚远。在服务器领域，特别是拥有众多 CPU 和大量内存的环境下，Java 的 VM 几乎是你能在地球上找到的最好的 VM。而 v8 既不能充分利用多 CPU 的性能，也不能将内存充分利用。你唯一能做的事情就是开很多个 Node.js 实例来缓解，但这进一步带来了更多的问题。
• 在语言层面 JavaScript 本身的设计让你感觉很灵活，因为它基本上是不对类型进行约束的，只有当运行过程中发生了错误才会提示你，毕竟在浏览器环境内，这算不上什么问题；但在一个团队内进行协作时，你会深刻的明白类型系统如果能在运行前就帮你找出那些低级的类型错误问题，将会节省你多少的时间和金钱。特别是别忘了，系统总是在演进的，一个稍微复杂些的业务系统就拥有几十个乃至上百个类型，而类型修改又往往很频繁，想想这个过程里会发生些什么你就明白了。（更新：TypeScript 的出现很大程度解决了这个问题，目前在实践层面而言，至少我们确实知道这个问题能够解决；而且 WebAssembly 在 Node.js 中的落地未来我们甚至可以期待更好的解决方案）
• 在领域应用层面 Node.js 在 Web 开发领域特别是其中的前端部分已经达到了惊人的繁荣程度，甚至有不少重要系统的后端部分也基于 Node.js 完成。但如果仅凭这些就轻易的认为 Node.js 将会一统全栈打败包括 Java 在内的其它语言是很幼稚的。首先，在一个大型的系统架构中，整个系统是拆分成很多很小的业务系统的，这些系统往往通过消息队列（如 RabbitMQ、Kafka 等等）相互连接起来。也许在小型 Web 站点中，你从来没用过这些。但相信我，在但凡稍微大一些的业务系统中，都是这么干的。这些消息队列服务存在的理由就是将各个子系统解耦。这样一来，你可以在前端部分应用 Node.js 进行快速开发，在业务处理部分使用 Java 来完成。数据分析系统却可以使用 Python/Scala （例如基于 Spark）实现。大型业务系统的架构者们都是些经验丰富的老手，他们知道每个语言/系统的利弊，也知道世界总在变，今天是 Node.js、明天也许就是另一个新秀，因此在整个业务系统中，你要做的根本不是“统一”，反而是“分离”。这样的设计才能够预留出扩展和变更的机会。

总的来看，Node.js 特别适合中小型系统的快速开发，而当系统变得复杂以后，Node.js 更适合充当 Web Gateway 的角色，以及用于前端开发。在这两方面它拥有绝对优势。

综上所述，我相信 Node.js 会拥有大量的用户，但其未来发展也存在天花板，适用领域有局限性。

（2017年补充说明）

个人背景：我从 2011 年底开始一直使用 Node.js 至今，并通读过它大部分模块的源代码，甚至为了阅读它的源码（以及其他 JavaScript 大型项目的源码），我还专门创建了 lambda-view 这一项目：Jianru-Lin/lambda-view。目前我的工作主要集中在 Node.js 和 Erlang 方面。