为何要先后端分离？

时间 2019-11-13

标签为何后端分离繁體版

原文原文链接

本文转载如下连接：css

http://baijiahao.baidu.com/s?id=1604051586865039850&wfr=spider&for=pchtml

未分离时期前端

MVC，博主就很少作解释了，在早期JSP+SERVLET中的结构图以下vue

大体就是全部的请求都被发送给做为控制器的Servlet，它接受请求，并根据请求信息将它们分发给适当的JSP来响应。同时，Servlet还根据JSP的需求生成JavaBeans的实例并输出给JSP环境。JSP能够经过直接调用方法或使用UseBean的自定义标签获得JAVABeans中的数据。须要说明的是，这个View还能够采用 Velocity、Freemaker 等模板引擎。使用了这些模板引擎，可使得开发过程当中的人员分工更加明确，还能提升开发效率。那么，在这个时期，开发方式有以下两种：node

方式一:jquery

方式二:程序员

先说明一下，方式二已经逐渐淘汰。主要缘由有两点:ajax

(1)前端在开发过程当中严重依赖后端，在后端没有完成的状况下，前端根本没法干活。(2)因为趋势问题，会JSP,懂velocity,freemarker的前端愈来愈少。所以，方式二逐渐不被采用。然而，不得不说一点，方式一，其实不少小型传统软件公司至今还在使用。那么，方式一和方式二具备哪些共同的缺点呢?json

I、前端没法单独调试后端

在项目上线后，遇到一些问题。好比样式出问题了，因为前端不具有项目开发环境，那么就有可能出现以下对话

前端:"我这里没问题啊。后端，你那里正常么？"后端:"我这里不正常啊。要不你过来看一下吧?"前端:"一时我也看不出问题，我也没环境，怎么办？"后端:"你没环境，坐我这边调吧。"而后，前端就满脸不爽的在你那调代码了。更有些情商低的后端就直接在旁边开摁手机，实在是。。。。。

总结，由于前端没法单独调试。一方面开发效率下降。另外一方面，还有可能引起公司内部人员上的矛盾。

II、前端不可避免会遇到后台代码

好比前端可能碰到以下结构的代码

身为前端，在页面里看到了后台代码，必然心里是十分不快的，这种方式耦合性太强。那么，就算你用了freemarker等模板引擎，不能写JAVA代码。那前端也不可避免的要去从新学习该模板引擎的模板语法，无谓增长了前端的学习成本。正如咱们后端开发不想写前端同样，你想一想若是你的后台代码里嵌入前端代码，你是什么感觉？所以，这种方式十分不妥。

III、JSP自己所致使的一些其余问题

好比，JSP第一次运行的时候比较缓慢，由于里头包含一个翻译为Servlet的步骤。再好比由于同步加载的缘由，在jsp中有不少内容的状况下，页面响应会很慢。

半分离时期

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

步骤以下:(1)浏览器请求，cdn返回html页面(2)html中的js代码以ajax方式请求后台的restful接口(3)接口返回json数据，页面解析json数据，经过dom操做渲染页面ps：博主早期就是用jquery的ajax请求，而后这么作的。为何说是半分离的？由于不是全部页面都是单页面应用，在多页面应用的状况下，前端由于没有掌握controller层，前端须要跟后端讨论，咱们这个页面是要同步输出呢，仍是异步json渲染呢？所以，在这一阶段，只能算半分离。这种方式的优缺点有哪些呢？首先，这种方式的优势是很明显的。前端不会嵌入任何后台代码，前端专一于html、css、js的开发，不依赖于后端。本身还可以模拟json数据来渲染页面。发现bug，也能迅速定位出是谁的问题，不会出现互相推脱的现象。然而，在这种架构下，仍是存在明显的弊端的。最明显的有以下几点：(1)js存在大量冗余，在业务复杂的状况下，页面的渲染部分的代码，很是复杂。(2)在json返回的数据比较大的状况下，渲染的十分缓慢，会出现页面卡顿的状况(3)seo很是不方便，因为搜索引擎的爬虫没法爬下js异步渲染的数据，致使这样的页面，SEO会存在必定的问题。(4)资源消耗严重，在业务复杂的状况下，一个页面可能要发起屡次http请求才能将页面渲染完毕。可能有人不服，以为pc端创建屡次http请求也没啥。那你考虑过移动端么，知道移动端创建一次http请求须要消耗多少资源么？正是由于如上缺点，真正的先后端分离架构诞生了

分离时期

在这一时期，扩展了前端的范围。认为controller层也属于前端的一部分。在这一时期前端：负责View和Controller层。后端：只负责Model层，业务处理/数据等。但是前端不懂后台代码呀？controller层如何实现呢？这就是node.js的妙用了，node.js适合运用在高并发、I/O密集、少许业务逻辑的场景。最重要的一点是，前端不用再学一门其余的语言了，对前端来讲，上手度大大提升。因而，这一时期架构图以下

增长node.js做为中间层，具体有哪些好处呢？

(1)适配性提高

咱们其实在开发过程当中，常常会给pc端、mobile、app端各自研发一套前端。其实对于这三端来讲，大部分端业务逻辑是同样的。惟一区别就是交互展示逻辑不一样。若是controller层在后端手里，后端为了这些不一样端页面展现逻辑，本身维护这些controller，徒增和前端沟通端成本。若是增长了node.js层，此时架构图以下

在该结构下，每种前端的界面展现逻辑由node层本身维护。若是产品经理中途想要改动界面什么的，能够由前端本身专职维护，后端无需操心。先后端各司其职，后端专一本身的业务逻辑开发，前端专一产品效果开发。

(2)响应速度提高

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

(3)性能获得提高

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

分离所带来的缺点

在分析缺点以前，容博主先自责一下。博主拿着底层程序员的工资，想着架构师，甚至是部门leader该考虑的问题了。博主有罪！ok，说重点。先上结论，中小型软件公司，慎用先后端分离架构！慎用！

(1)人员问题

你们本身留意一下宣传这种架构的是什么级别的公司，中小型公司通常没有这样的前端资源来支撑这样的架构。若是强推这样的分离架构会致使一个后果，后端被硬逼着去学vue.js，node.js这些，白白增长后端的负担。最后处理很差，会出现一个后端纷纷离职的场面，

(2) 产品迭代周期问题

中小型软件公司，通常须要一个比较快的软件迭代周期。采用分离架构，增长了一个接口制定流程和先后端联调流程。从本质上来讲，放慢了迭代周期。

(3) 前端须要学习业务

原本前端只须要掌管视觉交互的部分。如今由于controller层也归前端管了，前端必须对公司的业务流程有深刻的了解，才能准确的写出显示逻辑。不过这样会让后端以为，前端夺权，前端在混KPI。前端也必需要去学无聊的业务，不过正所谓有得必有失，前端所以也可以站稳脚跟。或许正是由于先后端分离架构的出现，前端能够朝着架构师进军吧。