建设企业级微前端方案.pptx

1、建设企业级微前端方案张浩 网易资深前端工程师 网易严选数据产品前端负责人 致力于工程化与效率工具、企业级应用架 Angular爱好者 为什么要微前端网易严选微前端建设背景 网易严选企业级微前端架构 微前端带来的优化与变革 总结与思考1为什么要微前端？网易严选微前端建设背景业务背景业务背景在大量SPA项目(100+)的开发实践中，我们总结了一些传统SPA开发模式的困境。传统SPA开发模式困境巨石应用的维护困难巨石应用传统SPA开发模式困境技术栈的更替与变迁传统SPA开发模式困境跨系统复用困难大型业务功能模块的跨系统复用-npm包模式跨系统工单-业务流转跨系统工单-开发模式传统SPA开发模式困境跨

2、多团队合作开发困难跨多团队合作开发困难破局破局一击，微前端。什么是微前端？微前端是多个小型前端应用聚合为一的应用，它们彼此项目分离但又运营聚合。2网易严选企业级微前端架构常见微前端方案在此之前，我们先来简单了解下当前几种主流的微前端方案。常见微前端方案MPA + 路由分发这种方式就是在多个独立的 SPA 应用之间跳转，通过把界面、导航、皮肤做成类似的样子，让用户感觉像是同一个应用。优点：a. 框架无关；b. 独立开发、部署、运行； c. 应用之间 100% 隔离。缺点：a. 应用之间的彻底割裂导致复用困难。（比如，每个应用左侧和顶部都带有导航，那么, 当我要把该应用在其他系统中复用时，需要对该

3、子应用的导航做较为复杂的改动） ；b. 每个独立的 SPA 应用加载时间较长，容易出现白屏，影响用户体验；c. 后续如果要做同屏多应用，不便于扩展。常见微前端方案类 Single-SPA这种模式一般分为主应用和子应用。主应用的代码一般非常简单，仅作为加载容器，管理子应用的生命周期。主应用捕获全局的路由事件，基于当前路由判断需要加载哪个子应用。比如路由为 /vue，我们就加载 /vue 子应用；路由为/react，我们就加载 /react 子应用。当然，在路由切走后，也要卸载该应用。优点：a. 框架无关；b. 独立开发、部署、运行；c. 项目自由切割，应用可以自由组合，方便复用；d. 便于自由扩

4、展功能。缺点：a. 子应用需要实现 mount、unmount 等钩子，侵入式的代码开发体验并不友好；b. 全局污染和资源竞争。常见微前端方案基座式 SPA，主从应用设计原理和single-spa有点类似。不同点在于基座会包含应用依赖的绝大多数环境，包括基础框架、基础组件与第三方依赖包。当我们的主应用启动之后，基本就有了全套的运行时环境。同时路由这块也有点区别，子应用一般会把自己的路由注册到主应用中，并不接管系统路由。子应用更像是主应用的一个“路由模块”。优点：显而易见，这种模式打包出来的子应用只包含了业务代码，体积小、加载快、用户体验好。缺点：缺点也很明显，首先基座就决定了它是框架强相关的，

5、哪怕是基座的版本升级迭代，也会非常容易造成子应用 break change；同时需要自定义方案来解决公共依赖的管理和加载，增加项目维护的复杂度。常见微前端方案传统 SPA + 组件化（比如 Web Components） + 私有 npm 源通用的一些业务功能发布成组件，通过私有 npm 的方式去维护和管理。其中，跟框架无关又比较有代表性的方案就属 Web Components 了。当然，这种模式更像是业务组件，或者说业务模块，而不是应用。优点：对现有项目渐进式增强，逐步改进。缺点： 随着业务中组件数量的爆发式增加，组件粒度通信、组件的维护成本都急剧增加；并不能做到真正的独立开发、测试、部署。

6、常见微前端方案网易严选企业级微前端方案网易严选微前端是怎么建设的呢?网易严选企业级微前端方案严选的微前端方案，在 Single-SPA 的思想上进行了大刀阔斧的改革和创新，同时借助 Node 层（数据层、服务端渲染、静态资源处理）来作为支撑，可以说形成了一个较有特色的微前端应用体系。严选微前端整体架构网易严选企业级微前端方案网易严选企业级微前端是一整套包括规范、工具、主框架、配置中心、应用监控等一系列相关功能在内的前端应用架构体系。网易严选企业级微前端方案下面来具体看以下严选微前端的具体设计。微前端设计Par t 1应用抽象应用抽象应用抽象应用抽象单个APP构成应用加载与路由策略Par t 2

7、应用加载与路由策略应用加载与路由策略url: http:/ 主应用是微前端框架的承载体。包括主框架渲染，路由监听，应用隔离，应用通信。2. 子引用启动后接管系统路由，与一个独立运行的完整应用没有本质区别。3. 按照约定 path 的规则获取entry statics。【约定优于配置】的思路可以使我们的代码变得简单，避免需要在代码中手动维护router和entry的对应关系。应用隔离Par t 3应用隔离为什么要应用隔离应用从加载，运行到卸载，会对全局产生一些污染，包括但不限于： 添加/删除/修改全局变量。 绑定全局事件。 全局定时器/requestAnimationFrame 修改原生方法或对

