中后台项目的升级实践

本文作者为 360 奇舞团前端开发工程师

背景

前端项目的种类很多，特别是有了大前端概念之后，除了传统 web 的项目外，还有各种端。从项目的生命周期去看，中后台、巨石应用等已经是长周期项目的代名词，此类项目有其独有的特点。那么随着项目的持续迭代，代码量及开发者都在递增，随之也带来了如：技术栈落后、不易维护、开发效率及体验差等等问题。如果这个项目还需要持续维护，那我们不得不做一些思考了。

重构

因为是生命周期长的原因，才导致中后台项目不断暴露出来问题。重构好像是解决此类项目的最佳选择，能够解决开发及可维护性上的问题，对用户体验也可以有一定提升的。但是重构的代价是巨大的，因为此类项目经过大量长期的功能迭代，不仅需要前端同学的开发，还需要后端、测试等进行介入，才能保证重构的质量。不论从人力时间成本、还是风险性上来说，完全重构并不是最好的选择。那么除了重构，还有什么方案能够解决此类项目的弊端？

渐进式重构

或者叫增量升级，这种解决方案的目的和重构是一致的。区别是在于，增量升级的过程更灵活可控、风险性更小。在项目重构的实践中，可以使用微前端的方式来实现渐进式重构，相关概念这里不做过多的描述了，大家可以自行查阅。下面主要探讨基于一个大型 MPA 中后台应用，如何实现项目的增量升级。

实践思路

作者所在团队支持的业务中，现有维护的项目不乏有长期迭代的中后台系统，其中痛点也是深有体会。下面通过简述对一个云控制类中后台系统的改造升级的思路，希望对你有所帮助。

项目的背景

前端当前版本基于 React v0.14 + webpack4，经过 7+ 年持续迭代。随之而来的带来如下问题：

• 代码量巨大

• 编码规范不统一

• 编译速度越来越慢

• 无成熟组件库

• 自研组件不满足现有需求开发

• 技术栈老旧、文档缺失

• 新需求功能实现繁琐

• 开发体验极不友好

• 发版全量编译

• ……

项目现在面临的问题是长期迭代的必然结果，随着项目生命周期的不断延长，现有的缺陷会被进一步放大。整体来说随着持续的迭代，现在项目暴露的问题越来越多，主要体现在开发体验和效率上。

已有的优化及现状

虽然对项目做了很多优化，但是随着项目的迭代，优化是治标不治本。
如编译速度方面，通过增量编译的方式提升了首次编译的效率，二次的编译通过缓存方式优化后依旧是不理想，代码的改动更新依旧需要 10 秒以上。
首次全量编译：

首次增量编译：

二次编译：

如果要彻底解决，还是要对项目整体的技术架构进行升级。

如何解决

上面也提到过通过微前端的方式对项目进行增量升级，这样既可以解决项目本身的痛点，也不会对开发人员日常的开发工作增加过大的负担。相关的技术已经比较成熟，社区也有很多好的实践方案，重点是如何根据项目本身的特点，选择合适的技术栈，以及合理的颗粒度拆分，低成本稳定的进行升级。

基于业务场景、项目和团队因素，选择了如下技术组合：

• React hooks

• Antd

• webpack

• qiankun

• monorepo

• pnpm

• ……

之前的技术栈

基于 webpak+react0.14 将多个应用使用 MPA 的方式进行构建，MPA 的方式在项目生命周期初期还是比较合适的，但是持续迭代到现在，已经暴露出了很多问题。

应用拆分

• 首先是将 MPA 应用拆分为多个 SPA，以端口区别启动

• 将 webpak 配置、公共模块进行抽取，统一复用

• pnpm 配置命名空间，添加公共组件到 SPA

• 拆分完的子应用使用 pnpm 的命名空间复用公用模块

主子应用改造

使用新的技术栈创建一个基座应用接入 qiankun、注册子应用。指定不同 URL 加载子应用挂载到指定节点。

调整旧 SPA 应用 webpack 配置，导出 qiankun 生命周期改造为子应用。

