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

一、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


Comments are closed.