最近入职新公司，在了解公司项目架构时，引发了一些思考，因为项目产品是一个Devops平台，而项目中使用了微前端的实现方式，因此将了解过程中引发的一些思考记录下来。
前端架构--从入门到微前端中提及了下面的问题：
- 1.和业务关系不大、相同部分如何抽离+维护？
- 2.业务相关的内容，相同部分如何抽离+维护？ 当业务关系不大，可以从组件库重手：
- 第一阶段：从项目中抽离了组件库和图表库（两个独立工程、项目中通过 git subtree引用）
- 第二阶段：对 charts、components 按照组件思路进行改造（merge + extend + template）
- 第三阶段：建立 Demo 站，为 charts、components 提供开发和展示环境（无特殊诉求无需查看源码）
- 第四阶段：抽离 charts、components 共同的 utils（独立仓库 git subtree 引用）
- 第五阶段：通过 yarn workspace 来处理公共依赖（关键点）
- 第六阶段：解决 charts、components、utils 多仓提交的问题（monorepo） 对于业务相关内容： 可以用微前端
微前端：在页面不刷新的情况下，同一个页面可使用不同的框架，这些不同的框架实现的前端应用可以独立部署。
微前端的演变：
- 1.iframe方案
- 2.single-spa方案
iframe方案
对于iframe方案，其实就是通过iframe标签在一个页面里嵌套了另一个页面，不过它有一定的弊端：
- 路由限制：在iframe内的页面里切换路由后，无法跟随浏览器进行前进后退
- 资源加载：每次iframe的页面都需要重新加载
- 资源共享：与外层的父组件隔离，无法实现状态共享
- dom结构不共享：iframe里的全局modal框也是显示在iframe里
single-spa
single-spa方案解决了iframe方案的弊端。 single-spa官网
