微前端架构的几种技术选型

,随着SPA大规模的应用，紧接着就带来一个新问题：一个规模化应用需要拆分。
,一方面功能快速增加导致打包时间成比例上升，而紧急发布时要求是越短越好，这是矛盾的。另一方面当一个代码库集成了所有功能时，日常协作绝对是非常困难的。而且最近十多年，前端技术的发展是非常快的，每隔两年就是一个时代，导致同志们必须升级项目甚至于换一个框架。但如果大家想在一个规模化应用中一个版本做好这件事，基本上是不可能的。
,最早的解决方案是采用iframe的方法，根据功能主要模块拆分规模化应用，子应用之间使用跳转。但这个方案最大问题是导致页面重新加载和白屏。
,那有什么好的解决方案呢？微前端这样具有跨应用的解决方案在此背景下应运而生了！
,微前端是什么：微前端是一种类似于微服务的架构，是一种由独立交付的多个前端应用组成整体的架构风格，将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的应用，而在用户看来仍然是内聚的单个产品。有一个基座应用（主应用），来管理各个子应用的加载和卸载。
,,f135ab0912746bd6.png
,所以微前端不是指具体的库，不是指具体的框架，不是指具体的工具，而是一种理想与架构模式。
,微前端的核心三大原则就是：独立运行、独立部署、独立开发
,采用微前端架构的好处就是，将这些小型应用融合为一个完整的应用，或者将原本运行已久、没有关联的几个应用融合为一个应用可以将多个项目融合为一，又可以减少项目之间的耦合，提升项目扩展性。
,single-spa是一个很好的微前端基础框架，而qiankun框架就是基于single-spa来实现的，在single-spa的基础上做了一层封装，也解决了single-spa的一些缺陷。
,首先我们先来了解该如何使用single-spa来完成微前端的搭建。
,,single-spa.jpg
,Single-spa实现原理,首先在基座应用中注册所有App的路由，single-spa保存各子应用的路由映射关系，充当微前端控制器Controler，。URL响应时，匹配子应用路由并加载渲染子应用。上图便是对single-spa完整的描述。
,有了理论基础，接下来，我们来看看代码层面时如何使用的。
,以下以Vue工程为例基座构建single-spa,在Vue工程入口文件main.js完成基座的配置。
,基座配置,构建基座的核心是：配置子应用信息，通过registerApplication注册子应用，在基座工程挂载阶段start启动基座。
,子应用配置,配置子应用为umd打包方式,配置子应用环境变量,子应用配置的核心是用singleSpaVue生成子路由配置后，必须要抛出其生命周期函数。
,用以上方式便可轻松实现一个简单的微前端应用了。
,那么我们有single-spa这种微前端解决方案，为什么还需要qiankun呢？
,相比于single-spa，qiankun他解决了JS沙盒环境，不需要我们自己去进行处理。在single-spa的开发过程中，我们需要自己手动的去写调用子应用JS的方法（如上面的 createScript方法），而qiankun不需要，乾坤只需要你传入响应的apps的配置即可，会帮助我们去加载。
,Qiankun的优势,基座配置,子应用配置
,以 create react app 生成的 react 16 项目为例，搭配 react-router-dom 5.x。
,1.在 src 目录新增 public-path.js，解决子应用挂载时，访问静态资源冲突,2.设置 history 模式路由的 base：,3.入口文件 index.js 修改，为了避免根 id #root 与其他的 DOM 冲突，需要限制查找范围。,4.修改 webpack 配置
,安装插件 @rescripts/cli，当然也可以选择其他的插件，例如 react-app-rewired。,根目录新增 .rescriptsrc.js：,以上对Qiankun的使用可以看出，与single-spa使用过程很相似。不同的是，Qiankun的使用过程更简便了。一些内置的操作交由给Qiankun内部实现。这是一种IOC思想的实现，我们只管面向容器化开发，其他操作交给Qiankun框架管理。
,micro-app并没有沿袭single-spa的思路，而是借鉴了WebComponent的思想，通过CustomElement结合自定义的ShadowDom，将微前端封装成一个类WebComponent组件，从而实现微前端的组件化渲染。并且由于自定义ShadowDom的隔离特性，micro-app不需要像single-spa和qiankun一样要求子应用修改渲染逻辑并暴露出方法，也不需要修改webpack配置，是目前市面上接入微前端成本最低的方案。
,WebComponent的概念,**WebComponent**[2]是HTML5提供的一套自定义元素的接口，**WebComponent**[3]是一套不同的技术，允许您创建可重用的定制元素（它们的功能封装在您的代码之外）并且在您的 web 应用中使用它们。以上是MDN社区对WebComponent的解释。
,接下来用一个小例子更快来理解WebComponent的概念。,一个存在组件内交互的WebComponent,有了对WebComponent的理解，接下来，我们更明白了Micro-app的优势。
,micro-app的优势,,d879637b4bb34253.png
,      我们将所有功能都封装到一个类WebComponent组件中，从而实现在基座应用中嵌入一行代码即可渲染一个微前端应用。
,      同时micro-app还提供了js沙箱、样式隔离、元素隔离、预加载、数据通信、静态资源补全等一系列完善的功能。
,      micro-app没有任何依赖，这赋予它小巧的体积和更高的扩展性。
,      为了保证各个业务之间独立开发、独立部署的能力，micro-app做了诸多兼容，在任何技术框架中都可以正常运行。
,基座的简易配置,基座存在预加载子应用、父子应用通信、公共文件共享等等：,分配一个路由给子应用：
,子应用的简易配置：,设置子应用路由,以上便是Micro-app的用法
,Module Federation是Webpack5提出的概念，module federation用来解决多个应用之间代码共享的问题，让我们更加优雅的实现跨应用的代码共享。
,MF想做的事和微前端想解决的问题是类似的，把一个应用进行拆分成多个应用，每个应用可独立开发，独立部署，一个应用可以动态加载并运行另一个应用的代码，并实现应用之间的依赖共享。
,为了实现这样的功能， MF在设计上提出了这几个核心概念。
,Container,一个被 ModuleFederationPlugin 打包出来的模块被称为 Container。通俗点讲就是，如果我们的一个应用使用了 ModuleFederationPlugin 构建，那么它就成为一个 Container，它可以加载其他的 Container，可以被其他的 Container 所加载。
,Host&Remote,从消费者和生产者的角度看 Container，Container 又可被称作 Host 或 Remote。
,Host：消费方，它动态加载并运行其他 Container 的代码。
,Remote：提供方，它暴露属性（如组件、方法等）供 Host 使用
,可以知道，这里的 Host 和 Remote 是相对的，因为 一个 Container 既可以作为 Host，也可以作为 Remote。
,Shared,一个 Container 可以 Shared 它的依赖（如 react、react-dom）给其他 Container 使用，也就是共享依赖。
,,微信图片_20220626184254.png
,,微信图片_20220626184305.png
,以上是webpack5与之前版本的模块管理对比图
,微应用配置,通过webpack5的配置达成微应用的效果,以上便是我对微应用架构的理解，以及微应用架构技术的演变过程。不难看出，这些技术的演变都朝着易用性和可拓展性的方向演进。其中技术也有其时代的局限性，不过思想和技术总是在不断进步的。这几类技术选型都有其优缺点，各有千秋，我们可以根据不同的需要选择不同的技术来构建应用。