为什么新来的经理强烈推荐前后端分离

前言

我在合肥的一家公司上班，公司规模不大不小。不是什么互联网公司，也不像北上广那些大城市的公司，我们的开发技术很保守，运用传统的技术来玩着我们的项目。因为大家都习惯了，也懒得去换什么新潮技术了。前段时间部门招了一位经理。看了我们目前项目的架构，根据项目的实际情况，以及开发情况，就一直推荐使用前后端分离来重构项目。在之前虽然学习了点前后端分离的小知识，但没有深入学习。由于没有切身体会前后端分离的有点，所以不懂为什么经理这么强烈的推荐前后端分离呢？

原来的传统项目模式

部门之前用的开发模式就是采用传统的mvc模式来进行开发。大致如下图

我们的JavaWeb项目都是使用了若干后台框架，springmvc/struts + spring + spring jdbc/hibernate/mybatis 等等。

大多数项目在java后端都是分了三层，控制层（controller/action），业务层（service/manage），持久层（dao）。控制层负责接收参数，调用相关业务层，封装数据，以及路由&渲染到jsp页面。然后jsp页面上使用各种标签（jstl/el/struts标签等）或者手写java表达式（）将后台的数据展现出来，玩的是MVC那套思路。庆幸的是公司还是有前端工程师（把html静态页面切出来的那种)。所以我们和前端一起合作的开发模式类似下面这种。

采用上面的开发模式，我们遇到一些问题

1.初版本项目完成之后，由于项目的原因客户需求确定也不太清晰，经常改需求很大一部分需求都是对页面样式的修改，甚至是对整个项目的页面进行升级，每一次升级都得麻烦前端去重新设计界面或者修改界面，前端界面把新的html搞好了之后会发一个文件过来，我们把新的样式文件加到原来得项目中，但是以前得页面样式又不敢随便删除也还保留在以前得项目中（谁知道哪天客户又觉得以前得样式好看呢）。随着需求的变更，整个项目的变得越来越大（前端样式和业务接口都在里面），每次修改的时候苦不堪言。

2.由于项目不确定需求太多，项目上线之后。项目的浏览器的兼容性和屏幕分辨率的问题暴露出来了，这时候让前端再去改这些页面也是难上加难，前端也没有实际的调试环境。没办法只能自己去搞，但是说实话这些兼容性问题我们真的不擅长，往往这时候就会发生前后端踢皮球的一幕。。

半分离模式

前后端半分离，前端负责开发页面，通过接口（Ajax）获取数据，采用dom操作对页面进行数据绑定，最终是由前端把页面渲染出来。这也就是其他博客里说的，Ajax与SPA应用（单页应用）结合的方式。其结构图如下

步骤如下:

(1)浏览器请求，cdn返回html页面

(2)html中的js代码以ajax方式请求后台的restful接口

(3)接口返回json数据，页面解析json数据，通过dom操作渲染页面

为什么说是半分离的？

因为不是所有页面都是单页面应用，在多页面应用的情况下，前端因为没有掌握controller层，前端需要跟后端讨论，我们这个页面是要同步输出呢，还是异步json渲染呢？因此，在这一阶段，只能算半分离。

这种方式的优缺点有哪些呢？

首先，这种方式的优点是很明显的。前端不会嵌入任何后台代码，前端专注于html、css、js的开发，不依赖于后端。自己还能够模拟json数据来渲染页面。发现bug，也能迅速定位出是谁的问题，不会出现互相推脱的现象。

然而，在这种架构下，还是存在明显的弊端的。最明显的有如下几点：

(1)js存在大量冗余，在业务复杂的情况下，页面的渲染部分的代码，非常复杂。

(2)在json返回的数据比较大的情况下，渲染的十分缓慢，会出现页面卡顿的情况

(3)seo非常不方便，国内的搜索引擎爬虫只会抓取静态数据，不会解析页面中的js，这使得应用得不到良好的搜索引擎支持。

(4)资源消耗严重，在业务复杂的情况下，一个页面可能要发起多次http请求才能将页面渲染完毕。

最终的前后端分离

在这一时期，扩展了前端的范围。认为controller层也属于前端的一部分。在这一时期

前端：负责View和Controller层。

后端：只负责Model层，业务处理/数据等。

可是前端不懂后台代码呀？controller层如何实现呢？

这就是node.js的妙用了，node.js适合运用在高并发、I/O密集、少量业务逻辑的场景。

这时候的开发模式就是下面的这种了

上面这种模式的‘优势在哪呢？

1. 适配性提升

我们其实在开发过程中，经常会给pc端、mobile、app端各自研发一套前端。其实对于这三端来说，大部分端业务逻辑是一样的。唯一区别就是交互展现逻辑不同。如果controller层在后端手里，后端为了这些不同端页面展示逻辑，自己维护这些controller，徒增和前端沟通端成本。

如果增加了node.js层，此时架构图如下

在该结构下，每种前端的界面展示逻辑由node层自己维护。如果产品经理中途想要改动界面什么的，可以由前端自己专职维护，后端无需操心。前后端各司其职，后端专注自己的业务逻辑开发，前端专注产品效果开发。

2. 响应速度提升

我们有时候，会遇到后端返回给前端的数据太简单了，前端需要对这些数据进行逻辑运算。那么在数据量比较小的时候，对其做运算分组等操作，并无影响。但是当数据量大的时候，会有明显的卡顿效果。这时候，node中间层其实可以将很多这样的代码放入node层处理、也可以替后端分担一些简单的逻辑、又可以用模板引擎自己掌握前台的输出。这样做灵活度、响应度都大大提升。

3. 性能得到提升

大家应该都知道单一职责原则。从该角度来看，我们请求一个页面，可能要响应很多看后端接口，请求变多了，自然速度就变慢了，这种现象在mobile端更加严重。采用node作为中间层，将页面所需要的多个后端数据，直接在内网阶段就拼装好，再统一返回给前端，会得到更好的性能。

参考文献

JavaWeb项目为什么我们要放弃jsp

分布式之闲侃前后端分离的必要性