找回密码
 会员注册
查看: 23|回复: 0

模块联邦在微前端架构中的实践

[复制链接]

2万

主题

0

回帖

6万

积分

超级版主

积分
64454
发表于 2024-10-12 08:43:46 | 显示全部楼层 |阅读模式
译自 https://medium.com/@sercaneraslan/micro-frontend-architecture-with-webpack-module-federation-part-1-9827d436bd1e原文作者Sercan Eraslan背景我们有一个用React编写的管理面板,在这里我们跟踪和管理Trendyol GO(Hzl Market和Trendyol Yemek)中所有阶段的订单。单一仓库很好地满足了我们的期望,因为一开始我们是唯一的团队,员工数量不多。单一的仓库并不总是坏的。如果它能满足你的期望,如果它不会给你带来负面影响,那么你可以使用各种方法。重要的是;找到以最有效的方式达到你的目标的方法。大约1.5年后,当我们的队友人数变得足够多时,我们以领域驱动设计(DDD)的理念将我们的团队划分为多个小团队。在这一点上,我们必须设计微前端的结构,使每个团队可以独立开发应用。我之前在几个不同的项目中有过微前端的经验。我也曾自己设计过一个微前端架构,但研究所有其他的替代方案并选择最能满足我们需求的方案是更合理的。我们探索了所有的替代方案,权衡了每个方案的利弊(我不会在这篇文章中谈论所有的替代方案,因为那是另一个话题。),在评估的最后,我们发现Webpack 模块联邦可以很好地满足我们的需求。为什么是Webpack模块联邦?当我们研究了所有的替代方案后,出于以下原因,选择Webpack模块联邦更有意义。没有维护成本(如果你自己建立一个架构,会有维护成本)没有团队特定的学习成本(如果你自己建立一个架构,会有学习成本)向模块联邦过渡的成本很小不需要对每个项目进行重新架构所有的需求都在构建时得到满足在运行时不需要额外的工作分享依赖的成本低库/框架独立你不需要处理所有的压缩和缓存问题你不需要处理路由问题Shell和Micro Apps不是紧耦合的,而是松耦合的怎么使用模块联邦有以下三种形式:域名通过这种方式,你可以创建尽可能多的微型前端(应用程序),并通过Shell App管理完全独立的域。例如,想象一下,在Shell App中有一个菜单,当链接被点击时,它将在右边带出相关的应用程序。image.png2.微件通过这种方式,你可以从任何应用程序中添加任何微件/组件(即一小段代码)到任何应用程序。你可以在产品应用中的用户应用中公开UserDetail组件。image.png混合型你可以同时使用第一和第二种方式。开始实践首先创建一个app 命名为shell,并且以相同的方式创建应用product & usernpxcreate-react-appshellcdshellyarnaddwebpackwebpack-cliwebpack-serverhtml-webpack-plugincss-loaderstyle-loaderbabel-loaderwebpack-dev-server第一步:初始化项目importReactfrom'react';importReactDOMfrom'react-dom';importAppfrom'./App';ReactDOM.render(,document.getElementById('root'));第二步:配置webpackconstHtmlWebpackPlugin=require('html-webpack-plugin');constModuleFederationPlugin=require('webpack/lib/container/ModuleFederationPlugin');constdeps=require('./package.json').dependencies;module.exports={mode:'development',devServer:{port:3001,},module:{rules:[{test:/.js$/,exclude:/node_modules/,loader:'babel-loader',options:{presets:['@babel/preset-env','@babel/preset-react',],},},{test:/.css$/i,use:["style-loader","css-loader"],},],},plugins:[newModuleFederationPlugin({name:'SHELL',filename:'remoteEntry.js',shared:[{...deps,react:{requiredVersion:deps.react,singleton:true},'react-dom':{requiredVersion:deps['react-dom'],singleton:true,},},],}),newHtmlWebpackPlugin({template:'./public/index.html',}),],};其中关于模块联邦的配置项,解释如下:name: 我们用它来确定应用程序的名称。我们将通过这个名称与其他应用程序进行交流。filename: 我们用它作为一个入口文件。在这个例子中,其他应用程序将能够通过输入 "SHELL@http://localhost:3001/remoteEntry.js "访问SHELL应用程序。shared(共享)。我们用它来指定这个应用程序将与其他应用程序共享哪些依赖。这里需要注意的是 "singleton: true"。如果你不写 "singleton: true",每个应用程序将在一个单独的React实例上运行把同样的文件复制到User和 Product项目,但不要忘记增加端口和改变名称字段。第三步:设计//app.jsimportReactfrom'react';import'./App.css';constApp=()=>( HifromShellApp );exportdefaultApp;//app.css.shell-app{margin:5px;text-align:center;background:#FFF3E0;border:1pxdashed#FFB74D;border-radius:5px;color:#FFB74D;}上面两个文件都放到src下,Product以及User项目也做同样的更改,只是将src命名为shell。 三个项目依次运行以下的命令yarnwebpackserverimage.png现在,我们所有的应用程序都为Micro Frontends架构做好了准备,并且可以相互独立运行。第四步:整合是时候提到模块联邦的两个伟大的功能了 expose:它允许你从任何应用程序到另一个应用程序共享一个组件、一个页面或整个应用程序。你所暴露的一切都被创建为一个单独的构建,从而创造了一个自然的tree shaking。每个构建都以文件的MD5哈希值命名,所以你不必担心缓存的问题。remote: 它决定了你将从哪些应用程序接收一个组件、一个页面或应用程序本身。 每个应用程序都可以同时暴露和定义一个远程,并多次进行。现在让我们把Product应用暴露给Shell应用,让我们做第一个微前端连接。让我们打开产品 repo 中的 webpack.config.js 文件,并改变其中传给ModuleFederationPlugin中的对象,如下。exposes对象中的值决定了它在repo中共享哪个组件,而对象中的key决定了其他应用程序可以访问这个组件的名称。newModuleFederationPlugin({name:'PRODUCT',filename:'remoteEntry.js',exposes:{'./App':'./src/App',},shared:[{...deps,react:{requiredVersion:deps.react,singleton:true},'react-dom':{requiredVersion:deps['react-dom'],singleton:true,},},],}),让我们打开shell repo中的webpack.config.js文件,将其中传给ModuleFederationPlugin方法的对象做如下修改。remotes对象中的值决定了如何访问Product(@符号前的名称必须与Product库中Webpack config中的名称相同),对象中的key允许我们只用名称来访问Product。newModuleFederationPlugin({name:'SHELL',filename:'remoteEntry.js',remotes:{PRODUCT:'PRODUCT@http://localhost:3002/remoteEntry.js'},shared:[{...deps,react:{requiredVersion:deps.react,singleton:true},'react-dom':{requiredVersion:deps['react-dom'],singleton:true,},},],}),我们已经将2个应用程序连接在一起。现在让我们看看如何在Shell应用程序中使用Product。让我们在shell资源库中打开App.js并做如下修改。importReactfrom'react';import'./App.css';constProductApp=React.lazy(()=>import('PRODUCT/App'));constApp=()=>( HifromShellApp );exportdefaultApp;我们已经定义了名为 "App "的组件,该组件通过React的lazy方法从Product中暴露出来,到我们名为ProductApp的变量。我们需要对我们将从不同的微前端获得的组件使用lazy函数,我们需要使用Suspense在模板部分使用它,这样我们可以确保所有的东西都加载到页面上。如果你现在想,你可以在User应用程序中添加一个组件,并尝试在产品应用程序中使用这个组件 你可以使用expose和remotes共享你想要的组件。 创建模块联邦的Zack Jackson有一个Github repo,叫做module-federation-examples。在这个Repo中,有许多的示例,如React、Vue、Angular、服务器端渲染、共享路由,如果你想的话,你可以查看它们。需要解决的问题路由其中一个重要的问题是,微前端管理自己的路由,以保持它们与Shell的松散耦合关系。在我们建立的项目中,我们倾向于在Shell的路由安装微前端模块。当到达/mf-a路径时,Shell会懒加载Micro-Frontend-A应用程序,当用户到达/mf-b路径时,它以同样的方式加载Micro-Frontend-B。//shell/src/Shell.jsimport...constMicroFrontendA=lazy(()=>import('MicroFrontendA/MicroFrontendARoutes'));constMicroFrontendB=lazy(()=>import('MicroFrontendB/MicroFrontendBRoutes'));constShell=()=>{return(Yükleniyor...}>);};exportdefaultShell;之后,控制权转移到微前端。微前端-A处理自己的子模块,并对其进行路由设置。与上面的例子有关,当导航到/mf-a的路径时,PageA被加载,当路径是/mf-a/page-b时,PageB被加载。//micro-frontend-a/src/pages/MicroFrontendARoutes.jsimportReact,{lazy}from'react';import{Switch,Route,useRouteMatch}from'react-router-dom';importwithPermissionsfrom'Shell/hoc/withPermissions';constPageA=lazy(()=>import('pages/pageA/PageA'));constPageB=lazy(()=>import('pages/pageB/PageB'));constMicroFrontendARoutes=()=>{const{path}=useRouteMatch();return(withPermissions(['VIEW_PAGE_A'])(PageA)}/>withPermissions(['VIEW_PAGE_B'])(PageB)}/>);};exportdefaultMicroFrontendARoutes;共享状态以及hooks实际上,在模块联邦中共享这些是非常容易的;但它目前有一个有趣的解决方案。如果你看看我为Shell的webpack.config.js所举的例子,在共享方面有一个微妙的接触。一个消耗公共状态的hooks也在库下共享。由于应用程序总是在Shell下渲染,所有的context都以正确的顺序加载,当我们像例子中那样共享 hooks时,我们可以在微前端中使用通用context而不会有任何错误。//shell/webpack.config.jsconst{dependencies:deps}=require('./package.json');constmoduleFederationOptions={...exposes:{...'./hooks/useToastr':'./src/hooks/useToastr',},shared:[{...},'./src/hooks/useToastr',//Here!],};热重载举例说明我们遇到的问题。如果我们通过Shell访问应用程序,我们在Micro-Frontend-A中做的一个改变不会触发热重载。因此,我们在开发的时候会慢一点,我们必须在每次改变后刷新。为了解决这个问题,模块联邦团队开发了@module-federation/fmr包。当它作为插件被包含在Webpack配置中时,你的模块联邦结构的任何变化都会自动运行Live Reload。部署在使应用程序上线的过程中,我们遇到了两个主要问题。在运行时动态地设置publicPath。 当用模块联邦创建一个复杂的应用程序时,会出现这类问题。Shell将从哪里获得微前端的共享文件?属于Shell的文件将来自微前端的哪些路径?许多文件路径需要被设置。我们通过正确指定publicPath选项来控制这些。在Trendyol GO中,我们将应用程序作为Docker镜像创建一次,然后我们使它们在不同的环境中通过环境变量接受不同的设置。如果publicPath是在构建时设置的,我们就必须解决大的配置文件问题,这不是一个优化的解决方案。我们稍微修改了Zack Jackson在这篇文章中提到的方法,使其非常简单地在运行时分配动态publicPath。在我们使用的方法中,有一个叫做setPublicPath.js的文件。其内容的格式如下。//shell/src/setPublicPath.js__webpack_public_path__=`${newURL(document.currentScript.src).origin}/`;我们通过在构建时操作Webpack设置中的entry//shell/webpack.config.jsentry:{Shell:'./src/setPublicPath',main:'./src/index',},在运行时,动态设置模块联邦设置中分配的远程URL。我们用External Remotes Plugin来实现//shell/webpack.config.jsconstmoduleFederationOptions={...remotes:{MicroFrontendA:'MicroFrontendA@[window.MF_A_URL]/remoteEntry.js',MicroFrontendB:'MicroFrontendB@[window.MF_B_URL]/remoteEntry.js',},...};如何在运行时设置window.MF_A_URL and window.MF_B_URL//shell/src/index.jsimportconfigfrom'config';//dynamicvars.froman.envfilee.g.window.MF_A_URL=config.MF_A_URL;window.MF_B_URL=config.MF_B_URL;import('./bootstrap');在这个过程的最后,我们实现了一个稳定的应用程序。虽然在我们面前还有许多不同的改进,但从现在开始,每个团队可以开发自己的模块,而不必依赖其他团队。-END-关于奇舞团奇舞团是 360 集团最大的大前端团队,代表集团参与 W3C 和 ECMA 会员(TC39)工作。奇舞团非常重视人才培养,有工程师、讲师、翻译官、业务接口人、团队 Leader 等多种发展方向供员工选择,并辅以提供相应的技术力、专业力、通用力、领导力等培训课程。奇舞团以开放和求贤的心态欢迎各种优秀人才关注和加入奇舞团。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 会员注册

本版积分规则

QQ|手机版|心飞设计-版权所有:微度网络信息技术服务中心 ( 鲁ICP备17032091号-12 )|网站地图

GMT+8, 2024-12-27 01:03 , Processed in 0.617921 second(s), 26 queries .

Powered by Discuz! X3.5

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表