目前各种分案的比较
巨石应用
以spa/mpa为技术架构， 针对产品体验的场景，一个简单的 SPA 应用、肯定是能够给到一个整体的系统体验，并且能够管控系统的技术复杂度。但如果系统越来越臃肿，就会遇到上面到的技术纬度的问题
iframe
（列子：qq网页客服）iframe对于三方，二方接入都没有问题， 但它存在一个致命的问题，就是用户体验。举个常见的问题，iframe 如果不去做一些特殊处理，嵌入的页面双滚动条问题、路由无法同步问题、包括 iframe 内部有一些弹出遮罩交互，这些问题从体验纬度上说是非常不友好的。
框架组件
框架组件的方案，通常在一些通用的头部或吊顶逻辑共用的场景下。常用的逻辑封装成一个组件，其实就是以 npm 包的形式去引入进来。
缺点： 它本质上并没有去解决前面所提到的问题，包括技术架构的升级、用户体验的优化。 再两套系统中不易维护长期维护成本高
微前端
在做架构设计的时候，我们把一个整体的系统按功能的维度去拆分。比如按它的入驻，账号管理，包括内容相关的能力，数据相关能力等进行拆分成大概有20个独立应用，这些应用统一接入到一个平台当中。这其实就完成了一个基于微前端架构升级，使平台的可维护性得到一个质的提升。
微前端的应用
path-基准路由： 声明访问什么路由地址时这个微应用将会加载
url–buddle的资源：微应用所依赖的js\css\
entry–针对anguler的强依赖html文件
核心：通过路由劫持判断跳转
框架应用会维护微应用的注册信息。用户在访问系统的时候，根据它之前注册的路由信息，它能够精确地匹配到当前需要加载的应用信息，根据相应的信息去加载应用的资源并最终渲染应用
路由规则的图解
路由劫持-跳转的原理
微模块
作为微前端能力补充能力 – 微模块。上面提到的一些技术方案、技术架构，以及解决思路，更多的是以加载一个微应用的方式，它的核心解的问题，就是把单个的 SPA 应用去接入框架应用中。那微模块又是怎么样的场景？
在模块的标准上面，微模块是以 UMD 的方式直接打包，通过这种标准模式打包，即便是以 npm 包的形式也可以正常使用。在微模块内部除了默认导出模块方法外，还需要定义挂载（mount）和卸载（unmount）的生命周期。
微模块的应用场景其实是对微应用的一个补充，它更适用于更加细粒度的功能拆分和动态搭建的场景。
参考：icestark
