浅聊微前端

为什么出现了微前端：

"单项目的弊端"：
1.打包项目的等待时间长
2.新的技术栈
3.不同团队项目的融合，不同的技术栈不兼容

一、为什么要使用微前端？

微服务：
微服务的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底的解耦。每一个服务提供单个业务功能的服务。一个服务做一件事情。
从技术的角度看就是一种小而独立的处理过程，类似进程的概念，能够自行单独启动和销毁，拥有自己独立数据库。
微服务注重解耦，微前端注重聚合，

• 不同团队间开发同一个应用技术栈不同怎么办？
• 希望每个团队可以独立开发，独立部署怎么办？
• 项目中还需要老的应用代码怎么办？
  微前端就是通过引入一种更优雅的方式来解决面临的问题

二、什么是微前端

微前端借鉴微服务的架构理念，将一个庞大的前端应用拆分为多个独立灵活的小型应用，每个应用都可以独立开发、独立运行、独立部署，再将这些小型应用联合为一个完整的应用。微前端既可以将多个项目融合为一，又可以减少项目之间的耦合，提升项目扩展性，相比一整块的前端仓库，微前端架构下的前端仓库倾向于更小更灵活

image.png

三、微前端的优/劣势

微前端优势

微前端特点：

• 技术栈无关 主项目框架不限制接入项目的技术栈，子应用可自由选择技术栈
• 独立开发/部署 团队之间仓库独立，单独部署，互不依赖
• 增量升级 当一个项目庞大起来，技术升级和重构都比较麻烦，而微应用具备渐进式升级的特性
• 独立运行时 微应用之间运行时，互不依赖，状态管理独立
• 提升效率 项目越庞大，越难以维护，协作效率越低下。微应用就可以很好拆分，提高效率
  资源复用
  场景：如果项目需要开发某个新功能，而另外一个项目已经开发过这个功能，如果想直接复用，对于传统的单页面应用来说，需要考虑到技术不同，版本不同以及别人的页面有些自己项目的某些操作，这些都要考虑到
  微前端可以将我们所需要的一些页面或者功能，通过特定的配置，快速集合进一个新的项目中，达到快速的可复用级应用页面及资源

微前端劣势

1.重复依赖，不同应用之间的依赖包有可能会存在很多重复的，由于各应用独立开发、编译、部署，难免会出现重复依赖，不同应用之间重复下载依赖，额外再增加了流量和服务端压力
2.技术成本变高，一个问题的跟踪，有可能需要对应的人员，懂微前端，又懂主应用和子应用，可能需要同时深入了解微前端和react和vue才能解决问题，复杂度由代码转向基建。
3.没有健全的前端周边让其充分发挥架构的优势

微前端的设计

主要采用：组合式应用路由方案
核心：“主从思想”
包括一个基座（MainApp）应用、公共应用（CommanApp）和多个单独的微应用（MicroApp）组成
基座应用：前端VUE SPA项目，主要负责渲染公共的页面元素，比如 header、footer、应用注册、路由映射、消息下发、菜单渲染、逻辑控制、数据传输等。
公共应用：单独的VUE SPA项目，包含一些公用的页面、组件以及登陆逻辑等，辅助基座应用进行运行，
微应用是独立前端项目，这些项目不限制接入的技术栈，可自由选择技术栈，每个微应用注册到基座应用中，由基座进行管理，但是如果脱离基座也是可以单独访问

四、微前端实现

1.常见微前端方案

• 基于iframe完全隔离的方案
  优点：
  1.简单无需任何改造
  2.js和css都是独立的运行环境
  3.不限制使用，可放多个iframe来组合业务
  缺点：
  1.刷新后路由状态丢失，无法保持路由状态
  2.完全的隔离导致通讯交互困难，只能采用postMessage方式 全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
  3.iframe中的弹窗无法突破其本身
  4.整个应用全量资源加载，加载太慢
• 基于single-spa路由劫持方案
  通过劫持路由的方式来做子应用之间的切换，（监听url的变化动态加载资源）但接入方式需要融合自身的路由，有一定的局限性。
  上手成本高
• 阿里qiankun
  qiankun基于single-spa做的封装，通过 import-html-entry 包解析 HTML 获取资源路径，然后对资源进行解析、加载。
  优点：
  1.基于single-spa封装，提供了更加开箱即用的API
  2.接入微应用像接入iframe一样简单
  3.样式隔离，确保微应用之间样式互不打扰
  4.js沙箱，确保微应用之间全局变量/事件不冲突
  5.资源预加载，在浏览器空闲时间预加载未打开的微应用资源，加速微应用打开速度
  缺点：
  qiankun只能解决子项目之间的样式污染，无法阻止子项目的样式污染主项目的样式

qiankun3.0筹备中。。。
3.0 里一个主要的功能是会把沙箱开放出去，可以让开发者自己根据场景制定沙箱规则。
比如上面提到的，有的场景你希望更严格的沙箱，比如劫持 localStorage 的读写，但是默认沙箱里没有做，那你可以直接通过 api 把逻辑加进去，
或者有的场景你觉得默认沙箱又太严格，希望共享一些东西，那就可以通过一些配置，把默认的行为关掉一些。

（为什么不能在vite上使用微前端）
qiankun 是目前是社区主流微前端方案。它虽然很完善、流行，但最大的问题就是不支持 Vite。
因为 esm 的机制导致现在没办法把 js 拿来做手动 evaluate，因为要支持沙箱，
如果看到社区中有qiankun+vite的方案，像这种是不支持沙箱的。
它基于 import-html-entry 解析 HTML 来获取资源，由于 qiankun 是通过 eval来执行这些 js 的内容，而 Vite 中的 script 标签类型是 type="module"，里面包含 import/export 等模块代码， 所以会报错：不允许在非 type="module" 的 script 里面使用 import。

• 京东micro-app方案
  micro-app借鉴了 WebComponent 的思想，通过 CustomElement 结合自定义的 ShadowDom，将微前端封装成一个类 webComponents 组件，从而实现微前端的组件化渲染

image.png