北京网站开发学习,网站配色,wordpress 命令执行,网站建设小程序开发公司一、背景
在 Monorepo 大仓模式中#xff0c;我们把组件放在共享目录下#xff0c;就能通过源码引入的方式实现组件共享。越来越多的应用愿意走进大仓#xff0c;正是为了享受这种组件复用模式带来的开发便利。这种方式可以满足大部分代码复用的诉求#xff0c;但对于复杂…一、背景
在 Monorepo 大仓模式中我们把组件放在共享目录下就能通过源码引入的方式实现组件共享。越来越多的应用愿意走进大仓正是为了享受这种组件复用模式带来的开发便利。这种方式可以满足大部分代码复用的诉求但对于复杂业务组件而言无论是功能的完整性还是质量的稳定性都有着更高的要求。 源码引入的组件提供方一旦发生变更其所有使用方都需要重新拉取 master 代码然后构建发布才能使用新功能这一特性对物料组件、工具组件以及那些对新功能敏感度较低的业务组件来说是可以接受的但对于新功能敏感度高的复杂业务组件来说功能更新的不及时会直接面临着资损风险。 这类复杂组件也往往面临着频繁且快速的迭代发布这样一来对于组件使用方而言不光需要订阅组件更新而且需要做到及时发布升级才能规避风险因此只用源码引入的方式来共享复杂业务组件是耗费精力且不合适的。 Webpack5 的 MFModule Federation模块联邦有着动态集成多个构建的特性能够规避上述更新的问题。但同样也是把双刃剑一旦远程组件提供方发挂了其所有使用方也就不能正常使用问题所造成的影响面也会被进一步放大。从分布式风险转化为集中式风险后权限管控、依赖关系、业务埋点各方面都需要考虑清楚对组件的能力要求更高。 而且 MF 远程组件本地开发代理复杂无插件情况下本地至少要启两个服务进行调试对电脑配置有一定要求总的来说有一定上手成本。 那么有没有一种共享方式能够保留两者的优点又能对缺点进行规避。本文就基于这个目的从以下两点展开讨论
对于共享复杂业务组件如何做好权限控制、数据埋点以及平稳降级。如何规避 MF 远程组件的稳定性风险、解决组件源码依赖发布更新等问题保证稳定性的同时降低本地开发门槛。
二、大仓下组件共享方式
Monorepo 大仓模式下跨应用共享组件的方式有很多常用的是源码引入、模块联邦两种方式。本文不对这两种方式的原理展开介绍和讨论先简单介绍下这两种方式在大仓下的使用方法。
源码引入组件
这种方式能解决大仓下大部分组件复用的需求代码复用的便利性也是大家愿意走进大仓的原因之一。
组件提供
为了区分其他组件可以在 /业务域/_share/remote-components 目录下开发远程组件。dx 是内部大仓的 CLIcc 命令可以快速生成一个组件模板。
// 区分普通组件新增一个remote-components组件目录
cd remote-components dx cc order-detail同样是 Monorepo大仓组件的创建方式和 Lerna 新建物料组件类似。借助脚手架根据填写的内容就能生成模版可以编写单测去自测组件变更能一定程度的保证组件的健壮性避免出现破坏性升级的问题。生成之后的模板目录结构如下图。 组件使用
依赖注入、源码引用
package.json 引入依赖配置 workspace:*构建时动态去取_share/目录下最新版本的组件资源。若从稳定性考虑也可以固定版本号。
/** package.json */
demo/order-detail: workspace:*/** 业务组件 */
import OrderDetail from demo/order-detailOrderDetail {...props} /总结
优点
开发便捷本地只需启一个应用就能开发调试方便。若组件迭代发挂了只会影响当前发布的应用不影响其他使用方能正常使用该组件对普通组件和一些对新功能不敏感的业务组件来说是合适的。
缺点
对新功能敏感度较高的复杂业务组件而言使用方如果要更新版本需要重新拉代码构建部署信息同步、发布投入成本较高。由于大仓特性代码变更权限很难做到管控非组件提供方也能修改代码组件 Owner 需要严格 CR 变更。
MF远程组件
umi 4.0.48 支持在 umi config 使用 MF 配置来使用 MF 的功能。umi4 可以直接从umijs/max导出defineConfig也可以使用umijs/plugins/dist/mf插件去支持配置 MF 属性本质也是对 WebPack Plugin 的封装属性是类似的。不一样的点在于 Host 不再需要通过配置 Exposes 将组件一个个的暴露出去而是约定暴露 Exposes 目录下的组件十分方便。
需要注意的是该特性用到了 ES2021 的 Top-Level await所以浏览器必须支持该特性。比如谷歌 Chrome 浏览器要在 89 版本以上。 /** 方法一使用umijs/max导出的defineConfig */
import { defineConfig } from umijs/max;export default defineConfig({// 已经内置 Module Federation 插件, 直接开启配置即可mf: {remotes: [{name: remote${MFCode},aliasName: APP_A,entry: xxx/remote.js,},],// 配置 MF 共享的模块shared,},
});
/** 方法二使用umijs/plugins/dist/mf的插件 */
import { defineConfig } from umi;export default defineConfig({plugins: [umijs/plugins/dist/mf], // 引入插件mf: {remotes: [{name: remote${MFCode},aliasName: APP_A,entry: xxx/remote.js,},],// 配置 MF 共享的模块shared,},
});
组件提供
用了该插件后可在正常目录结构/pages下开发代码约定在 Exposes 目录下新建对应组件引用然后将其暴露出去。 之前 现在
组件使用
使用方也在 Config 配置 MF可配置多个 Host自己也能当 Host。然后使用umijs/max的safeRemoteComponent 异步注册组件。 //config.tsconst APP_A_ENTRIES {PROD: https://prod-a-env.com/xxxx/remote.js,DEV: https://dev-a-env.com/xxxx/remote.js,PRE: https://pre-a-env.com/xxxx/remote.js,TEST: https://test-a-env.com/xxxx/remote.js,
}const APP_B_ENTRIES {PROD: https://prod-b-env.com/xxxx/remote.js,DEV: https://dev-b-env.com/xxxx/remote.js,PRE: https://pre-b-env.com/xxxx/remote.js,TEST: https://test-b-env.com/xxxx/remote.js,
}mf: {name: remote${DemoCode},library: { type: window, name: remote${DemoCode} },remotes: [{/** app-A远程组件 */name: remote${aMFCode},aliasName: appA,keyResolver: getEnv(),entries: ORDER_ENTRIES,},/** app-B远程组件 */{name: remote${bMFCode},aliasName: appB,keyResolver: getEnv(),entries: IM_ENTRIES,},],shared},
在 moduleSpecifier 配置使用的远程组件规则为 Guest Remotes 配置的 ${aliasName}和 Host Exposes 目录下的组件名。在 FallbackComponent 配置远程组件加载失败的兜底。在 LoadingElement 配置加载远程组件的过度状态。 总结
优点
非源码依赖Host 组件更新所有使用者都能马上同步新版本使用到新功能节省了订阅发布的投入。权限隔离有 Host 应用权限才能开发组件。
缺点
虽然 umi 已经能够集成代理了需要注意资源跨域问题但开发仍需要至少本地启两个项目。如果 Host 发挂了所有使用者的对应功能都受影响了。
三、最佳实践
简单介绍完两种大仓组件共享方式进入本文的正题。
权限管控复杂业务组件有着完整的功能内部往往会请求很多接口接口就伴随着权限分配的问题如何不申请组件主系统权限就能将组件集成到自己的系统中。埋点上报前端 APM 平台能够记录用户行为进行上报用于数据分析。不做任何处理会上报到组件主系统的应用中组件使用方无法在自己的应用监控中接受这部分埋点数据。平稳降级质量问题是重中之重作为复杂业务组件的使用方不关注组件具体业务逻辑的但是需要考虑系统的整体稳定性不受引入的组件所影响。
业务权限控制
首先要确认系统权限的结构大部分系统只用了系统权限校验不过一些系统还有服务端的权限校验。
系统权限原理401
通过系统唯一编码去匹配接口 Header 头中的系统码字段的方式去绑定权限组。如下图所示左图是用来配置系统菜单和分配角色的平台右图是没有匹配权限的接口就会报 401 状态码。 同样的也是根据系统码去请求菜单渲染菜单这些逻辑大部分都是 umi 样板间(plugin-proRoute/service/menu)里实现了可以在 src/.umi 下看到具体实现逻辑注入 Backstagecode 的逻辑还是需要自己在 Request 配置里实现。
业务权限原理432
一些系统除了系统权限外还保留业务权限校验此校验通过 Redis 匹配用户登陆态进行鉴权。没有匹配权限就会报 432 状态码。 其原理图如下可通过 getTicketAuth 接口将登陆态写入 Redis第一张图为 B 平台依赖 A 系统登陆。第二张图为改造后不再依赖 A 系统登陆原理还是比较好理解的就不展开了。 Request方案
根据权限原理可以知道权限管控问题的核心就是去考虑清楚什么时候该用什么系统码而我们塞系统码的任务都是由 Request 来做的。所以接下来我们先了解下常用的 Request 方案如果组件双方的 Request 方式不一致怎么解决。
proRequest通过内部 xx/umi-request引入。
已经停止维护了但是一些早期迁移的应用都还在使用 proRequest。App 入口或者 umi config 中配置 proRequest 属性。 //config.tsexport default defineConfig({// 其他配置proRequest: {},})//app.tsx
export const proRequest {prefix: proxyFix,envConfig: {},headers: {backstageCode,},successCodes: [200, 200],
};
Request 、基于 Request 的 crud 库通过 umijs/Max 引入。
目前比较常用的 Request有 crud 的方法新迁移的应用都使用这个 Request后续新应用也优先使用这个方法。
通过 Curd API 为 umi 的 Request 提供能力。
//utilsimport { AxiosRequestConfig, request } from umijs/max;
import initCrudApiClass from /utils/api;const CrudService initCrudApiClassAxiosRequestConfig(({ url, ...config }) request(url as string, config).then((res) res.data),
);CrudService.registerApiOptions(default, {mapping: {paramsType: {read: data,remove: data,queryList: data,queryPage: data,},},
});
通过请求配置拦截器去配置 Headers。
// app.tsxexport const request: RequestRuntimeConfig {baseURL: proxyFix,// 请求拦截器requestInterceptors: [(c: RequestConfig) {/** 一些配置 */Object.assign(c.headers, {/** 其他配置 */backstageCode,});return c;},],//响应拦截器responseInterceptors: [(res) {/** 一些配置 */return res;},],// 错误配置errorConfig: {errorHandler: (error) {return errorhandlerCallback(error as ResponseError);},},
};
Axios 、基于 Axios 的 crud 库源码依赖。
原生支持可以自适应 Request 配置。
功能集成在 utils 包中需要单独源码引入。
xxx/utils: workspace:*
通过请求配置拦截器去新增headers会自动获取backstageCode支持传递去修改
// src/app.tsximport { RuntimeConfig } from umijs/max;/*** param instance - axios 实例采用原生方式进行配置即可* param setOptions - 配置函数*/
export const configRequest: RuntimeConfig[configRequest] (instance, setOptions) {instance.interceptors.request.use((c) {// 默认携带了两个请求头accessToken、backstageCodeObject.assign(c.headers as object, {backstageCode});return c;});setOptions({errorResponseHandler(error) {return undefined;},});
};
组件双方的 Request 不一致怎么解决
系统 A 的 Reuqest 用的是 umijs/max 的系统 B 的 Request 用的是 ProRequest。
上面 2 个原理搞清楚了这个问题也就迎刃而解。
首先在业务组件中动态初始化 Request 配置不能用 app.tsx 的配置接收组件使用方传过来的系统码动态注册 Request 实例。
// 可以通过动态注册的方式初始化request使用UmiRequest.requestInit方法。//被用作远程组件时从远端拿到系统码通过api改写headers配置enum BackstageCode {APP_A: CODE_A,APP_B: CODE_B,APP_C: CODE_C}UmiRequest.requestInit({prefix: proxyFix,headers: {backstageCode: BackstageCode[props.code],},});然后在提供远程组件时把依赖提供出去使用方也不需要去安装其他版本的 Request。 // config.tsmf: {name: remote${mfName},library: { type: window, name: remote${mfName} },shared: {/** 其他依赖 */du/umi-request: {singleton: true,eager: true,}}}
权限管控最佳实践
下面的方案都是在跑的方案都能正常使用各有优劣按需使用。
方案一权限管控在组件提供方。
组件使用方不需要关心页面权限但访问页面的人需要申请 Host 系统的权限。
对组件提供者很友好对页面使用者很不友好需要申请多个系统权限。 方案二权限管控在组件使用方将接口配置在自己的天网子系统下改写系统码需要注意资源跨域问题。
访问页面的人对权限无感知但对开发者无论是组件使用方还是提供方都要做更多的处理。使用者需要关心页面权限并及时配置组件提供方要感知是哪个系统在用组件并把 Request 配置及时修改不然就走到组件主系统的权限里去了。 总结一句就是所有工作量都来到了组件维护者这边不过不用担心掌握上面说到的几点原理就能游刃有余地处理权限问题。 埋点上报
数据上报 SDK 也都支持系统码作为上报应用同理可在 monitor.monitorInit 注册实例时传递系统码作为参数。 支持使用方通过传递 Source 或者上报配置给组件。 Host 根据 Source 帮助 Guest 维护上报配置配置维护在 Host。Host 根据 Guest 的传递的自定义配置直接集成配置进行上报。也可通过接口调用维度去分析数据。 降级方式
对于发挂的应用做到自动降级。 FallbackComponent
前面说到 umi 支持配置远程组件降级方案将源码依赖的组件传给 SafeRemoteComponent 的 FallbackComponent 属性当远程组件挂载失败可以直接加载本地组件用作降级。
import { safeRemoteComponent } from umijs/max;
import { Spin } from poizon-design;
import { SharedOrderDetail } from xxx/order-detail
import React from react;const MFOrderDetail safeRemoteComponentReact.FCProps({moduleSpecifier: Demo/OrderDetail,/** 将源码依赖的组件 */fallbackComponent: SharedOrderDetail {...props} /,loadingElement: Spin/Spin,
});const OrderDetailModule: React.FCProps (props) MFOrderDetail key{props.name} {...props} /export default OrderDetailModule;
开关
对于远程组件挂载成功但是功能不能正常使用的可用下面的方法。
对于新功能未达到业务要求需要支持手动回退版本的降级。
使用前端配置平台开关开关开启走 MF 组件开关关闭走源码引入组件后续可用主干研发模式替代也可通过监控告警阈值去做到自动降级。 四、源码依赖结合MF模式
先源码引入后MF
在 _share/remote-components 目录下进行业务组件开发 之后在子应用 Expose 目录下通过源码引入的方式使用组件再暴露出去。用源码依赖的方式注入 MF 暴露的组件中可以适配自动降级方案代码片段如下。 先MF后源码引入
在子应用编写组件通过 Expose 方式提供远程组件使用 Webpack Plugin 复制文件或者 Pre-Commit Hooks 的方式将组件代码同步至 Share 目录下这样能够利用源码依赖不会自动更新版本的特性用作降级优先使用实时更新的 MF 远程组件降级使用源码引入的大仓组件而且这个方法也能够管控开发权限。 五、未来总结
未来
结合主干研发模式
新逻辑使用 MF老逻辑使用源码依赖。
import FWIns from /config/fw-config;const fw FWIns.init({branchName: feature-base-main-xxx-xxx,
});await fw.feature(async () {/** 新逻辑使用MF*/MFComponent /},async () {/** 老逻辑使用源码依赖*/SharedComponent /},
);
需要开发一些插件
为了提升开发效率需要一个将子应用的业务代码同步至是 Share 目录下的 WebPack 插件或者 Git Hooks。目前接入 MF 不管是 Host 还是 Guest 都需要在 umi config 配置一些东西这些配置大部分是重复的可以通过插件方式注入降低接入成本。源码依赖大文件对构建速度有影响需进一步比对构建产物进行优化。
总结
本文首先介绍了两种大仓下常用的共享组件方式进行优劣势的分析并对其大仓内外的用法进行比对。
源码引入开发便捷调试方便组件稳定性较高但对于复杂业务组件代码成本较高开发权限管控较难。Module Federation动态集成节省订阅发布成本权限隔离过于依赖组件 Host 稳定性调试较复杂。
然后对于共享复杂业务组件的一些注意事项提出解决方案。
权限管控组件权限可以管控在使用方也可以管控在提供方。如果管控在使用方可以通过系统码去动态初始化 Request 实例对于组件双方 Request 方式不一致可通过 MF Shared 依赖的方式解决。埋点上报同样的通过接收系统码去实例化监控 SDK不做任何处理就上报到组件得主系统的应用中。平稳降级可以使用 FallbackComponent 对加载远程组件失败的情况做到自动降级对于远程组件加载成功功能发挂了或者新功能未达到业务要求的支持手动回退版本的降级。可利用源码依赖不会自动更新版本的特性用作开关也可使用主干研发模式的能力去做降级。
最后聊了如何在大仓下基于源码依赖结合模块联邦的方式实现共享组件。
先源码引入后 MF在 Share 目录下开发业务代码在子应用 Expose 目录下通过源码引入使用组件再暴露出去供使用者使用。先 MF 后源码引入在子应用正常目录下开发组件通过 Expose 方式提供远程组件编译时将业务代码同步至 Share 目录下。组件使用者可编写开关优先使用 MF 组件再利用源码依赖不会自动更新版本的特性将源码依赖版本用作降级。
*文/昌禾
本文属得物技术原创更多精彩文章请看得物技术官网
未经得物技术许可严禁转载否则依法追究法律责任
