在2020年12月05号的一个美好下午，咱们团队在早早聊的B站直播间分享了EMP微前端---团队半年以来的技术果实。内容比较丰富，分为三篇文章阐述，恳请你们给EMP库一个宝贵的star支持一下吧，感谢！！！前端
前言
你们好，今天咱们将带来EMP微前端解决方案。看到这个名字，你们脑海里是否会想起这些问题：EMP是个什么？微前端又是什么？微前端有什么用？EMP微前端的价值点在哪里？vue
带着这些问题，咱们来一块儿学习。react
首先，介绍一下咱们团队成员。EMP微前端解决方案是一个生态，是由咱们团队成员一块儿开发和维护以及迭代的。而今天将由咱们三个讲师，来说述EMP微前端解决方案的一些原理性知识和具体的实战状况。webpack
听完此次分享，你们能够学到什么呢？git
能够学到EMP微前端解决方案的脚手架以及生态的设计，给予你借鉴。github
经过这套生态的打造，EMP微前端解决方案实际应用了多个大型项目，有显著的收益，具体的实战项目能够看如下列表：web
接下来，咱们将讲述的内容目录以下：npm
业务背景
咱们目前的业务是中台业务，须要开发面向公司内部配置的toB产品，这种管理后台系统。当须要开发愈来愈多的管理系统，咱们会发现，不少系统直接能够有些复用的东西，好比：通用的用户数据、UI架构风格、类似的业务逻辑等。antd
因而，咱们要解决的问题就是：如何多个应用项目直接，共享一些资源。架构
按照以往，咱们可能会选择npm包形式，将要共享的资源抽离封装成npm包，再给须要使用的项目引入npm包使用。可是，现在咱们有另外的一种选择，那就是：微前端！
什么是微前端
从Micro Frontends 官网能够了解到，微前端概念是从微服务概念扩展而来的，摒弃大型单体方式，将前端总体分解为小而简单的块，这些块能够独立开发、测试和部署，同时仍然聚合为一个产品出如今客户面前。能够理解微前端是一种将多个可独立交付的小型前端应用聚合为一个总体的架构风格。
值得留意的几个点：
- 微前端不是一门具体的技术，而是整合了技术、策略和方法，可能会以脚手架、辅助插件和规范约束这种生态圈形式展现出来，是一种宏观上的架构。这种架构目前有多种方案，都有利弊之处，但只要适用当前业务场景的就是好方案。
- 微前端并没有技术栈的约束。每一套微前端方案的设计，都是基于实际需求出发。若是是多团队统一使用了react技术栈，可能对微前端方案的跨技术栈使用并无要求；若是是多团队同时使用了react和vue技术栈，可能就对微前端的跨技术栈要求比较高。
简单理解，微前端改变了一种开发方式。相比于之前的每一个开发者都须要本身维护应用，共享的资源抽离成包引入，到如今使用微前端，能够将共享的资源放在一个基站应用管理，而后其余的开发人员在开发某业务应用的时候，能够快速以另外一种优雅姿态从基站应用中，引入须要的资源。
具体概念学习能够看： 什么是微前端，能够带来什么价值
微前端能够解决什么问题
不少人会问的一个问题就是：用npm方式不香吗？搞不懂为什么要用微前端？
那么，看完npm方式和微前端的对比以后，大概您对微前端会有比较好的认知了。
先从业务场景来讲起，可能你们会接触到上面几种业务场景，这里大概说一下哈。
第一种，零散的活动页面。像这种，其实也要看状况，好比像咱们公司内部运营须要快速的更新活动页面，因而内部就会本身开发一套活动页面配置系统，供运营使用，像咱们后面会说到的欢聚变色龙，就是这样的案例，但咱们的欢聚变色龙接入了微前端，具体有什么效益，能够看后面分享。
第二种，外包项目。其实像外包项目前期可能会比较小型，也许前期会看不到微前端带来的收益，可是随时项目越作越大，其实微前端的急迫度会愈来愈大。像咱们后面分享的实战中， YY PC客户端项目，其实就是一个大型项目改造接入微前端的过程，从过程当中咱们能够看到一开始接入微前端可能看不出比较大的效果，但后面随着业务迭代，微前端带来的效益能够说是指数式得增加，对后面维护也是很是友好的一种方式。
第三种，中台项目，以及第四种，大型产品项目。这两种更不用说了，这时使用微前端的效益是会比较明显的，带来的收益也是可观的。若是参与过这两类项目的童鞋，可能对如下npm带来的痛点有比较深入的感同身受。
接下来，咱们来经过npm方式和微前端的对比，来阐述为何咱们要使用微前端。
第一痛点，也是很是重要的痛点，就是使用npm包的更新流程繁琐复杂。
好比，开发三个管理后台应用项目，将相同的业务子模块抽离成npm包方式，这时候，若是要更新该业务子模块的逻辑时，那么须要作如下的流程操做：
- 更新npm包版本
- 更新A管理系统应用的npm包版本
- 发布部署A管理系统应用
- 对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微前端分享内容回顾（下）