十年老树发新芽-前后端分离实践

栏目: jQuery · 发布时间: 6年前

内容简介:最早从Web2.0 Ajax技术开始兴起,就有提前后端分离了。从Gmail的单页应用,到现在的单页应用层出不穷。浏览器渲染引擎也一直在突破,越来越多的交互、计算放在了浏览器这一层。传统后端MVC架构,变成了前后端的MVC。后台的接口变成了模型层,逻辑处理层从CGI变成了JavaScript,展示层则还是标记语言HTML和CSS。当前项目从立项到2018年,已经有10余年的历史了。前端的技术栈是jQuery。后台是基于10年前的PHP框架,中间也经历过多次重构。但总体架构还是LNMP,PHP渲染的,存在的问

最早从Web2.0 Ajax技术开始兴起,就有提前后端分离了。从Gmail的单页应用,到现在的单页应用层出不穷。浏览器渲染引擎也一直在突破,越来越多的交互、计算放在了浏览器这一层。传统后端MVC架构,变成了前后端的MVC。后台的接口变成了模型层,逻辑处理层从CGI变成了JavaScript,展示层则还是标记语言HTML和CSS。

为什么要做前后端分离

当前项目从立项到2018年,已经有10余年的历史了。前端的技术栈是jQuery。后台是基于10年前的 PHP 框架,中间也经历过多次重构。但总体架构还是LNMP,PHP渲染的,存在的问题比较多。

  • 从维护侧看:1)业务逻辑复杂,充斥着很多明眼不可见的业务。导致更改bug很容易引发其他的bug。2)代码巨长无比,可读性差。3)代码结构性差、分层模糊,逻辑层的代码充斥在View层中。找代码的时间占据解决bug的大部分时间。4)前端尚处在刀耕火种的年代,前端规范差、压缩混淆不彻底,难以适应新的浏览器渲染技术。

  • 从性能侧看:单一请求,往往读取比页面所需要多得多的数据。频繁的拉取数据,不仅对后端资源是一种浪费,也会导致单一请求耗时过长。

  • 从用户侧看:因为多页应用的频繁刷新,新的URL都需要页面重载。单一页面会触发多个HTTP请求(静态资源、Ajax)。这两个因素导致用户等待时间过久。

  • 从开发人员侧看:1)开发者往往热衷于新技术。学习新技术不仅有利于团队技术成长,也有利于发挥成员的积极性。2)团队成员本身具有全栈开发的能力,转换成前后端分离的模式成本较低。

  • 从业务本身来看:产品天生适合采用单页应用,无需SEO。

前端方案选型

基于上述原因,促成团队下定决心进行正式的改造。新的项目,由于没有历史包袱,采用开源框架是水到渠成的。但对于已有项目而言,采用新框架意味着要对现有代码进行彻底重构。结合自身业务来讲,自研框架可以完美的兼容现有的前端组件库。其次,自研对框架细节的把握程度也会更强。

但是从长期来看,自研意味着需要专业人员长期维护。采用自研,对团队而言是摸着石头过河。我们需要改造业务,需要兼容现有组件,需要考虑长期的维护性,需要考虑安全和性能,需要考虑前端开发流程,还有新成员的上手程度。最重要的还有改造进度和成本。

在前端方案的落地中,团队花费了很长时间进行框架的预研,最终选择了Vue。对业务而言,框架需要提供双向数据绑定、模版引擎、组件化、前端路由,还有能与jQuery组件进行通信,定制化程度较高。

  1. React意味着全局替换,替换成本过高,成果成型慢
  2. Jsx、Ts对偏后台同学而言,学习门槛较高
  3. 在国内Vue显然更受欢迎,文档、社区也更活跃
  4. React许可协议的具有潜在的不可控性

实际开发遇到的问题

1.与jQuery组件通信:庞大的现有组件,短时间内非常难Vue化改造。必须采用hack的方式完成jQuery组件和Vue业务的通信。最终是选择发布订阅模式,收集组件的变更。如果Vue需要知道jQuery组件的变更,jQuery组件需要显式$emit通知到Vue。

2.状态管理:状态管理的加入,会增加开发门槛,使用不恰当也会导致乱用。但如果后续引入,又会增加回炉再造的成本。其次不引入状态管理,全局变量的处理也是问题。

3.样式的规范管理:前端的样式规范,也是需要改造的痛点。最终选用业界使用较成熟的BEM规范。

后端方案选型

这些年后端的发展与前端相比,就显得小巫见大巫了。后端现有代码量更大,如果仅仅为了PHP的命名空间、自动加载、依赖注入,就去更换框架就有些得不偿失了。现有的框架性能、类的加载、路由、关系对象映射模型,已经有较好的方案来支撑。

前后端分离对后端而言,最大的改造点,在于接入层的处理,即数据的输入输出方式。对接口而言,性能对前后端分离的体验至关重要,也是我们重点考虑的问题,我们加入了HTTP协议层的缓存。在代码规范、log管理、安全校验(参数过滤)、业务安全(越权)、频率限制、签名验证、登陆验证等问题,也在框架层面做了完善和加强。最后基于前后端分离流程的完善,我们使用Apidoc作为接口文档的管理工具。

后续的工作

前端

  1. 开发规范:Js代码规范、CSS规范、组件规范,自动检测 工具 支撑。
  2. 代码结构:文件结构划分。
  3. 测试支撑:UI自动化测试、前端构建测试。
  4. 运维监控:前端日志上报、前端错误监控、优化分析。
  5. 运营支撑:点击流、访问转化分析。
  6. 开发调试:开发调试工具的完善。
  7. 运维部署:灰度引入、前端发布流程及工具完善。

后端

  1. 业务接口性能和安全:随着业务改造,新接口的性能及伴随的业务安全。
  2. 共用逻辑的拆分和复用:和现有模式的代码复用和拆分,服务层的完善。

一些观点

  1. 没有工具支撑的规范,抵不过人的惰性。
  2. 动态优化的方法论。改造之前想想两年后你期望项目长什么样,反过来推导现在应该怎么做。
  3. 理解业务是重点,任何框架都会被时代抛弃,选择最适合业务的。
  4. 系统性思维,无论前端还是后端,都具等同性。
  • 开发流程始终围绕:代码管理、开发调试、代码编译、项目构建、模块管理、配置部署、测试支撑、性能检测、安全扫描、规范约束、统计分析、运营支撑。
  • 开发指标:可用性、可靠性、可维护性、安全性。

以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

计算机组成原理

计算机组成原理

唐朔飞 / 高等教育出版社 / 2008-1 / 43.00元

《面向21世纪课程教材•普通高等教育"十一五"国家级规划教材:计算机组成原理(第2版)》内容简介:为了紧跟国际上计算机技术的新发展,《面向21世纪课程教材•普通高等教育"十一五"国家级规划教材:计算机组成原理(第2版)》对第1版各章节的内容进行了补充和修改,并增加了例题分析,以加深对各知识点的理解和掌握。《面向21世纪课程教材•普通高等教育"十一五"国家级规划教材:计算机组成原理(第2版)》通过对......一起来看看 《计算机组成原理》 这本书的介绍吧!

随机密码生成器
随机密码生成器

多种字符组合密码

RGB HSV 转换
RGB HSV 转换

RGB HSV 互转工具

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具