什么是微应用？我需不需要使用微应用？

随着产品的迭代，我们的一级菜单高达20项 ，一级菜单下的二级、三级目录更是多达半百。这种TOB产品在其实在公司核心产线很常见的。

那么如果这个时候我们还用vue单页面应用开发会面临什么问题呢？

1. 体积过大 ：打包体积可能经过一系列优化，但是由于一个项目太大了引入好多的插件，还是会存在很大的体积问题。
1. 风险过大：改一个公共业务组件需要好多个模块去验证，因为可能好多个模块使用到了该组件。
1. 打包过慢：项目体积过大，也预示着打包会很慢。
1. 代码维护：项目体积过大，预示着代码量非常大，也预示着代码维护成本会很大。（每次迭代后都进行codereview,避免代码过于乱，维护起来过于麻烦）
1. 首次加载 ：首次加载问题也是需要时刻关注的点。就是上手段后可能还是不可避免加载过多会影响用户体验。

那么我们该如何解决这个问题呢？

我们能使用iframe的方式，拆分成多个单页面项目，例如一个一级菜单就是一个项目（拆分成20或者10个项目，不包含横向的一级菜单 ），一级菜单部分作为一个单独的容器项目。如下图：

主应用（带一级菜单的容器）嵌套各个子应用（各个单页面项目） ，在一级菜单点击的时候，切换iframe子应用 的URL。并且可以在本次存储一个当前iframe URL 作为刷新浏览器的首次加载地址。

上面这么做解决了我们的代码体积过大等的问题，而且开发体验大大提升，不会说由于代码体积过大，热更新 等都反应不过来了。

这么做算是一个微应用 了吗？好像也能算，我需要一个新模块，只需要启动一个单页面应用，然后挂载在主应用上 就行了。

但是呢会存在几个问题：

问题一其实可以解决：

子应用的路由跳转可以简单封装下，如果在iframe内，所有的跳转操作都通过postMessage来通知基座应用进行跳转。
还有如果产品的要求不高可以把一级横向菜单 作为公共组件引入各个子应用中，每次菜单切换做打开新浏览器tab标签。也就不存在iframe嵌套的问题了。（缺点：打开新浏览器tab标签，产品会觉得有些割裂）

问题二、

问题三、

如果你只是纯iframe不做任何处理确实是会切换的时候加载资源，会慢，但是你就是使用qiankun没有配置预加载也是每次切换都要载资源的啊。iframe预加载无界中就有实现，等我后面分享细说。

问题四、

UI上确实会遇到些问题，比如弹窗就只是以你iframe区域作为容器。会让用户觉得像不是全局居中 样。如果你把弹出层的遮罩透明度 设置为0（遮罩层其实对产品体验要不要透明的都大差不差）, 且你的布局如我前面样图画的那样常景下，就可以利用css: 一级菜单定位在头部,且子应用iframe高度默认最小盛满整个屏幕，然后在子应用的容器使用margin-top: ***px;来往下移动实现。
其他的样式问题我觉得还是需要看你嵌套的系统在不做改造 的情况下（比如两系统都有横向菜单等等），是不是真的适合你嵌套。

总结

1、如果你们的产品形态不是很大（就几个菜单、或者业务就是个增删改查，再或者就是小h5页面），我觉得不用考虑这些微应用多页应用的考虑了，直接vue、react路由就够用了。
2、如果你们是全新系统，项目体积很大，并且没有高级技术 人员去能使用qiankun或者无界，那么我觉得iframe嵌套也是可以的，毕竟成本很低。
3、如果你们有高级前端技术人员 能胜任使用qiankun或者无界（配合webpack打包部署），那么我建议你使用qiankun或者无界。毕竟他们有预加载，有全局组件 ，全局方法挂载 等方法，可以让你共享组件、axiox、函数等等。要比你单纯使用iframe好很多

我认为可以胜任使用qiankun前端至少具备：

1. 熟悉nginx,自己部署过多页应用(多个HTML)系统。
1. 熟悉webpack打包。因为使用微应用你需要调整publicPath。因为你使用了qiankun,那么你后续肯定会有子应用的公共组件、以及函数抽离到基座的需求。