在2020年12月05号的一个美好下午，我们团队在早早聊的B站直播间分享了EMP微前端---团队半年以来的技术果实。内容比较丰富，分为三篇文章阐述，恳请大家给EMP库一个宝贵的star支持一下吧，感谢！！！

前言

大家好，今天我们将带来EMP微前端解决方案。看到这个名字，大家脑海里是否会想起这些问题：EMP是个什么？微前端又是什么？微前端有什么用？EMP微前端的价值点在哪里？

带着这些问题，我们来一起学习。

首先，介绍一下我们团队成员。EMP微前端解决方案是一个生态，是由我们团队成员一起开发和维护以及迭代的。而今天将由我们三个讲师，来讲述EMP微前端解决方案的一些原理性知识和具体的实战情况。

听完这次分享，大家可以学到什么呢？

可以学到EMP微前端解决方案的脚手架以及生态的设计，给予你借鉴。

通过这套生态的打造，EMP微前端解决方案实际应用了多个大型项目，有显著的收益，具体的实战项目可以看以下列表：

接下来，我们将讲述的内容目录如下：

业务背景

我们目前的业务是中台业务，需要开发面向公司内部配置的toB产品，这种管理后台系统。当需要开发越来越多的管理系统，我们会发现，很多系统直接可以有些复用的东西，比如：通用的用户数据、UI架构风格、相似的业务逻辑等。

于是，我们要解决的问题就是：如何多个应用项目直接，共享一些资源。

按照以往，我们可能会选择npm包形式，将要共享的资源抽离封装成npm包，再给需要使用的项目引入npm包使用。但是，如今我们有另外的一种选择，那就是：微前端！

什么是微前端

从Micro Frontends 官网可以了解到，微前端概念是从微服务概念扩展而来的，摒弃大型单体方式，将前端整体分解为小而简单的块，这些块可以独立开发、测试和部署，同时仍然聚合为一个产品出现在客户面前。可以理解微前端是一种将多个可独立交付的小型前端应用聚合为一个整体的架构风格。

值得留意的几个点：

• 微前端不是一门具体的技术，而是整合了技术、策略和方法，可能会以脚手架、辅助插件和规范约束这种生态圈形式展示出来，是一种宏观上的架构。这种架构目前有多种方案，都有利弊之处，但只要适用当前业务场景的就是好方案。
• 微前端并没有技术栈的约束。每一套微前端方案的设计，都是基于实际需求出发。如果是多团队统一使用了react技术栈，可能对微前端方案的跨技术栈使用并没有要求；如果是多团队同时使用了react和vue技术栈，可能就对微前端的跨技术栈要求比较高。

简单理解，微前端改变了一种开发方式。相比于以前的每个开发者都需要自己维护应用，共享的资源抽离成包引入，到现在使用微前端，可以将共享的资源放在一个基站应用管理，然后其他的开发人员在开发某业务应用的时候，可以快速以另一种优雅姿态从基站应用中，引入需要的资源。

具体概念学习可以看： 什么是微前端，可以带来什么价值

微前端可以解决什么问题

很多人会问的一个问题就是：用npm方式不香吗？搞不懂为何要用微前端？

那么，看完npm方式和微前端的对比之后，大概您对微前端会有比较好的认知了。

先从业务场景来说起，可能大家会接触到上面几种业务场景，这里大概说一下哈。

第一种，零散的活动页面。像这种，其实也要看情况，比如像我们公司内部运营需要快速的更新活动页面，于是内部就会自己开发一套活动页面配置系统，供运营使用，像我们后面会说到的欢聚变色龙，就是这样的案例，但我们的欢聚变色龙接入了微前端，具体有什么效益，可以看后面分享。

第二种，外包项目。其实像外包项目前期可能会比较小型，也许前期会看不到微前端带来的收益，但是随时项目越做越大，其实微前端的急迫度会越来越大。像我们后面分享的实战中， YY PC客户端项目，其实就是一个大型项目改造接入微前端的过程，从过程中我们可以看到一开始接入微前端可能看不出比较大的效果，但后面随着业务迭代，微前端带来的效益可以说是指数式得增长，对后面维护也是非常友好的一种方式。

第三种，中台项目，以及第四种，大型产品项目。这两种更不用说了，这时使用微前端的效益是会比较明显的，带来的收益也是可观的。如果参与过这两类项目的童鞋，可能对以下npm带来的痛点有比较深刻的感同身受。

接下来，我们来通过npm方式和微前端的对比，来阐述为什么我们要使用微前端。

第一痛点，也是非常重要的痛点，就是使用npm包的更新流程繁琐复杂。

比如，开发三个管理后台应用项目，将相同的业务子模块抽离成npm包方式，这时候，如果要更新该业务子模块的逻辑时，那么需要做以下的流程操作：

1. 更新npm包版本
2. 更新A管理系统应用的npm包版本
3. 发布部署A管理系统应用
4. 对B和C管理系统应用循环2和3步骤

