More than code
Welcome to the website

基于NodeJS重新思考前后端分离

一、认识前后端分离

在传统的web应用开发中,大多数的程序员会将浏览器作为前后端的分界线。将浏览器中为用户进行页面展示的部分称之为前端,而将运行在服务器,为前端提供业务逻辑和数据准备的所有代码统称为后端。

对于前后端分离这个概念可能会对它产生一些误解,误以为前后端分离只是一种web应用开发模式,只要在web应用的开发期进行了前后端开发工作的分工就是前后端分离。其实前后端分离并不只是开发模式,而是web应用的一种架构模式。在开发阶段,前后端工程师约定好数据交互接口,实现并行开发和测试;在运行阶段前后端分离模式需要对web应用进行分离部署,前后端之间使用HTTP或者其他协议进行交互请求。然而作为一种架构模式,我们在实施的过程中主要对以下四个方面来进行比较和重新认识。

前后端分离大概可以从四个方面来理解:

  1. 交互形式
  2. 代码组织方式
  3. 开发模式
  4. 数据接口规范流程

1. 交互形式


在前后端分离架构中,后端只需要负责按照约定的数据格式向前端提供可调用的API服务即可。前后端之间通过HTTP请求进行交互,前端获取到数据后,进行页面的组装和渲染,最终返回给浏览器。

2. 代码组织方式


在传统架构模式中,前后端代码存放于同一个代码库中,甚至是同一工程目录下。页面中还夹杂着后端代码。前后端工程师进行开发时,都必须把整个项目导入到开发工具中。

而前后端分离模式在代码组织形式上有以下两种:

  • 半分离
    前后端共用一个代码库,但是代码分别存放在两个工程中。后端不关心或很少 关心前端元素的输出情况,前端不能独立进行开发和测试,项目中缺乏前后端交互的测试用例。
  • 分离
    前后端代码库分离,前端代码中有可以进行Mock测试(通过构造虚拟测试对 象以简化测试环境的方法)的伪后端,能支持前端的独立开发和测试。而后端 代码中除了功能实现外,还有着详细的测试用例,以保证API的可用性,降低集成风险。

3. 开发模式


之前的架构属于传统的MVC架构,整体没有进行前后端分离,在项目的开发阶段,前端工程师负责编写HTML,完成前端的页面设计并套页面,然后再使用模板技术将写好的前端代码转换为Smarty脚本,同时内嵌一些后端提供的模板变量和一些逻辑操作。应用运行期,将全部代码进行打包,和后端代码部署到同一服务器上,同时会进行简单的动静态分离部署。

此时,应用的开发流程如下图所示。

而在实现前后端分离架构之后,前端工程师只需要编写HTML、js、CSS等前端资源,然后通 过HTTP请求调用后端提供的服务即可。除了开发期的分离,在运行期前后端资源也会进行分离部署。

前后端分离之后,开发流程将如下图所示。

通过上面的两幅流程图,不难发现,在开发模式上,前后段分离不仅仅只是工程师的分工开发,更重要的意义在于实现了前后端的并行开发,简化了开发流程

4. 数据接口规范流程


在开发期间前后端共同商定好数据接口的交互形式和数据格式。然后实现前后端的并行开发,其中前端工程师再开发完成之后可以独自进行mock测试,而后端也可以使用接口测试平台进行接口自测,然后前后端一起进行功能联调并校验格式,最终进行自动化测试。

二、前后端分离的四个好处

前后端分离模式和传统的web应用架构相比有很大的不同,到底分还是不分,这还真是个问题。

从目前应用软件开发的发展趋势来看,主要有两方面需要注意:

  1. 越来越注重用户体验,随着互联网的发展,开始多终端化。
  2. 大型应用架构模式正在向云化、微服务化发展。

我们主要通过前后端分离架构,为我们带来以下四个方面的提升:

  • 为优质产品打造精益团队
    通过将开发团队前后端分离化,让前后端工程师只需要专注于前端或后端的开发工作,使得前后端工程师实现自治,培养其独特的技术特性,然后构建出一个全栈式的精益开发团队。
  • 提升开发效率
    前后端分离以后,可以实现前后端代码的解耦,只要前后端沟通约定好应用所需接口以及接口参数,便可以开始并行开发,无需等待对方的开发工作结束。与此同时,即使需求发生变更,只要接口与数据格式不变,后端开发人员就不需要修改代码,只要前端进行变动即可。如此一来整个应用的开发效率必然会有质的提升。
  • 完美应对复杂多变的前端需求
    如果开发团队能完成前后端分离的转型,打造优秀的前后端团队,开发独立化,让开发人员做到专注专精,开发能力必然会有所提升,能够完美应对各种复杂多变的前端需求。
  • 增强代码可维护性
    前后端分离后,应用的代码不再是前后端混合,只有在运行期才会有调用依赖关系。

应用代码将会变得整洁清晰,不论是代码阅读还是代码维护都会比以前轻松。

三、怎样做前后端分离

  • 前端:负责View和Controller层。
  • 后端:负责Model层,业务处理/数据等。

如果前端掌握了Controller,我们可以做url design,我们可以根据场景决定在服务端同步渲染,还是根据view层数据输出json数据,我们还可以根据表现层需求很容易的做Bigpipe,Comet,Socket等等,完全是需求决定使用方式。

四、基于NodeJS的全栈式开发

如果想实现上图的分层,就必然需要一种web服务帮我们实现以前后端做的事情,于是就有了标题提到的“基于NodeJS的全栈式开发”

关于这张图做如下解释:

