大型 SPA 项目架构设计与重构

简介: 本文主要为分享我司 控制台 最近两年的架构演进,遇到的问题和解决方案等。控制台项目包含近百个不同产品,跨部门、跨地域协作开发,是一个比较典型的大型 SPA 前端项目。

大型 SPA 项目架构设计与重构

本文主要为分享我司 控制台 最近两年的架构演进,遇到的问题和解决方案等。控制台项目包含近百个不同产品,跨部门、跨地域协作开发,是一个比较典型的大型 SPA 前端项目。

先说下为何要做架构重构,老架构以及老架构下的一些问题。

老架构介绍

控制台老架构底层为 angular@1,使用 angularui-routerlazy-load 来进行项目的按需加载运行。大部分项目通过 angular 挂载 react 实例,虽然很多业务代码和 angular 无关,但是依然有很多地方(如 services、路由等)依赖 angular

老架构存在的问题

老架构存在的问题主要分为两部分,运行时问题和开发时问题:

运行时问题

老架构严重依赖 angular

由于当初整套架构设计基于 angular 的能力,导致启动器体量大、加载慢、性能差。

老架构下的依赖体量重

老架构下公共部分主要分为 commoncomponents,里面存在大量的历史遗留、冗余、无效代码,历史包袱重,而且依赖混乱,无法安全清理。

耦合严重

老架构下的项目,虽然大部分项目代码已经都是 react 代码,但是有一些 services 依然依赖 angular。启动器、公共依赖、项目间的代码耦合严重。

性能问题

启动器重、依赖重、语言文件混合导致过大、初始化内容过多等各种问题导致项目加载慢、执行慢。

开发时问题

使用麻烦、风险高

老架构的项目结构为一个主项目和 N 个子项目,主项目中包含着开发脚本、开发依赖,其它的项目如依赖、启动器、项目均作为子模块(git submodule)管理。

开发时需要检查主仓库更新,检查依赖更新,执行开发脚本,还需注意启动器项目的版本、冲突、依赖更新等,使用成本高。

升级成本高

开发环境无法安全升级,由于所以依赖、脚本都是全项目共享,升级会直接影响到上百个子项目,导致不能随意变动。

新架构

微信截图_20221018131738.png

控制台项目分三层,启动器、公共模块、业务模块。

启动器

启动的承载着网站最基本的功能,包括:

  • 骨架屏
  • 浏览器兼容处理 - 不兼容版本提示
  • 项目路由管理(router-service) - 跨项目跳转
  • 项目加载/挂载/卸载(微前端 rapiop
  • 模块管理器(mod
  • 主题 - 主题加载/切换
  • 基础依赖 - babel polyfillreset-style
  • sentry - 错误上报
  • matomo - 用户行为分析、数据上报
  • 其它的一些内部服务等

公共模块

services

services 为内部的一些公共服务。

  • user - 用户信息
  • intl - 语言翻译
  • das - 数据上报
  • regionproject

libs

libs 用于输出一些常用的公共模块、开源库。

  • reactreact-domreact-router - react 相关库
  • components - 公共组件库
  • apexchartsreact-apexcharts - 图标库
  • lodash 等工具库

components

components 包括控制台相关的一些业务组件

  • common-components - 常用的业务组件、布局、路由组件等
  • umon-components - 监控相关组件
  • code-components - 代码编辑器组件
  • ulog-componentspay-components

其它模块

  • sidebarnavbar - 公共部分的 UI
  • styles - 通用的样式
  • react-adapter - 项目适配器,减少样板代码(注册微前端、初始化语言、依赖加载等)

业务模块

业务模块主要为各业务项目,分为老项目、新项目。

优化后

  • 轻量无依赖启动器
  • 职责明确
  • 模块拆分、自治、依赖明确
  • 无耦合

运行流程

进入页面:

  • 浏览器兼容检测,polyfill、基本依赖加载
  • reset 样式加载,主题、matomosentry 初始化
  • 灰度信息获取,未登陆则跳回登陆
  • 使用灰度信息初始化微前端、模块管理器
  • 根据当前 url 匹配项目,如果为老项目则加载老启动器,进入老项目加载流程,新项目直接加载项目、依赖

微信截图_20221018131824.png

开发

开发环境拆分为两部分:CLIdev-dependences

CLI

提供 CLI 工具,提供开发、构建、打包分析、codemod、依赖管理等功能。

dev-dependences

包含了项目的开发依赖:webpackeslintloaders 等,存在多版本,可方便后续的升级迭代,降低升级成本和风险。

提供依赖对应的功能脚本:开发、构建等。

开发启动

通过 CLI 启动开发命令,会根据命令启动启动器(线上/预发步/本地),启动指定项目中的开发依赖中的开发脚本并通信,合并线上灰度信息和本地文件信息。

优势

  • 升级维护安全
  • 使用方便

现状

目前处于新架构老架构共存的状态,大部分的老项目在逐渐替换旧的 services 等,进行平滑升级。

相关文章
|
28天前
|
前端开发 JavaScript 测试技术
Kotlin教程笔记 - 适合构建中大型项目的架构模式全面对比
Kotlin教程笔记 - 适合构建中大型项目的架构模式全面对比
30 3
|
2月前
|
前端开发 JavaScript 测试技术
android做中大型项目完美的架构模式是什么?是MVVM吗?如果不是,是什么?
android做中大型项目完美的架构模式是什么?是MVVM吗?如果不是,是什么?
122 2
|
25天前
|
监控 前端开发 数据可视化
3D架构图软件 iCraft Editor 正式发布 @icraft/player-react 前端组件, 轻松嵌入3D架构图到您的项目,实现数字孪生
@icraft/player-react 是 iCraft Editor 推出的 React 组件库,旨在简化3D数字孪生场景的前端集成。它支持零配置快速接入、自定义插件、丰富的事件和方法、动画控制及实时数据接入,帮助开发者轻松实现3D场景与React项目的无缝融合。
97 8
3D架构图软件 iCraft Editor 正式发布 @icraft/player-react 前端组件, 轻松嵌入3D架构图到您的项目,实现数字孪生
|
1月前
|
前端开发 JavaScript 测试技术
android做中大型项目完美的架构模式是什么?是MVVM吗?如果不是,是什么?
在 Android 开发中,选择合适的架构模式对于构建中大型项目至关重要。常见的架构模式有 MVVM、MVP、MVI、Clean Architecture 和 Flux/Redux。每种模式都有其优缺点和适用场景,例如 MVVM 适用于复杂 UI 状态和频繁更新,而 Clean Architecture 适合大型项目和多平台开发。选择合适的架构应考虑项目需求、团队熟悉度和可维护性。
53 6
|
1月前
|
存储 前端开发 数据可视化
在实际项目中,如何选择使用 Flux 架构或传统的 MVC 架构
在实际项目中选择使用Flux架构或传统MVC架构时,需考虑项目复杂度、团队熟悉度和性能需求。Flux适合大型、高并发应用,MVC则适用于中小型、逻辑简单的项目。
|
2月前
|
前端开发 JavaScript 测试技术
Android适合构建中大型项目的架构模式全面对比
Android适合构建中大型项目的架构模式全面对比
51 2
|
2月前
|
存储 分布式计算 Hadoop
Hadoop-33 HBase 初识简介 项目简介 整体架构 HMaster HRegionServer Region
Hadoop-33 HBase 初识简介 项目简介 整体架构 HMaster HRegionServer Region
59 2
|
3月前
|
负载均衡 数据库 开发工具
|
3月前
|
Java 数据库 Maven
谷粒商城笔记+踩坑(1)——架构、项目环境搭建、代码生成器
项目介绍、项目环境搭建、docker配置mysql,redis,jdk,maven、人人开源、快速开发、安装nodejs、逆向工程搭建,人人开源代码生成器
谷粒商城笔记+踩坑(1)——架构、项目环境搭建、代码生成器
|
2月前
|
缓存 前端开发 JavaScript
前端架构思考:代码复用带来的隐形耦合,可能让大模型造轮子是更好的选择-从 CDN 依赖包被删导致个站打不开到数年前因11 行代码导致上千项目崩溃谈谈npm黑洞 - 统计下你的项目有多少个依赖吧!
最近,我的个人网站因免费CDN上的Vue.js包路径变更导致无法访问,引发了我对前端依赖管理的深刻反思。文章探讨了NPM依赖陷阱、开源库所有权与维护压力、NPM生态问题,并提出减少不必要的依赖、重视模块设计等建议,以提升前端项目的稳定性和可控性。通过“left_pad”事件及个人经历,强调了依赖管理的重要性和让大模型代替人造轮子的潜在收益
下一篇
DataWorks