咱们团队在早早聊的B站直播间分享了EMP微前端---团队半年以来的技术果实。分享的内容全在这里，会讲述微前端的由来，解决的问题，以及EMP微前端方案的不一样之处，更有四个实战项目的总结，欢迎你们一块儿探讨EMP微前端的将来。html
前言
你们好，今天咱们将带来EMP微前端解决方案。看到这个名字，你们脑海里是否会想起这些问题：EMP是个什么？微前端又是什么？微前端有什么用？EMP微前端的价值点在哪里？前端
带着这些问题，咱们来一块儿学习。vue
首先，介绍一下咱们团队成员。EMP微前端解决方案是一个生态，是由咱们团队成员一块儿开发和维护以及迭代的。而今天将由咱们三个讲师，来说述EMP微前端解决方案的一些原理性知识和具体的实战状况。react
听完此次分享，你们能够学到什么呢？webpack
能够学到EMP微前端解决方案的脚手架以及生态的设计，给予你借鉴。ios
经过这套生态的打造，EMP微前端解决方案实际应用了多个大型项目，有显著的收益，具体的实战项目能够看如下列表：git
接下来，咱们将讲述的内容目录以下：github
业务背景
咱们目前的业务是中台业务，须要开发面向公司内部配置的toB产品，这种管理后台系统。当须要开发愈来愈多的管理系统，咱们会发现，不少系统直接能够有些复用的东西，好比：通用的用户数据、UI架构风格、类似的业务逻辑等。web
因而，咱们要解决的问题就是：如何多个应用项目直接，共享一些资源。npm
按照以往，咱们可能会选择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-cli脚手架、格式规范插件、ts辅助插件等，后面完善了更多的场景demo和插件，推荐能够上emp库的demo例子学习：
https://github.com/efoxTeam/emp/tree/main/projects
基于这些脚手架生态，上层的使用设计也有必定的技巧。比较推荐的使用方式是，能够搭建一个应用基站，基站内部能够放置多个项目的共享资源（组件、模块、方法等），这些共享资源放在基站，可让专门的几我的维护，确保稳定性和可靠性。其余的业务项目，好比图中的APP1和APP2，可使用基站资源。
另外，其实APP1和APP2项目直接，也是能够进行资源共享的。
下面是EMP生态的主要脚手架工具和插件列表：（后面不止了）
看过源码的朋友，能够看到efoxTeam/emp库中的emp-cli脚手架，是使用了lerna进行管理的，这种管理方式比较清晰明了，能够在project中并行执行多个项目。
@efox/emp-cli脚手架是其中比较重要的一部分，能够从上图看到，目前emp是基于webpack5执行的，利用了webpack的chain特性，从全局项目的emp.config.js文件中读取配置，来执行dev、build等命令。能够看到命令中有emp tsc这种更新远程d.ts声明文件的命令，这也是下面要提到的ts规范：
使用ts其实能够带来上图比较多的好处，对于一个团队的规范来讲，是友好的。因此emp是推荐你们使用ts的。
像上图使用ts后，在业务项目中，只要执行了emp 的同步远程的声明文件（ emp tsc）的命令，就能够在引入组件的时候，知道组件须要传什么参数，返回什么参数了。
经过emp脚手架命令，还有emp-yune-dts-plugin插件的辅助，就能够将多项目之间的声明文件彼此同步，提高团队协做的规范性。
使用体验
首先，咱们能够来一个简单的demo体验。咱们以react项目为demo，分别执行命令emp init建立两个项目：react-base和react-project。
咱们能够看到，react-base和react-project两个项目下，都有一个配置文件：emp-config.js。
咱们细看emp-config.js配置文件里面的内容，其中在webpack chain中，使用了mf插件，主要的字段如图所示。
同时在在webpack chain中，使用了html插件，便于引入其余应用资源入口。
咱们整理了一系列的emp教程文章，能够看wiki列表：
https://github.com/efoxTeam/emp/wiki
值得期待的是，为了下降使用门槛和便于管理，咱们如今正在开发GUI可视化工具。
这是GUI的项目列表图。
GUI新建项目，会调用emp init命令去建立对应模板。
这是项目仪表盘，便于管理单个项目。
单个项目可能引入多个基站，能够引入基站、查看基站列表和详细信息：
GUI很快就能够和你们见面啦，敬请期待！！！
实战项目
EMP在我司内部其实应用了挺多的业务项目和中台项目，其中拿四个项目来说解一下具体的实战过程：
PK条项目
PK条是包含了业务逻辑的组件，用于显示多人之间的pk进度，主要用到PC客户端的内嵌页面web项目和移动端APP的内嵌页面web项目中。因此，咱们要解决的是，pc web项目和移动端web项目之间如何共享这个组件资源。
有三种方案，一种是简单的复制粘贴，咱们就不考虑了。第二种是npm包方式，若是使用的话，须要维护一个UI库，基于前面说到的npm包方式的痛点，也句不采用了。第三种就是咱们说的EMP微前端方案。
使用EMP微前端改造的先后对比，能够将PK条这一业务逻辑组件放在远程组件基站维护，而后暴露出来，供应用项目使用。
这是最终实现的产品效果图，PC web项目引入该资源组件，能够传参数自定化和修改样式。
后面的维护，只要在远程基站中，更新迭代PK条组件的功能，就能够同步更新到这些应用项目中，提高了更新速度，维护起来也比较方便。
cocosd游戏项目
目前cocos2d游戏最主要的开发方式是经过官方提供的GUI图形界面工具——creator，经过 creator 开发者无需关注构建自己，只需经过界面操做便可对游戏代码进行构建打包。可是这样也存在着如下几个问题：
构建闭源，致使开发者对项目构建没法定制化，假如编译出来的代码存在兼容性问题，那只能进入 creator 安装目录寻找对应的某个配置文件进行修改，这种侵入性的修改颇有可能会引起不稳定性。 没法使用其余构建工具进行打包，意味着项目没法使用新的技术方案，只能局限于 creator 设定的框架之中 游戏组件在不一样项目之间难以复用，组件一般包含了 prefab、sprite 等资源，如何发布托管并在其余项目复用组件，简单地经过 creator 是没法作到的。 发版流程繁琐，由于开发多个cocos2d游戏可能会复用一些资源，若是使用npm包方式抽离的话，发布流程会比较麻烦。
咱们要作的第一步是，接入webpack模型，为后面微前端改造作准备。
首先看看单一 creator 的开发过程，它会在本地服务开启 7456 的端口服务，整个本地开发流程如上图。
接入 webpack 和 emp 后的开发过程，首先 webpack 会经过 axios 抓去 creator服务生成出来的 index.html文件做为 template，并开启一个新的服务，并经过 devServer 将资源请求转发回 creator的端口服务，确保资源访问正常，开发流程图如上图。
因而咱们成功解决了两个痛点。
第二步，正式接入EMP微前端。
上图是具体接入过程说明。
这是使用资源的代码图。
须要注意一点，cc全局变量。
经过接入EMP微前端，成功解决了剩下的两个痛点。
这是咱们的效果图。
详细的cocos2d游戏项目接入微前端，能够看：
YY PC客户端
YY语音是欢聚时代旗下一款知名的集娱乐，交友，游戏，教育等于一身，并包含移动端、web端，PC端三端的国内聊天直播软件。
为了可以让用户在产品中获得更好的体验，同时摒弃过期技术，保持对前沿技术的探索，与时俱进，公司决定对YY PC客户端（如下简称PC端）现有一些主要模板进行web改造。
改造以前，咱们存在以上三点痛点。
这是改造的主要经历，一共有三段。
第一段，改造现有项目为EMP微前端。开始改造新频道模板的时候，用create-react-app搭建了一个普通项目进行开发和部署。但后面要继续接新模板的时候，想要每一个模板都抽离成一个个独立部署的应用，方便专门的人维护（一个模板的逻辑很复杂不少，能够抽离成一个项目了）。因而，这时候对新频道模板的项目进行了微前端改造，花了半天的时间。
第二段，用emp脚手架新建应用项目。在改造了新频道模板的项目为微前端后，咱们将须要用到的功能资源，所有都整和到了基站管理，而后emp init项目以后，能够直接使用基站资源，起一个新项目非常迅速。
第三段，一键更新多个项目，同时维护多个项目。后面，有愈来愈多的模板改形成一个个不一样的应用项目，这时候就体验到一键更新的好处了。若是多个模板的应用项目使用的共享资源须要更新，只须要更新基站，就能够很好达到咱们的目的了。
这是产品效果图。
这是咱们前先后后使用EMP微前端后带来的收益。
更详细的YY PC客户端实战内容，能够看：
欢聚变色龙
在开发过程当中，常常会遇到不一样的业务方须要快速上线一些诸如协议页、图文介绍页、引导页等的静态页面和榜单、抽奖等动态页面来支撑线上业务，可是不管是静态仍是动态页面，这样的研发和上线成本无疑是巨大的，这样一个可以提供让不一样业务方的产品和运营可以快速配置活动上线的平台的需求就油然而生了，下面列举一些痛点：
- 活动上线成本
- 支持多语言
- 不一样业务之间的活动组件没法复用
- 组件没法实现动态更新
这是效果图。
中途有代码展现，能够看录屏。
更详细关于欢聚变色龙项目实战，能够看： 欢聚变色龙落地EMP微前端
感谢
这是咱们的开源仓库是efoxTeam/emp，欢迎你们关注。另外，咱们的掘金团队帐号是：Efox。