基于多项目的微前端思考

背景介绍

公司业务高速发展，为了迎合发展的需要，拆分出多个平台和相应的后台管理系统，部分已经投入使用。但是虽然拆分出的系统更利于开发和维护，但是使用起来却比较分散，不便于公司其他上下游部门使用，需要频繁的切换操作，所以我们就考虑使用一个大的后台系统将各个子系统接入进来，一来省去切换系统的麻烦，二来一键登陆所有系统任我用。

微前端

基于上述业务，我们就引入了一个微前端的概念，其实就是分久必合、合久必分，说人话就是一个项目合在一起长时间的不断迭代导致项目越来越大，越来越难维护，这个时候就需要进行拆分，这样可以单独开发、单独测试、单独部署，并且拆分的子系统可以用不同的技术栈去实现，更利于不同属于的团队进行开发和迭代。

反之同理，当拆分出来的系统越来越多的时候，使用起来就不是那么方便了，这个时候我们就需要把系统进行合并，如何进行合并就是我们下面要讨论的内容了。

公司业务需求

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

通过iframe引入子系统，然后在大后台进行登陆后将token传给当前子系统（可以通过postmessage、url等），子系统将token放入请求头作为后端接口鉴权，看起来很完美。

为什么说很完美，第一所有系统的样式（就是css）都隔离开了，第二每个系统都是一个js沙箱，第三通过postmessage实现了通讯，这三个也就是微前端的必要条件。

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

进一步思考

其实微前端的本质就是路由，其实我们vue项目类似，只是component变成了系统而已。我们上面的逻辑是各自打包、各自发布，然后通过iframe引入不同的子系统进行耦合。

其实我们还有另外的方法，就是通过webpack5的联邦模块, 联邦模块别看多高级，其实就是通过我们配了子模块或子系统的地址，然后在父系统打包的后自动帮我们fetch子系统的打包文件而已，这样我们就能以组件的形式使用子模块和子系统了，本期只介绍微前端的三种实现，不涉及具体代码，后面会出一期webpack5联邦模块。如果还有疑问，请看webpack5联邦模块demo

但是，但是，前提是你所有的子系统都是用webpack5进行开发，这种模式适合刚发展的互联网企业，所有系统都是新开发的。

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