来源：得物技术

• 对于共享复杂业务组件，如何做好权限控制、数据埋点以及平稳降级。
• 如何规避 MF 远程组件的稳定性风险、解决组件源码依赖发布更新等问题，保证稳定性的同时，降低本地开发门槛。

这种方式能解决大仓下大部分组件复用的需求，代码复用的便利性也是大家愿意走进大仓的原因之一。

为了区分其他组件，可以在 /业务域/_share/remote-components 目录下开发远程组件。dx 是内部大仓的 CLI，cc 命令可以快速生成一个组件模板。

// 区分普通组件，新增一个remote-components组件目录cd remote-components && dx cc order-detail

依赖注入、源码引用

• package.json 引入依赖，配置 workspace:*，构建时动态去取_share/目录下最新版本的组件资源。若从稳定性考虑，也可以固定版本号。

/** package.json */"@demo/order-detail": "workspace:*"
/** 业务组件 */import OrderDetail from '@demo/order-detail'
<OrderDetail {...props} />

• 开发便捷，本地只需启一个应用就能开发，调试方便。
• 若组件迭代发挂了，只会影响当前发布的应用，不影响其他使用方，能正常使用该组件，对普通组件和一些对新功能不敏感的业务组件来说是合适的。

• 对新功能敏感度较高的复杂业务组件而言，使用方如果要更新版本需要重新拉代码构建部署，信息同步、发布投入成本较高。
• 由于大仓特性，代码变更权限很难做到管控，非组件提供方也能修改代码，组件 Owner 需要严格 CR 变更。

umi 4.0.48 + 支持在 umi config 使用 MF 配置来使用 MF 的功能。umi4 可以直接从@umijs/max导出defineConfig，也可以使用@umijs/plugins/dist/mf插件去支持配置 MF 属性，本质也是对 WebPack Plugin 的封装，属性是类似的。不一样的点在于 Host 不再需要通过配置 Exposes 将组件一个个的暴露出去，而是约定暴露 Exposes 目录下的组件，十分方便。

/** 方法一：使用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,  },});

之前

现在

 //config.ts const 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 平台能够记录用户行为进行上报，用于数据分析。不做任何处理会上报到组件主系统的应用中，组件使用方无法在自己的应用监控中接受这部分埋点数据。
• 平稳降级：质量问题是重中之重，作为复杂业务组件的使用方不关注组件具体业务逻辑的，但是需要考虑系统的整体稳定性不受引入的组件所影响。

首先要确认系统权限的结构，大部分系统只用了系统权限校验，不过一些系统还有服务端的权限校验。

• proRequest，通过内部 @xx/umi-request引入。

  //config.ts  export default defineConfig({      // 其他配置      proRequest: {},  })
  //app.tsxexport const proRequest = {  prefix: proxyFix,  envConfig: {},  headers: {    backstageCode,  },  successCodes: [200, '200'],};

• Request 、基于 Request 的 crud 库，通过 @umijs/Max 引入。

//utils
import { AxiosRequestConfig, request } from '@umijs/max';import initCrudApiClass from '@/utils/api';
const CrudService = initCrudApiClass<AxiosRequestConfig>(({ url, ...config }) =>  request(url as string, config).then((res) => res.data),);
CrudService.registerApiOptions('default', {  mapping: {    paramsType: {      read: 'data',      remove: 'data',      queryList: 'data',      queryPage: 'data',    },  },});

// app.tsx
export 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 库，源码依赖。

"@xxx/utils": "workspace:*"通过请求配置拦截器去新增headers，会自动获取backstageCode，支持传递去修改// src/app.tsx
import { RuntimeConfig } from '@umijs/max';
/** * @param instance - axios 实例，采用原生方式进行配置即可 * @param setOptions - 配置函数 */export const configRequest: RuntimeConfig['configRequest'] = (instance, setOptions) => {  instance.interceptors.request.use((c) => {    // 默认携带了两个请求头：accessToken、backstageCode    Object.assign(c.headers as object, {      backstageCode，    });
    return c;  });
  setOptions({    errorResponseHandler(error) {      return undefined;    },  });};

系统 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.ts mf: {    name: `remote${mfName}`,    library: { type: "window", name: `remote${mfName}` },    shared: {      /** 其他依赖 */      '@du/umi-request': {        singleton: true,        eager: true,      }    } }

• 方案二：权限管控在组件使用方，将接口配置在自己的天网子系统下，改写系统码，需要注意资源跨域问题。

数据上报 SDK 也都支持系统码作为上报应用，同理可在 monitor.monitorInit 注册实例时传递系统码作为参数。

• 支持使用方通过传递 Source 或者上报配置给组件。
• Host 根据 Source 帮助 Guest 维护上报配置，配置维护在 Host。
• Host 根据 Guest 的传递的自定义配置，直接集成配置进行上报。
• 也可通过接口调用维度去分析数据。

• 对于发挂的应用做到自动降级。

• FallbackComponent

import { safeRemoteComponent } from '@umijs/max';import { Spin } from 'poizon-design';import { SharedOrderDetail } from '@xxx/order-detail'import React from 'react';
const MFOrderDetail = safeRemoteComponent<React.FC<Props>>({  moduleSpecifier: 'Demo/OrderDetail',  /** 将源码依赖的组件 */ fallbackComponent: <SharedOrderDetail {...props} />,  loadingElement: <Spin></Spin>,});
const OrderDetailModule: React.FC<Props> = (props) => <MFOrderDetail key={props.name} {...props} />
export default OrderDetailModule;

• 开关

• 对于新功能未达到业务要求需要支持手动回退版本的降级。

在 _share/remote-components 目录下进行业务组件开发， 之后在子应用 Expose 目录下通过源码引入的方式使用组件，再暴露出去。用源码依赖的方式注入 MF 暴露的组件中，可以适配自动降级方案，代码片段如下。

在子应用编写组件，通过 Expose 方式提供远程组件，使用 Webpack Plugin 复制文件或者 Pre-Commit Hooks 的方式将组件代码同步至 Share 目录下，这样能够利用源码依赖不会自动更新版本的特性用作降级，优先使用实时更新的 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 组件，再利用源码依赖不会自动更新版本的特性将源码依赖版本用作降级。