一体式Web架构示意为什么要前后端分离?(组图)

由于层出不穷的问题,甚至会有团队质疑,一体化好好的,为什么要前后端分离?为什么要前后端分离比为什么要前后端分离更现实的问题是什么时候需要前后端分离,即前后端分离的应用场景。前后端分离之后,两端的开发人员都轻松不少,由于技术和业务都更专注,开发效率也提高了。然而实际场景中,架构师或者设计师往往也是开发人员,所以他们的主要技术栈会极大的影响前后端在整个项目中的主次作用。

一体式Web架构示意为什么要前后端分离?(组图)

因为问题层出不穷,甚至有团队提出质疑。集成好,为什么要前后端分离?

说到底,不是正反分离不好,只是可能不合适,或者……设计思维没有转变……

一体式Web架构示意为什么要前后端分离?(组图)

一体化网络架构

前后分离Web架构示意图

为什么要前后端分开

一个比为什么需要前后端分离更现实的问题是什么时候需要前后端分离,即前后端分离的应用场景。

说起这个问题,我想到了2011年,当时公司在.NET开发团队的基础上扩充了Java团队。

虽然两个团队在开发不同的产品,但还是有很多重复的开发。比如组织相关的页面是用ASP.NET写的,需要用JSP再写一次。

在这种情况下,团队开始思考解决方案:如果前端实现与后端技术无关,页面渲染部分可以共享,不同的后端技术只需要实现后端业务逻辑。

该方案要解决的根本问题是将数据从页面中分离出来。满足这一需求的技术是现成的。前端采用静态网页相关技术,HTML+CSS+,通过AJAX技术调用后端提供的服务。界面。

前后端协商接口通过HTTP提供,统一使用POST动词。接口数据结构用XML实现,前端解析XML很方便,后端对XML的处理工具比较多……

后来由于后端JSON库(如JSON.NET、Gson等)的兴起。

在前端处理JSON(JSON.()和JSON.())也比较容易,所以数据结构换成JSON实现。这种架构本质上是 SOA(面向服务的架构)。

当后端不提供页面,而只通过Web API提供数据和业务交互能力时,Web前端就变成了一个纯客户端角色,与移动端应用同属角色,可以结合。一起,统称为前端。

之前的集成架构需要自定义页面来实现Web应用,同时定义了一套/WSDL来为移动终端提供服务。

转换为新架构后,所有类型的前端都可以使用Web API以统一的形式提供服务。至于某种前端对这个 Web API 的 RPC 封装,那就是另外一回事了。

通过这次架构改造,前后端其实已经分开了。除了其他类型的前端,这里只讨论Web前端和后端。

因为分离,web前端在开发的时候不需要知道后端使用的是什么技术。只需要后端提供什么样的接口可以用来做事,比如C#/ASP.NET、Java/JEE、数据库……这些技术都可以忽略。

后端.NET团队和Java团队也是出于与逻辑无关的审美思维。他们不需要面对美工精细的界面设计约束,也不需要在考虑逻辑实现的同时考虑页面的布局。 ,你只需要处理你擅长的逻辑和数据。

前后端分离后,两端的开发者都轻松了许多。因为技术和业务更加专注,开发效率也提高了。分离的好处逐渐显现:

前后职责分离

前端倾向于呈现,关注用户体验相关问题;后端往往是业务逻辑、数据处理和持久化。

在设计明确的情况下,后端只需要负责以数据为中心的业务处理算法,并按照约定为前端提供API接口;前端使用这些接口负责用户体验。

前后技术分离

前端不需要了解后端技术,也不关心用什么技术来实现后端。您只需要了解 HTML/CSS/ 即可开始使用。

后端只需要关心后端开发技术。除了省去学习前端技术的麻烦,即使是Web框架的学习和研究,也只需要专注于Web API即可。

而不是关注基于页面浏览量的MVC技术(不是说不需要MVC,Web API的接口部分的数据结构呈现也是View),也不需要考虑特别复杂数据组织和呈现。

用户体验与业务处理的解耦

前端可以根据不同时期的用户体验需求快速修改,后端对此毫无压力。同理,后端进行的业务逻辑升级和数据持久化方案的变化,只要接口不受影响,前端可以不察觉。

当然,如果界面因需求变化而变化,前后端需要坐在一起同步信息。

两端的设计可以分别减少

后端只提供API服务,不考虑页面渲染问题。实现 SOA 架构的 API 可以服务于各种前端,而不仅仅是 Web 前端,并且可以实现一套可供所有端使用的服务。

