背景
随着业务线的发展，项目已经发展为一个巨石项目，代码模块耦合性越来越大，互相依赖。导致后期维护成本以及项目的版本演进成本越来越大，例如：仅仅改动一处代码，需要重新部署整个应用。同时业务需要接入第三方项目，由于第三方项目技术栈以及前端框架版本都是未知。因此需要考虑将项目进行拆分，各个模块进行独立开发和部署同时需要考虑嵌入页面的方案。
微前端简介
前端主要是借鉴后端微服务的概念。简单地说，就是将一个巨无霸的前端工程拆分成一个一个的小工程。各个小工程完全具备独立的开发、运行能力。整个系统就将由这些小工程协同合作，实现所有页面的展示与交互。
微前端组成
微前端组成
因此微前端架构应该具备以下几点：
1：技术栈无关：接触框架限制，主应用可以无限制接入不同技术栈项目，子应用具备完全自主权
2：独立：独立开发，独立部署，可独立运行。子应用间状态相互不影响。
微前端页面布局
当整个微前端运行成功后，整体布局类似下图所示
页面布局
因此主应用中有一些菜单项，点击每个菜单项展示对应的微应用。这些应用的切换是纯前端无感知的。
方案选择
当前微前端的主要有两种解决方案：iframe方案和single-spa方案。以下为两个方案的对比
方案对比
因此在项目中我们采用基于single-spa来实现的乾坤微前端框架。乾坤框架在single-spa的基础上，实现了开箱即用。除一些必要的修改外，子项目只需要做很少的改动，就能很容易的接入。
方案架构
架构
从上图可以看出。我们将整个项目分为主应用和子应用。以及公共模块。各个模块承担的职责如下：
主应用：负责注册子应用以及调度治理子应用功能
子应用：负责具体业务逻辑以及乾坤框架提供的状态管理器（bootstrap，mount unmount）
公共模块：负责应用鉴权以及用户管理模块。
因为所有的子项目都能独立运行以及部署，因此公共模块需要统一。
时序图.png
网友评论