一、如何判定公司项目是否需要微前端？

其实如何判定公司项目是否需求使用微前端，也很简单，主要查看一点项目是不是一个巨石应用，如何去定义一个巨石应用，我们从下面几方面可以定义；

1. 部署频繁：每一次细微的修改都需要整个部署应用；
2. 部署时间长：每次部署的时间渐渐进入10min的行列；
3. 加载缓慢；
4. 开发效率随着应用变大而低下；

常见的微前端解决方案对比

1、使用 HTTP 服务器（Nginx）的路由来重定向多个微应用

2、使用 iframe 及自定义消息传递机制

3、使用纯 Web Components 构建应用

4、Module Federation 模块联邦

1. 使用 HTTP 服务器（Nginx）的路由来重定向多个微应用

其实这也可以理解把一个大型项目拆分成多个微模板应用，每个微模板应用就代表一个前端服务，然后通过 Nginx 配置代理映射到不同的子模板应用上，这也叫路由分发式微前端，是一个非常古老且传统的方法；

细心的同学会发现这种方式看上去更像是多个前端应用的聚合，即我们只是将这些不同的前端应用拼凑到一起，使他们看起来像是一个完整的整体。但是它们并不是，每次用户从 A 应用到 B 应用的时候，往往需要刷新一下页面。

优点： 简单、快速、易配置

缺点： 在切换应用时会触发浏览器刷新，影响体验

2. 使用 iframe 及自定义消息传递机制

iframe 作为一个非常古老的，人人都觉得很普通的技术，却一直都很管用。

就其性质而言，iframe 可以轻松地从独立的子页面构建页面。它们还在样式和全局变量方面提供了很好的隔离度，不会相互干扰。

优点:

1. 实现简单： 子应用之间自带沙箱，天然隔离，互不影响
2. 技术不限制： 可以各自使用完全不同的前端框架；
3. 消息传递： 只要每个 iframe 来自同一个来源，可以使用 Window.postMessageAPI 来进行消息传递；

缺点：

1. Bundle 的大小各异： 构建时也不能提取公共依赖关系；
2. 无 SEO： 众所周知 iframe 对 SEO 是毁灭性的打击，单这一条即可否定该方案了；
3. URL 状态不同步： iframe 的页面 url 中的状态信息并不能同步到父窗口，无法使用浏览器的前进后退功能；
4. DOM 结构不共享： iframe 的页面布局只针对于 iframe 窗口（例如：全局弹框无法给出合理布局）；
5. 全局上下文完全隔离，内存变量不共享： iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的微应用中实现免登效果；
6. 慢： 每次微应用进入都是一次浏览器上下文重建、资源重新加载的过程；

3. 使用纯 Web Components 构建应用

Web Components 是一个 Web 标准，所以像 Angular、React/Preact、Vue 或 Hyperapp 这样的主流 JavaScript 框架都支持它们；

你可以将 Web Components 视为使用开放 Web 技术创建的可重用的用户界面小部件，它或许会是 Web 组件化 的未来。

优点：

1. 拥有自己独立的 Scripts 和 Styles，以及对应的用于单独部署子应用组件的域名；
2. 代码的可读性变得非常清晰，组件资源内部高内聚，组件资源由自身加载控制；

缺点：

1. 浏览器和框架的支持不够： 需要更多的 polyfills 从而影响到用户页面的加载体验；
2. 重写现有的前端应用： 我们需要在整个前端应用上把它们全部转换成 Web Components；
3. 系统架构复杂： 当应用被拆分为一个又一个的组件时，组件间的通讯就成了一个特别大的麻烦
4. 社区不够活跃： Web Components 还没有真正流行起来，可能很快亦有可能永远也不会；

4. Module Federation 模块联邦

webpack5 新增的 Module Federation（模块联邦）功能，他可以帮助将多个独立的构建组成一个应用程序，不同的构建可以独立的开发与部署，利用模块联邦我们可以在一定程度上去实现微前端。

优点：

1. 开箱即用：你只需要执行几行命令即可拉取相应的模板代码并把项目跑起来，包括基座应用和微前端应用，无需处理构建工具的复杂配置；
2. 独立开发与部署：基于提供的代理工具，微应用开发者在单独开发微应用时，无需启动基座或者其它微应用；
3. 去中心化： 因为采用的是模块共享，所以不用使用中心基座的概念；
4. 组件共享： 与 npm 发包类似的组件共享管理；

缺点：

1. 无法沙箱隔离： 需借助其它工具和框架才能做到应用层面的隔离；
2. 技术单一： 仅限使用 webpack5 版本以上；
3. 代码封闭性高： 依旧需要做npm那一套管理和额外的拉取代码，还不如直接 npm 复用方便；
4. 拆分粒度需要权衡： 共享的 lib 无法做到 tree-shaking；
5. 依赖前置： 导致时间加载变长；

5. 组合式应用路由分发（中心基座方案）

当下微前端主要采用的是 组合式应用路由方案，该方案的核心是 主从 思想，即包括一个基座（MainApp）应用 和 若干个微（MicroApp）应用；

基座应用大多数是一个前端SPA项目，主要负责 应用注册，路由映射，消息下发 等，而微应用是独立前端项目，这些项目不限于采用 React，Vue，Angular 或者 JQuery 开发，每个微应用注册到基座应用中，由基座进行管理，但是如果脱离基座也是可以单独访问，基本的流程如下图所示：

优点：

1. 技术不限制： 可以各自使用完全不同的前端框架；
2. 无感切换： 因为是一个 SPA 项目，所以体验极佳；
3. 利于SEO
4. 独立开发与部署
5. 微前端优势几乎都有

缺点：

1. 沙箱不隔离： 也就是 js 与 css 样式会出现冲突的问题

6. 自由框架组合模式（复合型）

因为上述的几种方案都存在一定的优缺点，所以顾名思义咱们可以发挥方案的优势以及结合自己的项目来进行自定义的方案的组合模式，自定义一个更适合自己项目的微前端框架；

1. 就好比完美解决沙箱隔离的 qiankun.js 就是基于 中心基座方案去做的一个升级；
2. 还有比较完美的框架如：micro-app、EMP微前端等框架都是采取了以上的一种或多种方案的组合；