如何认识微前端（你知道微前端吗）
如何认识微前端（你知道微前端吗）还有比较常见的解决方案如iframe嵌入式页面等，这种应用的缺点是全局化的时间和样式问题，如全局弹窗在嵌入页面中无法使用等问题。中后台应用由于其应用生命周期长的特点，最后演变成一个巨石应用的概率往往高于其他类型的 web 应用。而从技术实现角度，微前端架构解决方案大概分为两类场景：2.独立开发、独立部署 子应用仓库独立，前后端应用独立开发，部署完成后主框架自动完成同步更新；3.独立运行时 每个子应用之间状态隔离，运行时状态不共享；微前端架构方案主要解决前端应用在开发部署过程中，随着时间的拉长，前端参与团队成员的增加和变动，导致前端应用从普通应用演变成一个巨石应用，随之而来的是前端应用的开发维护成本剧烈增加和逐渐的不可维护性。其次，前端技术栈的变动，导致在新的项目中想使用老的业务逻辑，唯一的方案是重写业务逻辑，这再次增加前端的开发成本，同时也增加了前端开发人员的学习成本，开发难度增加等问题。
阅读原文：【技术分享】你知道微前端吗？
点击关注“八戒技术团队”，阅读更多技术干货
微前端具备哪些价值
1.前端技术栈无关主框架不限制接入应用的技术栈，子应用具备完全自主权；
2.独立开发、独立部署 子应用仓库独立，前后端应用独立开发，部署完成后主框架自动完成同步更新；
3.独立运行时 每个子应用之间状态隔离，运行时状态不共享；
微前端架构方案主要解决前端应用在开发部署过程中，随着时间的拉长，前端参与团队成员的增加和变动，导致前端应用从普通应用演变成一个巨石应用，随之而来的是前端应用的开发维护成本剧烈增加和逐渐的不可维护性。其次，前端技术栈的变动，导致在新的项目中想使用老的业务逻辑，唯一的方案是重写业务逻辑，这再次增加前端的开发成本，同时也增加了前端开发人员的学习成本，开发难度增加等问题。
中后台应用解决方案中后台应用由于其应用生命周期长的特点，最后演变成一个巨石应用的概率往往高于其他类型的 web 应用。而从技术实现角度，微前端架构解决方案大概分为两类场景：
- 单实例：即同一时刻，只有一个子应用被展示，子应用具备一个完整的应用生命周期。通常基于 url 的变化来做子应用的切换。
- 多实例：同一时刻可展示多个子应用。通常使用 Web Components 方案来做子应用封装，子应用更像是一个业务组件而不是应用。
还有比较常见的解决方案如iframe嵌入式页面等，这种应用的缺点是全局化的时间和样式问题，如全局弹窗在嵌入页面中无法使用等问题。
微前端常见框架
目前微前端实现方案中比较主流的有以下框架：
Web Components
Web Components 是一套不同的技术，允许您创建可重用的定制元素（它们的功能封装在您的代码之外）并且在您的web应用中使用它们。
简单来说，就是就是自定义html元素标签，在项目中引入自定义的元素标签即可实现封装好的功能。同时，Web Component 允许内部代码隐藏起来，这叫做 Shadow DOM，即这部分 DOM 默认与外部 DOM 隔离，内部任何代码都无法影响外部。
iframeiframe是HTML标签，作用是文档中的文档，或者浮动的框架(FRAME)。iframe元素会创建包含另外一个文档的内联框架（即行内框架）。
iframe作为一种古老的页面嵌入方案，可以简单且快速的解决多项目中页面嵌入问题，提供了浏览器原生的隔离方案，无论是样式还是js隔离这些问题都能被完美解决。这是它的优点，也是最大的缺点，这导致应用内上下文不能共享，嵌入的页面与宿主页面之间无法通讯，导致应用的体验问题。同时还有页面url变化导致嵌入页面的状态丢失，全局DOM不共享，导致弹窗位置无法自动居中处理等问题。
Single-spaSingle-spa 是一个将多个单页面应用聚合为一个整体应用的 JavaScript 微前端框架。在single-spa中，微前端是浏览器内的javascript模块。
Singe-spa的工作方式：
Singe-spa可以实现通过对路由的匹配，在不同路由时渲染不同的web应用，同时利用沙箱机制实现样式的重用。
qiankun
qiankun 是一个基于 single-spa 的微前端实现库，旨在帮助大家能更简单、无痛的构建一个生产可用微前端架构系统。
特点：
- 基于single-spa封装，简化接入流程，做到了开箱即用。
- 技术栈无关
- HTML Entry接入方式
- 样式隔离
- js沙箱
- 资源预加载
qiankun在single-spa的基础上，增加了js沙箱和样式隔离，同时简化了single-spa的配置流程，做到了简单，易用的特性。
ModulFederation（模块联邦）ModulFederation是webpack5推出的一项新功能，官方定义如下：多个独立的构建可以形成一个应用程序。这些独立的构建不会相互依赖，因此可以单独开发和部署它们。这通常被称为微前端，但并不仅限于此。通俗来说，ModulFederation提供了能在当前应用中远程加载其他服务器上应用的能力。对此，可以引出下面两个概念：
- host：引用了其他应用的应用
- remote：被其他应用所使用的应用
鉴于ModulFederation的能力，我们可以完全实现一个去中心化的应用部署群：每个应用单独部署在各自的服务器，每个应用都可以引用其他应用，也能被其他应用所引用，即每个应用可以充当host的角色，亦可以作为remote出现，无中心应用的概念。
通过ModulFederation可以将多个应用都用到的通用组件单独部署，在runtime时将模块引入到其他项目中，这样组件代码就不会编译到项目中，同时亦能满足多个项目同时使用的需求。
猪八戒前端项目改造实践
主应用使用utopia nuxt-ssr，子应用使用纯vue项目
1. 在nuxt.config.js中映入微前端组件
2. Micros.js代码如下
import { registerMicroApps start } from 'qiankun'
const apps = [
{
name: 'vueApp'
entry: '//dyf.test.zbjdev.com:10000'
container: '#vue'
activeRule: '/vue'
props: { asd: 123 }
}
// {
// name: 'reactApp'
// entry: '//localhost:20000'
// container: '#react'
// activeRule: '/react'
// }
]
registerMicroApps(apps)
start()
3. 生成子应用
对子应用入口main.js改造
import Vue from 'vue'
import App from './App.vue'
import router from './router'
Vue.config.productionTip = false
// new Vue({
// router
// render: h => h(App)
// }).$mount('#app')
let instance = null
function render() {
instance = new Vue({
router
render: h => h(App)
}).$mount('#app')
}
if (window.__POWERED_BY_QIANKUN__) {
__webpack_public_path__ = window.__INJECTED_PUBLIC_PATH_BY_QIANKUN__;
}
if (!window.__POWERED_BY_QIANKUN__) {
render()
}
export async function bootstrap() { }
export async function mount(props) {
console.log(props);
render(props)
}
export async function unmount() {
instance.$destroy()
}
4. 最后在nuxt的layout文件下的default.vue添加挂载标签
<div id="vue"></div>即可
5. 运行结果
同时启动主应用和子应用，通过访问/vue路由即可看见加载了子应用的项目。
总结
微前端的本质在于资源的隔离与共享，这里的颗粒度既可以是应用，也可以是模块，或者是自己定义的抽象层，这些都是为了更好的“高内聚，低耦合”。微前端可以降低项目的复杂程度和降低耗费在部署和发布项目上的时间成本，但并不能解决所有的业务问题。使用微前端框架在目前的猪八戒前端项目完全可以取代seajs的项目加载方式，如果想在更多的业务分层中使用，实现微前端项目的特性，独立运行、独立部署，还需要对前端项目进一步改造。
希望以上内容能对有需要的人有所帮助
欢迎大家留言写下自己希望了解的技术方向
欢迎大家一起探讨交流
