微前端
微前端在这两年逐渐火热起来，在掘金甚至经常看到相关文章。看的有些烦了，所以仔细研究了一下。
微前端的概念更多是相对于TO B的项目，比如一些中台/后台。因为这些中后台相对与TO C的业务变化没那么大，通常情况下一个项目能够维护迭代五年以上（在业务持续在跑的情况下）。而TO C的业务可能五年已经重构两三个版本了。
而微前端的发展正是因为日益庞大的中后台项目以及人员流动带来的杂乱代码，和依赖混乱之间的矛盾越来越突出。不难想象，五年前的代码可能已经经过了十几个人的维护，内部逻辑混乱程度简直不敢想象。而当依赖升级的时候更是不敢轻举妄动，一不小心就是全盘崩溃的危机。
为了解决这个问题，所以引申出了微前端的概念：对巨石项目进行结偶，将其每一个功能模块拆分成一个子应用，各个子应用之间互不干扰。
微应用的简单解析
将一个大型中台项目拆分，在主应用支持基本的模块级的路由划分匹配，全局的数据管理，自应用加载&切换，样式隔离能力。（为了不同子应用的独立性，主应用不应该要求子应用采用任何依赖）
在将每个模块划分为一个子应用（也可能是好几个模块合并成一个子应用，主要看有没有历史包袱）。
由于主应用没有任何依赖，所以每个子应用理论上都是自由的，它可以使用任何技术栈，完全可以做到一个中台使用了angular/vue/react甚至更多的框架，因为子应用们互不影响。
这样每个子应用自己维护自身，最多仅有少部分对于全局状态的依赖，甚至可以自身独立出来作为一个单独的项目。
这就是微前端大概的实现原理了。
为什么不直接用iframe
仔细想一下，其实微应用的模式完全可以使用iframe来实现，但是为什么最后不采用呢？
其实网上已经有很多解释了。 – Why Not Iframe
俺觉得它说的对！
qiankun
qiankun(乾坤)是阿里团队开发的一个微前端框架，它主要提供了子应用加载&切换，全局状态管理，样式隔离等能力。
它的使用可以直接看qiankun官网, 或者直接下载它的demo跑一下qiankun。
俺觉得挺好！
我体验了一下乾坤，总体感觉还不错，符合我心目中对于微前端的期待。
但是其实还是有些问题需要解决：
-
由于子应用拆分独立，导致整个项目中出现大量子项目，而每个子项目的项目都是单独部署，单独维护自身的依赖的，所以也就导致初始化时需要初始化好几个项目，并且基本上很多都是重复的依赖，这也就导致了初始化时间过长，其实启动的时候也有这毛病。
-
打包时是否也是所有子项目一起打包？那打包时间是否也会更长。
-
随着业务发展，不同子项目之间差异越来越大，最后可能维护这些子项目的成本还要更高？（因为巨石项目再怎么说技术栈&依赖&工具模块都是共用的，而拆分之后可能每个子应用维护自身的，增加了复杂度）。
对于应用的迭代开发，是否开发的时候可以仅仅开启需要改动的自应用服务，其他服务直接使用线上打包好的代码。
对应的，打包时也可以指打包指定的子项目。
对于第三点，随着业务的深入，子应用的差异越来越大，导致维护一个项目需要熟悉好几个项目的代码。目前看来似乎是无解的，只能尽量约束（因为要保持子应用的独立性，尽量不要共享逻辑）。
总结
微前端确实解决了大型To B项目的维护难问题，但是那也只是从现在的眼光看未来，而这些很可能只是我们的想当然。
拆分子项目，并使其独立，明面上让各个子应用各自的维护成本降低了，但是反过来看，子应用的独立给整个项目的技术架构何尝不是加大了复杂度呢。
随着时间的发展，可能三五年后你就会收获一个同时使用angular/react/vue框架，以及各自多个版本写的微前端项目，而当时或许这些框架已经过时了，但是你为了维护老项目却不得不去学习相关知识，而如果简单使用一个spa项目开发，那或许迭代成本还没那么高也不一定。
这也就是为什么说“凡事不能只看它好的一面”，我看现在前端社区的风气就是往往出来一个新架构，新框架，就只看它好的一面，它能够为我们解决什么问题，但是却很少有人反过来想，它给我们带来了什么？