零、什么是前端微应用？

前端微应用可以将多个独立的Web应用整合到一起，为用户提供统一的访问入口。

一、什么是乾坤（QianKun）？

QianKun是一个前端微应用的解决方案，其特点为“任意 js 框架（不同技术栈）均可使用”、“几乎包含所有构建微前端系统时所需要的基本能力，如 样式隔离、js 沙箱、预加载等”。

二、背景

该项目是国内知名C开头车企的B端系统，两年前项目立项，前端采用了乾坤架构方案。该文章用以总结项目中使用乾坤架构所遇到的问题和经验。

三、结论

有朋友一直好奇和纠结项目中到底能否使用乾坤架构，怕踩到很多未知的坑。 这里先说结论，“用，放心大胆用，如果有必要的话”。

四、微前端所解决的痛点

1、技术栈无关

当项目足够大、需求多、业务背景或资本利益方足够复杂，则很可能有多个公司、部门和小组参与到不同的模块需求的开发中。

此时，不同小组和部门可能使用不同的技术栈和UI框架，例如Vue、React、且有着不同的开发流程和代码规范或成品套件。

从需求、技术和组织架构上看皆为不同的子项目。但产出结果又需要集成各个子系统且运行于同一系统中，此时乾坤则赋予这一统一整合的能力。

2、代码拆分

当代码量足够大，使用Webpack开发则会遇到性能瓶颈（两年前Vite和运行时编译的开发思想尚未成熟），使用乾坤将不同的业务模块拆分为不同的子项目则可以低性能占用和低消耗进行开发。

且博主以往正好参与了一个B端大型“大一统”的复杂前端系统，亲身体会了其开发时的弊端。A项目使用Webpack+Vue架构，业务组件3万余个（非依赖项），一台8代i5+8G内存+SSD硬盘的笔记本启动该项目未经优化过的开发模式需要30+分钟，改一行代码热更新需要1+分钟响应刷新。即使后期优化后启动也需要10余分钟。

此时使用乾坤框架将项目模块拆分为多个子系统交由不同小组分别开发，是解决这一痛点的方案之一。

3、分别部署

从系统层面来看，不同的子系统拥有独立的CICD流程，子系统的分别更新部署和重启以及回退能将风险降到最低。

举个例子，子系统①由于某些因素上线了带有BUG、引用了不兼容特定浏览器的依赖包或其他会造成运行错误的版本，则此时前端系统不可用率则仅限于该项目所实现的业务模块，不可用功能仅占项目的1/5。

五、选用乾坤的时机

“没有最牛的架构方案，只有最适合具体业务的架构方案”

你需要结合你的需求规模、业务背景、等各条件评估是否采用乾坤架构。简言之，代码量多的，需求量大的，资本利益结构复杂的（不同公司参与）的大型项目才有采用乾坤架构的必要。

采用乾坤的时机可分为：

1、立项时采用

如果项目立项时能有清晰的各项评估，则一开始就在工程种使用乾坤架构再好不过。

2、后期采用

当前期需求不明确，对系统规模不可知，且开发资源暂时不足时，你也可选择先用传统模式进行项目的架构。后期如果需求越来越多，代码量膨胀到开发困难时，你可择机引入乾坤框架并做架构改造。

准确的说，乾坤的侵入性很低。

六、前端项目层级图

七、主子应用数据通信

通常我们在主应用中实现登录功能，主数据在主应用中初始化和管理，然后分别向各个子应用下发数据。

1、主应用启动激活子应用时下发数据（单向下发）

主应用在激活或启动子应用时向其下发主数据，包括但不限于登录信息、权限信息和业务信息等。

2、中途相互通信（双向）

主/子应用可在运行中双向交换数据。

3、制定封装格式

立项或引入乾坤时，需指定数据通信的格式规范，主应用和各个子应用按照该规范解析和组装消息体。

4、消息分发的时序问题

建议使用同步且阻塞的方式进行数据下发和交换，确保时序的简单性和可控性。

例如，一定要在主应用初始化完成基础账号权限信息后再启动和下发数据给子应用。

八、接口请求的跨域问题

略。参考Qiankun官网文档。 qiankun.umijs.org/zh

九、微应用参考资料

微前端在美团外卖的实践 juejin.cn/post/684490…