微前端技术概览

August 17, 2024

微前端是一种前端网页开发模式，允许将单个应用程序构建自不同的独立构建模块。
它类似于微服务架构，但适用于用 JavaScript 编写的客户端单页应用（SPA）。它是针对多个前端应用程序分解和路由的解决方案。

可以想到，一个复杂的单体前端应用（当然，后端应用也是如此），代码上要基于一套代码去支持多个业务，这限制了新业务的技术栈，还会困于已有的技术债。

微前端和微服务的软件工程思路大致一致，将应用根据团队或业务模块做拆解（即单体架构→垂直架构），不过前端应用本质上是一个单独的 GUI 应用，技术上实现子应用的独立（解耦）并不容易。

此外，对于这样一个复杂的单体前端应用，其背后的后端应用也是数量庞大的微服务集群。微前端可以对应微服务，最终团队实现从UI实现到数据库设计这样端到端的跨职能人员构成。

Micro Frontends - extending the microservice idea to frontend development 一文探讨了微前端架构下如何实现不同团队开发的页面模块的组合和交互，并提出了使用 Custom Elements、DOM 事件和 Server Side Includes 等技术方案，以解决页面渲染、数据获取、跨团队通信等技术难题。

抛开前后端如何集成来自于不同开发框架的代码这个问题本身，还有很多其他值得讨论的话题：用来隔离js作用域的机制，避免css样式冲突，按需加载资源，团队之间共用资源的共享，处理获取数据的流程以及因此产生的如何通过更好的加载状态管理来为用户带来更好的体验。

微前端（MFE）可以通过以下方法实现：

使用模块联邦（module federation）或原生联邦（native federation）（例如 Web Components 和 iframe）
使用微前端框架：Single-SPA, Piral , qiankun, icestark, Alfa, FrintJS, Ara Framework, PuzzleJs, MicroApp, OpenComponents, Luigi, wujie, EMP, Garfish, bit

注：Module Federation 已发布 2.0

注册中心/主应用：整体布局，子应用的注册和加载（生命周期管理）

隔离 JavaScript：隔离全局环境/副作用（例如通过 Proxy/new Function），例如劫持 DOM，全局事件，样式，localStorage 等，不妥善处理将导致内存泄露

隔离样式：传统 CSS modules，Shadow DOM 引入的 CSS Scoping 等

虽然微前端得到了独立部署的好处（例如通过模块联邦，子应用只需将自身打包成模块，无需考虑其它应用），但相比于微服务，微前端所有应用共享一个浏览器页面的资源。虽然某些微前端框架/库为我们做了隔离处理，本质上来说所有应用还是在共享资源。
与微服务不同，我们必须面对这些问题，导致微前端应用不太能像普通单体应用一样自由。

此外，微前端可能没有解决代码膨胀的问题（相比于 MPA），因为应用间仍有可能需要数据传输和依赖共享，而运行在浏览器中的微前端根本就不如微服务一般自由（例如通信和隔离）。
因此，必须权衡其利弊：例如，需要微前端提供的哪些必要能力？使用后收益真的高于多页应用吗？

iframe有利点：

真正的环境/DOM隔离，确保页面组件间完全独立

iframe不利点：

无法跨 iframe 传递 DOM 事件，需要使用其它方式做事件处理（见下文 iframe 通信方法）
独立环境需占用更多性能资源，且路由控制可能存在延迟

iframe 通信方法 直接调用：

window.frames 或 HTMLIFrameElement.contentWindow/contentDocument

事件通信：

跨源通信 postMessage 和 Window: message event

利用 localStorage 或 sessionStorage 对应的 Window: storage event

创建和触发自定义事件