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

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

背景

  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分发的方式