前后端未分离时代，页面逻辑处理以及页面渲染全部由后端完成。如最具代表性的 MVC 三层框架。用户发起请求至服务端控制层（Controller），控制层通过调用模型处理器（Model）以及渲染视图（View）并最终将页面返回给客户端。
大致就是所有的请求都被发送给作为控制器的Servlet，它接受请求，并根据请求信息将它们分发给适当的JSP来响应。同时，Servlet还根据JSP的需求生成JavaBeans的实例并输出给JSP环境。JSP可以通过直接调用方法或使用UseBean的自定义标签得到JavaBeans中的数据。需要说明的是，这个View还可以采用 Velocity、Freemaker 等模板引擎。使用了这些模板引擎，可以使得开发过程中的人员分工更加明确，还能提高开发效率。
在这个时期，开发方式有如下两种：
方式二已经逐渐淘汰。主要原因有两点：
1）前端在开发过程中严重依赖后端，在后端没有完成的情况下，前端根本无法干活；
2）由于趋势问题，会JSP，懂velocity，freemarker等模板引擎的前端越来越少；
因此，方式二逐渐不被采用。然而，不得不说一点，方式一，其实很多小型传统软件公司至今还在使用。
方式一和方式二具有哪些共同的缺点呢?1、前端无法单独调试，开发效率低；
2、JSP本身所导致的一些其他问题 比如，JSP第一次运行的时候比较缓慢，因为里头包含一个将JSP翻译为Servlet的步骤。再比如因为同步加载的原因，在JSP中有很多内容的情况下，页面响应会很慢。
3、 前端不可避免会遇到后台代码，例如：
这种方式耦合性太强。那么，就算你用了freemarker等模板引擎，不能写Java代码。那前端也不可避免的要去重新学习该模板引擎的模板语法，无谓增加了前端的学习成本。正如我们后端开发不想写前端一样，你想想如果你的后台代码里嵌入前端代码，你是什么感受？因此，这种方式十分不妥。
前后端半分离，前端负责开发页面，通过接口（Ajax）获取数据，采用Dom *** 作对页面进行数据绑定，最终是由前端把页面渲染出来。这也就是Ajax与SPA应用（单页应用）结合的方式
步骤如下：（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请求需要消耗多少资源么？
分离时代用NodeJs来作为桥梁架接服务器端API输出的JSON。后端出于性能和别的原因，提供的接口所返回的数据格式也许不太适合前端直接使用，前端所需的排序功能、筛选功能，以及到了视图层的页面展现，也许都需要对接口所提供的数据进行二次处理。这些处理虽可以放在前端来进行，但也许数据量一大便会浪费浏览器性能。因而现今，增加Node中间层便是一种良好的解决方案。
从物理层做区分（认为只要是客户端的就是前端，服务器端就是后端）这种分法已经无法满足前后端分离的需求，我们认为从职责上划分才能满足目前的使用场景：
前端负责view和controller层 后端只负责model层，业务处理与数据持久化等 controller层与view层对于目前的后端开发来说，只是很边缘的一层，目前的java更适合做持久层、model层的业务。
在前后端彻底分离这一时期，前端的范围被扩展，controller层也被认为属于前端的一部分。在这一时期：前端：负责View和Controller层。后端：只负责Model层，业务/数据处理等。
可是服务端人员对前端HTML结构不熟悉，前端也不懂后台代码呀，controller层如何实现呢？这就是node.js的妙用了，node.js适合运用在高并发、I/O密集、少量业务逻辑的场景。最重要的一点是，前端不用再学一门其他的语言了，对前端来说，上手度大大提高。
服务器端（后端）的服务器种类主要分为 WEB 服务器以及应用服务器，WEB 服务器主要用来发布静态资源（html、css 等静态资源文件），如 Nginx 服务器、Apache 以及 CDN 服务器等。WEB 服务器对于静态资源发布以及静态文件缓存有极大的优势。应用服务器主要用来发布应用程序代码（ASP.NET、PHP、JAVA 等），如 Tomcat、IIS 服务器等。WEB 服务器一般通过公网 VIP 或者 SLB 等方式对外提供外网服务。应用服务器一般只运行在内网环境，无法通过外网方式直接访问应用服务器资源，这样也是对应用服务器的一种网络安全保护。
后端技术体系包括 JAVA、C#等程序开发语言。MySQL、MongoDB 等数据库技术。Tomcat、IIS 等 web 服务器技术。JSF、JMQ 等处理分布式应用的中间件技术。
前后端路由分离前后端分离的实现基于一个前提条件，就是要将前后端路由分离，即前端页面路由和后台服务接口有独立的路由。路由相互独立意味着前后端服务的分离，就可以各自负责各自的服务，互不干扰。有了这个基础，就只需要想办法维护自己的服务即可，就可以实现上面说的三个条件，所以，这里说的实现方式，就是指如何去分离前后端的路由，并能在这种方式的基础上扩展和自定义前端和后端各自的服务。在这里，将介绍几种前后端分离的几种思路：
- 后端分离路由
- nginx分离路由
- Node服务分离路由
这里分离路由的方式只考虑这两种:
- nginx配置代理
- Node服务代理
nginx可以通过正向代理实现接口代理，Node服务也可以通过转发实现代理。那么需要了解的是这两种代理方式的优缺点和适用场景。
nginx配置是服务器的一部分，那么它也就是服务器上所有服务的一部分，前端业务只是使用了后台服务而已，所以，不应该因为添加了前端业务而修改服务本身。但是，如果业务简单，通过nginx来分离路由，也能达到同样的目的，还能减少服务器资源的使用。
前后分离的代理方式不是用来实现后台服务功能的。这里的Node服务有点类似nginx的反向代理，只是我们将这些需要代理的请求整合起来，用一个专门的服务来提供，让后台服务能专注于提供业务服务，分离职责。这就是Node服务做的事情。
通过Node服务分离路由，有几个很明显的好处：
- 不需要修改服务本身，耦合为零；
- Nodejs本身就是异步IO，语言特性方面很适合做这种低计算量，多IO的服务；
- 分离了后台服务的职责，能专注提供业务接口，不用管这些业务无关的内容，具体如何使用由使用者决定；
后端分离路由要根据需要使用分离路由的方式。但是，总体上来说，Node服务更适合
后端分离路由的前提是独立存储前端模板文件。在前端发布过程中，资源文件最好是上传CDN，所以，这里说的独立存储是指的模板文件，即页面文件index.html。
独立存储就是将前端的入口文件保存到一个特定的公用的地方，前后端都可以读取，类似于进程间的共享内存通信。这种后端服务就可以从这个共享内存中读取模板，从而提供前端的模板服务，前端只需要往这块共享内存写入模板即可。具体的部署结构图如下：
这个公用的地方可以是部署服务器上的一个文件夹，也可以是数据库中的某个表字段，也可以是redis中的某个key，等等。这里推荐使用page-version-control。这是一个通过redis控制页面文件版本的工具，将前端文件存入到redis中，内存读取速度快，而且更新方便，推荐使用。
nginx分离路由优点：简单，只需要一个后台服务即可，nginx也没有复杂的配置；
缺点：安全，SEO等需求需要在后台服务中完成，后台职责不清晰，开发方式不友好；
适用场景：SPA生成的模板文件，不适合前端文件很多的情况，且需要前端的特殊需求较少；
在nginx中分开配置前端和后端路由，将前端路由和后端路由代理到对应的服务中去。通过Nodejs服务器提供前端特有的服务，包括模板文件，SEO，WEB安全等。Node服务器可以提供非常完善的前端服务。其中，模板文件的存取和版本控制可以在Redis中提供。具体的部署图如下：
这种方式相对于上一种后台分离路由，独立出了前端服务，这样就可以在前端这方面做更多的事情。当前端需要多个后台服务支持时，只需要添加nginx配置项即可。
但是，这种部署方式有个很大的缺点。也就上面说的，nginx是服务的一部分，不应该因为前端接入而修改。
Node服务分离路由优点：前端服务独立出来了；只需要一台部署服务器，节省了资源；
缺点：nginx的配置相对比较繁琐；
适合场景：仅适用于后台服务简单的情况, nginx仅需要配置少量服务；
nginx直接将web的全部服务（前后端请求）都代理到Node服务中，Node服务代理再根据请求的类型将其转发到不同的服务中，前端路由直接处理，不同服务的后端请求代理到相应的后端服务器，即引入Node服务做客户端和后台服务器的中间层。具体的部署图如下：
相对于上一种部署方式，改动在于通过Node服务代理请求的方式分离路由，这样的好处在于：
- 可以在单独的服务器上部署前端的Node服务，实现部署服务器的分离，这样后台服务器也可以单独部署了，不会受到nginx的限制。
- Node服务在路由控制方面相对Nginx更加灵活；
- 可以在Node服务中对请求数据做一些事情了，比如：控制请求的访问频率，预处理请求返回的数据。
适配性提升优点：灵活，前端可以控制的事物范围更广了；
缺点：Node服务的复杂度较高；
适合场景：均可；
我们其实在开发过程中，经常会给PC端、mobile、app端各自研发一套前端。其实对于这三端来说，大部分端业务逻辑是一样的。唯一区别就是交互展现逻辑不同。如果controller层在后端手里，后端为了这些不同端页面展示逻辑，自己维护这些controller，模版无法重用，徒增和前端沟通端成本。如果增加了node.js层，此时架构图如下：
在该结构下，每种前端的界面展示逻辑由node层自己维护。如果产品经理中途想要改动界面什么的，可以由前端自己专职维护，后端无需 *** 心。前后端各司其职，后端专注自己的业务逻辑开发，前端专注产品效果开发。
响应速度提升；我们有时候，会遇到后端返回给前端的数据太简单了，前端需要对这些数据进行逻辑运算。那么在数据量比较小的时候，对其做运算分组等 *** 作，并无影响。但是当数据量大的时候，会有明显的卡顿效果。这时候，node中间层其实可以将很多这样的代码放入node层处理、也可以替后端分担一些简单的逻辑、又可以用模板引擎自己掌握前台的输出。这样做灵活度、响应度都大大提升。
举个例子，即使做了页面静态化之后，前端依然还是有不少需要实时从后端获取的信息，这些信息都在不同的业务系统中，所以需要前端发送5、6个异步请求来。有了NodeJs之后，前端可以在NodeJs中去代理这5个异步请求。还能很容易的做bigpipe，这块的优化能让整个渲染效率提升很多。在PC上你觉得发5、6个异步请求也没什么，但是在无线端，在客户手机上建立一个http请求开销很大。有了这个优化，性能一下提升好几倍。
大家应该都知道单一职责原则。从该角度来看，我们，请求一个页面，可能要响应很多个后端接口，请求变多了，自然速度就变慢了，这种现象在mobile端更加严重。采用node作为中间层，将页面所需要的多个后端数据，直接在内网阶段就拼装好，再统一返回给前端，会得到更好的性能。
淘宝首页就是被几十个HTML片段（每个片段一个文件）拼装成，之前PHP同步include这几十个片段，一定是串行的，Node可以异步，读文件可以并行，一旦这些片段中也包含业务逻辑，异步的优势就很明显了，真正做到哪个文件先渲染完就先输出显示。前端机的文件系统越复杂，页面的组成片段越多，这种异步的提速效果就越明显。前后端模板统一在无线领域很有用，PC页面和WIFI场景下的页面适合前端渲染（后端数据Ajax到前端），2G、3G弱网络环境适合后端渲染（数据随页面吐给前端），所以同样的模板，在不同的条件下走不同的渲染渠道，模板只需一次开发。
高稳定性
若通过 APP 内置数据库存储部分接口数据（用户的重要数据，如资产数据，收益数据等），可以实现 APP 的离线数据访问。当后端接口服务出现问题，前端依然能够正常展示。本图示只是一个简单的架构示意图，本意是为了说明在设计整体前后端工程时，同时利用前后端技术优势能够设计出更为稳定的系统架构。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）