解决：
- webpack externals 简单解决包大的问题，但是无法解决共存版本
- DLL 打包进模块，存在冗余模块
- Federation可以解决这个问题
- 按照业务领域划分页面
平滑上线，通过版本机制进行控制，将html进行hash化的管理。同时要保证发布次序，主应用最后发布。
问题：
- 开发体验差，通信成本高
- 样式控制成本高
- 用户体验差，加载效率等问题
- 项目状态公用的问题，例如登录状态、cookie等
框架应用：负责 layout 以及微应用配置与注册渲染 微应用：按业务维度进行拆分，一般是SPA应用
微应用通过bundleURL的形式进行引入，可以减少包的构建大小，和更好的进行版本管理。 通过路由劫持，控制资源的访问和加载
应用间通信，通过window全局变量作为桥梁
icestark 没有在源码中做隔离，主要还是靠上层微应用使用css modules等进行自我隔离，待优化。 shadow Dom 优化css隔离，但也存在问题，例如弹窗的容器节点问题，事件机制无法很好传递
js 沙箱隔离，主要通过proxy 和 new Function 的形式进行隔离，主要是为了保留window快照，能竟可能恢复页面离开后，保证window不被污染
第三方隔离，iframe，安全可靠
多模块共存，模块组合搭建，动态渲染模块，不要依赖路由，尽可能的低耦合度 在umd模块标准下进行打包，引入到项目中 widget
蚂蚁团队维护的微前端的技术方案
future state 问题，路由劫持解决 -- single-spa方案 应用加载：通过html entry 作为子应用入口，可以更好的解耦，并行加载
1.0 版本 snapshot 记录快照，在卸载时恢复，缺点：无法支持多个实例，无法同时挂在两个沙箱。 2.0 版本 proxy 代理沙箱内部操作，将副作用局限在子应用内部，
子应用之间的隔离：动态样式表 dynamic stylesheet，当子应用切换时，激活新的样式表 父子应用的隔离：
- 通过工程化手段解决。BEM/CSS module/css in js
- Shadow DOM，可以严格隔离父子所有的样式。但是也有一些问题，比如一些事件会逃离边境，antd的modal也会出现挂载时逃离边界。这些问题需要在对应子项目各自中解决
- runtime css transformer(RFC) 未来可能的方案，运行时转换css的位置
- 基于URL通信: 例如b子应用调用 log('data')，会在url中xxx/func-log-'data'
- CustomEvent: 发布/订阅模型 使用浏览器自带的customEvent作为主事件进行通信
- 基于props：主应用传递props到子应用中，子应用通过调用进行通信。是常见的各种框架通信机制