微前端

[sanlangguo]

什么是微前端

官方解释: 用于构建具有多个可以独立发布功能的团队的现代 Web应用程序的技术、策略和方法。 Micro Frontends

说白了,就是一个应用,有多个模块组合而成,且每个模块是一个独立的项目,这独立的项目可以分不同的团队自主维护,技术选型可以自选,例如react,vue 等,当然也可以不用前端框架去实现,后续可以独立发布,团队自主自治.

对比微服务

微服务是指后端服务，它们在自己的操作系统中运行，管理自己的数据库并通过网络进行彼此间的通信。

将其与所有存在于单个选项卡中的微前端进行比较：一个选项卡中的所有浏览器javascript都存在于单个操作系统进程（甚至线程！）。浏览器javascript通常不能直接访问数据库，浏览器选项卡内的通信发生在内存中，而不是通过网络进行通信。

那它们有什么共同点？？？

独立的构建和部署。将DOM视为微前端使用的共享资源。一个微前端的DOM不能够被其他微前端触及，类似于一个微服务的数据库不应该被其他没有权限的微服务触及。

参考 single-spa 微前端概念

为什么会有微前端

任何新技术的产生都是为了解决现有场景和需求下的技术痛点，微前端也是,它的存在,必有它出现的原因

• 拆分和细化：当下前端领域，单页面应用（SPA）是非常流行的项目形态之一，而随着时间的推移以及应用功能的丰富，单页应用变得不再单一而是越来越庞大也越来越难以维护，往往是改一处而动全身，由此带来的发版成本也越来越高。微前端的意义就是将这些庞大应用进行拆分，并随之解耦，每个部分可以单独进行维护和部署，提升效率。

• 整合历史系统：在不少的业务中，或多或少会存在一些历史项目，这些项目大多以采用老框架类似（Backbone.js，Angular.js 1）的B端管理系统为主，介于日常运营，这些系统需要结合到新框架中来使用还不能抛弃，对此我们也没有理由浪费时间和精力重写旧的逻辑。而微前端可以将这些系统进行整合，在基本不修改来逻辑的同时来同时兼容新老两套系统并行运行。

微前端的使用场景

这篇文章 微前端的核心价值

还有目前,我们公司特别是审核后台 TOB 项目有大部分重复的功能,且被不同团队在使用,我们可以常用的公共部分(文章,文件管理)独立出来,根据业务功能做一个子应用

实现微前端方案的对比

方案	描述	优点	缺点
Nginx路由转发	通过Nginx配置反向代理来实现不同路径映射到不同应用，例如www.abc.com/app1对应app1，www.abc.com/app2对应app2，这种方案本身并不属于前端层面的改造，更多的是运维的配置。	简单，快速，易配置	在切换应用时会触发浏览器刷新，影响体验
iframe嵌套	父应用单独是一个页面，每个子应用嵌套一个iframe，父子通信可采用postMessage或者contentWindow方式	实现简单，子应用之间自带沙箱，天然隔离，互不影响	1.url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。 2.UI 不同步，DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时我们要求这个弹框要浏览器居中显示，还要浏览器 resize 时自动居中 3. 全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。4.慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。
Web Components	每个子应用需要采用纯Web Components技术编写组件，是一套全新的开发模式	每个子应用拥有独立的script和css，也可单独部署	对于历史系统改造成本高，子应用通信较为复杂易踩坑
组合式应用路由分发	每个子应用独立构建和部署，运行时由父应用来进行路由管理，应用加载，启动，卸载，以及通信机制	纯前端改造，体验良好，可无感知切换，子应用相互隔离	需要设计和开发，由于父子应用处于同一页面运行，需要解决子应用的样式冲突，变量对象污染，通信机制等技术点

现在有哪些成熟的微前端框架?

1. single-spa：社区公认的主流方案，可以基于它做二次开发
2. qiankun：基于 single-spa 封装，增加 umi 特色，增加沙箱机制（JS、ShadowDOM 等）
3. icestark：类似于 single-spa 实现，React 技术栈友好，阿里的另一个轮子