Web端架构
Posted Xi-Jun博客
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Web端架构相关的知识,希望对你有一定的参考价值。
Web 框架是如何工作的?
- 首先,计算机会将网站的 html指令 发送到 Web 应用程序。即使应用程序是JSON 或 CSS 代码也会被转换为 HTML发送到 Web应用程序。
- 第二步,接收到 HTML 指令的 Web 应用从Web 服务器(也称为应用服务器)“下载” 网站。
这一步中,这个过程根据“请求 - 响应”模型网络协议实现。浏览器从 Web 应用进程 “请求”(Request) 数据,Web 应用进程通过发送数据来 “响应”(Respond)。
“请求 - 响应”动作只是单向的。只有 Web 浏览器可以请求数据,而 Web 应用进程不能。发送此请求指令的不同方式是 HTTP Get、HTTP Post 和 HTTP Response 代码。
Web 框架架构组件的元素
Web 框架架构的组件 包括以下元素——管理工具 (Administration Tool)、客户端层 (Client Layer)、推荐服务器 (Recommender Server) 和生成服务器 (Generator Server)。
- 管理员层或工具,包含管理、API 文档和管理。
- Recommender Server 包含 API 层、应用层(包含在线、动作、离线推荐服务)和具有数据库动作和关联规则的数据库层。
- 生成服务器有一个数据挖掘层 (Data mining layer),它包含基于动作 (action-based) 和基于内容 (content-based) 的生成器。
Web 框架架构分类
- 基于动作的架构 (Action-based Web Framework),Model-View-Controller, 模型+视图+控制器架构
MVC 是基于推送的逻辑架构。Web 应用被分成三个部分:Model、View 和 controller。数据库中的 Table 表示为 Model,业务逻辑架构包含在 Controller 中。
这种架构的好处是它允许代码重用并且模块化代码。这种架构使 Web 应用程序能够为用户显示网页,并为远程应用程序显示 Web 界面。
MVC 架构将“显示层 (Presentation)”和“业务逻辑层 (Logic Model)”分开,具有开发快捷、部署方便、可重用性高、维护成本低的优点。
基于动作的 Web 框架有 Ruby on Rails、Symfony、Spring MVC、Stripes、Django 和 Diamond。 - 基于组件的框架 (Component-based Framework)
这种框架从控制器 (controller) 或视图层 (View Layer) “拉取”数据。这种架构允许 Web 应用程序为单个视图拉取多个控制器。使用这种架构的框架有 Wicket、Lift、Tapestry、JavaServer Faces 和 JBoss Seam 等。 - 三级组织架构 (Three-tier Organization)
这种架构具有三个物理层——应用程序 (application)、数据库 (database) 和客户端 (client)。该应用程序使用业务逻辑在服务器上运行并与Web 浏览器客户端进行通信。 Web 浏览器在由 Web 应用程序生成的 HTML 上运行。
Web架构的应用场景
- 服务器端应用 (Server-side Application)
最初开发Web 框架时,是基于服务器的。这种类型的框架是必不可少的,因为它具有必要的应用程序逻辑,以确保适当的用户体验和用户界面上的交互。这些框架控制和管理数据库、处理 HTTP 请求以及对应映射 URL。
流行的服务器端框架有 Django、Symfony、Ruby on Rails、ASP.NET 和 Express Node等。 - 客户端应用 (Client-side Application)
这个框架处理用户看到和导航的界面。渲染、播放声音、播放视频、路由输入等功能由前端应用程序框架处理。这种动态框架也称为单页应用程序 (Single Page Application)。它在不加载新页面的情况下更新用户正在查看的同一页面上的数据。此过程可提高性能并减少内容重新加载时间。
客户端框架包括 Angular.js、javascript、Bootstrap、React js、Semantic UI 和 Backbone等。 - 移动端应用 (Mobile Application Architecture)
移动应用架构分为三层,即界面 (Presentation)、数据 (Data) 和业务 (Business)。
显示或用户界面是面向用户的层。所有的交互和操作都发生在这一层。
业务层负责工作流程并管理最终用户行为。
数据层管理数据功能、配置、通信和设置。
在开发移动框架应用程序时,需要考虑移动操作系统、存储空间、设备屏幕分辨率、屏幕尺寸和处理器能力等。
这节介绍了如何开发一个 Web 网站或者是应用,主要的 Web 架构类型。祝大家周末愉快!
前后端分离架构:Web 实现前后端分离,前后端解耦
你知道的越多,不知道的就越多,业余的像一棵小草!
你来,我们一起精进!你不来,我和你的竞争对手一起精进!
编辑:业余草
blog.csdn.net/fuzhongmin05
推荐:https://www.xttblog.com/?p=5178
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 的结构图如下:
大致就是所有的请求都被发送给作为控制器的 Servlet,它接受请求,并根据请求信息将它们分发给适当的 JSP 来响应。同时,Servlet 还根据 JSP 的需求生成 JavaBeans 的实例并输出给 JSP 环境。JSP 可以通过直接调用方法或使用 UseBean 的自定义标签得到 JavaBeans 中的数据。需要说明的是,这个 View 还可以采用 Velocity、Freemaker 等模板引擎。使用了这些模板引擎,可以使得开发过程中的人员分工更加明确,还能提高开发效率。
那么,在这个时期,开发方式有如下两种:
「方式一」
「方式二」
方式二已经逐渐淘汰。主要原因有两点:
1)前端在开发过程中严重依赖后端,在后端没有完成的情况下,前端根本无法干活;
2)由于趋势问题,会 JSP,懂 velocity,freemarker 等模板引擎的前端越来越少;
因此,方式二逐渐不被采用。然而,不得不说一点,方式一,其实很多小型传统软件公司至今还在使用。那么,方式一和方式二具有哪些共同的缺点呢?
1、前端无法单独调试,开发效率低;2、前端不可避免会遇到后台代码,例如:
<body>
<%
request.setCharacterEncoding("utf-8")
String name=request.getParameter("username");
out.print(name);
%>
</body>
这种方式耦合性太强。那么,就算你用了 freemarker 等模板引擎,不能写 Java 代码。那前端也不可避免的要去重新学习该模板引擎的模板语法,无谓增加了前端的学习成本。正如我们后端开发不想写前端一样,你想想如果你的后台代码里嵌入前端代码,你是什么感受?因此,这种方式十分不妥。
3、JSP 本身所导致的一些其他问题 比如,JSP 第一次运行的时候比较缓慢,因为里头包含一个将 JSP 翻译为 Servlet 的步骤。再比如因为同步加载的原因,在 JSP 中有很多内容的情况下,页面响应会很慢。
3、半分离时代
前后端半分离,前端负责开发页面,通过接口(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 请求需要消耗多少资源么?
正是因为如上缺点,我们才亟需真正的前后端分离架构。
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(控制器)。Nodejs 路由的实现逻辑是把前端静态页面代码当成字符串发送到客户端(例如浏览器),简单理解可以理解为路由是提供给客户端的一组 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同步include这几十个片段,一定是串行的,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)为主的 MVVM 时代,然后是 Nodejs 引领的全栈时代,技术和架构一直都在进步。虽然“基于NodeJS的全栈式开发”模式很让人兴奋,但是把基于 Node的全栈开发变成一个稳定,让大家都能接受的东西还有很多路要走。创新之路不会止步,无论是前后端分离模式还是其他模式,都是为了更方便得解决需求,但它们都只是一个“中转站”。前端项目与后端项目是两个项目,放在两个不同的服务器,需要独立部署,两个不同的工程,两个不同的代码库,不同的开发人员。前端只需要关注页面的样式与动态数据的解析及渲染,而后端专注于具体业务逻辑。
参考
淘宝前后端分离解决方案:http://2014.jsconf.cn/slides/herman-taobaoweb/index.html
浅谈前后端分离技术:https://zhuanlan.zhihu.com/p/20534796
以上是关于Web端架构的主要内容,如果未能解决你的问题,请参考以下文章