125、新技术之微前端
目录
一、微前端是什么？
二、微前端的实现
2.1 iframe
2.2 Web Components
2.3 ESM 即 ES Module
2.4 qiankun
2.5 EMP
2.6 总结
三、微前端和npm的区别
3.1 非常重要的痛点，使用npm包的更新流程繁琐复杂。
3.2 npm包方式构建速度慢
3.3 npm方式 应用迭代麻烦
一、微前端是什么？
（1）微服务
为了解决庞大的一整块后端服务带来的变更与扩展方面的限制，出现了微服务架构（Microservices）：
微服务是面向服务架构（SOA）的一种变体，把应用程序设计成一系列松耦合的细粒度服务，并通过轻量级的通信协议组织起来
具体地，将应用构建成一组小型服务。这些服务都能够独立部署、独立扩展，每个服务都具有稳固的模块边界，甚至允许使用不同的编程语言来编写不同服务，也可以由不同的团队来管理
（2）微前端
越来越重的前端工程也面临同样的问题，自然地想到了将微服务思想应用（照搬）到前端，于是有了「微前端（micro-frontends）」的概念：
即，一种由独立交付的多个前端应用组成整体的架构风格。具体的，将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的小块，而在用户看来仍然是内聚的单个产品。
微前端的概念由ThoughtWorks于2016年提出，此后很快被业界所接受，并在各互联网大厂中得到推广和应用。
注意：
- 微前端不是一门具体的技术，而是整合了技术、策略和方法，可能会以脚手架、辅助插件和规范约束这种生态圈形式展示出来，是一种宏观上的架构。
- 微前端并没有技术栈的约束。如果是多团队同时使用了react和vue技术栈，可能就对微前端的跨技术栈要求比较高。
（3）微服务与微前端的相似之处
- 都是希望将某个单一的单体应用，转化为多个可以独立运行、独立开发、独立部署、独立维护的服务或者应用的聚合，从而满足业务快速变化及分布式多团队并行开发的需求。
- 微服务与微前端不仅仅是技术架构的变化，还包含了组织方式、沟通方式的变化。微服务与微前端原理和软件工程，面向对象设计中的原理同样相通，都是遵循单一职责、关注分离、模块化与分而治之等基本的原则。
二、微前端的实现
2.1 iframe
众所周知，iframe是html提供的标签，能加载其他web应用的内容，并且它能兼容所有的浏览器，因此，你可以用它来加载任何你想要加载的web应用。
iframe最大的特性就是提供了浏览器原生的硬隔离方案，不论是样式隔离、js 隔离这类问题统统都能被完美解决。
但是iframe的最大问题也在于他的隔离性无法被突破，导致应用间上下文无法被共享，随之带来开发体验、产品体验的问题。
iframe没能作为官方微前端方案的原因：
- 不是单页应用，会导致浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
- 弹框类的功能无法应用到整个大应用中，只能在对应的窗口内展示。
- 可能应用间不是在相同的域内，但是主应用的 cookie 要传到根域名都不同的子应用中才能实现免登录效果。
- 每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程，占用大量资源的同时也在极大地消耗资源。
- iframe的特性导致搜索引擎无法获取到其中的内容，进而无法实现应用的seo
2.2 Web Components
Web Components由google推出的浏览器的原生组件。
作为开发者，我们都知道尽可能多的重用代码是一个好主意。这对于自定义标记结构来说通常不是那么容易 — 想想复杂的HTML（以及相关的样式和脚本），有时您不得不写代码来呈现自定义UI控件，并且如果您不小心的话，多次使用它们会使您的页面变得一团糟。
Web Components由三项主要技术组成，允许创建可重用的定制元素（它们的功能封装在您的代码之外），可以在你喜欢的任何地方重用，不必担心代码冲突。
它的三项主要技术是指：
- Custom elements（自定义元素）：一组JavaScript API，允许您定义custom elements及其行为，然后可以在您的用户界面中按照需要使用它们。
- Shadow DOM（影子DOM）：一组JavaScript API，用于将封装的“影子”DOM树附加到元素（与主文档DOM分开呈现）并控制其关联的功能。通过这种方式，您可以保持元素的功能私有，这样它们就可以被脚本化和样式化，而不用担心与文档的其他部分发生冲突。
- HTML templates（HTML模板）：
<template>和<slot>元素使您可以编写不在呈现页面中显示的标记模板。然后它们可以作为自定义元素结构的基础被多次重用。
通过以上描述，再结合微前端的概念，我们来看看Web Components是如何做到微前端：
- 技术栈无关：
Web Components是浏览器原生组件，那即是在任何框架中都可以使用。 - 独立开发：使用
Web Components开发的应用无需与其他应用间产生任何关联。 - 应用间隔离：
Shadow DOM的特性，各个引入的微应用间可以达到相互隔离的效果。
综上所述，Web Components是有能力以组件加载的方式将微应用整合在一起作为微前端的一种手段，但不幸的是，Web Components是浏览器的新特性，所以它的兼容性不是很好，如果有兼容性要求的项目还是无法使用。
补充：Shadow DOM（影子DOM）
最常见的shadow DOM就是video/audio标签。一个video标签可以描述那么复杂的界面(有暂停、进度条等)，它就属于shadow DOM。但是我们打开调试工具，查看video标签，并没有发现什么元素，因为shadow DOM默认不可见。
像 input, audio, video等这些元素是以组件的形式存在的，这些组件内部是由一些HTML标签组成的。当我们访问网页DOM结构的时候，这些子树都会暴露出来。如果DOM的类名和该子树的类名相同的话，会和子树的样式产生冲突，并且我们使用控件的时候，我们并不关心控件的内部结构，只关心控件本身，因此我们需要将控件的内部信息封装起来。因此 W3C提出了 ShadowDOM的概念，ShadowDOM可以使一些DOM节点在特定范围内可见，在网页中是不可见的。但是在页面渲染的时候也会渲染该ShadowDOM。可以保持元素的功能私有，这样它们就可以被脚本化和样式化，而不用担心与文档的其他部分发生冲突。
总结：
- shadow DOM一般情况下使用肉眼看不到的、无法直接控制操纵的DOM结构；
- 浏览器正是通过Shadow DOM，将一些内容封装起来作为一个完整的整体来实现某一个功能，，不用担心与文档的其他部分发生冲突。
2.3ESM 即 ES Module
ES Module的缩写，是ECMA script 2015中提出的一种前端模块化手段。如何做到微前端的：
- 无技术栈限制：
ESM加载的只是js内容，无论哪个框架，最终都要编译成js，因此，无论哪种框架，ESM都能加载。 - 应用单独开发： ESM只是js的一种规范，不会影响应用的开发模式。
- 多应用整合： 只要将微应用以
ESM的方式暴露出来，就能正常加载。 - 远程加载模块:
ESM能够直接请求cdn资源，这是它与生俱来的能力。
但是ESM存在着兼容性问题，大部分老版的浏览器仍然无法直接使用。这也是babel等编译工具出现的原因，它可以通过webpack、rollup、esbuild、snowpack等编译工具成为兼容性的代码。
2.4 qiankun
在微前端界，qiankun算得上是最早成型且知名度最广的框架了，它是真正意义上的单页微前端框架，qiankun的特点：
- 基于
single-spa封装，提供了更加开箱即用的 API - 技术栈无关，任意技术栈的应用均可 使用/接入，不论是 React/Vue/Angular/JQuery 还是其他等框架
- HTML Entry 接入方式，让你接入微应用像使用 iframe 一样简单
- 样式隔离，确保微应用之间样式互相不干扰
- JS 沙箱，确保微应用之间 全局变量/事件 不冲突
- 资源预加载，在浏览器空闲时间预加载未打开的微应用资源，加速微应用打开速度
- umi 插件，提供了 @umijs/plugin-qiankun 供 umi 应用一键切换成微前端架构系统
除了最后一点拓展以外，微前端想要达到的效果都已经达到。
补充：
single-spa是一个很好的微前端基础框架，qiankun框架就是基于single-spa来实现的，在single-spa的基础上做了一层封装，也解决了single-spa的一些缺陷。
single-spa是一个可以让使用多个使用javascript语言框架的构建的应用集成在一起的框架, 使用signle-spa架构可以带来一下好处：
- 在同一个页面下使用多个框架可以实现无刷新（react/vue/angluar/ember或其他）
- 单个前端应用独立部署
- 使用新框架无需重写现有的应用
- 懒加载
2.5 EMP
EMP是由欢聚时代业务中台自主研发的最年轻的单页微前端解决方案。特性为：
- 基于
Webpack5的新特性Module Federation实现，达到第三方依赖共享，减少不必要的代码引入的目的，什么是Module Federation这里就不再赘述。 - 每个微应用独立部署运行，并通过cdn的方式引入主程序中，因此只需要部署一次，便可以提供给任何基于
Module Federation的应用使用。并且此部分代码是远程引入，无需参与应用的打包。 - 动态更新微应用：
EMP是通过cdn加载微应用，因此每个微应用中的代码有变动时，无需重新打包发布新的整合应用便能加载到最新的微应用。 - 去中心化，每个微应用间都可以引入其他的微应用，无中心应用的概念。
- 跨技术栈组件式调用，提供了在主应用框架中可以调用其他框架组件的能力（目前已支持互相调用的框架及使用方式请参阅官方文档）。
- 按需加载，开发者可以选择只加载微应用中需要的部分，而不是强制只能将整个应用全部加载。
- 应用间通信，每一个应用都可以进行状态共享，就像在使用npm模块进行开发一样便捷。
- 生成对应技术栈模板，它能像
create-react-app一样，也能像create-vue-app一样，通过指令一键搭建好开发环境，减少开发者的负担。 - 远程拉取ts声明文件，
emp-cli中内置了拉取远程应用中代码声明文件的能力，让使用ts开发的开发者不再为代码报错而烦恼。
EMP除了具备微前端的能力外，还实现了跨应用状态共享、跨框架组件调用的能力，这是现有框架所不具备的优秀特性！
2.6 总结
1）现有微前端解决方案：
- iframe
- Web Components
- ESM
- qiankun
- EMP
2）各解决方案的利弊：
iframe可以直接加载其他应用，但无法做到单页导致许多功能无法正常在主应用中展示。web Components及ESM是浏览器提供给开发者的能力，能在单页中实现微前端，不过后者需要做好代码隔离，并且他们都是浏览器的新特性，都存在兼容性问题，微前端方面的探索也不成熟，只能作为面向未来的微前端手段。qiankun基本上可以称为单页版的iframe，具有沙箱隔离及资源预加载的特点，几乎无可挑剔。但可能存在以下几点不足：- 对于React 深度定制项目来说，无法做到状态管理很好的传递
- 对于非标准的AMD、UMD、SystemJS 等加载方式的库会存在依赖问题(需要针对性改造)
- 多框架实现体积过大以及存在一定的调试成本
EMP作为最年轻微前端解决方案，也是吸收了许多web优秀特性才诞生的，它在实现微前端的基础上，扩充了跨应用状态共享、跨框架组件调用、远程拉取ts声明文件、动态更新微应用等能力。同时，细心的小伙伴应该已经发现，EMP能做到第三方依赖的共享，使代码尽可能地重复利用，减少加载的内容。
三、微前端和npm的区别
很多人会问的一个问题就是：用npm方式不香吗？搞不懂为何要用微前端？
3.1 非常重要的痛点，使用npm包的更新流程繁琐复杂。
第一痛点，也是非常重要的痛点，就是使用npm包的更新流程繁琐复杂。
比如，开发三个管理后台应用项目，将相同的业务子模块抽离成npm包方式，这时候，如果要更新该业务子模块的逻辑时，那么需要做以下的流程操作：
- 更新npm包版本
- 更新A管理系统应用的npm包版本
- 发布部署A管理系统应用
- 对B和C管理系统应用循环2和3步骤
我们可以看到，该业务子模块，随着被使用的管理应用系统的增加，更新流程会叠加式得复杂起来。
而微前端可以做到一键更新。
具体理解就是，我们可以把复用的业务子模块，放在同一个基站应用之中，来管理和维护，并且暴露出去可以给多个管理系统应用使用。如果业务子模块需要更新逻辑的话，只需要发布部署基站应用，其他管理系统应用并不需要做什么操作，只需要访问时刷新，就可以立即拿到最新的业务子模块逻辑了。
3.2 npm包方式构建速度慢
假如一个大型管理应用系统，引入了n个可复用的业务子模块，在构建层面来说，相当于将n个可复用的业务子模块的代码“复制”到了项目中，构建的时候也需要同步去构建这些业务子模块，这样一来，要构建的体积就大大增加了，构建时长也因此延长，开发体验会越来越不友好，发布效率也会随之降低。
而微前端，可以提升整个应用的构建速度，可以在线使用其他管理系统应用的子模块（或者是用基站应用维护的形式），并不需要本地构建这些子模块的代码，从而减小了构建体积，提高了开发效率。
从另一个角度，比较好的微前端方案，会解决不重复引入第三方依赖包的问题。比如上图左侧，两个应用可能会引入多个第三方包：react、antd等。但好的微前端方案，可以做到右侧引入第三方包的时候，只引入一个包版本。从这个角度来说，减少重复引入第三方依赖包，也可以提升速度。
3.3 npm方式 应用迭代麻烦
npm方式。比如我们多个后台管理配置系统，使用了一些相同的资源，比如：统一的UI风格、移动端适配功能、通用状态。
这时候，如果使用了npm包方式，可能给抽离成template模板，然后执行命令或者手动去复制一个应用项目模板使用。但这种有个弊端是，如果我们对应用模板的内容更新了，需要同步到实际已经使用的项目的时候，就需要每个实际项目都去代码复制，甚至需要解决冲突之类的。这样一来，不便于我们后续的应用迭代。
而如果采用微前端共享资源方式，也就是将相同的资源全部都放在一个基站应用中，然后直接把基站应用分享出去（至少EMP微前端解决方案可以做到分享应用），管理系统项目再直接在分享出来的应用上进行迭代开发具体业务功能。这样一来，由于微前端一键更新的优势，大大简化了我们后续管理系统的迭代维护，甚至一开始创建的时候，也只需要简单的步骤。
参考：
微前端简介 - 简书https://juejin.cn/post/6911496724938752007
掘金
掘金
125、新技术之微前端相关推荐
- 乾坤 微前端_微前端架构初探以及我的前端技术盘点
前言 最近几年微前端一直是前端界的热门议题, 它类似于微服务架构, 主要面向于浏览器端,能将一个复杂而庞大的单体应用拆分为多个功能模块清晰且独立的子应用,且共同服于务同一个主应用.各个子应用可以独立运 ...
- 前端dashboard框架_微前端在网易七鱼的实践
一.前言 网易七鱼是提供围绕客户服务与智能营销的 SaaS 平台.在七鱼业务中,有在线系统.呼叫系统.机器人.工单系统.数据大屏等业务线,它们分布在两个业务端,管理端和客服端.这两个端的功能框架类似, ...
- 微前端在网易七鱼的实践
一.前言 网易七鱼是提供围绕客户服务与智能营销的 SaaS 平台.在七鱼业务中,有在线系统.呼叫系统.机器人.工单系统.数据大屏等业务线,它们分布在两个业务端,管理端和客服端.这两个端的功能框架类似, ...
- 微前端概述(Micro Frontends) 以及相比单体应用，微前端能带来什么好处
原文地址 好的前端开发很难. 扩展前端开发,让多个团队可以同时开发一个大型复杂的产品就更难了.在本文中,我们将描述将前端单体分解成许多更小.更易于管理的部分的最新趋势,以及这种架构如何提高处理前端代码 ...
- 前端怎么使用jsessionid_前端搞微前端 | 侑夕 - 如何落地微前端一体化运营工作台...
下期预告 前端早早聊大会目标成为用得上.听得懂.抄得走的技术大会,计划 2020 年办 >= 15 期,由前端早早聊与掘金联合举办,前端早早聊大会行程动态.录播视频/PPT/讲稿资料下载请关注 ...
- 微前端是什么、价值、不足、典型模式
微前端技术调研 微前端(Micro-Frontends)是什么 为了解决庞大的后端服务带来的变更与扩展方面的限制,出现了微服务架构(Microservices),越来越重的前端工程也面临同样的问题,自 ...
- 这可能是你们都在找的：React 纯原生纯hook多标签微前端
项目地址:https://github.com/X-neuron/antdFront.git 项目特点: 1.采用webpack.babel.antd 等较为原生的配置和函数组件搭建,支持pw ...
- iframe 接班人-微前端框架 qiankun 在中后台系统实践
「福利」 ✿✿ ヽ(°▽°)ノ ✿:文章最后有抽奖,转转纪念 T 恤,走过路过不要错过哦 背景 在转转的中台业务中,交易流转.业务运营和商户赋能等功能,主要集中在两个系统中(暂且命名为 inner/o ...
- 微前端在平台级管理系统中的最佳实践
微前端在平台级管理系统中的最佳实践 一.什么是微前端 二.什么是通用管理端工程 三.当管理端工程遇上微前端 四.未来展望 作者:杨朋飞 一.什么是微前端 近十年来,前端技术有了长足发展,各种概念与框架 ...
最新文章
- 国际基因编辑科技发展报告
- Javascript 限制文本字节数
- 给Anaconda安装国内镜像，加快下载速度
- 游戏人生，谈谈自己的游戏经历
- JavaScript splice() 方法使用
- 王道考研 计算机网络20 应用层 客户端/服务器C/S模型 P2P模型 DHCP协议 域名解析系统DNS 文件传送协议FTP 万维网 超文本传输协议HTTP
- Intellij Idea的使用之svn篇
- java 设置不可点击_Java Selenium webdriverwait 解决元素不可点击问题
- Linux服务器集群系统（二）——LVS集群的体系结构
- java 编译class_.java文件怎样编译成.class文件，你值得一看的技巧
- 利用flashback query解决误删除表数据
- delphixe10linux,减小Delphi XE 以上版 编译出来的程序体积
- 互联网发展的成功经验，以及面临的挑战
- 25.龙贝格求积公式
- 2023新疆大学计算机考研信息汇总
- 阴暗的底层阶级版罗密欧与朱丽叶——甲贺忍法帖
- 通过一个例子来介绍OD的简单使用
- 【解决The package java.awt is not accessible】
- github下载提速常用方法
- 小强的HTML5移动开发之路（5）——制作一个漂亮的视频播放器