闲庭信步聊前端 - 见微知著微前端

笔者初次接触微前端在2020年7月，是从同事的口中听说的。虽然不算是一个早期接触者，但是也确实的推动和跟进了内部某大型项目的开发和落地。也希望能把一些走过的坑和一些思考分享给大家。文内所指应用均为PC网页应用。此文不进行移动端M页讨论。

当时网上信息也不是很多，百度搜索微前端的结果也寥寥无几，乾坤，飞冰占据了大部分篇幅，还有的就是美团的内部技术沙龙。谁想半年后微前端一词越炒越烈，各种解决方案和技术实现如雨后春笋，也逐渐形成了百家争鸣的态势。

什么是微前端

网上介绍微前端的文章不胜枚举，大多源引自 Micro Frontends这篇文章。文内详细的介绍了微前端的思想。也推广了一种微前端的实现方案（ Web Components ），随着时间的推移和笔者对微前端的实践，对微前端这一概念也有了一些自己的认知，希望可以帮助大家更好的理解微前端。

何为微前端，分而治之然同台而坐也。微者，散也。详细来说，即微前端是一种架构，是将整个巨石应用拆分成多个可独立开发、部署、上线，运行的小型应用（子应用），对外暴露一个控制台应用（父应用）来统一管理各个子应用的运行状态，多个子应用间在用户无感情况下往复切换。

微前端一词第一次出现是在工作思维（ThoughtWorks）2016年的技术雷达（ Technology Radar ）中。但是笔者认为微前端的思想在更早就已经被频繁的应用于巨石应用上了。回望前后端还未分离的时代，还在用jsp混写java和HTML时，当时一个页面就是一个html文档，以index.html文件为入口，通过锚点标签（<a/>）将页面连接起来，页面以功能为指标，分别隶属于不同的项目中，项目间互不影响，可分布独立上线。笔者认为这就是最早期的微前端。随着SPA应用的兴起，这一早期的微前端思想也慢慢的被埋没。

为什么要用微前端

现在，SPA应用已经无法满足现代网页应用的逻辑复杂度和功能的多样性了。试想一个几M的入口文件，在首开时请求无数张图片和css文件，这期间的网络耗时和浏览器渲染时间都早已远远达不到用户预期了。

虽然也出现了诸如懒加载，精灵图，文件压缩，CDN等数不胜数的解决方案，但本质还是隶属于同一个巨石应用，这也导致对应用的任何改动都要重新打包整个项目，即使开启了happypack多线程打包，其工程效率也是不敢恭维。相信有过大型项目维护经验的读者也能体会到那种心在飞而身不动的那种无力感。

另一方面，今年前端技术栈爆炸式增长，早已不是手握jQuery，走遍天下都不怕的时代了。vue已经到了3.0，react的版本更是到了17这个恐怖数字。angular国内虽然用的不多，但是也是三大框架之一，其版本也是早早到了11。即使在各个版本向下兼容的情况下，试问有几个人敢保证项目在基础框架不被时代抛弃的前提下。长期稳定运行。这些人中又有几个人经历过angular2的重写升级和react的hooks重构（虽然react不建议这样）。

所以长远来看，将一个巨石应用拆分成多个小型应用。以达到项目可稳定升级迭代还是很具有可行性的。基本原理的流程如下：

现代应用痛点：

• 项目中的组件和功能模块会越来越多，导致整个项目的打包速度变慢；

• 因为文件夹的数量会随着功能模块的增多而增多，查找代码会变得越来越慢；

• 如果只改动其中一个模块的情况，需要把整个项目重新打包上线；

• 目录层级和模块层级过深而且文件又多，定位文件会越来越慢；

• 所有的项目都只能使用同一技术框架如：react、vue等；

微前端优势：

• 技术栈无关：主框架不限制接入应用的技术栈，微应用完全具备自主权；

• 独立开发、独立部署：微应用的 git 仓库独立，微应用部署完成后父应用打开的页面同步更新；

• 增量升级：在面对各种复杂的场景时，我们通常很难对一个已存在的系统做全量的技术栈升级或者重构，而微前端可以让我们可以做到很好的渐进式重构；

• 独立运行：每个项目都可以作为一个完整的单独项目去运行，它可能只是一个大后台项目中的某个功能模块，然后所有微应用组合到一起就是 PM 想要的完整功能；

微前端技术方案

路由分发式微前端

顾名思义就是通过路由（如 nginx 配置）将不同的业务分发到不同的应用上，这也是采用较多而且做简单的“微前端”方法，但是这种方式其实更像是将多个应用聚合起来了，将不同的前端应用拼凑到一起让他们看起来像是一个整体。

iFrame

iframe 是浏览器提供的一个 html 标签，iframe 元素会创建包含另一个页面的内联框架（即行内框架）。这个标签可以有效的把完成“微前端”，但是如果使用就要考虑两件事情：

1. 应用的加载问题：父应用何时去加载和卸载微应用，在页面切换时使用怎么的效果或者动画让整个页面看起来更加自然更容易接受；

2. 应用的通讯问题：通过 HTMLIFrameElement.contentWindow 去获取 iFrame 元素的 window 对象是一种更简化的方法，但是这就需要定义一套通讯规范：事件的key采用什么形式怎么起名，从什么时候开始监听时间等等问题；

Web Components

Web Components 是一套不同的技术，允许您创建可重用的定制元素（它们的功能封装在您的代码之外）并且在您的web应用中使用它们。它主要有三项主要技术组成