微前端解决方案

前言

随着技术的发展，前端应用承载的内容也日益复杂，基于此而产生的各种问题也应运而生，从MPA（Multi-Page Application，多页应用）到SPA（Single-Page Application，单页应用），虽然解决了切换体验的延迟问题，但也带来了首次加载时间长，以及工程爆炸增长后带来的巨石应用（Monolithic）问题；对于MPA来说，其部署简单，各应用之间天然硬隔离，并且具备技术栈无关、独立开发、独立部署等特点。要是能够将这两方的特点结合起来，会不会给用户和开发带来更好的用户体验？至此，在借鉴了微服务理念下，微前端便应运而生。

目前社区有很多关于微前端架构的介绍，但大多停留在概念介绍的阶段。而本文会就某一个具体的类型场景，着重介绍微前端架构可以带来什么价值以及具体实践过程中需要关注的技术决策，并辅以具体代码，从而能真正意义上帮助你构建一个生产可用的微前端架构系统。

什么是微前端？

微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将单页面前端应用由单一的单体应用转变为把多个小型前端应用聚合为一的应用。各个前端应用还可以独立开发、独立部署。

微前端的价值

微前端架构具备以下几个核心价值：

• 技术栈无关 主框架不限制接入应用的技术栈，子应用具备完全自主权
• 独立开发、独立部署 子应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
• 独立运行时 每个子应用之间状态隔离，运行时状态不共享

微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用(Frontend Monolith)后，随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。

针对中后台应用的解决方案

中后台应用由于其应用生命周期长(动辄 3+ 年)等特点，最后演变成一个巨石应用的概率往往高于其他类型的 web 应用。这主要带来了技术栈落后、编译部署慢两个问题。而从技术实现角度，微前端架构解决方案大概分为以下几类场景：

• 前端容器化：iframe能有效地将另一个网页/单页面应用嵌入到当前页面中，两个页面间的CSS和JavaScript是相互隔离的。iframe相当于创建了一个全新的独立的宿主环境，类似于沙箱隔离，它意味着前端应用之间可以相互独立运行。如果我们做一个应用平台，会在系统中集成第三方系统，或多个不同部门团队下的系统，将iframe作为容器来容纳其他前端应用，显然这依然是一个非常靠谱的方案。
• 微组件：借助于Web Components技术，开发者可以创建可重用的定制元素，来构建跨框架的前端应用。通常使用 Web Components来做子应用封装，子应用更像是一个业务组件而不是应用。真正在项目上使用Web Components技术，离现在的我们还有些距离，可是结合Web Components来构建前端应用，是一种面向未来演进的架构。
• 微应用：通过软件工程的方式，在部署构建环境中，把多个独立的应用组合成一个单体应用。
• 微模块：开发一个新的构建系统，将部分业务功能构建成一个独立的chunk代码，使用时只需要远程加载即可。

微前端架构

当下微前端主要采用的是组合式应用路由方案，该方案的核心是“主从”思想，即包括一个基座（MainApp）应用和若干个微（MicroApp）应用，基座应用大多数是一个前端SPA项目，主要负责应用注册，路由映射，消息下发等，而微应用是独立前端项目，这些项目不限于采用React，Vue，Angular或者JQuery开发，每个微应用注册到基座应用中，由基座进行管理，但是如果脱离基座也是可以单独访问，基本的流程如下图所示：

 

当整个微前端框架运行之后，给用户的体验就是类似下图所示：

 

简单描述下就是基座应用中有一些菜单项，点击每个菜单项可以展示对应的微应用，这些应用的切换是纯前端无感知的，很好的借鉴了SPA无刷新的特点。