滴普大前端|DevOps（A10）基于qiankun的微前端实践「微前端」可以算是 2019年前端技术领域中最热门的话题

前言

「微前端」可以算是 2019年前端技术领域中最热门的话题。各个大厂也纷纷贡献出了自己的解决方案和实践分享。滴普科技作为一家致力于为企业提供数字化转型服务的技术公司，前端也需要灵活聚合，快速复用，才能显示出中台在实际业务中的复用能力，为企业数字化转型大大提速。

既然谈到实践微前端架构，那么要很好落实这个方案，接下来给大家分享一下DevOps基于qiankun的微前端实践。

本文仅基于实践重点部分介绍，也欢迎广大读者来信讨论，对于流行技术我们是认真的。

👇微前端架构开源项目

github.com/FEMessage/n…

1. 为什么需要微前端❓

滴普科技既然致力于企业数字化转型，自然需要沉淀出一系列业务中台，以实现敏捷开发和快速交付的行业竞争力。然而，中台服务下沉了，可以快速复用，前端却需要不断重复编写类似的业务逻辑和界面。导致人力瓶颈经常落到前端开发，因此迫切需要一个解决方案，类似微服务，可以让开发分离，运营聚合。

DEEPEXI DevOps (A10) 前端痛点

定位于企业级研发效能平台的A系列产品DEEPEXI DevOps(A10)后文简称(DevOps)，从早期构建发布工具升级变成一个集开发、测试、构建发布、应用网关、应用引擎于一体的研发效能平台。随着其功能迭代，代码增加带来的成本问题越来越大，如：

开发体验变差：单次构建的时间长达2-3分钟，启动开发环境耗时1分半；
代码维护成本增加：升级依赖修复某一个模块的bug导致另一个模块出现问题；跨模块引用模块私有组件，当该组件修改后，引用该组件的地方出现bug；
项目复杂度增加：熵增增加了项目复杂度，多个子系统业务代码在一个仓库维护，导致沟通协调的成本增加

2. 技术选型

对市面上已有的微前端方案做了简单对比后，我们选择了基于qiankun(非常感谢作者的开源)。qiankun采用运行时集成主、子应用，HTML entry作为子应用入口的中心路由基座式微前端方案。

qiankun：基于single-spa实现，主、子应用都可以做到技术栈无关，方便接入子应用；完备的应用生命周期管理，子应用只需要暴露生命周期钩子即可实现应用接入。

运行时集成：运行时的最大优点是主子应用间解耦，技术栈无关；发布时不需要整个系统重新构建发布。它的不足之处在于存在资源重复加载的情况，但是可以通过https等缓存的方式解决部分框架层资源共享的问题。
样式污染：一是采用HTML entry方式。应用卸载后，会同时卸载其样式表，做到样式的隔离。因为浏览器会对所有样式表的插入、移除做整个CSS、DOM的重构，从而达到插入、卸载样式的目的。二是约定开发规范，如子应用不能侵入(如动态增加全局样式等)修改除本应用外的样式；子应用样式写在以子应用名作为命名空间的类里等。
js污染：qiankun 有提供js沙箱机制，解决js全局变量的污染，实现子应用间的软隔离。

（注：图片来自qiankun）

在应用的 bootstrap 及 mount 两个生命钩子调用之前分别给全局状态打下快照，然后当应用切出/卸载时，将状态回滚至 bootstrap 开始之前的阶段，确保应用对全局状态的污染全部清零。而当应用二次进入时再恢复至 mount 前的状态的，从而确保应用在 remount 时拥有跟第一次 mount 时一致的全局上下文。

应用间通信：我们使用了@ice/stark-data，自定义发布-订阅通信的实现，处理全局消息通信和数据管理，解决如用户登录后，主子应用间共享用户信息的问题。
DevOps应用整体架构：主应用负责权限、路由等管理，布局交由布局组件。子应用在开发阶段可以通过npm包引入布局组件的方式，达到仿真在与子应用联调的效果。
应用整体架构图：如下图所示。

3. 工程与业务价值💰

基于该方案，对工程和业务带来的价值有：

解决DevOps在作为一个大型单体应用条件下开发维护成本高的问题；
新模块开发能享受独立开发、部署，灵活上线的便利；
子应用开发技术栈无关，团队能快速试验新技术；
应用自治，功能内聚，降低系统复杂度；
更灵活的系统组合，基于现有子应用自由组合出新的系统；
大幅度降低构建时间，提升开发体验。

4. 拆分与实践🛠

理想中的微前端模式是一个后端微服务对应一个前端微应用。但是由于前端应用多数时候会依赖多个后端服务，因此不能简单对应后端微服务划分。我们按照业务模块划分，以下是划分的一些模块：

拆分之后，如何平滑的迁移旧系统呢？迁移期间如何保证业务的并行开发呢？

我们前端技术栈是基于vue技术栈的Nuxt.js体系，但在社区中并没有找到合适的Nuxt.js接入qiankun或者single-spa的方案。因此我们做了两个备案。

一、基于vue-cli做改造，低成本的迁移旧系统，同时拥抱更大的生态；
二、基于Nuxt.js做改造，让其支持接入qiankun，这样可以方便系统的平滑迁移。

最终经过一个星期的调研、demo确认后，有了基于nuxtjs接入qiankun的方案nuxt-micro-frontend。该方案最小限度的减少了对原有代码的侵入，通过Nuxt.js框架插件化机制，使Nuxt.js支持接入qiankun，同时回馈了Nuxt.js社区。

该方案解决了Nuxt.js未能暴露接入微前端所需生命钩子的问题，同时内置了子应用跨域访问的解决方案，新增mounted和beforeUnmount两个生命周期钩子，能够更灵活的处理不同场景的问题。

迁移期间，我们优先迁移边缘、且相对独立的模块，核心模块放后，降低迁移风险；因为是基于原nuxt.js框架做微前端迁移，迁移后除了处理样式和应用间通信问题，基本不会动到业务逻辑，减轻了测试人员回归测试的压力。

5. 基于实践的一些总结

合适、简单、演变的理解：架构在满足业务或者技术要求前提下，应该尽可能的保持简单、并保持扩展性。成员开始考虑基于single-spa做定制化，但目前还没有定制化的需求。因此采用已经有的社区实现是一种最经济的方式。如果后面要定制化了，完全可以抛弃qiankun，或者基于qiankun做二次开发。
面包屑管理：面包屑位于布局组件wrapper中。我们约定面包屑的数据格式，面包屑的组装交给子应用，解耦实现和展示，让面包屑的处理更灵活。
应用间通信：我们约定所有的子应用只能从自己的store获取数据，应用间的共享数据统一由publish.js插件读取和写入。尽可能将变化集中一处管理，方便后面的维护。
通用util和业务组件等的维护：我们采用lerna+workspace的方案，采用独立仓库维护多包的管理。
应用层框架、库如vue、element-ui、vuex是否全局共享：我们的理念是自治，主子应用完全独立。这带来的问题是资源的重复加载，这块我们还在优化。
关于微前端化后如何回滚：我们DevOps研发平台目前已经支持回滚。