8、象。 修改原生方法或对象的原型链。 CSS冲突覆盖应用隔离子应用 & 子应用子应用与子应用隔离-js隔离mainmainS1S1userListchartuserListchart子应用s2子应用s1S2S2pageXpageXpageYpageY子应用调度:Loader Engine子应用与子应用隔离-js隔离硬隔离Window Reload + 白屏优化1. 浏览器: snapshot + resume2. 服务端: SSR现代浏览器-白屏优化子应用与子应用隔离-js隔离软隔离jsSandbox1. 记住对全局变量的修改，解除应用时恢复原有值。2. 记住全局事件的监听，比如 window/

9、document.addEventListener，卸载应用时卸载事件。3. 记住 setTimeout/requestAnimationFrame的调用，卸载应用时解除。4. 此外，sandbox 并不能监听到对全局方法（对象）和它们的原型链修改，因此我们还需要在加载子应用前创建一份 window snapshot ，卸载应用后按 snapshot 恢复全局方法（对象）和它们的原型链。jsSandBox子应用与子应用隔离-css隔离css动态化我们只需要在子应用加载时，标记该子应用所有的 link 和 style文件。在子应用卸载后，同步卸载所有的 link 和 style 即可。主应用与子

10、应用隔离主应用 & 子应用主应用与子应用隔离-js实际业务场景中，主应用功能是可收敛的。基于 webpack 模块化的打包方式，应用之间天然就可以避免绝大多数的全局冲突，因为大多数都被编译成了闭包、内部变量和方法。余下部分通过约束业务代码开发规范解决： 不挂载会引起副作用的全局变量； 建立模块池，收敛不可控第三方包。 针对当前已知的会引起冲突的包（如 webpack 的全局webpackJsonp 变量），全部会在 cli 工具中 cover 掉。主应用与子应用隔离-css隔离来思考一下，主应用与子应用同屏渲染，如何隔离css，不互相影响？主应用与子应用隔离-css隔离iframe?显然不是一

11、个好方案iframe不占满window，对需要定位的组件影响极大。带来事件通信、共享数据的设计复杂度提升。主应用与子应用隔离-css隔离shadow dom?看似可行，但是：我们不可避免地会把 dom 渲染到全局的 document 上，至少我们不能避免子应用的某些第三方库会这么干。而一旦把 css/html 写到全局，那么势必就会破坏 css 隔离。主应用与子应用隔离-css隔离综上所述，对于全局共享的基础样式，其实我们并不能技术上做到绝对隔离。但是在设计上，我们可以采用同一套规范(rebase方案)，保证基础样式不会互相覆盖。对于具体业务模块的样式，我们采用 CSS Module 或者命名

12、空间的方式，给每个业务模块以特定前缀，即可保证不会互相干扰。应用通信Par t 4应用通信应用通信Event 对象初始化后挂载在 Window 下，在全局以单例模式运行。应用通信应用请求分发Par t 5应用请求分发应用请求分发应用开发链路闭环Par t 6应用开发链路闭环应用开发链路闭环sharkr/cli严选的项目基于 sharkr/cli 脚手架创建，底层基于 webpack。我们通过约定、插件、配置等手段，让每个应用在开发、构建、部署时，不需要用户再去做一丝一毫的改动，从而都能符合我们微前端所需的规范。说白了，我们做到了“零成本接入”。应用开发链路闭环物料市场维护通用的业务组件（商品选

13、择、物流信息展示）、常见物料模板（list/detail/form）、可视化（流程图、柱图、折线、饼），形成紧紧围绕严选业务场景的物料市场，为应用开发提供充足的可选物料，减少重复开发。物料市场应用开发链路闭环当然，我们做的不止这些。简单来说，就是我们可以通过一些工具和规范约定，同时与每个企业自身的 devops 平台无缝对接，形成从dev、test、build、deploy的完整开发链路闭环。配置中心等相关配套设施Par t 6配置中心等相关配套设施配置中心 应用导航配置化 应用关联关系 应用权限控制 应用状态监控 应用代理层配置 如果说主框架是让我们从技术上实现了微前端，那么相关配套设施则是

14、在具体业务场景中落地的点睛之笔。网易严选企业级微前端方案独立开发、 技术栈 应用自由拆 前端+服务端的整体方业务代码无侵入设 子应用绝 优秀的用 低成本部署、运行无关解和组合， 案，既可独立运行，亦 计，子应用免主动对隔离户体验接入复用性强可作为子应用式申明生命周期严选微前端Single-SPAMPA-路由分发式基座-主从式3微前端带来的优化与变革巨石应用的“化整为零”复杂业务模块复用能力的提升工单开发模式的革新多团队合作模式的优化4总结与思考新一代开发模式的继任者保障应用持续稳定开发的基石降低技术栈变动带来的风险高度可复用的应用体系建设模块化项目外包，降低协作成本关于严选微前端网易严选微前端方案内部代号wolf。一匹狼并不凶猛，就比如一个子应用也并不能解决什么问题。但当我们的微应用成体系、成规模时，我们希望它如狼群一样能紧密、有序、协作，发挥 1+12 的效果。蓝图全面落地 = 发现问题解决问题 = 持续完善在我们的设想的美好蓝图中，如果子应用做得足够丰富，主应用能够做到足够的配置化。那么当有新需求来时，通过配置化来实现大部分业务场景是不是也未尝不可呢？就好比搭积木一般，只不过这里的积木是各种子应用罢了。THANKS