微前端与项目实施方案研究

一、前言

微前端(micro-frontends)是近几年在前端领域出现的一个新概念，主要内容是将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的小块，而在用户看来仍然是内聚的单个产品。微前端的理念源于微服务，是将庞大的整体拆成可控的小块，并明确它们之间的依赖关系，而它的价值在于能将低耦合的代码与组件进行组合，基座+基础协议模式能接入大量应用，进行统一的管理和输出，许多公司与团队也都在不断尝试和优化相关解决技术与设计方案，为这一概念的落地和推广添砖加瓦。结合自身遇到的问题，适时引用微前端架构能起到明显的提效赋能作用。

二、背景

目前我司拥有大量的内部系统，这些系统采用相同的技术栈，在实际开发和使用过程中，逐渐暴露出如下几个问题：

1.有大量可复用的部分，虽然有组件库，但是依赖版本难统一；
2.静态资源体积过大，影响页面加载和渲染速度；
3.应用切换目前是通过链接跳转的方式实现，会有白屏和等待时长的问题，对用户体验不够友好；
针对上述几个问题，决定采用微前端架构对内部系统进行统一的管理，本文也是围绕微前端落地的技术预研方案。

三、方案调研

目前业界有多种解决方案，有各自的优缺点，具体如下：

• 路由转发：路由转发严格意义上不属于微前端，多个子模块之间共享一个导航即可 简单，易实现 体验不好，切换应用整个页面刷新；

• 嵌套 iframe：每个子应用一个 iframe 嵌套 应用之间自带沙箱隔离 重复加载脚本和样式；

• 构建时组合：独立仓储，独立开发，构建时整体打包，合并应用 方便依赖管理，抽取公共模块 无法独立部署，技术栈，依赖版本必须统一；

• 运行时组合：每个子应用独立构建，运行时由主应用负责应用管理，加载，启动，卸载，通信机制 良好的体验，真正的独立开发，独立部署 复杂，需要设计加载，通信机制，无法做到彻底隔离，需要解决依赖冲突，样式冲突问题；

  开源微前端框架也有多种，例如阿里出品的qiankun，icestark，还有针对angular提出的mooa等，都能快速接入项目，但结合公司内部系统的特点，直接采用会有有些限制，例如要实现定制界面，无刷新加载应用，且不能对现有项目的开发和部署造成影响，因此决定自研相关技术。

四、架构设计

4.1 应用层

应用层包括所有接入微服务工作台的内部系统，他们各自开发与部署，接入前后没有多大影响，只是需要针对微服务层单独输出打包一份静态资源；

4.2 微服务层

微服务层作为核心模块，拥有资源加载、路由管理、状态管理和用户认证管理几大功能，具体内容将在后面详细阐述，架构整体工作流程如下：

4.3 基础支撑层

基础支撑层作为基座，提供微服务运行的环境和容器，同时接入其他后端服务，丰富实用场景和业务功能