需求场景描述
在B端的多个业务系统中，模块A 存在于存在业务系统甲中，强依赖该业务系统；模块A的体积随着需求的不断更新迭代也在一天天变大，加载的速度也在一天一天的变慢。
加载慢的原因有多个方面，本身模块A的功能很大很复杂，大量组件，以及网络请求，以及强制的接口依赖顺序等等各方面原因；
项目的脚手架依旧使用的是 vue + element ，这熟悉的配方，熟悉的味道；但是因为是内网项目且对应的客户群体尤为特殊，我们自己封装了统一的业务系统脚手架以及魔改的它妈都认不出的Element UI，作为我们的业务统一的基座；
就在这样的项目情况下，项目乙 也需要集成 模块A， 而且整个的业务流程模块A在乙项目中作为前置流程，有了这个前置才能流转到项目甲；
是的没错，就这么扯，模块A既满足了项目乙的业务，还满足了系统甲的业务，然后构成了整个业务的闭环；
因为只是流程的不同和部分内容的不同（很多都是共用的），我们决定将业务进行耦合；决定不拆分。
最原始的解决方案
V1.0的方案也就是最原始的方案就是 模块A存在于项目甲中； 项目乙 使用 iframe 加载项目甲的页面组件（模块A）； 通过参数 进行了 业务隔离； 顺利上线后，用肯定是用，跑的也很欢；客户因为是从CS的系统 首次过渡到BS的系统； 整体操作体验，界面UI，都优于CS，客户表示没啥问题；但是慢慢的就开始反馈页面打开非常慢7,8秒 loading 才能消失，严重影响工作效率，要求限时优化，实现秒开和其他页面响应时间一致。
那我们经过了分析是有优化的空间的；其实我们自己也知道很慢，但是没办法目前就只能这样；
那因为客户的特殊性 优化指定是必须要进行的；于是就有了第二版的方案；
第二版的解决方案
经过分析 也大致确定了优化的点无非就是，
- 需加载，按需显示，
- 能异步的API接口全部异步，同步的强依赖的接口尽可能的合并；
- 页面的数据字典加载全部进行了业务分离，抽象成了全局的字典集合，以 provider 的形式下发；
- 针对不需要响应式的数据进行了冻结；
- 页面的拆分，再组织等等
经过了这一波的优化，效果提升还是比较明显，加载速度有了肉眼可见的变化；
但是依旧不能达到秒开的效果；
继续分析是因为 iframe 加载的 项目甲初始化加载就慢了，其实也很好理解 因为项目甲的初始加载这个过程本身项目乙是不需要的，它作为使用方只是要甲的一个页面；但是甲的页面必须是甲初始化完成才能呈现出来的；
那这个点是可以优化的，于是就有了第三版；
目前的解决方案
既然要去掉项目初始化的时间，我们就思考那就吧 模块A 以npm包的形式进行封装成独立的业务模块；在需要的集成的业务系统中进行安装使用；
经过了紧张的开发及测试，终于跑在了生产环境；加载速度又有了肉眼可见的提升；
经过了一段时间； 随之而来的问题也逐渐凸显出来了； 那就是没错 bug修改后，或者需求优化过后发版 就需要将全部依赖该包的业务系统全部升级进行发布； 因为垮部门，垮业务中心等原因已经多次出现了版本不一致的情况。
虽然这个问题依然可以通过 行为去规范解决，但依旧不是最优的方式；能自动的咱们尽量不手动；毕竟谁都有忘记的时候；
现准备优化的方案
有了几次漏发版的经历，一直在寻找解决方案中.....
呐，寻找到了 webpack 5.x 模块联邦 的这个解决方案；
看模块联邦解释： 模块联邦（Module Federation）最早是由Zack Jackson这位工程师提出的一种JavaScript架构，后来被他和其他几个工程师共同编写集成进了webpack5。 所以要使用 模块联邦 webpack 的版本至少的V5 及以上，
模块联邦的核心作用官网介绍的很明确，那就是： 在当前构建中动态地加载来自另一个bundle或者build的代码 简单的讲就是： 在当前应用中动态地加载来自另一个应用的代码
多个独立的构建可以组成一个应用程序，这些独立的构建之间不应该存在依赖关系，因此可以单独开发和部署它们。
这通常被称作微前端，但并不仅限于此。
虽然这个概念的动机，是用于微前端的，但是依然非常适合我们当前的需求场景；多业务系统的依赖，解决掉系统加载的消耗，直接加载页面（模块）；
解决方案算是有了，下一步就是实践了，下一篇 我们从一个 Demo 亲手实践配置配置以进一步了解这个模块联邦；
毕竟实践出真知嘛，Demo 跑通了对其有一定的基本了解之后再开始集成进业务系统。
下一篇 《了解使用webpack Module Federation 就从这个Demo 开始》 我们将通过一个Demo 去基本的了解一下 Module Federation 。
最后的最后
下面请上我们今天的主角：有请小趴菜
