基于多项目的微前端思考 #

背景介绍 #

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

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

微前端 #

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

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

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

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

公司业务需求 #

之前公司开发的子系统是没有登陆操作的，所以准备把所有子系统都接入平台然后接入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。

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

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

总结 #

三种实现微前端的手段：

• 1、iframe + postmessage
• 2、webpack5的联邦模块
• 3、使用开源的微前端框架（single-spa、阿里的乾坤）