阅读 571

基于多项目的微前端思考

背景介绍

公司业务高速发展,为了迎合发展的需要,拆分出多个后台管理系统,部分已经投入使用。虽然拆分出的系统更利于开发和维护,但是其他上下游部门使用起来比较分散不便于管理,所以我们就考虑使用一个平台将各个子系统接入进来,有两个优势:

  • 便于管理和使用的同时,并没有失去多系统开发上的优势
  • 所有系统的登陆全部抽象到平台中,通过平台登陆后分发给各个子系统

微前端

基于上述业务,我们引入一下微前端的概念。

“微”字面解释是“细小,少”,微前端也就是将一个大系统拆分成粒度更小的模块或系统。

一个项目经过长期的不断迭代会导致项目越来越大,越来越难维护,这个时候就需要进行拆分,这样可以单独开发、单独测试、单独部署,并且拆分的子系统可以用不同的技术栈去实现,更利于不同属于的团队进行开发和迭代。

但是分的太细以后,我们管理起来就非常麻烦,可以十几个甚至几十上百个子系统,不同的功能需要在不同系统中进行操作,有的时候可能满足某个业务,需要切换多个子系统配合数据的操作,十分的低效。这个时候,我们就需要将子系统再重新整合到一个平台中进行维护,这应了一句老话“分久必合,合久必分”。

公司业务需求

之前公司开发的子系统是没有登陆操作的,所以准备把所有子系统都接入平台然后接入protal进行统一管理,接下来说一下具体的实现:

通过iframe引入子系统,然后在平台上进行登陆后将token传给当前子系统(可以通过postmessage、url等),子系统将token放入请求头作为后端接口鉴权,看起来很完美,简单快捷。

为什么说很完美

  • 1、iframe隔离了所有子系统的样式(就是css)
  • 2、每个子系统都是一个沙箱
  • 3、第三通过postmessage实现了双向通讯

上面三点也就是实现微前端的必要条件

但是,你细品,细品,会发现
1、iframe的url和浏览器的url不同步,浏览器不会记录iframe的浏览记录。所以不能使用浏览器的前进后退对iframe的url进行操作,也不能刷新,否则会丢失iframe的当前页
2、iframe里面的遮罩只能在iframe中
3、每个系统都是一个沙箱,数据同步、父子系统通讯比较麻烦
4、慢,每次子系统进入都是一次浏览器上下文重建、资源重载的过程。

不过这都是体验性的问题,只要能后台操作人员能接受其实也无伤大雅

进一步思考

说到底这里,我们发现其实微前端的本质就是路由,其实我们vue-router类似,只是component变成了子系统而已。

我们上面的逻辑是各自打包、各自发布,然后通过iframe引入不同的子系统进行耦合。

其实我们还有其他的方法去实现微前端:

  • 1、webpack5新增了联邦模块, 联邦模块别以为多复杂,其实就是在子系统中导出然后在父系统中导入,父系统在打包的时候代码会自动添加fetch子系统的打包文件的代码,这样我们就能以组件的形式使用子模块和子系统了,本期只介绍微前端的三种实现,不涉及具体代码,后面会出一期webpack5联邦模块。如果还有疑问,请看webpack5联邦模块demo

image.png

image.png

但是,但是,有个问题就是你所有的子系统和父系统都是用webpack5进行开发(wepback5才有联邦模块),这种模式适合刚发展的互联网企业,所有系统都是新开发的。

  • 2、那么那种又老又臭的系统怎么接入呢,也是可以的,市面上已经有很多的微前端框架可以使用,例如single-spa、阿里的乾坤(基于single-spa二次开发)等,大致逻辑是通过生命周期将子系统的dom、css等以某种形式解析到父系统中,还有css隔离、js沙箱、各个系统间的通讯处理等,由于没有实际使用过这些框架暂不发表深入讨论,后期实际用上了再单独发表解析吧

总结

三种实现微前端的手段:

  • 1、iframe + postmessage
  • 2、webpack5的联邦模块
  • 3、使用开源的微前端框架(single-spa、阿里的乾坤)
文章分类
前端
文章标签