同时对于前端来说,不依赖后端技术的前端部分可以独立部署,也可以应用到架构中,嵌入各种“外壳”( , 等) 快速实现多终端。

前后独立架构

任何技术解决方案都不是灵丹妙药。前后分离不仅带来好处,也带来矛盾。在我们实践之初,由于前端团队的实力相对较弱,按照惯例,几乎所有的业务处理都是由后端(原技术骨干)设计和定义的。

在前端处理过程中,经常发现接口定义不符合用户操作流程,AJAX异步请求过多。

毕竟后端思维和前端思维还是有区别的——前端思维更偏向于用户体验,而后端思维更偏向于业务的技术实现。

另外,前后分离的安全要求略有不同。由于前后端分离本质上是一种 SOA 架构,授权也需要按照 SOA 架构的方式来考虑。

/ 方法可用,但不是特别适合。相对来说,基于的认证更合适。

使用-意味着后端的认证部分需要重写……当然后端不想重写,所以会踢到前端去让前端想办法实现基于/的认证…于是前端开始抱怨(悲剧)…

谁将主宰

产生这些矛盾的原因是设计不够清晰。毫无疑问,在开发过程中,领导者应该是架构师或设计师。

但在实际场景中,架构师或设计师往往是开发者,所以他们的主要技术栈会极大地影响整个项目中前后端的主次角色。

这个骨干在哪里,开发的便利性就会偏向哪一边。这是一个不好的现象,但是我们不得不面对这样的现状,相信很多规模不算太大的团队都面临着类似的问题。

如果没有好的流程规范,通常前端会比后端暴露更多的角色(大部分应用项目/产品,不是所有情况):

也就是说,前端可以成为项目沟通的中心,所以比后端更适合担当主角。

界面设计

接口分为后端服务实现和前端调用两部分。技术成熟不难,难的是界面设计。前面说了,前后端会有一些矛盾。

从前端看,重点是用户体验,包括用户在业务运营过程中的流向和相关处理。

从后端的角度来看,重点是数据完整性、可用性和安全性。矛盾在于双方关注点不同、信息不对称、利益不同。解决这些矛盾的重点是界面设计。

在设计界面时,其粒度往往代表前后端工作负载的大小(不是绝对的,与整体架构有关)。

界面粒度太小,前端要处理的东西很多,尤其是各种异步处理可能会觉得不堪重负。

如果粒度过大,会出现高耦合,降低灵活性和可扩展性。当然,在这种情况下,后端的工作就不容易了。

业务层面的事情,涉及到具体的产品,这里就不多说了,这里主要谈一点技术层面的事情。

形式上,Web API 可以定义为 REST 或 RPC,只要前端和后端协商确定即可。

更重要的是,在输入参数和输出结果方面,最好从一开始就有一个相对固定的定义,这往往取决于前端架构或使用的UI框架。

常见请求参数的数据形式如下:

服务器响应的数据形式多种多样,通常一个完整的响应至少需要包含三个部分:状态码、消息和数据,其中:

我们在实践中使用的是JSON形式,这种形式最初是定义的。

代码主要用于引导前端进行一些特殊的操作,比如0表示API调用成功,非0表示调用失败,1表示需要登录,2表示未授权……

对于这个定义,前端得到响应后,可以在应用框架层进行一些通用的处理。

例如code为1时,会弹出登录窗口,要求用户在当前页面登录,code为2时,会弹出提示信息并附上引导链接用户获得授权。

参考前后分离模型的封装Api调用:

在前端框架切换到 .比如很多UI库支持为组件配置数据URL,会通过AJAX自动获​​取数据,但是需要数据结构。

如果还是使用之前设计的响应结构,需要为组件定义一个数据过滤器()来处理响应结果,为组件编写和声明的工作量不小。

为了减少这部分的工作量,我们决定改变界面。新接口是一个可变结构。通常,它返回 UI 所需的数据结构。在发生错误的情况下,它会响应原始类型的数据结构。 :

对于新的响应数据结构,前端框架只需要判断该属性是否存在,如果存在,则检查该属性是否为指定的特殊值(如特定的GUID)。

然后使用它的代码和属性来处理错误。这个错误判断过程稍微复杂一些,但是前端应用框架可以统一处理。

如果你使用样式接口,一些状态码可以被HTTP状态码代替。例如,401表示需要登录,403表示未授权,500表示程序处理出错。

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

发表评论

登录后才能评论