qinkun 系列 01 - 为什么选用乾坤

项目使用qiankun 改造的背景：

项目A、项目B、项目C；

项目A和项目B具有清晰的服务边界，从服务类型的角度能够分为两个项目。

在公司项目一体化的背景下，所有的项目又应该是一个项目。

项目B研发启动的时候

        1. 由于开发时间紧张；

        2. 项目B需要共用A项目中的“项目模块”和“人员管理”模块；

        3. 项目B中的功能模块根据项目A的路由进行激活加载；

       

基于以上的情况，采取了在项目A中增加模块进行项目B的开发，

由于B项目包含在A项目中，当A项目和B项目同时开始需求迭代的时候，两个开发人员开始代码合并的时候简直就是灾难，需要花费大量的时间小心谨慎的进行这项工作。

为了不使项目A变为巨石应用，需要将A项目进行解构。

微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用(Frontend Monolith)后，随之而来的应用不可维护的问题。

提到微前端，第一个想到的肯定是iframe，iframe嵌入网页几乎没有什么改造成本。

我们的项目为什么不使用iframe？

iframe  是在主应用中嵌入子应用系统，iframe 为子应用提供了一个完美的隔离环境，完美的样式隔离和js 隔离。

iframe 所带来的问题：

        1. iframe拥有独立的window 。独立的浏览器缓存（无法便捷的实现单点登陆。例如：主应用登陆后将token 存储在sessionStorage中，子应用无法直接拿到token。）

        2. 每次子应用的进入都是一次浏览器上下文重建，资源重新加载的过程。

        3. url 不同步，浏览器舒心，iframe url 状态丢失，后退、前进按钮无法使用。

为什么选用qiankun

1. 技术栈无关。

2. 主应用与微应用能够独立运行，独立开发。

3. 微应用与主应用之间做到了该隔离的隔离，不该隔离的共用。（浏览器缓存可共用）

当遇到像我们这种项目情况的时候：

        主应用与微应用基地相同，意味着，两个项目的缓存操作方法相同，vuex store方法相同时，应该首选采取qiankun 接入微应用的方式。

        由于qinkun 没有隔离浏览器缓存，因此，可以不用考虑子应用的登录问题，菜单栏tab 的显示问题。

简直比德芙还丝滑！！