前后端分离技术架构概述（转载）
前后端分离技术架构概述（转载）
1、背景
前后端分离已成为互联⽹项⽬开发的业界标准使⽤⽅式，通过nginx+tomcat的⽅式（也可以中间加⼀个nodejs）有效的进⾏解耦，并且前后端分离会为以后的⼤型分布式架构、弹性计算架构、微服务架构、多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS 等等）打下坚实的基础。这个步骤是系统架构从猿进化成⼈的必经之路。
核⼼思想是前端HTML页⾯通过AJAX调⽤后端的RESTFUL API接⼝并使⽤JSON数据进⾏交互。
Web服务器：⼀般指像Nginx，Apache这类的服务器，他们⼀般只能解析静态资源；
应⽤服务器：⼀般指像Tomcat，Jetty，Resin这类的服务器可以解析动态资源也可以解析静态资源，但解析静态资源的能⼒没有web 服务器好；
⼀般都是只有web服务器才能被外⽹访问，应⽤服务器只能内⽹访问。
以前的Java Web项⽬⼤多数都是Java程序员⼜当爹⼜当妈，⼜搞前端，⼜搞后端。随着时代的发展，渐渐的许多⼤中⼩公司开始把前后端的界限分的越来越明确，前端⼯程师只管前端的事情，后端⼯程师只管后端的事情。正所谓术业有专攻，⼀个⼈如果什么都会，那么他毕竟什么都不精。⼤中型公司需要专业⼈才，⼩公司需要全才，但是对于个⼈职业发展来说，前后端需要分离。
2、未分离时代（各种耦合）
早期主要使⽤MVC框架，Jsp+Servlet的结构图如下：
web后端是指什么
⼤致就是所有的请求都被发送给作为控制器的Servlet，它接受请求，并根据请求信息将它们分发给适当的JSP来响应。同时，Servlet 还根据JSP的需求⽣成JavaBeans的实例并输出给JSP环境。JSP可以
通过直接调⽤⽅法或使⽤UseBean的⾃定义标签得到JavaBeans中的数据。需要说明的是，这个View还可以采⽤ Velocity、Freemaker 等模板引擎。使⽤了这些模板引擎，可以使得开发过程中的⼈员分⼯更加明确，还能提⾼开发效率。
那么，在这个时期，开发⽅式有如下两种：
⽅式⼆
⽅式⼀ ⽅式⼆
⽅式⼀
这种⽅式耦合性太强。那么，就算你⽤了freemarker等模板引擎，不能写Java代码。那前端也不可避免的要去重新学习该模板引擎的模板语法，⽆谓增加了前端的学习成本。正如我们后端开发不想写前端⼀样，你想想如果你的后台代码⾥嵌⼊前端代码，你是什么感受？因此，这种⽅式⼗分不妥。
3、JSP本⾝所导致的⼀些其他问题 ⽐如，JSP第⼀次运⾏的时候⽐较缓慢，因为⾥头包含⼀个将JSP翻译为Servlet的步骤。再⽐如因为同步加载的原因，在JSP中有很多内容的情况下，页⾯响应会很慢。
3、半分离时代
前后端半分离，前端负责开发页⾯，通过接⼝（Ajax）获取数据，采⽤Dom操作对页⾯进⾏数据绑定，最终是由前端把页⾯渲染出
来。这也就是Ajax与SPA应⽤（单页应⽤）结合的⽅式，其结构图如下：
⽅式⼆已经逐渐淘汰。主要原因有两点：
1）前端在开发过程中严重依赖后端，在后端没有完成的情况下，前端根本⽆法⼲活；
2）由于趋势问题，会JSP，懂velocity，freemarker等模板引擎的前端越来越少；
因此，⽅式⼆逐渐不被采⽤。然⽽，不得不说⼀点，⽅式⼀，其实很多⼩型传统软件公司⾄今还在使⽤。那么，⽅式⼀和⽅式⼆具有哪些共同的缺点呢?
1、前端⽆法单独调试，开发效率低；
2、 前端不可避免会遇到后台代码，例如：<body> <% request.setCharacterEncoding("utf-8") String Parameter("username"); out.print(name); %></body>
1
2
3
4
5
6
7
步骤如下：
（1）浏览器请求，CDN返回HTML页⾯；
（2）HTML中的JS代码以Ajax⽅式请求后台的Restful接⼝；
（3）接⼝返回Json数据，页⾯解析Json数据，通过Dom操作渲染页⾯；
后端提供的都是以JSON为数据格式的API接⼝供Native端使⽤，同样提供给WEB的也是JSON格式的API接⼝。
那么意味着WEB⼯作流程是：
1、打开web，加载基本资源，如CSS，JS等；
2、发起⼀个Ajax请求再到服务端请求数据，同时展⽰loading；
3、得到json格式的数据后再根据逻辑选择模板渲染出DOM字符串；
4、将DOM字符串插⼊页⾯中web view渲染出DOM结构；
这些步骤都由⽤户所使⽤的设备中逐步执⾏，也就是说⽤户的设备性能与APP的运⾏速度联系的更紧换句话说就是如果⽤户的设备很低端，那么APP打开页⾯的速度会越慢。
为什么说是半分离的？因为不是所有页⾯都是单页⾯应⽤，在多页⾯应⽤的情况下，前端因为没有掌握controller层，前端需要跟后端讨论，我们这个页⾯是要同步输出呢，还是异步Json渲染呢？⽽且，即使在这⼀时期，通常也是⼀个⼯程师搞定前后端所有⼯作。因此，在这⼀阶段，只能算半分离。
⾸先，这种⽅式的优点是很明显的。前端不会嵌⼊任何后台代码，前端专注于HTML、CSS、JS的开发，不依赖于后端。⾃⼰还能够模拟Json数据来渲染页⾯。发现Bug，也能迅速定位出是谁的问题。
然⽽，在这种架构下，还是存在明显的弊端的。最明显的有如下⼏点：
1）JS存在⼤量冗余，在业务复杂的情况下，页⾯的渲染部分的代码，⾮常复杂；
2）在Json返回的数据量⽐较⼤的情况下，渲染的⼗分缓慢，会出现页⾯卡顿的情况；
3）SEO（ Search Engine Optimization，即搜索引擎优化）⾮常不⽅便，由于搜索引擎的爬⾍⽆法爬下JS异步渲染的数据，导致这样的页⾯，SEO会存在⼀定的问题；
4）资源消耗严重，在业务复杂的情况下，⼀个页⾯可能要发起多次HTTP请求才能将页⾯渲染完毕。可能有⼈不服，觉得PC端建⽴多次HTTP请求也没啥。那你考虑过移动端么，知道移动端建⽴⼀次HTTP请求需要消耗多少资源么？
正是因为如上缺点，我们才亟需真正的前后端分离架构。
4、分离时代
⼤家⼀致认同的前后端分离的例⼦就是SPA(Single-page application)，所有⽤到的展现数据都是后端通过异步接⼝(AJAX/JSONP)的⽅式提供的，前端只管展现。从某种意义上来说，SPA确实做到了前后端分离，但这种⽅式存在两个问题：
WEB服务中，SPA类占的⽐例很少。很多场景下还有同步/同步+异步混合的模式，SPA不能作为⼀种通⽤的解决⽅案；
现阶段的SPA开发模式，接⼝通常是按照展现逻辑来提供的，⽽且为了提⾼效率我们也需要后端帮我们处理⼀些展现逻辑，这就意味着后端还是涉⾜了view层的⼯作，不是真正的前后端分离。
SPA式的前后端分离，从物理层做区分（认为只要是客户端的就是前端，服务器端就是后端）这种分法已经⽆法满⾜前后端分离的需求，我们认为从职责上划分才能满⾜⽬前的使⽤场景：
前端负责view和controller层
后端只负责model层，业务处理与数据持久化等
controller层与view层对于⽬前的后端开发来说，只是很边缘的⼀层，⽬前的java更适合做持久层、model层的业务。
在前后端彻底分离这⼀时期，前端的范围被扩展，controller层也被认为属于前端的⼀部分。在这⼀时期：
前端：负责View和Controller层。
后端：只负责Model层，业务/数据处理等。
可是服务端⼈员对前端HTML结构不熟悉，前端也不懂后台代码呀，controller层如何实现呢？这就是node.js的妙⽤了，node.js适合运⽤在⾼并发、I/O密集、少量业务逻辑的场景。最重要的⼀点是，前端不⽤再学⼀门其他的语⾔了，对前端来说，上⼿度⼤⼤提⾼。
可以就把Nodejs当成跟前端交互的api。总得来说，NodeJs的作⽤在MVC中相当于C（控制器）。Nod
ejs路由的实现逻辑是把前端静态页⾯代码当成字符串发送到客户端（例如浏览器），简单理解可以理解为路由是提供给客户端的⼀组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)的架构如下图所⽰：
增加node.js作为中间层，具体有哪些好处呢？
(1)适配性提升；我们其实在开发过程中，经常会给PC端、mobile、app端各⾃研发⼀套前端。其实对于这三端来说，⼤部分端业务逻辑是⼀样的。唯⼀区别就是交互展现逻辑不同。如果controller层在后端⼿⾥，后端为了这些不同端页⾯展⽰逻辑，⾃⼰维护这些controller，模版⽆法重⽤，徒增和前端沟通端成本。 如果增加了node.js层，此时架构图如下：
在该结构下，每种前端的界⾯展⽰逻辑由node层⾃⼰维护。如果产品经理中途想要改动界⾯什么的，可以由前端⾃⼰专职维护，后端⽆需操⼼。前后端各司其职，后端专注⾃⼰的业务逻辑开发，前端专注产品效果开发。
(2)响应速度提升；我们有时候，会遇到后端返回给前端的数据太简单了，前端需要对这些数据进⾏逻辑运算。那么在数据量⽐较⼩的时候，对其做运算分组等操作，并⽆影响。但是当数据量⼤的时候，会有明显的卡顿效果。这时候，node中间层其实可以将很多这样的代码放⼊node层处理、也可以替后端分担⼀些简单的逻辑、⼜可以⽤模板引擎⾃⼰掌握前台的输出。这样做灵活度、响应度都⼤⼤提升。
举个例⼦，即使做了页⾯静态化之后，前端依然还是有不少需要实时从后端获取的信息，这些信息都在不同的业务系统中，所以需要前端发送5，6个异步请求来。有了NodeJs之后，前端可以在NodeJs中去代理这5个异步请求。还能很容易的做bigpipe，这块的优化能让整个渲染效率提升很多。在PC上你觉得发5,6个异步请求也没什么，但是在⽆线端，在客户⼿机上建⽴⼀个http请求开销很⼤。有了这个优化，性能⼀下提升好⼏倍。
(3)性能得到提升；⼤家应该都知道单⼀职责原则。从该⾓度来看，我们，请求⼀个页⾯，可能要响应很多个后端接⼝，请求变多了，⾃然速度就变慢了，这种现象在mobile端更加严重。采⽤node作为中间层，将页⾯所需要的多个后端数据，直接在内⽹阶段就拼装好，再统⼀返回给前端，会得到更好的性能。
(4)异步与模板统⼀；淘宝⾸页就是被⼏⼗个HTML⽚段（每个⽚段⼀个⽂件）拼装成，之前PHP同步i
nclude这⼏⼗个⽚段，⼀定是串⾏的，Node可以异步，读⽂件可以并⾏，⼀旦这些⽚段中也包含业务逻辑，异步的优势就很明显了，真正做到哪个⽂件先渲染完就先输出显⽰。前端机的⽂件系统越复杂，页⾯的组成⽚段越多，这种异步的提速效果就越明显。前后端模板统⼀在⽆线领域很有⽤，PC页⾯和WIFI场景下的页⾯适合前端渲染（后端数据Ajax到前端），2G、3G弱⽹络环境适合后端渲染（数据随页⾯吐给前端），所以同样的模板，在不同的条件下⾛不同的渲染渠道，模板只需⼀次开发。
增加NodeJS中间层后的前后端职责划分：
5、总结
从经典的JSP+Servlet+JavaBean的MVC时代，到SSM（Spring + SpringMVC + Mybatis）和SSH（Spring + Struts + Hibernate）的Java 框架时代，再到前端框架（KnockoutJS、AngularJS、vueJS、ReactJS）为主的MV*时代，然后是Nodejs引领的全栈时代，技术和架构⼀直都在进步。虽然“基于NodeJS的全栈式开发”模式很让⼈兴奋，但是把基于Node的全栈开发变成⼀个稳定，让⼤家都能接受的东西还有很多路要⾛。创新之路不会⽌步，⽆论是前后端分离模式还是其他模式，都是为了更⽅便得解决需求，但它们都只是⼀个“中转站”。前端项⽬与后端项⽬是两个项⽬，放在两个不同的服务器，需要独⽴部署，两个不同的⼯程，两个不同的代码库，不同的开发⼈员。前端只需要关注页⾯的样式与动态数据的解析及渲染，⽽后端专注于具体业务逻辑。
参考：
参考：
参考：
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论