1. 为什么要加NodeJS这一层

现阶段我们主要以后端MVC的模式进行开发,这种模式严重阻碍了前端开发效率,也让后端不能专注于业务开发。解决方案是让前端能控制Controller层,但是如果在现有技术体系下很难做到,因为不可能让所有前端都学java,安装后端的开发环境,写VM。NodeJS就能很好的解决这个问题,我们无需学习一门新的语言,就能做到以前开发帮我们做的事情,一切都显得那么自然。

2. 性能问题

分层就涉及每层之间的通讯,肯定会有一定的性能损耗。但是合理的分层能让职责清晰、也方便协作,会大大提高开发效率。分层带来的损失,一定能在其他方面的收益弥补回来。
另外,一旦决定分层,我们可以通过优化通讯方式、通讯协议,尽可能把损耗降到最低。

举个例子:
淘宝宝贝详情页静态化之后,还是有不少需要实时获取的信息,比如物流、促销等等,因为这些信息在不同业务系统中,所以需要前端发送5,6个异步请求来回填这些内容。
有了NodeJS之后,前端可以在NodeJS中去代理这5个异步请求,还能很容易的做Bigpipe,这块的优化能让整个渲染效率提升很多。
可能在PC上你觉得发5,6个异步请求也没什么,但是在无线端,在客户手机上建立一个HTTP请求开销很大,有了这个优化,性能一下提升好几倍。

3. 前端的工作量是否增加

相对于只切页面/做demo,肯定是增加了一点,但是当前模式下有联调、沟通环节,这个过程非常花时间,也容易出bug,还很难维护。
所以,虽然工作量会增加一点,但是总体开发效率会提升很多。

另外,测试成本可以节省很多。以前开发的接口都是针对表现层的,很难写测试用例。如果做了前后端分离,甚至测试都可以分开,一拨人专门测试接口,一拨人专注测试UI(这部分工作甚至可以用工具代替)。

4. 增加Node层带来的风险怎么控制

随着Node大规模使用,系统/运维/安全部门的同学也一定会加入到基础建设中,他们会帮助我们去完善各个环节可能出现的问题,保障系的稳定性。

5. Node什么都能做,为什么还要JAVA

我们的初衷是做前后端分离,如果考虑这个问题就有点违背我们的初衷了。即使用Node替代Java,我们也没办法保证不出现今天遇到的种种问题,比如职责不清。我们的目的是分层开发,专业的人,专注做专业的事。基于JAVA的基础架构已经非常强大而且稳定,而且更适合做现在架构的事情。

五、部署案例

1. 以百度网盘为例分析。

1.1 分离之前的架构


前后端分离之前,网盘的后端架构是Nginx服务和后端的PHP服务以及前端的静态资源都是部署在同一台服务器上。当浏览器发起访问请求时,如何请求的是静态资源,Nginx直接把静态资源返回给服务器;如果请求的是页面或后端服务,则经Nginx将请求转发到后端的PHP服务器,完成响应后经Nginx返回到浏览器。

注:此图中的Nginx属于后端机,主要针对前端机Nginx转发过来的请求进行识别弄转发给本机的PHP服务;前端机和后端机各有一个Nginx服务。

这个方案比较简单,易于实现,而且能到达前后端解耦的目的。而且很多公司目前都是基于这种架构或者一定的变形来实现的web应用。

但是对于页面量比较大,需要有良好SEO的应用来说,此方案缺点也较为明显。因为 Nginx只是向浏览器返回页面静态资源,而国内的搜索引擎爬虫只会抓取静态数据, 不会解析页面中的js,这使得应用得不到良好的搜索引擎支持。同时因为Nginx不会进行页面的组装渲染,需要把静态页面返回到浏览器,然后完成渲染工作,这加重了浏览器的渲染负担。

另外,由于这种架构使得前端工程师的工作范围只局限在了浏览器一侧,导致在进行一些特殊的性能优化时,前端工程师无法独立完成,还需要后端开发人员的配合,这也一定程度上影响了双方的进度。

1.2 分离之后的架构


前后端分离之后,我们在原先的架构上再单独增加了一个Node Server作为中间层,将前端资源部署到Node Server中。Node Server还实现了一层数据代理服务,负责与提供数据的后端服务进行通信。

并且还在这个基础上增加并使用了前端机(前端机是对所有的请求进行预处理和负载均衡,然后再转发给后端机。)的Nginx服务,浏览器发起的请求经过前端机的Nginx进行分发,URL请求统一分发到Node Server,在Node Server中根据请求类型从后端服务器上通过RPC服务请求页面的模板数据,然后进行页面的组装和渲染;API请求则直接转发到后端服务器,完成响应。

注:此图中的Nginx属于前端机。

1.3 前后端分离方案对比


2. 淘宝基于Node的前后端分离

上图是我理解的淘宝基于Node的前后端分离分层,以及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,只是把本该就前端控制的部分交由前端掌控。

六、结语

前后端分离并非仅仅只是前后端开发的分工,而是在开发期进行代码存放分离、前后 端开发职责分离,前后端能够独立进行开发测试;在运行期进行应用部署分离,前后 端之间通过HTTP请求进行通讯。前后端分离的开发模式与传统模式相比,能为我们 提升开发效率、增强代码可维护性,让我们有规划地打造一个前后端并重的精益开发 团队,更好地应对越来越复杂多变的Web应用开发需求。

参考文章

赞(0) 打赏
未经允许不得转载:李帅帅空间 » 基于NodeJS重新思考前后端分离

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