前后端分离架构，Node 中间层

calendar Jun 28, 2019 · 1 分钟 阅读 · node frontend

一、Web 中前后端模板引擎

1、模板引擎的概念

模板引擎（这里特指用于Web开发的模板引擎）是为了使用户界面与业务数据（内容）分离而产生的，它可以生成特定格式的文档，用于网站的模板引擎就会生成一个标准的HTML文档。

模板引擎不只是可以让你实现代码分离（业务逻辑代码和用户界面代码），也可以实现数据分离（动态数据与静态数据），还可以实现代码单元共享（代码重用），甚至是多语言、动态页面与静态页面自动均衡（SDE）等等与用户界面可能没有关系的功能。

模板引擎不属于特定技术领域，它是跨领域跨平台的概念。

后端：在Java、PHP、ASP.net中均有模板引擎
前端模：Vue.JS, AngularJs中也有模板引擎支持

2、前后端分离

前后端分离已成为互联网项目开发的业界标准使用方式，通过nginx+tomcat的方式（也可以中间加一个nodejs）有效的进行解耦，核心思想是前端HTML页面通过AJAX调用后端的RESTFUL API接口并使用JSON数据进行交互。

Web服务器：一般指像Nginx，Apache这类的服务器，他们一般只能解析静态资源；

应用服务器：一般指像Tomcat，Jetty，Resin这类的服务器可以解析动态资源也可以解析静态资源，但解析静态资源的能力没有web服务器好；

一般都是只有web服务器才能被外网访问，应用服务器只能内网访问。

以前的Java Web项目大多数都是Java程序员又当爹又当妈，又搞前端，又搞后端。随着时代的发展，渐渐的许多大中小公司开始把前后端的界限分的越来越明确，前端工程师只管前端的事情，后端工程师只管后端的事情。
正所谓术业有专攻，一个人如果什么都会，那么他毕竟什么都不精。
大中型公司需要专业人才，小公司需要全才，但是对于个人职业发展来说，前后端需要分离。

3、前后端分离之一：后端 MVC

一般从 Model 层中读取数据，然后将数据传到 View 层渲染（渲染成 HTML 文件），而 View 层，一般都会用到模板引擎，比如 PHP(Laravel) 的 blade 模板引擎

以前的 WEB 项目大多会采用这种后台 MVC 模式，这样做有利于 SEO，并且与前端请求接口的方式相比，少了个 HTTP 请求，理论上加载速度可能会稍微快些。

后端 MVC 缺点：

前端写完静态页面，要让后台去「套模板」，每次前端稍有改动，后台对应的模板页面同时也需要改动，非常麻烦。页面中如果有复杂的 JS，前端写还是后端写？前端写的话，没有大量的数据，调试不方便，后端写的话... 所以一般的后端程序员通常都会 JS。

4、前后端分离之二：前端模板引擎

AJAX 的出现使得前后端分离成为可能。后端专注于业务逻辑，给前端提供接口，前端通过 AJAX 的方式向后端请求数据，然后动态渲染页面。

前后端分离最大的缺点可能就是 SEO 无力了，毕竟爬虫只会抓取 HTML 代码，不会去渲染 JS

二、Node 中间层

单纯的后端模板引擎（后端 MVC）以及前端模板引擎方式都有一定的局限性，Node 的出现让我们有了第三种选择，让 Node 作为中间层。

简单地说就是让一门后台语言（比如 Java、PHP）单纯提供渲染页面所需要的接口，Node 中间层用模板引擎来渲染页面，使得页面直出。这样一来，后台提供的接口，不仅 Web 端可以使用，APP，浏览器也可以调用，同时页面 Node 直出也不会影响 SEO，并且前后端也分离，不失为一种比较完美的方案。


在服务器和浏览器之间增加了一个中间层

在前后端彻底分离这一时期，前端的范围被扩展，controller层也被认为属于前端的一部分。在这一时期：
前端：负责View和Controller层。
后端：只负责Model层，业务/数据处理等。

可是服务端人员对前端HTML结构不熟悉，前端也不懂后台代码，controller层如何实现呢？这就是node.js的妙用了，node.js适合运用在高并发、I/O密集、少量业务逻辑的场景。最重要的一点是，前端不用再学一门其他的语言了，对前端来说，上手度大大提高。

