微前端
微前端实践模型
基座模式
以主应用提供基本能力，例如权限、路由管理、日志、数据通信、加载子应用等；子应用契合各个业务线
特点：
- 避免代码重复，有效的公用主应用提供的基本能力
- UI 定制化较弱，主应用奠定了整个 UI 的风格
镶嵌模式
将通用功能做成子应用，在各个业务中插入使用
特点：
- 可实现 UI 定制化，因为 UI 是各个自引用自身开发
- 可实现按需整合
- 实现较为复杂，需要考虑业务引用的菜单、路由、权限等等
微前端实践方式
路由分发
what: 由服务器分配路由，例如将 /one 分配到服务器 One，将/two 分配到服务器 Two why:
- 实施简单
- 系统天然隔绝，无需考虑多个子系统隔绝问题
- 兼容性较好，兼容各个系统，各个框架
how: 使用 Ngnix 进行配置
defect:
- 系统会出现跳转，体验没有 SPA 好
- 由于是不同的系统，需要考虑系统的通信问题
- 由于是不同的 HTML 文件，需要考虑子系统的缓存问题，避免重复加载
iframe
what: 利用 iframe 去嵌套各个子应用 why:
- iframe 天然隔离，直接解决 javascript 隔离和 css 隔离
- iframe 兼容性好
how: 将各个子应用加载到 iframe 上
defect:
- 设计管理应用机制
- 需要设计应用通信机制，PostMessage API
- UI 不共享。例如弹窗问题
- URL 不同步
- 资源会重复加载，无法命中强缓存。可以设置
[sandbox](https://developer.mozilla.org/zh-CN/docs/Web/HTML/Element/iframe#attr-sandbox)="allow-same-origin"开启，但开启后会使同源策略检查失败
微应用
what: 开发时，各个子应用分别开发，发布时一起构建 why:
- 统一技术栈
- 实施较为简单
how: 利用 CI/CD 在构建阶段将各个应用合并，构建为一个服务
defect：
- 依赖基础设施，例如 CI/CD
- 子应用依赖较强，尤其是各个子应用依赖包的版本，如果其中有冲突就遭了
微服务
what: 利用注册表注册服务，在指定路由时加载应用 why:
- 各个子应用完全隔离，无需在乎技术栈、依赖版本…
- 发布独立
- runtime 时，子应用之间隔离（沙箱）
how:
- 利用注册表挂载子应用，需指明 挂载的 DOM 节点，挂载子应用名称，子应用地址，子应用入口文件
- 在合适的路由时，通过指定的地址获取子应用，并根据指定的入口文件，挂载至指定的 DOM 节点（此处可参照 Single-SPA）
defect:
- 设计比前面的其他的方式复杂些
- 需要考虑子应用的加载机制，通信机制
- 需要考虑路由机制，防止路由同时在多个子应用之间触发
- 需要考虑沙箱机制（隔离）
微组件
what: 各个团队编写组件，将组件上传至服务器，使用时直接拉取组件组合为应用
web component
what: 以新的 HTML 标准 Web Component 来完成微服务