JavaWeb项目大多数的系统架构从猿进化成人的必经之路

大中型公司需要专业人才,小公司需要全才,但是对于个人职业发展来说,前后端需要分离。而且,即使在这一时期,通常也是一个工程师搞定前后端所有工作。可是服务端人员对前端HTML结构不熟悉,前端也不懂后台代码呀,层如何实现呢?前后端各司其职,后端专注自己的业务逻辑开发,前端专注产品效果开发。

#背景

前后端分离已成为互联网项目开发的行业标准。 + 方法(或者中间也可以加一个)可以有效解耦,前后端分离将是未来大规模分布式架构和弹性计算架构的基础。 ,微服务架构,多终端服务(多客户端,如浏览器、车载终端、、IOS等)打下坚实的基础。这一步是系统架构从猿进化到人的唯一途径。

核心思想是前端HTML页面通过AJAX调用后端API接口,使用JSON数据进行交互。

Web服务器:一般指这样的服务器,一般只能解析静态资源;

应用服务器:一般指能解析动态资源和静态资源的服务器,但解析静态资源的能力不如web服务器;

一般情况下,外网只能访问web服务器,内网只能访问应用服务器。

以前的 Java Web 项目大多是 Java 程序员,他们既是父亲又是母亲,从事前端和后端工作。随着时代的发展,越来越多的大中小型企业开始越来越清晰的区分前端和后端的界限。前端工程师只关心前端事务,后端工程师只关心后端事务。俗话说,艺术行业有专长。如果一个人什么都擅长,那么他终究不是什么都擅长。大中型企业需要专业人才,小企业需要全才,但个人职业发展需要前后端分离。

#未分离时代(各种联轴器)

早期主要使用MVC框架。 Jsp+的结构图如下:

前后端分离seo怎么做_前后端分离不利于seo_前后端 分离 seo

几乎所有请求都发送到控制器,控制器接受请求并根据请求信息将它们分派到适当的 JSP 来响应。同时,也根据JSP的要求生成实例并输出到JSP环境中。 JSP中的数据可以通过直接调用方法或者使用自定义标签来获取。需要注意的是,这个View还可以使用、、等模板引擎,使用这些模板引擎可以让开发过程中的分工更加清晰,提高开发效率。

那么,在这个时期,有两种发展方式:

方法一

前后端分离不利于seo_前后端分离seo怎么做_前后端 分离 seo

方法二

方法 2 已被淘汰。主要有两个原因:

1)前端在开发过程中严重依赖后端。如果后端没有完成,前端根本无法工作;

2)因为趋势问题,JSP、理解等模板引擎的前端越来越少;

因此,第二种方法逐渐不被采用。但是,不得不说,第一种方式,其实很多小型传统软件公司还在使用。那么,方法一和方法二的共同缺点是什么?

1、前端无法单独调试,开发效率低;

2、 前端难免会遇到后端代码,例如:

   <%       request.setCharacterEncoding("utf-8")       String name=request.getParameter("username");       out.print(name);   %>

这个方法太耦合了。好吧,即使您使用模板引擎,也无法编写 Java 代码。前端也不可避免地要重新学习模板引擎的模板语法,无谓地增加了前端的学习成本。就像我们不想为后端开发编写前端一样,想想如果将前端代码嵌入到后端代码中,您会有什么感受?因此,这种方法是非常不合适的。

3、其他一些由JSP本身引起的问题比如JSP第一次运行很慢,因为它包含一个将JSP翻译成的步骤。再比如,由于同步加载,当JSP中的内容很多时,页面响应会很慢。

#半分离时代

前后端半分离,前端负责开发页面,通过接口(Ajax)获取数据,使用Dom操作将页面与数据绑定,最后通过前端呈现页面。这就是 Ajax 与 SPA 应用程序(单页应用程序)结合的方式。结构图如下:

前后端分离seo怎么做_前后端 分离 seo_前后端分离不利于seo

步骤如下:

(1)浏览器请求,CDN返回HTML页面;

(2)HTML中的JS代码以ajax方式请求后台界面;

(3)接口返回Json数据,页面解析Json数据,通过Dom操作渲染页面;

后端提供JSON格式的API接口供最终使用,同时也提供JSON格式的API接口给WEB。

那么意味着WEB工作流程是:

1、打开网页,加载基础资源,如CSS、JS等;

2、发起ajax请求,然后向服务器请求数据,同时显示;

3、获取json格式的数据,然后根据逻辑选择模板渲染DOM字符串;

4、将DOM字符串插入页面,web视图渲染DOM结构;

这些步骤是在用户使用的设备中一步一步进行的,也就是说用户的设备性能与APP的运行速度有更密切的关系。也就是说,如果用户的设备非常低端,那么APP打开页面的速度会比较慢。

为什么说是半分离的?因为不是所有的页面都是单页面应用,在多页面应用的情况下,因为前端没有层,前端需要和后端商量。我们的页面应该用Json同步输出还是异步渲染?而且,即使在此期间,通常由一名工程师完成所有前端和后端工作。因此,现阶段只能算一半分离。

首先,这种方式的优势是显而易见的。前端不会嵌入任何后端代码。前端专注于HTML、CSS、JS的开发,不依赖后端。也可以自己模拟 Json 数据来渲染页面。如果发现bug,可以快速定位问题。

但是,这种架构下存在明显的缺陷。最明显的是:

1)JS 有很多冗余。在业务复杂的情况下,页面渲染部分的代码非常复杂;

2)当Json返回的数据量比较大时,渲染很慢,会卡住页面;

3)SEO(,搜索引擎优化)很不方便,因为搜索引擎的爬虫无法爬取JS异步渲染的数据,导致这样的页面,SEO会有一定的问题;

4)资源消耗严重。在业务复杂的情况下,一个页面可能要发起多个HTTP请求才能完成页面的渲染。有的人可能不满意,觉得在PC端发出多个HTTP请求就可以了。有没有考虑过移动端,是否知道移动端建立一个HTTP请求需要消耗多少资源?

正是由于以上缺点,我们迫切需要一个真正的前后端分离架构。

#分居年代

一致同意前后端分离的例子是SPA(-page),所有使用的显示数据都是后端通过异步接口(AJAX/)提供的,前端只是显示从某种意义上说,SPA确实是前后端分离的,但是这种方式存在两个问题:

在WEB服务中,SPA类的比例很小。很多场景下还有同步/同步+异步混合模式,SPA不能作为通用方案;

在目前的SPA开发模式中,接口通常是根据表现逻辑来提供的,为了提高效率,我们还需要后端帮我们处理一些表现逻辑,也就是说后端还是要参与视图层的工作。不是真正的前端分离。

SPA式的前后端分离,区别于物理层(以为只要客户端是前端,服务器就是后端)这种分离方式已经不行了满足前后端分离的需求,我们认为职责分工只能满足目前的使用场景:

前端负责view和

后端只负责层、业务处理和数据持久化等。

和view层对于现在的后端开发来说只是一个很边缘的层,而现在的java更适合做持久层和业务。

在前后端完全分离的时期,前端的范围扩大了,层被认为是前端的一部分。在此期间:

前端:负责View和。

:只负责层、业务/数据处理等

但是服务端人员不熟悉前端HTML结构,前端不懂后端代码。如何实现层?这就是 node.js 的魔力。 Node.js 适用于高并发、I/O 密集、业务逻辑量少的场景。最重要的一点是前端不需要学习另一种语言。对于前端,熟悉度大大提高。

前后端分离不利于seo_前后端分离seo怎么做_前后端 分离 seo

您可以将其视为与前端交互的 api。一般来说,MVC的作用相当于C(控制器)。路由的实现逻辑是将前端静态页面代码作为字符串发送给客户端(如浏览器)。简单理解可以理解为路由是提供给客户端的一组api接口,但是返回的数据是一串页面代码。就是这样。

用作桥接来自服务器端 API 的 JSON 输出的桥梁。由于性能等原因,后端提供的接口返回的数据格式可能不适合前端直接使用。前端需要的排序和过滤功能,以及视图层的页面展示,都可能需要对提供的数据进行第二次处理。虽然这些处理可以在前端进行,但由于数据量大,可能会浪费浏览器的性能。所以现在,添加一个Node中间层是一个很好的解决方案。

![在这里写图片描述]()

() 不再直接请求 JSP API,而是:

1)浏览器向服务器端请求;

2)发起HTTP请求JSP;

3)JSP 仍然按原样将 JSON 输出到 API;

4)收到JSON后渲染HTML页面;

5)将 HTML 页面定向到浏览器;

这样浏览器得到的是一个普通的HTML页面,而不是发送Ajax请求服务器。

淘宝前端团队提出的中途岛( )结构如下图所示:

前后端 分离 seo_前后端分离seo怎么做_前后端分离不利于seo

添加node.js作为中间层有什么好处?

(1)适应性提高了;其实在开发过程中,我们经常会为PC端、app端、app端开发一套前端。其实对于这些三个终端,大部分的侧边业务逻辑是一样的,唯一的区别就是交互展示逻辑不同,如果层在后端手里,后端为这些的展示逻辑维护这些不同的侧页,模板无法复用,增加了前端通信的成本,如果增加节点.js层,架构图如下:

前后端分离不利于seo_前后端分离seo怎么做_前后端 分离 seo

在这种结构下,各个前端的界面展示逻辑由节点层自己维护。如果产品经理中间要换界面,前端可以专职维护,后端不用操心。前后端各司其职,后端专注于自身业务逻辑开发,前端专注于产品效果开发。

(2)响应速度提升;我们有时会遇到后端返回给前端的数据过于简单,前端需要对数据进行逻辑运算。那么当数据量比较小,对操作分组等操作没有影响。但是当数据量大的时候,会有明显的冻结效果,这个时候node中间层其实可以放很多这样的代码进入节点层进行处理,或者替换它。终端共享一些简单的逻辑,并且可以使用模板引擎来控制前台的输出。这大大提高了灵活性和响应性。

例如,即使页面静态化后,前端仍然有很多信息需要从后端实时获取。这些信息都在不同的业务系统中,所以前端需要发送5到6个异步请求。来。之后前端就可以在里面代理这5个异步请求了。也可以轻松搞定,这个块的优化可以让整体渲染效率提升不少。在 PC 上,您认为发送 5 或 6 个异步请求是可以的,但在无线端,在客户端手机上发出 http 请求的成本很高。通过这种优化,性能提升了数倍。

(3)性能提升了,大家应该注意单一职责原则。从这个角度来说,当我们请求一个页面的时候,可能要响应很多后端接口。请求数增加,自然速度会增加。越慢,这种现象在端越严重。使用node作为中间层,可以在内网阶段直接组装页面所需的多个后端数据,然后返回到前端统一,性能更好。

(4)异步和模板统一;淘宝首页是由几十个HTML片段组装而成的(每个片段一个文件)。PHP同步这几十个片段之前必须是串行的,Node可以异步,读取文件可以并行处理,一旦这些也包含业务逻辑,异步的优势就很明显了,先渲染哪个文件先输出显示,前端电脑的文件系统越复杂,就越多页面组成。越多,异步提速效果越明显。前后模板的统一在无线领域非常有用。PC页面和WIFI场景下的页面适合前端渲染(后台-端数据Ajax到前端),2G和3G弱网环境适合后端渲染。端渲染(数据随页面吐到前端),所以同一个模板,在不同的条件下,经历不同的渲染通道,模板只需要开发一次。

加入中间层后的前后端职责划分:

![在这里写图片描述]()

#总结

从经典JSP++的MVC时代,到SSM(++)和SSH(++)的Java框架时代,再到前端框架(,,,,)主导的MV*时代,再到到领先的全栈时代,技术和架构一直在进步。虽然“全栈开发”模式令人兴奋,但要将基于 Node 的全栈开发变成稳定且所有人都能接受的东西,还有很长的路要走。创新之路不会停止。无论是前后端分离模式还是其他模式,都是为了更方便地解决需求,但它们只是一个“中转站”。前端项目和后端项目是两个项目,放在两个不同的服务器上,需要独立部署,两个不同的项目,两个不同的代码库,不同的开发者。前端只需要关注页面的样式和动态数据的解析渲染,而后端则关注具体的业务逻辑。

免责声明:本文来自网络用户投稿,不代表本站观点和立场。如有侵权请发送邮件至tzanseo@163.com告知本站删除,本站不负任何责任及承诺。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。

发表评论

登录后才能评论