因为旧的 SPA 应用的 webpack 已经抽离复用，所以只需要在公共的 webpak 配置里增加对应的配置

拆分需要重构的模块

上面说到，将 MPA 拆为多个 SPA。接下来就是要选择需要重构的应用的模块，将这个功能模块从 SPA 里拆分出来，作为一个新的 SPA，使用新的技术栈开发。
具体做法是将需要拆分的应用，公共部分抽离到基座管理，使用新的子应用替代原来应用里的对应的模块。如图，蓝色部分是包含基座在内的公共模块，绿色是拆分的应用。黄色虚线是暂未拆分的应用，需要的时候再进行抽离拆分。

主子应用技术栈划分及复用

从旧的子应用里拆分出新的子应用和基座的技术栈保持一致，并将新的 webpack 配置和公用组件抽离复用，旧技术栈的子应用使用之前的配置

• 新技术栈的应用复用新的 webpack 配置和新的组件

• 老的技术栈应用复用老的 webpack 配置和旧的组件

• 新老技术栈应用都可以复用公用函数类和登录逻辑

应用类型

整个生命周期内的应用类型包含基座应用、子应用、公共组件和公共逻辑

• 子应用包含完全未拆分（可以复用旧 UI）、部分已拆分、已拆分

• 组件也分为新组件(用于新技术栈应用)、旧组件(用于旧技术栈应用)

• 共用逻辑则包含登录、工单等信息

开发场景视角

从开发的视角看应用的流程
需要注意的是：

• 纯基座开发，只启动基座就行

• 子应用+基座，启动基座及子应用

• 子应用启动

  • 如果是没有拆分过的子应用，直接启动子应用，可以当做是一个 纯SPA 开发

  • 如果是拆分过的子应用单独启动，默认是没有侧边栏和顶部布局的（可以在子应用里通过全局变量判断，在公共组件里引入使用）

MPA部署逻辑及用户访问

全量编译部署，每次的改动发版都需要整体进行编译部署

通过nginx重定向到对应的 html入口 然后加载对应js、chunk进行渲染

MFE部署逻辑及用户访问

升级之后可以选择需要部署的应用实现增量编译部署

微前端改造完成之后，构建产物目录结构发生了变化，基座在根目录，子应用在二级目录。

正常的包含基座的访问，由nginx统一重定向到基座入口，然后由基座根据访问路径下发到对应子应用。
子应用单独访问不涉及到基座时，由nginx根据访问路径直接重定向到对应入口。需要提到的一点是未拆分的子应用本身完全不依赖基座，所以只由nginx代理到对应入口就行。
同时为了提供子应用单独访问的能力，其路径和正常访问有所差异，所以子应用的路由 base 需要根据qiankun的全局变量进行判断调整。

依赖及组件管理

可以通过这张图来看下整个应用生命周期内，对依赖及组件的管理

总结

结合业务场景及项目特点，现在的架构方式解决了之前的痛点，使得项目本身可以根据需求增量升级，同时满足了子应用单独对外开放、支持其它项目的接入。
简单说一下此次项目升级带来的好处：

• 本地拆分应用开发二次编译速度提升，由 10S+ 降低到 2S 左右，提升 5-10 倍

• 技术更新对新功能实现和用户体验更友好

• 应用独立开发、部署，效率提升

• 方便业务后续统一功能融合及拓展

• 新的技术栈接入对团队成员技术成长有积极的影响

最后

完成项目重构的基础架构只是从0到1，如何加速整个重构过程的速度也是更值得考虑的。同时根据项目和业务特点选择合适的技术方案，以合理的方式进行升级，让对应的技术发挥其价值。

- END -

关于奇舞团

奇舞团是 360 集团最大的大前端团队，代表集团参与 W3C 和 ECMA 会员（TC39）工作。奇舞团非常重视人才培养，有工程师、讲师、翻译官、业务接口人、团队 Leader 等多种发展方向供员工选择，并辅以提供相应的技术力、专业力、通用力、领导力等培训课程。奇舞团以开放和求贤的心态欢迎各种优秀人才关注和加入奇舞团。