我们可以看到，该业务子模块，随着被使用的管理应用系统的增加，更新流程会叠加式得复杂起来。

而微前端一个闪亮点，就是可以做到一键更新。

具体理解就是，我们可以把复用的业务子模块，放在同一个基站应用之中，来管理和维护，并且暴露出去可以给多个管理系统应用使用。如果业务子模块需要更新逻辑的话，只需要发布部署基站应用，其他管理系统应用并不需要做什么操作，只需要访问时刷新，就可以立即拿到最新的业务子模块逻辑了。想想这种效果，是不是很棒？

npm包方式带来的第二个痛点，就是构建速度慢。

假如一个大型管理应用系统，引入了n个可复用的业务子模块，在构建层面来说，相当于将n个可复用的业务子模块的代码“复制”到了项目中，构建的时候也需要同步去构建这些业务子模块，这样一来，要构建的体积就大大增加了，构建时长也因此延长，开发体验会越来越不友好，发布效率也会随之降低。

而微前端可以很好得解决这个问题。微前端，可以提升整个应用的构建速度，因为像某一管理应用项目，可以在线使用其他管理系统应用的子模块（或者是用基站应用维护的形式），并不需要本地构建这些子模块的代码，从而减小了构建体积，提高了开发效率。

从另一个角度，比较好的微前端方案，应该是会解决不重复引入第三方依赖包的问题。比如上图左侧，两个应用可能会引入多个第三方包：react、antd等。但好的微前端方案，可以做到右侧引入第三方包的时候，只引入一个包版本。从这个角度来说，减少重复引入第三方依赖包，也可以提升速度。

上图是我们对旧项目改造使用了EMP微前端方案后带来的速度提升数据。

npm方式的第三的痛点，体现在这样一个场景中。比如我们多个后台管理配置系统，使用了一些相同的资源，比如：统一的UI风格、移动端适配功能、通用状态。

这时候，如果使用了npm包方式，可能给抽离成template模板，然后执行命令或者手动去复制一个应用项目模板使用。但这种有个弊端是，如果我们对应用模板的内容更新了，需要同步到实际已经使用的项目的时候，就需要每个实际项目都去代码复制，甚至需要解决冲突之类的。这样一来，不便于我们后续的应用迭代。

而如果采用微前端共享资源方式，也就是将相同的资源全部都放在一个基站应用中，然后直接把基站应用分享出去（至少EMP微前端解决方案可以做到分享应用），管理系统项目再直接在分享出来的应用上进行迭代开发具体业务功能。这样一来，由于微前端一键更新的优势，大大简化了我们后续管理系统的迭代维护，甚至一开始创建的时候，也只需要简单的步骤。

微前端有哪些方案

在一开始，我们调研了业界可能比较出名的single spa和基于此搭建完善生态的乾坤，但会发现几个不足之处：

• 状态方面*。qiankun 所做的微前端不能把基站项目和子项目过度隔离导致上下文不一致，共享状态等等需要通过总线方式传递，十分麻烦。
• 跨框架调用实现qiankun 通过 dom 隔离的方式，使得跨框架实现十分容易，但是不能互相调用，粒度只能渲染在规定的 dom 区域。
• 体积方面。qiankun 因为是通过 dom 隔离方式实现，所以依赖共享并不完善，需要依赖于 systemjs，而且共享不方便，导致依赖可能会出现重复，使得出现体积变大。

我们在调研的时候，学习到了webpack5 Module Federation，具体的原理学习可以参考：webpack5 Module Federation原理

具体基于single spa以及乾坤，和EMP的对比如下：

像single spa是以来一个基座存活的，但EMP虽然提倡使用基站应用管理共享资源，但其实，每个应用之间都是可以共享资源的。

状态方面。像qiankun 所做的微前端不能把基站项目和子项目过度隔离导致上下文不一致，共享状态等等需要通过总线方式传递，十分麻烦。而 EMP 通过把调用远程的状态管理使得状态共享十分方便。

像基于single spa的乾坤在调研之时并不能使用SSR，但基于webpack5 Module Federation的EMP是可以支持SSR的。

另外补充：

• 跨框架调用实现。qiankun 通过 dom 隔离的方式，使得跨框架实现十分容易，但是不能互相调用，粒度只能渲染在规定的 dom 区域。EMP 实现的跨框架调用粒度到了 function ，而且使用十分方便。
• 体积方面。qiankun 因为是通过 dom 隔离方式实现，所以依赖共享并不完善，需要依赖于 systemjs，而且共享不方便，导致依赖可能会出现重复，使得出现体积变大。EMP 通过 module federation 实现依赖共享，使得依赖不会重新重复（依赖变成全局变量，相同依赖只会留下一个），所以体积会相对 qiankun 更小。

更新续文：

EMP微前端分享内容回顾（中）

EMP微前端分享内容回顾（下）