微前端（1）
本篇是微前端的学习记录。
概念
- 微前端就是将一个大型前端应用拆分成多个模块（eg: 将项目根据业务模块拆分），每个模块可以由不同的团队进行管理，并可以自主选择框架、有自己的仓库，可以独立部署上线。
- 主应用（基座）：主要负责集成所有的子应用，提供一个入口能访问你所需要的子应用。
（1）一个系统只有一个
（2）系统整体 Layout 的设计
（3）所有微应用的配置与注册、路由映射、消息下发
（4）尽量不写复杂业务逻辑
微应用：根据不同业务划分的模块，每个子应用都打包成umd模块的形式供主应用来加载。
（1）通常是一个单页面应用（SPA），负责具体的业务逻辑
（2）可以独立交付（开发、部署、运行），但是一般会集成到主应用中运行
（3）如有必要，甚至能集成到不同的主应用中
适用业务场景
- 需要将多个后台系统统一收口的一个系统内。
- 庞大的单页面应用，开发/构建时间长。
微前端可以实现各个微应用的独立开发和发版，主应用管理微应用的注册和渲染，将整个系统彻底解耦。
思考：公司的业务场景偏向于1，UMS作为所有系统、用户、权限的管理，子系统的统一入口，适合作为主应用。各个子系统分管不同的业务（订单管理、出入库管理、售后管理、质量管理、产品追溯管理等），有各自的代码仓库和不同的开发特性，迭代周期也不同，适合作为微应用。
各个子系统与不同后端进行交互，可能会共享数据。
各实现方式对比
| 方案 | 具体实现 | 优点 | 不足 |
|---|---|---|---|
| Nginx路由转发（服务端集成） | 通过nginx代理来区分，同一个端口不同路由指向不同的前端项目，通讯可使用 sharedWorker。 | 简单 | 跨服务的组件无法嵌套，简单通讯可以使用会话存储，但需要比较复杂的封装，使用也不方便，有一层逻辑处理。适合业务分割清晰、跨服务组件之间关联少的项目，并且路由规划要严格。 |
| iframe嵌套（运行时集成） | 父应用单独是一个页面，每个子应用嵌套一个iframe，父子通信可采用postMessage或者contentWindow方式 | 子应用之间自带沙箱，天然隔离，互不影响 | iframe样式显示（弹窗只在局部）、兼容性问题、刷新页面无法保存状态 |
| Web Components | 子应用使用纯Web Components编写 | 子应用拥有独立的script和css，也可以单独部署 | 改造成本高；子应用通信复杂 |
| 组合式应用路由分发 | 子应用独立构建和部署，运行时由父应用进行路由管理、应用加载、启动、卸载、通信 | 无感知切换体验良好，子应用相互隔离 | 父子应用处于同一页面，变量污染、通信问题 |
主要实现方式
路由分发
JavaScript的模块化来实现导入导出，可以使用importmap（eg: SystemJS），使变量名和其相应的地址一一映射，允许在非导入上下文中重用这个映射，避免重复书写地址。
隔离
css隔离： css Module或者namespace，可以采用webpack的postcss插件，在打包时添加特定的前缀；
js隔离：采用沙箱机制（局部的js运行不影响外部对象），对于浏览器需要结合with关键字和window.Proxy对象来实现。
通信
子应用之间不直接通信，采用消息订阅（pub/sub）模式，在基座应用中定义事件中心Event，子应用注册事件，当事件被触发时，事件中心统一分发。
生命周期
- registerApplication：注册微应用
- bootstrap：第一次挂载应用执行，只会被执行一次
- mount：创建DOM节点，监听DOM事件，激活路由
- unmount：卸载事件
- unloaded
其中bootstrap、mount、unmount必须由我们导出，否则会报错
Q & A
- 主应用怎么加载微应用？
- 主从通信？子应用之间通信？
- 部署问题？
附录
京东
Single-Spa最早的微前端框架
微前端-最容易看懂的微前端知识
微前端究竟是什么？微前端核心技术揭秘！
微前端框架qiankun、ice比较
真的有必要用微前端框架么
本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议 ，转载请注明出处！