企业项目微前端改造——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分发的方式
复制代码