前后端部署在两台服务器 服务器配置要求_漫谈前后端分离

49次阅读

前言 浅谈前后端

在我的脑海中一提到前端和后端,基本上第一个出现的区别点就是: 后端是跟数据库跟服务器打交道的,前端是跟浏览器打交道的。似乎没有什么问题,大家都这么认为的。当然这没有什么错,我们一直以来都认为仅仅是以浏览器作分界,把这两部分的代码分离出来。但是前后端分离的初衷是为了分离前后端开发人员的职责,同时解决开发模式的问题。但似乎他们的职责在以前甚至于现在都并不明确,虽然前端是跟浏览器打交道,但是最终浏览器拿到的页面是服务器通过模板生成的一个临时静态页面而已。所以,实际上后端也掺和进来了,因为他要处理模板。当然,一般传统上的开发协作模式有两种

· 一种是前端先写一个静态页面,写好后,让后端去套模板。静态页面可以本地开发,也无需考虑业务逻辑只需要实现 View 即可。不足是还需要后端套模板,这些前端代码后端需要浏览一遍,以免出错。

· 另一种协作模式是,前端直接去写模板,这样做的问题在于,前端编写过程中很依赖与后端环境,如果当后端没写完的情况下,前端几乎没法干活。

显然这两种方式似乎都有很多问题,但至少这还是目前为止大部分公司所采用的模式。他们从物理层来区分前后端的开发,同时淡化了前端在逻辑上的色彩。由于前端所做的事情就是来实现一个页面的静态版本,所以,大多数公司又给前端工程师们找了点活干。你去看现在公司在招聘的时候前端工程师的要求,除了对页面的基本制作技能外还有额外的设计职责。

到这里原本我们以为已经将前后端分离开来了,但是在模版这个尴尬的问题上,前后端的工程师们绝对吃过不少苦头,因为在整体网站架构上,这并不是前后端的分离。

Java 服务器端初学者最容易引起误解的一个概念就是: JSP 是前端技术。

1、什么是前后端分离

JSP 全称:Java Server Page。是运行在服务器端 JVM 之上 Servlet 容器里的,只是执行的结果是 HTML,响应给浏览器。

Java EE 先有的 Servlet,那时候已经有了 ASP(同样要知道是 Active Server Page 的意思)。

由于要在 Servlet 里面拼大量的 HTML 代码,所以 Java 规范学习了 ASP,提出 JSP。Servlet 是 Java 代码里混入 HTML,JSP 是 HTML 代码里混入 Java。

浏览器根本不关心服务器端是 JSP、ASP、PHP,或者还是原始的 Servlet,或是静态服务器上的 HTML,只要返回的是合法的 HTML 就可以。所以,把 JSP 中静态的 HTML 部分拿出来,变成简单的 HTML 文件,放在 HTTP 服务器上,浏览器只要获取到这些 HTML 就可以了。动态的数据部分用 HTML 里的 JS 通过 AJAX 的方式从服务器端获取,然后动态操作 Dom,完成动态内容的展示。这样前后端就分离了。

静态资源和数据接口被部署在两个不同的服务上就算前后端分离?

静态资源和服务(实现接口的业务逻辑),在开发阶段就分离开发,而部署阶段分离部署在不同服务器上,算是严格意义上的前后端分离。

有些小型项目,开发阶段没有分离开发,也就是说前后端代码在一个 Project 里。在部署阶段也没有分离,例如静态资源还是放在 Tomcat 里。这些情况,到底算不算前后端分离,关键是是否 ” 严格 ” 看待。

如果静态资源 (html 模板) 是 jsp,而 jsp 的所有动态数据均来自另一个服务,那这算不算前后端分离?

静态资源是 JSP 这个观点就是错误的,不做再次解释。JSP 是运行在 Server 上的,动态获取另一个 Server 上的数据,这是服务器和服务器之间的调用,只是两台服务器的相互角色和分工不同。JSP 所在的服务器被称为 Consumer(消费者,也就是服务的使用者),另一台提供数据的服务器被称为 Producer(生产者,也就是服务的提供者)。

如果上面为 JSP 提供数据的服务又调用了第三个服务的接口获取数据,那么就又产生了新的 Consumer 和 Producer 关系。

2、JSP 的痛点

以前的 JavaWeb 项目大多数使用 jsp 作为页面层展示数据给用户,因为流量不高,因此也没有那么苛刻的性能要求,但现在是大数据时代,对于互联网项目的性能要求是越来越高,因此原始的前后端耦合在一起的架构模式已经逐渐不能满足我们,因此我们需要需找一种解耦的方式,来大幅度提升我们的负载能力。

1、动态资源和静态资源全部耦合在一起,服务器压力大,因为服务器会收到各种 http 请求,例如 css 的 http 请求,js 的,图片的等等。一旦服务器出现状况,前后台一起玩完,用户体验极差。

2、UI 出好设计图后,前端工程师只负责将设计图切成 html,需要由 java 工程师来将 html 套成 jsp 页面,出错率较高(因为页面中经常会出现大量的 js 代码),修改问题时需要双方协同开发,效率低下。

3、jsp 必须要在支持 java 的 web 服务器里运行(例如 tomcat,jetty,resin 等),无法使用 nginx 等(nginx 据说单实例 http 并发高达 5w,这个优势要用上),性能提不上来。

4、第一次请求 jsp,必须要在 web 服务器中编译成 se

原文链接:https://blog.csdn.net/weixin_39980234/article/details/110134525

正文完
 
追风者
版权声明:本站原创文章,由 追风者 2023-12-30发表,共计2111字。
转载说明:声明:本站内容均来自互联网,归原创作者所有,如有侵权必删除。 本站文章皆由CC-4.0协议发布。