攻略：“微前端”这个词现在前端同学已经耳熟能详，各种解决方案也百花齐放。比较主流的比如single-spa，乾坤，后来的webpackmodulefederation。在项目前期后端微服务的过程中，爱饭饭团队也实现了自己的微前端解决方案，更好的服务于敏捷开发，提升交付效率。全文3308字，预计阅读时间10分钟。一、背景爱饭饭团队后台采用微服务架构，实现敏捷开发部署。前端为了配合微服务架构模型，需要对原有的web端单体项目进行拆分。每个微服务对应的前端需要有独立的代码库，可以独立开发、测试、部署、上线，实现团队自治。;同时，在用户感知层面，各个前端模块是一个整体，一个统一的系统，具有相同的页面风格和交互风格。2.初步解决方案鉴于以往的项目经验，我们在运行时将多个前端应用集成为一个统一的应用时多采用iframe方案，但iframe方案存在以下问题：切换速度慢，影响用户体验.窗口不能覆盖整个应用程序窗口，用户体验差。应用程序之间的通信是复杂的。这些问题大大降低了用户体验，我们无法使用。我们希望拆分代码库后，可以保证以下体验：在用户感知方面，系统与之前的单体应用一样流畅，并保持之前的交互方式。开发者开发的时候，也可以像之前开发单页应用一样方便单页应用按路由拆分代码产生的另一种解决方案：在优化单页应用的性能时，一般会使用按路由拆分代码。用户访问单页应用时，并不加载所有内容，只加载必要的前置依赖，然后按照当前页面路由异步加载该路由对应的js和css，渲染页面异步提高访问性能。顺着这个思路，结合iframe方案中的统一入口方式，我们的思路是拆分独立应用是页面路由对应的js和css的集合，有一个统一的入口应用保存所有的菜单。当用户点击菜单时，异步加载相应应用中的页面路由代码，渲染相应的页面。3.需要解决的问题3.1路由分析主工程负责所有菜单的存储和渲染，作为页面渲染的容器，负责前端路由的分析。主工程需要通过路由分析找到对应的子工程和对应子工程的页面，获取页面资源地址，加载页面资源，渲染页面。以上功能正是一个前端路由器需要做的。我们直接使用技术栈中已有的前端路由插件，并进行修改。路由规则：例如：访问/s1/aa=>加载https://xx.cdn.com/s1/s1\_aa.js组件。当vue-router的guard函数判断组件未加载时，解析路由加载对应页面的vue组件，加载的组件直接交给vue-router，vue-router自动处理渲染过程.3.2配合路由分析规范子工程打包输出路由分析逻辑完成后，我们需要对子工程的编译输出进行处理，处理成前端资源（js和css）拆分成路由。这种拆分只需要将每个路由作为webpack编译的一个入口，每个入口对应的一个js和css会自动打包。一般的方式是使用脚本在webpack配置文件中读取项目中的路由文件，整合所有入口，在webpack配置中进行配置。我们将这个过程封装在一个命令行工具中。编译过程中统一读取项目固定的路由配置文件，解析出所有表项。在此基础上，以往单页应用根据路由拆分代码时，会提取公共文件。一般的做法是common.js整合所有业务公共文件，vender.js整合所有第三方库或框架。我们在我们的微前端子项目中也使用了这种拆分代码的优化方法。这种拆分代码的方式优化后，我们需要在加载路由对应的资源时预加载common.js和vender.js。3.3解决子项目开发时独立运行的问题因为只有主项目才是一个完整的项目，包括单页应用的入口html、前端路由、页面容器，所以可以在本地完成独立运行，但是没有页面。因为子项目只是页面资源的集合，并不是一个完整的应用，所以不能单独运行。我们分别处理主项目和子项目的本地运营。子项目：我们将主项目作为npm依赖包导入到子项目中。通过在编译入口中加入主工程入口，可以同时编译主工程和子工程中的路由入口；主项目html中的npm依赖包作为项目入口html，主项目入口js文件作为项目入口js文件，然后进入路由分析逻辑。如果是当前子项目自己的路由，cdn资源前缀为local，其他路由使用测试环境cdn。主项目：在本地开发时，以启动本地服务为入口，其他子项目的路径可以使用测试环境资源。3.4解决版本变化引起的资源地址变化问题因为我们解析路由异步加载和渲染路由资源的方式完全依赖于资源的地址，当我们的子项目发布导致版本变化时，我们需要知道路由的新地址相应的资源。我们使用一种比较简单的方式来实现版本管理——使用时间戳来控制项目版本。使用时间戳的好处是：1.版本维护简单高效，我们不需要维护更多的信息，比如每个文件的hash。2、因为统一的hash，我们可以只用一个全局文件来维护所有的项目版本，比每个项目一个单独的版本文件在运行时加载和解析性能更高。3.5应用程序之间的隔离和通信问题应用程序之间必然要进行通信。我们在使用iframe的时候，可能会用到postMessage，localstorage等，如果是同一个runtime，不同的项目可能会使用window自定义事件，或者引入单独的事件机制等。因为我们微前端方案的技术栈是统一，自然交流非常方便，可以通过挂载全局的Vue事件机制和全局的store来实现交流。应用的格式主要是window全局对象上的属性隔离，本地存储隔离，全局样式隔离。在隔离方面我们没有做任何绝对的事情。我们主要使用名称空间并专注于约定。4.形成统一的工程解决方案4.1整合所有解决方案，形成命令行工具当我们对所有问题形成解决方案后，为了避免每次访问项目时重复配置设置，我们将所有解决方案整合成一个命令-line工具tangram-sdk。tangramSDK集成了这些能力：基于微前端方案的编译打包规则基于微前端方案的本地开发服务规则自动更新全局配置文件（新模块接入不需要注册）编译打包配置可扩展的mock数据和接口联调能力初始化项目脚手架云部署能力基于tangram-sdk框架，我们形成了统一的项目管理、依赖管理、公共库、ui框架、代码规范、单元测试、构建方法。4.2与CICD集成我们的解决方案需要与CICD配合以更有效地执行各种流程。子项目需要部署在同一个目录，部署阶段需要触发配置文件的更新等。我们实现了一个基于微前端架构的项目流水线模板，流水线统一处理初始化、部署以及发布各个环境，触发事件节点等，提高了前端同学的研发效率。4.3统一的微前端方案支持多款产品在爱饭饭团队，我们的微前端方案已经支持了多款线上产品。5.性能优化5.1加载性能优化微服务的方式需要接入网关配置转发规则。我们的前端资源，除了入口html，直接访问cdn资源，不经过Gateway，减少加载流程，访问云原生部署。直接使用前端代码压缩、https等方式提升性能，CDN方式加速资源访问，通过第三方库和组件库按需加载，iconfont图标减少代码大小通过分离第三方资源而版本变化不大的业务代码，通过设置不同的缓存时长等方式来提升非首次性能。关键页面使用非首屏异步加载处理，提升首屏性能。该子项目使用预加载来提高页面性能。加载子项目时，使用preload并行加载资源，提高加载性能。5.2运行性能优化改造表格、列表等组件，使用虚拟列表提示大长页面首屏表现使用懒加载、懒接口请求等提示首屏表现的主框架在层次上，核心功能的实例化优先，非核心功能的实例化惰性，从而加快业务页面的性能；业务组件等，核心组件同步加载，非核心组件异步加载。是的，线上运行也比较稳定。现在微前端框架的选择比较多，比如single-spa,qiankun,webpackmodulefederation等。相对于single-spa或者qiankun等框架：优点1.因为只有一个vue实例和一个前端-运行时结束路由实例，子项目切换性能高。2.由于我们统一的技术栈和单实例，我们的组件可复用性更强。在运行时，我们的公共模块只需要初始化一次，比如请求和公共组件。3.基于第二个原因，不同业务之间的切换成本对于开发者来说是低的。4.由于全局版本维护文件自增规则，新模块不需要在主工程中额外注册，pipeline会自动增加版本。缺点因为我们的框架是单实例的，一个比较突出的问题就是不利于技术的更新和演进。我们计划中的改造方案将基于乾坤框架，解决单实例的技术演进问题，保持现有代码的稳定性，逐步迁移新技术。方案。----------END------------推荐阅读：云原生时代的搜索服务算力管理浅谈小程序开源业务架构构建之路百度小程序包流式下载前端工程FaaSSSR方案的安装与优化
