企业项目微前端改造——qiankun框架

讲述以前在一家公司，经历了一次巨石项目的微前端改造(本篇几乎不涉及开发代码)。代码又是由第三方公司外包，后续公司拿来本身开发维护，因为公司业务发展迅猛，前期并无合理规划前端架构，在开发一年后决定技术改造，提出微前端的方式进行改造，同时提供一套兜底方案。这就面临着，一边是叠加的业务模块，一边是技术改造，两条腿同时走路的问题就在于，资源不够。

背景

1. 运营平台业务模块多达100+，近乎于巨石项目
2. 代码的打包发版时间过长
3. 多人协做开发，test环境频繁发版，形成环境不稳定
4. 共用模块频繁冲突，util模块冗余

基于上述4点，进行项目改造

预研

1. 拆服务——对于运营平台各个模块进行领域划分
2. 方案一：iframe 做为沙盒容器承载着各个服务
3. 方案二：拆服务，以一个服务做为主入口，关联其余服务(子入口)

这里作个小结
- 两套方法的思想实际上是差很少的，大容器套小容器，关键是容器直接的通讯、用户鉴权
- 微前端是个微服务的思想，若是从0-1作微前端是容易的，技改为微前端，存在必定挑战

复制代码

后续预研中，大佬提出使用qiankun框架，这个框架说是大厂作背书，应该不会有太多问题，(那会儿，qiankun刚开源没多久)。后面就是在已有项目中demo、申请服务资源、登录权限。

qiankun 摘要

yarn add qiankun # or npm i qiankun -S

import { loadMicroApp } from 'qiankun';
// 加载微应用
loadMicroApp({
  name: 'reactApp',
  entry: '//localhost:7100',
  container: '#container',
  props: {
    slogan: 'Hello Qiankun',
  },
});
// https://qiankun.umijs.org/zh
复制代码

qiankun框架中，提供了父、子服务的概念，它为咱们实现的是父、子之间的通讯，登录权限、用户状态、解决缓存

巨石项目须要处理的问题

1. 本地权限的拆分
2. node中间层(用于前端鉴权)交由后端负责
3. 限制发版次数
4. 共用模块拆分

总结

- 对巨石项目的拆解，套用qiankun框架，最后失败
- 在已经拆分的服务的基础上，采用兜底方案处理
- 失败的缘由，qiankun社区还没有丰富，平台自身业务发展迅速，彻底的qiankun化改造，跟不上预期效果
- 探索qiankun的过程当中，一部分拆解也在兜底方案中得以应用，也是有必定成果
- 微前端，是一种前端分发的理念。
- 以前，遇到的项目，也是微前端思想，采用的是咱们的兜底策略，只是人家把公共组件使用npm分发的方式
复制代码