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

314次阅读  |  发布于3年以前

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

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

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

老架构介绍

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

老架构存在的问题

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

运行时问题

老架构严重依赖 angular

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

老架构下的依赖体量重

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

耦合严重

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

性能问题

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

开发时问题

使用麻烦、风险高

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

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

升级成本高

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

新架构

架构图

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

启动器

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

公共模块

services

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

libs

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

components

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

其它模块

业务模块

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

优化后

运行流程

进入页面:

流程图

开发

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

CLI

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

dev-dependences

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

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

开发启动

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

优势

现状

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

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8