微前端个人理解与简单总结

本文介绍: 我研究、配置的第一个微前端是qiankun，根据qiankun 官方文档可以成功搭建Vue主子应用以及react子应用，但文档中配置项层级模糊且对应示例比较片面，好在网上博客、文档多。最近一段时间在学习微前端，一开始是看各种博客了解微前端含义、对比多种微前端框架优劣，最后选择了qiankun、micro–app、wujie这三种微前端框架进行深入研究、对比。可以说wujie给我最大的感觉是文档混乱、步骤不清晰、容易误导人，网上相关的博客、文档很少，翻来覆去内容都很相似，参考意义不大。Qi ankun（蚂蚁）

最近一段时间在学习微前端，一开始是看各种博客了解微前端含义、对比多种微前端框架优劣，最后选择了qiankun、m ic ro–app、wujie这三种微前端框架进行深入研究、对比。

Qi ankun：

我研究、配置的第一个微前端是qiankun，根据qi ankun官方文档可以成功搭建Vue主子应用以及react子应用，但文档中配置项层级模糊且对应示例比较片面，好在网上博客、文档多。如果注册了某个子应用，但没有启动的话会报错。

mic r o–app官方文档描述清晰，配置过程简单，是我花费时间最少的微前端。如果注册了某个子应用但没有启动的话不会报错。

Wujie:

可以说wujie给我最大的感觉是文档混乱、步骤不清晰、容易误导人，网上相关的博客、文档很少，翻来覆去内容都很相似，参考意义不大。花了半天搭建、配置Vue主子应用还是没能成功。

微前端的应用场景：

如果一个项目很大，我们更改了一部分代码，到发布的时候，就不用整个项目重新打包编译发布了，可以大大节省时间。还有一种情况：我们需要长时间下架、修改某个模块时，不用专门把这个模块代码去掉，它不会影响其它非相关功能线上正常使用。也意味着可以将故障风险的粒度隔离到更小的范围，更容易排查到问题所在；
微前端支持多种前端框架，可以让“新”应用与”旧”应用并行工作，从而提供了一种迁移手段；
多个独立的开发团队更容易协同开发单个前端应用，且职责范围更窄，更加易于理解；
通信比iframe容易（如可以共享 cookie、session），浏览器刷新不用重新加载全部资源且url 同步，但它样式隔离不够彻底，可能需要额外调整；
各个团队需要建立维护自己的服务器，构建流程和持续集成的管道，可能还加载冗余的js/css，小型项目或者功能简单的项目没有必要用微前端；
使用微前端且使用不同数据库的情况下，后端团队有独立的数据库，团队之间需要定期复制数据，一旦出现错误，容易引起数据不一致；
使用微前端意味着系统拆分，拆分的粒度越小，维护的成本越高；并且如果应用不同技术栈，技术栈种类越多，维护的难度越大。