《浅谈架构之路:前后端分离模式》
对前后端分离研究了一段时间,恰逢公司有一个大项目决定尝试使用前后端分离模式进行,便参与其中。该项目从2016年初立项至今,平平稳稳得度过,但也涌现出越来越多的问题,绝对不是说前后端分离模式不好,而是很多公司在尝试前后端分离的时候没有做好充分得准备。
网上对前后端分离介绍的文章已经屡见不鲜,接下来本人用一点粗浅的言语也谈谈这块,献丑了。
为什么要分离?如果只问“前后端分离的意义大么?”这是废话,因为从软件架构的角度 Web 的前后端从一开始不就一直是分离的么,而且 browser、server 可能将永远分离下去。
为了了解这个问题,我们有必要先了解一下 Web的研发模式演变,关于这个题材,下面这篇博文说得不错,这边就不做搬运工了。
https://github.com/lifesinger/blog/issues/184
我们不能“为了分离而分离”,而应该“为了真正理解web开发、为了更好完成需求而分离”。
前后端分离的误区?1、前端人员配备是否充足?
由于所在公司以往项目采用传统开发风格,即以后端MVC为主的开发模式,前端人员仅仅提供静态html页面,其余工作皆由后端开发人员完成。采用前后端分离模式可以减后台负担,加快研发效率,当然,前提是前端能做好的话。以往只需要提供静态页面的前端人员,在前后端分离模式中要负责项目的view+controller部分,即除了静态页面,还需要负责页面的所有交互代码、以及nodejs与视图层以及后端API的交互工作,无疑增加了前端人员的学习成本,在没有足够知识和人才储备的情况下,只能让前端人员加班加点。结果是大量前端人员离职(PS:做这么多事,工资总得加吧!)
2、前后端职责分配?
很多公司认为采用前后端分离之后,前后端只需要通过指定API进行交互即可,前端负责页面渲染,Nodejs负责路由分配,后端提供API。忽视了大量关键工作,职责分配和细节处理没有相应文档规定,缓存机制、图片上传下载、数据校验、语言国际化等等并没有出具相应信息。另外,大量忽视了nodejs层的作用,仅仅把nodejs当成一个路由中转,这一方面也是对nodejs技术的不熟悉导致的,其实nodejs能负责很多事,除了复杂业务逻辑处理和数据操作由Java 负责,大量工作完全可以在nodejs层处理。(PS:还是基础不够导致的!)
3、后端API是否Restful风格?
很多公司采用了前后端分离模式后,后端API仍然采用以往的传统风格,这是不合理的,Restful风格的API应该是前后端分离的最佳实践。ResultFul推荐每个URL能操作具体的资源,而且能准确描述服务器对资源的处理动作,通常服务器对资源支持get/post/put/delete/等,用来实现资源的增删改查。前后端分离的话,这些api-url是对接的桥梁,采用resultFul接口地址含义才更清晰、见名知意。(PS:用了Spring4.x 竟然还不用rest风格,说不过去啊)
4、前后端协作模式?
前后端分离后,无论是API接口的对接还是测试工作,都涉及到前后端人员的沟通,很多公司采用前后端分离后,前后端协作模式配合力度底,互相等待,开发效率低下,反而不如传统的开发模式。例如:当后端 API 没有编写完成时,前端无法进行调试,这就导致了前端会被后端阻塞的情况。其实像这种互相等待的模式需要改进, Mock Server 可能可以解决一些问题。
如何前后端分离?怎么做前后端分离?大方向就是
后端专注于:后端控制层(Restful API) 服务层 数据访问层;
前端专注于:前端控制层(Nodejs) 视图层
本人认为的前后端分离模式应该是这样,当然这不一定正确:
1、项目设计阶段,前后端架构负责人将项目整体进行分析,讨论并确定API风格、职责分配、开发协助模式,确定人员配备;设计确定后,前后端人员共同制定开发接口。
2、项目开发阶段,前后端分离是各自分工,协同敏捷开发,后端提供Restful API,并给出详细文档说明,前端人员进行页面渲染前台的任务是发送API请(GET,PUT,POST,DELETE等)获取数据(json,xml)后渲染页面。
3、项目测试阶段,API完成之前,前端人员会使用mock server进行模拟测试,后端人员采用junit进行API单元测试,不用互相等待;API完成之后,前后端再对接测试一下就可以了,当然并不是所有的接口都可以提前定义,有一些是在开发过程中进行调整的。
4、项目部署阶段,利用nginx 做反向代理,即Java + nodejs + nginx 方式进行。
编后语
从经典的JSP+Servlet+JavaBean的MVC时代,到SSM(Spring + SpringMVC + Mybatis)和SSH(Spring + Struts + Hibernate)的Java 框架时代,再到前端框架(KnockoutJS、AngularJS、vueJS、ReactJS)为主的MV*时代,然后是Nodejs引领的全栈时代,技术和架构一直都在进步。虽然“基于NodeJS的全栈式开发”模式很让人兴奋,但是把基于Node的全栈开发变成一个稳定,让大家都能接受的东西还有很多路要走。创新之路不会止步,无论是前后端分离模式还是其他模式,都是为了更方便得解决需求,但它们都只是一个“中转站”。
走过的“中转站”可能越来越多,但是不要渐行渐远才是。
作者:山人行
来源:51CTO
你知道微服务架构中的“发件箱模式”吗 微服务架构如今非常的流行,这个架构下可能经常会遇到“双写”的场景。双写是指您的应用程序需要在两个不同的系统中更改数据的情况,比如它需要将数据存储在数据库中并向消息队列发送事件。您需要保证这两个操作都会成功。如果两个操作之一失败,您的系统可能会变得不一致。那针对这样的情况有什么好的方法或者设计保证呢?本文就和大家分享一个“发件箱模式”, 可以很好的避免此类问题。
阿里 CTO 程立:Severless 化正加速重塑阿里应用架构和研发模式 “阿里巴巴正在享受云上研发带来的技术红利。”11 月 11 日,阿里巴巴 CTO 程立表示,作为全球最大、最复杂的电商交易系统,淘宝首页已完成了全面 Serverless 化,显著提升了研发运维效率,Severless 化正加速重塑阿里应用架构和研发模式。
Github标星67.9k的微服务架构以及架构设计模式笔记我粉了 微服务架构是什么? 我们都知道微服务架构是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的 类上应用很多SOLID原则。微服务架构是个很有趣的概念,它的主要作用是将功能分解到离散的各个服务当中,从而降低系统的耦合性,并提供更加灵活的服务支持。
组装式架构重构未来平台研发模式 企业数字化转型如火如荼的进行中,快速响应市场需求变化,低成本进行数字化改造时每个企业追求的目标。而组装式架构可以完美解决B段客户对于软件平台的高质量要求。
软件架构模式之微服务架构 微服务架构(Microservice Architecture)是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念,它的主要作用是将功能分解到离散的各个服务当中,从而降低系统的耦合性,并提供更加灵活的服务支持。
软件架构模式之事件驱动架构 事件驱动架构(Event Driven Architecture)是一个流行的分布式异步架构模式,可以用来设计规模很大的应用程序。基于这种架构模式应用可大可小。它由高度解耦的,单一目的的事件处理组件组成,可以异步地接收和处理事件。
微服务架构 | 11.1 整合 Seata AT 模式实现分布式事务 Seata 是一款开源的分布式事务解决方案,致力于在微服务架构下提供高性能和简单易用的分布式事务服务;它提供了 AT、TCC、Saga 和 XA 事务模式,为开发者提供了一站式的分布式事务解决方案;
相关文章
- 分布式Session架构演示史
- 聊聊架构模式的变迁:从分层架构到微服务架构
- 【并行计算-CUDA开发】从零开始学习OpenCL开发(一)架构
- CV-图像分割-20230405:DINOv2【预训练大模型,拥有 10 亿级参数量,采用Transformer架构;可在语义分割、图像检索、深度估计等方面实现自监督训练。无需微调即可应用于多种下游】
- 硬件架构的艺术学习笔记(2)时钟与复位
- 强势解析eBay BASE模式、去哪儿及蘑菇街分布式架构
- 移动支付技术架构及应用模式探讨
- SaaS模式实现架构
- [置顶] 遵循Java EE标准体系的开源GIS服务平台架构
- Supermicro公司采用Skylake芯片 性能优于Broadwell微架构
- 微博feed系统的推(push)模式和拉(pull)模式和时间分区拉模式架构探讨
- 分层架构设计模式总结-MVC,洋葱架构,整洁架构,六边形架构,DDD等等
- 【架构】Twitter高性能RPC框架Finagle介绍
- 稳定模式在RESTful架构中的应用
- 四种模式、五大架构 规划企业物联网蓝图
- MicroService 微服务架构模式简述
- LeetCode·707.设计链表·架构题
- ARMv7/ARMv8/ARMv9架构你不知道的那些事
- 轻松支撑百万级数据点写入 京东智联云时序数据库HoraeDB架构解密
- [转]秒杀业务架构优化之路
- JDBC操作数据库以及三层架构模式