可以就把Nodejs当成跟前端交互的api。总得来说，Nodejs的作用在mvc中相当于C（控制器）。Nodejs路由的实现逻辑是把前端静态页面代码当成字符串发送到客户端（例如浏览器），简单理解可以理解为路由是提供给客户端的一组api接口，只不过返回的数据是页面代码的字符串而已。

用NodeJs来作为桥梁架接服务器端API输出的JSON。后端出于性能和别的原因，提供的接口所返回的数据格式也许不太适合前端直接使用，前端所需的排序功能、筛选功能，以及到了视图层的页面展现，也许都需要对接口所提供的数据进行二次处理。这些处理虽可以放在前端来进行，但也许数据量一大便会浪费浏览器性能。因而现今，增加Node中间层便是一种良好的解决方案。

浏览器(webview)不再直接请求JSP的API，而是：
1）浏览器请求服务器端的NodeJS；
2）NodeJS再发起HTTP去请求JSP；
3）JSP依然原样API输出JSON给NodeJS；
4）NodeJS收到JSON后再渲染出HTML页面；
5）NodeJS直接将HTML页面flush到浏览器；

这样，浏览器得到的就是普通的HTML页面，而不用再发Ajax去请求服务器了。

淘宝的前端团队提出的中途岛(Midway Framework)的架构如下图所示：

增加NodeJS中间层后的前后端职责划分：

使用NodeJS作为Web中间层的优势：

a、跨系统、跨终端均可重用页面数据校验、逻辑代码，无需因为新系统、终端的接入而重写校验；

b、只在中间件中做一次数据校验，避免了前端做数据校验的同时后端也要做校验的重复，在有效保证数据的有效性的同时降低了团队整体的工作量；

c、处理数据逻辑，解放了前端既要做页面渲染又要写复杂的逻辑，使得页面开发人员专注于页面渲染，不仅使得分工更为明确，项目协作效率更高，更重要的是快速响应页面使得页面加载更快，用户体验更好，避免了浏览器长时间显示空白页面的不友好体验；

更多可能：

1）适用于高并发、短事务性数据请求处理的应用场景；
以下是nodejs处理请求提供web service服务与java对比：

Nodejs的高性能以及显著的io优势为架构提供了高可伸缩性。

2）适配性提升；我们其实在开发过程中，经常会给PC端、mobile、app端各自研发一套前端。其实对于这三端来说，大部分端业务逻辑是一样的。唯一区别就是交互展现逻辑不同。如果controller层在后端手里，后端为了这些不同端页面展示逻辑，自己维护这些controller，模版无法重用，徒增和前端沟通端成本。 如果增加了node.js层，此时架构图如下：

淘宝基于Node的前后端分离:

  • 最上端是服务端，就是我们常说的后端。后端对于我们来说，就是一个接口的集合，服务端提供各种各样的接口供我们使用。因为有Node层，也不用局限是什么形式的服务。对于后端开发来说，他们只用关心业务代码的接口实现。
  • 服务端下面是Node应用。
  • Node应用中有一层Model Proxy与服务端进行通讯。这一层主要目前是抹平我们对不同接口的调用方式，封装一些view层需要的Model。
  • Node层还能轻松实现原来vmcommon,tms（引用淘宝内容管理系统）等需求。
  • Node层要使用什么框架由开发者自己决定。不过推荐使用express+xTemplate的组合，xTemplate能做到前后端公用。
  • 怎么用Node大家自己决定，但是令人兴奋的是，我们终于可以使用Node轻松实现我们想要的输出方式:JSON/JSONP/RESTful/HTML/BigPipe/Comet/Socket/同步、异步，想怎么整就怎么整，完全根据你的场景决定。
  • 浏览器层在我们这个架构中没有变化，也不希望因为引入Node改变你以前在浏览器中开发的认知。
  • 引入Node，只是把本该就前端控制的部分交由前端掌控。

 

参考资料：
https://www.cnblogs.com/Renyi-Fan/p/9004047.html
https://blog.csdn.net/fuzhongmin05/article/details/81591072
https://blog.csdn.net/u011413061/article/details/50294263
淘宝前后端分离PPT： https://2014.jsconfchina.com/slides/herman-taobaoweb/index.html#/1