手把手实践qiankun微前端的开发和部署

文章开始之前，我们先提出几个问题，大家不妨带着问题来学习：

1、什么是微前端？有哪几种常见的解决方案？

2、为什么要是使用微前端，有什么样的场景使用微前端？

3、qiankun方案怎么实现微前端？

什么是微前端？有哪几种常见的解决方案？

      说说个人的理解。随着微服务开发模式的兴起，前端开发也提出了微前端的开发模式。主要是为了将复杂的大应用进行解耦，拆分成一个主应用下挂载多个子应用，有那么一点分而治之的思想。就像古代分封诸侯，皇帝如果一个人亲身亲为治理一个国家，大事小事都由皇帝处理的话，一来会把皇帝累死，二来可能精力有限而不能很好治理，于是提出了分封制，皇帝分封诸侯国，诸侯国治理自己封地的事情，定期向皇帝上报。诸侯国与中央的通讯就像子项目与主项目之间的通讯。

目前常见的解决方案有：

1. iframe方案
2. single-spa方案
3. qiankun方案

     其中，single-spa方案是早几年提出的方案，qiankun方案是基于single-spa封装的，上手简单，比single-spa更具优势。qiankun是蚂蚁金服开源的一款框架，目前已在蚂蚁内部服务了超过 200+ 线上应用，值得尝试。至于为什么不使用iframe，可以先阅读一下《Why Not Iframe》这篇文章。如果你懒得访问，这里浓缩一下重点：

1. url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
2. UI 不同步，DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时我们要求这个弹框要浏览器居中显示，还要浏览器 resize 时自动居中.
3. 全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
4. 慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。

      文中也提到如果不考虑体验问题，iframe 几乎是最完美的微前端解决方案了，其实iframe方案也不是一无是处，我们不能对它抱有偏见。iframe方案是接入成本最廉价的选择，同时也支持通过possMassage实现父子之间的通讯。它也是微前端的一种实现方式，在页面上无弹窗、无全屏等操作的时候，iframe 也是很好用的，加上配置缓存和 cdn 加速，如果是内网访问，也不会很慢。而且，对于陈年已久的Jquery多页面的老项目，qiankun似乎对多页应用没有很好的解决办法。每个页面都去修改，成本很大也很麻烦，但是使用 iframe 嵌入这些老项目就比较方便。与其折腾对接可能还会有很多配置上的问题，还不如用iframe干干净净接入，所以技术方案选择的同时，也要结合项目自身的情况。

      当然，已经2020年了，我们没有老项目了，Jquery已经不去讨论了，全部梭哈三大框架。我们都是单页面，所以，qiankun方案再适合不过了。

为什么要是使用微前端，有什么样的场景使用微前端？

如果需要开发这样的项目：

其中有多个模块，每一个模块都可以看成一个应用，每一个应用都是一个完整的项目。

如果不采用微前端，整个项目集中在一起，不但不好分离，还会导致项目越来越大，同时参与的人员也会越来越多，非常不好管理，代码也不好维护。如果有个需求：需要子应用脱离平台独立运行，如果是微前端的方式，不费吹灰之力，子应用可以直接运行。但要是整合在一起，就比较费力。

还有一种场景，开发中的平台项目，突然需要嵌入别的项目。重新开发是不可能的了，不但开发成本过高，还要维护多套代码，所以也只能采用微前端的形式了。（巨无霸的Jquery老项目建议使用iframe的形式）

所以，在以上场景的时候，使用微前端是非常合适的。

qiankun方案怎么实现微前端？

这个是我们文章的重点。我们慢慢探讨。

说在前面：

1. qiankun的使用与技术栈无关，同时子应用也是可以自由选择开发的框架，可以自己制定开发规范。
2. 本次例子主项目是以vue开发的，子项目一个是vue一个是react。
3. qiankun在开发环境下，主项目和全部子项目都会运行起来，如果子项目没有运行起来，当主项目菜单切到该子项目的时候，会打不开。所以在开发环境就会跑起多个服务。
4. 部署的时候，主项目和子项目都需要分别打包，通常在主项目创建一个文件夹，子项目都打包后，放在主项目文件夹下面。这样之后跑起一个服务，同时可以使用子项目的路径，独自运行子项目。

。。。。。未完待续