信安微前端一体化实践方案

原创王斌 58技术

导读

当我们遇到前端遗留系统迁移、后端解耦，前端聚合、项目过于庞大，代码编译慢、单一的技术栈无法满足业务需求的时候，我们该怎么办？那么，在这个时候，我们就需要使用新的技术、新的架构，来容纳、兼容这些旧的应用。而微前端就是来解决这些问题，微前端是一种将web应用由单一的单体应用转变为多个小型前端应用聚合为一的应用方案。可以解决巨无霸应用、工程膨胀、技术栈不一、开发维护等问题。

微前端架构价值：

1. 技术选型灵活: 技术栈无关，各个子项目可以使用如今市面上的所有前端技术栈；

2. 复杂度可控：每一个UI业务模块由独立的前端团队开发，避免代码巨无霸，保持开发时的高速编译，便于项目维护；

3. 独立部署：每一个模块可快速打包，独立部署，互不影响；

4. 容错：单个模块发生错误，不影响全局；

5. 扩展：每一个服务可以独立横向扩展以满足业务伸缩性。

背景

华生数据管理平台是信安一站式风控决策支持平台，目前规划有各种大盘展示、数据看版、多维分析、数据管理、用户分析等模块，这些模块均会持续迭代并后续还会新增多个华生体系下的模块。并且部分模块是完整的已经开发好的系统，由于历史原因所用的技术栈是jquery+jsp模版实现的，现为了平台的完整性，需要整合这些系统到平台上。

目前我们常用的前端开发模式如下：

可以看到，当我们把各个业务模块放在同一个项目中时，随着业务的迭代及增加时，有如下问题：

1，代码越来越多，打包越来越慢；

2，项目迭代优化某个模块部署升级需全量进行，容错性低；

3，项目太大，文件越来越多，文件结构不受控制，业务开发寻找变得也越来越困难。

1. 需求分析

结合以上业务背景和了解的微前端方案，我们对需求进行分析：

1、兼容遗留的jquery老系统到华生平台上；

2、拆分巨无霸应用项目，进行拆分解耦，将不同模块独立管理；

3、局部升级项目模块，不需要整体升级所有内容；

4、加速项目启动，提高开发维护体验，急速部署上线。

2. 方案选择

对于此类项目。在微前端方案中，有多种方案，如下图所示各个方案的分析：

由上述方案对比，因为可以看到我们项目需要兼容jquery等老项目，所以最终选择了自带js/css沙箱功能，通信低难度低，侵入性正常的qiankun方案。

3. 架构设计

参考《从入门到微前端》一书中，可以看到微前端设计理念：

1) 中心化路由：就是我们需要有一个地方来管理我们的应用，发现存在哪些路由，哪个应用使用哪个路由，管理好我们的路由，实际上就是管理好我们的应用

2) 标识化应用：根据康威定律，就是在同一个组织下，不可能有两个项目名称是一样的

3) 生命周期：qiankun基于Single-SPA封装的库，因此它延用了一个基本的声明周期，它包含五种状态：

lload,决定加载哪个应用，并绑定生命周期

lbootstrap，获取静态资源

lmount, 删除应用的生命周期

lunload，删除应用的生命周期

lunmount，卸载应用，如删除DOM节点

4) 标独立部署，配置自动化

基于以上微前端设计理念，系统的架构设计如下所示：

整体的工程流程如下所示：

一、主工程在运行的时候，会去服务器获取最新的应用配置

二、主工程在获取配置后，将一一创建应用，并为应用绑定生命周期

三、当主应用监测到路由变化的时候，将寻找是否有对应的路由匹配规则

四、当匹配对应用的时候，则加载相应的应用

4、业务实践

由上所说的架构方案，所对应的结构如下图所示：

构建主应用基座

将普通的项目改变成qiankun 主应用基座，需要进行三步操作：

l创建主应用容器，用于渲染子应用；

l注册子应用，设置子应用的激活条件，子应用的地址等等；

l启动qiankun。

说明: 构建主应用基座可以是任意技术栈，由于我们团队技术栈是react+umi+dva这套技术栈，因此以下介绍示例是react+umi 的主应用。

1. 创建主应用容器

我们在主应用中创建子应用的承载容器，这个容器规定了子应用的显示区域。

第55行：主应用菜单，用于渲染菜单，并配置菜单路由，触发路由加载子应用；
第65行：子应用加载后，渲染到当前节点中。

2. 设置qiankun插件

3. 设置运行时子应用配置

12行：通过props传递主应用的数据或者方法给子应用
33行：从上代码可以看出，我们重写了请求html。因为结合我们业务场景，我们部分子应用走了集团的安全验证，因此用户登录主应用后，需要携带我们安全验证的token,重写请求html就是携带token去验证。
注：考虑到业务需求扩展性，因此我们采用node搭建web站点，提供站点的sso,权限，路由，跨域等功能。

子应用接入