背景

目前经过一系列调研，大体总结出主流微前端方案大体分为

• 基座模式：通过搭建基座、配置中心来管理子应用
  • 统一框架约定方案 如《微前端在美团外卖的实践背景》
    • 统一业务框架 REACT
    • 统一配置信息
    • 建立基座工程，用于管理子工程的路由切换、注册子工程的路由和全局Store层、提供全局库和复用层
  • 问题点
    • 通过中心化配置的方式注册到基座工程进行加载
    • 项目改造存在一定成本
    • 代码复用性以及子应用调用的易用性存在疑虑
  • 多框架并存方案 如 Single-spa
    • 多框架并存、并且实现互不干扰
    • 创建根应用程序，以动态模块加载的方式加载子应用。
    • 独立发布的子应用提供一个活动 url 资源地址，随后在根应用中借助模块加载器（如 SystemJS）动态加载。
  • 问题点
    • 对于React 深度定制项目来说，无法做到状态管理很好的传递
    • 对于非标准的AMD、UMD、SystemJS 等加载方式的库会存在依赖问题(需要针对性改造)
    • 多框架实现体积过大以及存在一定的调试成本
• 自组织模式：通过约定进行互调
  • monorepo + npm包组合
  • amd,cmd or umd 等直接引用
  • webpack external
  • 问题点
    • 一个比较有意思对Module Federation分析的文章 《Webpack 新功能 Module Federation 深入解析》 ,可以解答大部分目前以 上自组织模式 遇到的问题

    • 本文主要介绍EMP落地，概念可以通过其他相关文章进行了解

思考

目前业务中台在业务推进过程中遇到比较多的问题是

• 如何更好的减少代码冗余
• 如何更高效的提升开发效率
• 如何减少通用资源更新所带来的影响力度
• 项目与项目之间如何更好下沉业务组件
• 可复用库与组件之间如何形成约定类型或者文档，让调用方更加高效完成任务，减少沟通成本

统一技术栈

从开发初期我们约定了中台的统一框架：React & hook + React-dom + React-router-dom + Mobx + Typescript，减少后期的额外框架消耗以及维护成本；
复用组件、工具库之间使用lerna + monorepo 方式下沉项目组件，通过npm方式安装到独立业务

从项目过程中遇到形形式式的包管理问题，以及代码重复打包，包信息更新不能及时等等问题

尝试使用 single-spa 落地微前端

• 项目推进中期上微前端需要对项目源码进行改造
• 项目深度依赖mobx 进行状态管理，依赖react-router-dom 做路由管理,在通用组件调用的同时不能用路由包裹传递
• 依赖single-spa 对非 umd 调用库支持不足需要进行一定改造

自组织模式

自组织模式：应用之间是平等的，不存在相互管理的模式。设计难度大，不方便实施，但是通用度高。
从目前主流开发模式下是很难完成 自组织模式的微前端落地，直到 Module Federation的出现

方案设计

• 组件联邦机制方式代替中心化，无需基站以及配置中心介入
• 以ts类型的方式进行约定
• 统一React框架、让组件中可以深度定制与引用(无需更改原有业务代码)
• 建立完善脚手架和类型同步方案，让开发部署得到约束以及自动化完成

基站式微前端方案 VS EMP微前端方案

EMP工作流

• @efox/emp-cli 脚手架主要作用是
  • 调试
  • 构建、代码分析
  • 生成项目所需类型
  • 通过远程项目类型
• @efox/emp-tune-dts-plugin ts相关类型操作
  • 1.在插件生命周期compiler.hooks.afterEmit.tap 执行生成类型文件
  • 2.类型文件生成后进行修正类型文件
• @efox/emp-tsconfig 针对ts与微前端定制配置

用例代码展示

以 antd + react-router-dom 为例通过远程方式引入外部定义好的骨架应用

//base->App.tsx
const App = ({layout, routes, stores}: RouterCompType) => (
    <StoreProvider stores={stores}>
      <RouterComp layout={layout} routes={routes || []} />
    </StoreProvider>
)
复制代码

当前应用引入外部库

//app->bootstrap.tsx
import EMPApp from '@emp-antd/base/App'
import stores from 'src/stores'
const App = () => <EMPApp routes={routes} stores={stores} />
复制代码

远程同步ts类型代码提示

EMP基站设计模型

EMP基站主要作用是组织和共享通用库，而非统一入口、统一配置

说明

框架级基站（以框架/技术栈为基础，为子基站提供框架级别的布局，方法，组件）

• 项目级基站（以业务项目为基础，为项目提供业务组件，方法，路由，配置等）
• • 项目内容

优点：

1. 支持多框架并存，并且实现互不干扰
2. 可根据项目级别定义多层级别基站
3. 项目级别基站相对独立
4. 相同中台基站下的项目可快速开发移植
5. 项目间可共享独立组件

EMP部署

多版本问题

在开发过程中会遇到公共库的不断迭代以及项目使用的兼容性问题

1. 基站部署：使用Docker的Volume方案，发布前，通过自定义Dockerfile，将每个版本内容都放在Volume中，然后从Volume拉取数据，最后进行发布。
2. Module Federation 在webpack5 beta-17后支持定义版本，不同入口可以应用可以定制自己的引用库版本如 React:16.13.1,然后从基站库相应版本里调用相应的组件

域名规范

域名规范遵循 emp-antd-[业务名称]-[环境].[一级域名].com。遵循这个规范，通过域名就能知道当前技术栈以及业务类型。

总结

从实战过程中已经可以满足目前业务中台的微前端需求，调用以及协同方面也得到更好的推进

• 1、从根本上摆脱了框架的束缚
• 2、在最轻量级的基础上进行微前端化，并且大量保留了原来代码的业务逻辑
• 3、最大化减少代码的冗余和更高的代码复用
• 4、落地应用不受入口限制，大大的提升了应用的定制如多主题等诉求

作者

Ken.Xu

D.Ragon

Abel

Benny Shi

Jiguli