关于webpack5:全面敏捷模式下的微前端方案设计篇

这里是忽然怠惰的 Zhuo，继续更新文档中。

本文只波及到 module-federation 微前端计划的设计层面分享，对于具体实现，能够参考写的简略例子；所有的设计图自取，如果对你有一些启发，请点个 star

背景

团队从瀑布流模式转变为麻利模式，将整个我的项目团队划分为多个小组并行开发，多小组同时降级的分支解决和代码抵触之类的问题频繁呈现。于是接到了组内一个技术需要：《模块反对独自降级和部署》。目前，咱们开发和保护代码的现状：

• 一个仓库蕴含了所有的业务组的前端代码
• 只能一起打包出一个整包，也无奈独自部署
• 后端已实现微服务的拆分

如上所述，尽管个别场景通过 git 多分支治理能解决【独立开发】和【公布】的问题，然而一遇到【多团队同时公布】的场景就让人头疼了：

• 须要拉上各个团队的负责人，重复确认当天是否失常上线
• 上线分支排列组合（release-a、release-b、release-ab）预防某一个团队突发问题不上线
• 测试工作量减少：本来只有验收一个代码包，当初还要验证多个代码包性能（> 1）

看一眼分支模型：

既然提出了已有问题，为了解决这些问题，咱们意识到和后端一样将整个我的项目拆分成若干的子利用，将它们也变成微服务，不就能够解决目前的窘境了吗？自然而然咱们就想到了“微前端”的概念。有指标，就好发力了，咱们参考了业务优良计划，同时联合了本身理论状况，最终决定用 webpack5 module federation 个性来进行微前端的实际与落地。

需要剖析

内部需要

1. 拆合成耦
2. 独自打包，独立部署
3. 不影响当初的用户体验

外部需要

1. 不影响开发体验
2. 计划对原业务代码侵入性最低
3. 学习成本低
4. 对立技术栈
5. 前端灰度公布

计划抉择

计划：

1. 利用微服务化，诸如 qiankun2

   • 存在性能问题，且沙箱逃逸问题难解决，放弃

2. 微件化：通过组合多个独立利用、组件来构建一个单体利用，例如 Module Federation

   • 在接入第三方利用上存在的问题比拟大，然而对于咱们想要达到【独立降级】的成果来说，此短板能够承受

3. 联合 Web Components 构建，例如 micro-app

   • 在解决沙箱的性能问题和逃逸问题上尽管比计划 1 更优良，但这两个问题呈现还是难解决，且目前官网保护的频率及未有稳固版本，放弃

4. MPA+ 路由散发

   • 相当将本来的一个零碎拆成多个零碎，体验上无奈承受，放弃

5. MPA + iframe

   • iframe 在性能和用户体验上的问题也是无奈承受，放弃

6. 纯 Web Component 进行构建利用

   • 须要用一个新的根底计划将整个我的项目的代码重构，工作量上无奈承受，放弃

最终采纳计划 2：module federation。

微前端实际

通过计划的剖析以及我的项目理论状况的梳理，咱们确定了微前端的整体计划，输入组件图，如下图所示：

能够看到，整个计划非常简单：依照开发小组进行路由级别的拆分，整个零碎可分为两个局部：

• 基座利用：用于治理子利用的路由切换、注册子利用的路由和全局 Store 层、提供全局库和复用层
• 子利用：用于开发子利用业务代码，一个子利用对应一个开发小组，并且治理本人的路由、语言包、埋点、Store

基座利用和子利用分割起来的桥梁则是 入口文件：remoteEntry.js。这能够让基座利用精确地发现子利用资源的门路从而进行加载。

因为依赖了 remoteEntry.js 进行关联，所以这个文件不会加 hash 后缀，这就要求对该命名的文件全副 设置协商缓存，不再是强缓存。

微前端下的架构变动

在整个计划的革新之后，咱们的我的项目整体的架构变成了如下图展现的样子：

前端侧的代码依照小组个性拆分成若干个子利用：

• 每个子利用只领有本人相干的代码，基座利用能够看成比拟非凡的子利用，它提供工程能力，最好不要有业务代码
• 将利用代码划分到 packages/apps文件下，通过 monorepo + pnpm 进行治理依赖
• 所有的文件夹进行独自的打包构建，搭配 Docker + Kubernetes 构建成独自的容器（红色局部内所有的子利用都是独自的容器）变成真正的微服务
• 通过 ingressroute + nginx 加载不同容器之间的子利用资源

以上的变动，让拆分进去的子利用可能独立开发 – 保护 – 公布之外，还使得咱们前端利用降级时的 灰度 – 部署 – 回滚 操作变得更加简略、疾速。

部署计划

在达成独立部署上线的指标之后，所有的子利用都是独立的，公布不须要依赖于任何利用。只须要确认开发批改了哪些子利用的代码，那么就降级对应的子利用即可。

具体流程：

1. 开发批改了 A 利用的代码，上库
2. 打包平台（千流，公司自建）辨认到具体变更的代码门路，对 A 利用进行打包，生成镜像容器、版本号等，推送到镜像平台
3. 降级对应服务

尽管步骤是这些，然而在开发人员这里，他只须要提供本次降级的版本号（1.0.xxx）即可，背地流程不须要深刻理解。

回滚计划

得益于 Docker + Kubernets，前端的回滚只须要执行一条 helm 命令即可。除此没有其余的内容。

总结

总的来说，咱们实现了以下的指标：

• [x] 代码拆合成耦
• [x] 独自打包，独立部署
• [x] 不影响当初的用户体验：没有引入其余类库，也没有应用 iframe
• [x] 不影响开发体验：反对热更新
• [x] 计划对原业务代码侵入性最低：外围工作量在代码拆分，webpack 的配置并没有多少工作量
• [x] 学习成本低：根本没有学习老本
• [x] 对立技术栈：原本就是一个我的项目
• [x] 前端灰度公布

学习链接

感激以下文章的作者 / 团队分享的文章，提供了很好的思路。

1. Module federation 原理钻研
2. Revolutionizing Micro Frontends with Webpack 5, Module Federation and Bit
3. How to Build a Micro Frontend with Webpack’s Module Federation Plugin
4. Webpack Module Federation
5. Module Federation Examples
6. https://medium.com/@A__G__B/i…
7. EMP- 面向未来微前端计划正式开源了！
8. micro-app 介绍
9. 可能是你见过最欠缺的微前端解决方案
10. 字节跳动是如何落地微前端的
11. 微前端在美团外卖的实际

都看到这里了，帮忙点个赞呗~