最容易看懂的微前端知识

微前端是一种将微服务理念应用于浏览器端的架构，它将单一的单体前端应用拆分为多个独立的小型前端应用聚合，这些应用可独立运行、开发、部署，是一套架构体系而非单纯的前端框架或工具。

• 拆分和细化：单页面应用（SPA）随功能丰富变得庞大难以维护，发版成本高。微前端将其拆分解耦，各部分可单独维护部署，提升效率。例如一个大型电商前端应用，原本所有功能代码在一个项目里，修改一个购物车功能可能影响整个页面，拆分后购物车作为一个独立微应用，修改时对其他部分影响小。
• 整合历史系统：业务中存在采用老框架的历史项目，如采用Backbone.js、Angular.js 1的B端管理系统，需结合新框架使用且不能抛弃旧逻辑。微前端可整合这些系统，基本不修改旧逻辑的同时兼容新老系统并行运行。比如企业既有老的用户管理系统，又有新的营销系统，通过微前端可整合在一起。

• Nginx配置反向代理：从接入层分离系统，但需运维配置。例如企业有多个前端应用部署在不同服务器，通过Nginx配置将不同URL请求转发到对应服务器应用。
• iframe嵌套：简单快速，但弊端明显。如在一个网页中通过iframe嵌入其他网页，可能存在样式、脚本冲突，且页面跳转等体验不好。
• Web Components方案：改造成本大。它是一套原生浏览器标准，允许开发者创建自定义的HTML标签，但要将现有应用改造成符合Web Components规范工作量较大。
• 组合式应用路由分发方案：改造成本中等，能满足大部分需求，不影响各前端应用体验，是当下普遍采用的方案。该方案核心是“主从”思想，包括基座（MainApp）应用和若干个微（MicroApp）应用。

基于组合式应用路由方案，微前端主要由基座应用和微应用组成：

• 基座应用：大多数是一个前端SPA项目，负责应用注册、路由映射、消息下发等。例如一个企业级管理后台作为基座应用，有菜单管理功能，可注册各个微应用并管理它们的路由。
• 微应用：独立前端项目，不限开发技术栈，如可采用React、Vue、Angular或者JQuery开发。每个微应用注册到基座应用中，由基座管理，脱离基座也可单独访问。

基座应用中有菜单项，点击菜单项可展示对应微应用，应用切换纯前端无感知。例如一个大型企业门户网站，左侧是导航菜单，点击不同菜单右侧展示对应的不同业务系统页面，切换流畅。

• 路由切换的分发问题

  基座应用作为SPA项目，展示微应用页面需远程拉取机制。通常用fetch API获取微应用HTML内容，解析抽离JavaScript和CSS，用eval运行JavaScript，将CSS和HTML内容append到基座应用展示区域，切换微应用时同步卸载。已有现成库如import-html-entry和system.js实现。

  以vue-router开发的基座SPA应用为例，浏览器路径变化后，vue-router监听hashchange或者popstate事件获取路由切换时机。基座router查询注册信息获取转发微应用，处理后用修改hash方法或者pushState方法推送路由信息给微应用，微应用可手动监听事件或用React-router、vue-router接管路由。

• 主微应用的隔离问题

  CSS隔离：主应用和微应用同屏渲染时，为避免样式污染，可采用CSS Module或者命名空间方式，给每个微应用模块加特定前缀，用webpack的postcss插件在打包时添加。微应用与微应用之间，加载时标记所有link和style内容，卸载时同步卸载对应link和style。

  JavaScript隔离：微应用JavaScript运行会修改全局对象Window和全局事件。加载和卸载微应用时，采用沙箱机制消除冲突。Node.js端用vm模块，浏览器端结合with关键字和window.Proxy对象实现。

• 通信问题：消息订阅（pub/sub）模式适用微应用间通信。基座应用定义事件中心Event，微应用注册事件，触发时由事件中心统一分发。若基座和微应用用React或Vue，可结合Redux和Vuex实现通信。

• Mooa：基于Angular的微前端服务框架。
• Single-Spa：最早的微前端框架，兼容多种前端技术栈。
• Qiankun：基于Single-Spa，阿里系开源微前端框架。
• Icestark：阿里飞冰微前端框架，兼容多种前端技术栈。
• Ara Framework：由服务端渲染延伸出的微前端框架。

• 适用场景：最佳使用场景是B端管理系统，能兼容集成历史系统，集成新系统且不影响原先交互体验。如企业内部的办公管理系统、客户关系管理系统等。
• 体系完善：整体微前端不仅是系统集成，还包括基座应用和微应用的自动部署能力、微应用的配置管理能力、本地开发调试能力、线上监控和统计能力等。只有体系完善才是完整的微前端流程。
• 效率判断：若使用微前端使效率变低，简单变更复杂，则不适用。例如一些小型项目，功能简单，使用微前端会增加不必要的复杂度和维护成本。