前端微服务化后的优势:
- 复杂度可控: 每一个UI业务模块由独立的前端团队开发,避免代码巨无霸,保持开发时的高速编译,保持较低的复杂度,便于维护与开发效率。
- 独立部署: 每一个模块可单独部署,颗粒度可小到单个组件的UI独立部署,不对其他模块有任何影响。
- 技术选型灵活: 也是最具吸引力的,在同一项目下可以使用如今市面上所有前端技术栈,也包括未来的前端技术栈。
- 容错: 单个模块发生错误,不影响全局。
- 扩展: 每一个服务可以独立横向扩展以满足业务伸缩性，与资源的不必要消耗；
我们何时需要前端微服务化?
- 项目技术栈过于老旧,相关技能的开发人员少,功能扩展吃力,重构成本高,维护成本高.
- 项目过于庞大,代码编译慢,开发体差,需要一种更高维度的解耦方案.
- 单一技术栈无法满足你的业务需求
微前端是什么：
- 技术栈无关，主框架不限制接入应用的技术栈，微应用具备完全控制权
- 独立开发、独立部署，微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
- 增量升级，在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略
- 独立运行时，每个微应用之间状态隔离，运行时状态不共享
single-spa到底是什么：
仅仅是一个子应用生命周期的调度者。single-spa 为应用定义了 boostrap, load, mount, unmount 四个生命周期回调：
single-spa 只做两件事： 提供生命周期概念，并负责调度子应用的生命周期 挟持 url 变化事件和函数，url 变化时匹配对应子应用，并执行生命周期流程
微前端概念
特点： 技术栈无关 独立开发、独立部署 增量升级 独立运行时
为了解决大型工程在变更、维护、扩展等方面的困难而提出的。
微前端就是将不同的功能按照不同的维度拆分成多个子应用。通过主应用来加载这些子应用。
微前端的核心在于拆, 拆完后再合!
将庞大的整体拆成可控的小块，并明确它们之间的依赖关系。关键优势在于：
- 代码库更小，更内聚、可维护性更高
- 松耦合、自治的团队可扩展性更好
- 渐进地升级、更新甚至重写部分前端功能成为了可能
微前端优点：
可以与时俱进，不断引入新技术/新框架
局部/增量升级
代码简洁、解耦、更易维护
独立部署
iframe和single spa区别：
iframe缺点：
1. 页面加载影响主页面的加载，阻塞onload时间，本身加载也慢
2. 布局问题：必须要个高度，可能出现多滚动条情况
3. 弹窗及遮罩层只能在iframe里
4. 浏览器前进和后退对iframe中内容不生效
优点：
- 完全隔离了css和js，避免了各个系统之间的样式和js污染
- 可以在子系统完全不修改的情况下嵌入进来
single spa 缺点：
1. css和js需要制定规范，进行隔离。否则容易造成全局污染，尤其是vue的全局组件，全局钩子。
2. 需要子系统配合修改。但是不影响子系统独立开发部署，路由部分对子系统有一些改动，但是不影响功能。
优点：
1. 加载快，可以将所有系统共用的模块提取出来，实现按需加载，一次加载，其他的复用。
2. 修改子系统的样式，不需要代理服务器，直接修改，因为同属于一个document。
3. 用户体验好、快，内容的改变不需要重新加载整个页面，避免了不必要的跳转和重复渲染
4. http请求少，服务器压力小。
弊端：
首先我们必须手动实现应用加载逻辑，挨个罗列子应用需要加载的资源，这在大型项目里十分困难
它只是负责把应用加载到一个页面中，至于应用能否协同工作，是很难保证的。
qiankun
基于single-spa，具备 js 沙箱、样式隔离、HTML Loader、预加载 等微前端系统所需的能力。qiankun 可以用于任意 js 框架，微应用接入像嵌入一个 iframe 系统一样简单。
主流微前端方案：
- iframe
- 基座模式，主要基于路由分发，qiankun和single-spa就是基于这种模式
- 组合式集成，即单独构建组件，按需加载，类似npm包的形式
- EMP主要基于Webpack5 Module Federation
- Web Components
iframe：是传统的微前端解决方案，基于iframe标签实现，技术难度低，隔离性和兼容性很好，但是性能和使用体验比较差，多用于集成第三方系统；
基座模式：主要基于路由分发，即由一个基座应用来监听路由，并按照路由规则来加载不同的应用，以实现应用间解耦；
组合式集成：把组件单独打包和发布，然后在构建或运行时组合；
EMP：基于Webpack5 Module Federation，一种去中心化的微前端实现方案，它不仅能很好地隔离应用，还可以轻松实现应用间的资源共享和通信；
Web Components：是官方提出的组件化方案，它通过对组件进行更高程度的封装，来实现微前端，但是目前兼容性不够好，尚未普及。
微前端需要解决的问题分为两大类：
- 应用的加载与切换
- 应用的隔离与通信
应用的加载与切换需要解决的问题包括：路由问题、应用入口、应用加载；
应用的隔离与通信需要解决的问题包括：js隔离、css样式隔离、应用间通信。
single-spa很好地解决了路由和应用入口两个问题，但并没有解决应用加载问题，而是将该问题暴露出来由使用者实现（一般可以用system.js或原生script标签来实现）；
qiankun在此基础上封装了一个应用加载方案（即import-html-entry），并给出了js隔离、css样式隔离和应用间通信三个问题的解决方案，同时提供了预加载功能。
借助single-spa提供的能力，我们只能把不同的应用加载到一个页面内，但是很难保证这些应用不会互相干扰。而qiankun为我们解决了这些后顾之忧，使得它成为一个更加完整的微前端运行时容器。
为什么要搞微前端？
随着单个独立产品越来越多，会导致当前项目越来越大
启动慢，编译慢
后期迭代时会局限在单一框架内
无法搭配后端的微服务进行单个服务的独立上线，因为前端项目是一个
为什么需要？
旧的系统不下线，新的需要还在来。
系统需要有一套支持动态插拔的机制
系统中的部件具备足够清晰的服务边界
具备以下几个核心价值：
技术栈无关
独立开发、部署
增量升级
独立运行时，运行时状态不共享
主要的微前端框架
single-spa、qiankun(蚂蚁金服)、microapp(京东 2021年7月)
github star：
single-spa 11.6k
qiankun 13.3k
micro-app 3.3k
single-spa：
1. 功能上，只做了路由劫持、提供参数填写加载微应用的逻辑，功能少。
2. 接入成本上，接入需要自己手写加载微应用的逻辑，且子应用需要额外安装依赖，接入成本高
3. 改造成本上，需要自己实现应用隔离、通讯、以及预加载等，改造成本高
qiankun：
微应用之间独立、互不影响
与技术无关接入简单、像iframe一样简单
改造成本低、对现有工程侵入低、业务线迁移成本也低
与原有开发模式一致，学习成本低
微应用拆分规则：
尽量减少彼此的通信和依赖
总结：
iframe、single-spa 在功能完善度上不足，所以放弃选择；
emp 比较适合在项目初期选型使用，用约定来规避样式隔离和js隔离（所以 emp 没有把应用隔离考虑进去），比较适合在大型项目中使用；使用它我们面临webpack的升级改造
microapp 和qiankun，功能完整度上比较好，尽管 microapp 比 qiankun 多了元素隔离功能、插件系统，且使用了类web component的思路降低子应用的接入成本。
但基于 microapp 对 Proxy目前不考虑兼容，且社区活跃度上，qiankun 更胜一筹，工期短需要有一定的保障，所以最后选了qiankun
但是！！！ 本人使用后出现如下问题：
使用qiankun
需要改动入口文件，
加public文件，
改webpack配置，
不支持webpack5的模块联邦，
组件共享困难，
全局状态管理会导致项目中redux全部修改，
无奈最终使用了模块联邦+microapp的微服务注册方式
