信安微前端一体化实践方案
source link: http://mp.weixin.qq.com/s?__biz=MzI1NDc5MzIxMw%3D%3D&%3Bmid=2247489720&%3Bidx=1&%3Bsn=a089c9544f3664977ae31540b96e9a45
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
导读
当我们遇到前端遗留系统迁移、后端解耦，前端聚合、项目过于庞大，代码编译慢、单一的技术栈无法满足业务需求的时候，我们该怎么办？那么，在这个时候，我们就需要使用新的技术、新的架构，来容纳、兼容这些旧的应用。而微前端就是来解决这些问题，微前端是一种将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封装的库，因此它延用了一个基本的声明周期，它包含五种状态：
l load,决定加载哪个应用，并绑定生命周期
l bootstrap，获取静态资源
l mount, 删除应用的生命周期
l unload，删除应用的生命周期
l unmount，卸载应用，如删除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,权限，路由，跨域等功能。
子应用接入
1. 非webpack构建的子应用接入
在HTML中申明entry入口：
-
291行：自己编写一个entry文件，作为入口文件，在entry里声明lifecycles。
编写entry文件：
-
4行：动态创建加载js文件；
-
38行：区分当前应用不在主应用中加载时，独立运行；
-
48行：当在主应用中时加载html所需要的资源。
2. React的UMI 子应用接入
umirc中配置：
-
5行：子应用的base,默认为packe.json中的name字段。
应用运行时配置 ：
3. React的常规子应用接入
在src目录新增文件public-path.js：
修改入口文件main.js/index.js：
更改webpack配置：
4. Vue及Angular子应用接入
此处不做过多介绍，接入方式与react常规项目接入类似。
父子应用通知
l 主应用中配置运行时apps以props将数据传递，子应用通过相应生命周期拿到数据存进store；
l qiankun提供一个全局的GlobalState来共享数据。
公共插件共享
因为qiankun将子项目的外链script 标签，内容请求到之后会记录到一个全局变量中，下次在使用，它会先从全局变量取。所以只要子项目配置webpack的externals，并在index.html中使用外链script引入这些公共依赖，便可实现子项目的公共依赖的按需引入
部署方案
之前所有的子项目都在一个工程中，打包速度随着业务线的膨胀越来越慢，现在使子项目独立开发，独立部署，单个模块项目打包也会加快。如下图所示，子工程部署只需要把子工程打包，然后传到CDN上，并把配置信息更新，配置信息包含子工程的资源地址及配置。
l Aurthur平台是58自研的部署工具，包含测试，线上，回滚等环境，将静态资源自动化的部署到CDN；
l 配置信息上传到上文提到的node服务上，主应用从node服务拉取配置信息，实现自动更新子应用项目接入。
监控方案
引入信安自研的前端监控平台，对页面进行实时监控，能够及时的发现子工程等相关问题。
权限方案
主应用接入信安权限系统，分配到各个子项目中，避免子项目重复对接权限，重复开发，由主应用统一分配。
总结
如我们所愿，通过微前端方案实现了华生数据管理平台，目前已经接入多个项目并迁移了老系统进入平台，消除了工程膨胀问题，工程大小也变得可控，子工程打包速度加快，提高了开发体验，并能够单独开发、单独部署、单独上线，业务之间互不影响，效果图如下：
作者简介：
王斌 ，201 8 年 3 月加入58集团，目前任信息安全部客服 工程组前端负责人，主要负责项目架构设计，基础工具及工程开发，前端前沿技术调研及应用等。
参考文献：
1. https://qiankun.umijs.org；
2. https://umi.org；
3. https://microfrontends.cn；
4. https://single-spa.js.org。
推荐阅读：
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK