我报名参加金石计划1期挑战——瓜分10万奖池，这是我的第一篇文章，点击查看活动详情

背景

上一篇讲到通过iframe实现了一个简单的微前端架构，带来了一定的好处，也带来了一定的问题。

iframe的利与弊

利

• 使用简单，无需安装依赖，随时使用
• 与技术栈无关、独立开发、独立部署、增量升级、独立运行
• 用成本最低的方式，实现了css、js隔离

弊

• 加载慢，每次打开都是一次资源重载、页面重建
• 相当于两个浏览器窗口，易造成焦点失控
• 不利于搜索引擎优化
• 频繁打开多次，不可避免的造成内存堆积

为什么要用vue3？

程序员最大的特点就是对新技术的追求，在这样的小型初创公司，最大的问题是，技术局限性高，刚来的时候，整个公司都是用vue2+element进行开发，追加一个新项目，便是简单的ctrl+c，ctrl+v，原本就混乱不堪的项目不断累加，架构混乱，代码甚是辣眼睛。

基于此，希望带领前端团队不断进步，学习不同的技术栈，扩展技术面。

因此在有机会构建一个全新的组件页面的第一时间，便想着趟一下vue3+vite+ts的水。

但是开发的时候享受了新鲜知识的快乐，上线的时候不可避免的面临vue2升级vue3的痛苦，vue3开发的组件，在vue2项目中是无法直接使用的！！

因此便有了这样的一个探索。

微前端框架

iframe是最简单，最基础的微前端框架，那么还有哪些微前端框架呢？

微前端的定义

微前端将前端整体分解为许多更小、更易管理的片段。每个团队可以端到端地拥有自己的功能，可以在自己的代码库中工作，可以独立发布版本，可以不断进行小的增量升级，还可以通过 API 与其他团队集成，以便他们可以一起组建和管理页面和应用程序。

常见微前端类型

这里会梳理常见的微前端架构，资料整理自网路，加上了浅显的个人理解，后续会具体的针对每一种架构进行细化调研。

各位看官欢迎对我的看法批评指正，轻踩即可～

一、构建期的微前端架构

Bit

使用 Bit，在与其他团队合作同时，不同的团队可以独立构建、发布和公开其组件，这样就可以将 Web 开发过程转变为功能和组件的模块化组合。

我的理解是，当你需要简单的解耦代码库、自治团队、小型定义良好的 API、独立的发布管道 和 持续增量升级，是可以选择这样的架构方案的。

Bit呈现的结果是，最终多个项目打包构建成一个整体来部署。

二、运行时集成

Webpack 5 和 Module Federation

Module Federation 允许 JavaScript 应用程序在运行时从另一个应用程序动态导入代码。模块将构建唯一的 JavaScript 入口文件，其他应用程序可以通过设置 Webpack 配置项来下载该入口文件。

个人理解，这其实应该就是现在的import按需引入。

Single SPA

众所周知的qiankun的基础依赖库，它将生命周期应用于每个应用程序。每个应用程序都可以响应 url 路由事件，并且知道如何从 DOM 引导，加载和卸载自身。传统 SPA 和 Single SPA 应用程序之间的主要区别在于它们能够与其他应用程序共存，并且它们各自没有自己的 HTML 页面。

由于之前尝试用qiankun并没有成功，可能后续也会把这个作为一个重点调研方向。

Qiankun

Qiankun 声称自己是“一个 微前端 实现，基于 single-spa，但已使 single-spa 可用于生产（production-ready）”。该项目旨在解决由较小的子应用程序组成较大的应用程序时所面临的一些主要问题，例如发布静态资源、集成单个子应用程序、确保子应用程序在开发和部署过程中彼此独立且运行时相互隔离、处理公共依赖性和处理性能问题等。

FrintJS

FrintJS 是“用于构建可伸缩和响应式应用程序的模块化 JavaScript 框架”。你可以使用它加载来自不同 bundlers 的应用程序，为应用程序提供结构，并处理诸如路由、依赖关系等问题。该项目可通过附加的软件包支持 RN 和 Vue，但文档和测试大多数是针对 React 的。

小结

以上部分内容来自itnext.io/11-micro-fr…

后续会继续先尝试使用qiankun进行接入，并记录下遇到的所有问题，如果最终无法解决使用，会考虑使用Single SPA这种解决方案～