关于微前端技术选型与说明

关于微前端技术选型与说明

目前各产品均为单个独立产品，但后期若聚合起来成为矩阵，那如果通过单纯的柔和代码，将会打造一个巨石项目，维护成本极高，且后期迭代时会局限在单一框架内，扩展性也会很差，基于以上几点，我们基本确定后期需要使用微前端去重构项目

一、为什么我们需要微前端

1. 系统本身是需要集成和被集成的 一般有两种情况：

   • 旧的系统不能下，新的需求还在来。
     没有一家商业公司会同意工程师以单纯的技术升级的理由，直接下线一个有着一定用户的存量系统的。而你大概又不能简单通过 iframe 这种「靠谱的」手段完成新功能的接入，因为产品说需要「弹个框弹到中间」
   • 你的系统需要有一套支持动态插拔的机制。
     这个机制可以是一套精心设计的插件体系，但一旦出现接入应用或被接入应用年代够久远、改造成本过高的场景，可能后面还是会过渡到各种微前端的玩法。

2. 系统中的部件具备足够清晰的服务边界

   • 通过微前端手段划分服务边界，将复杂度隔离在不同的系统单元中，从而避免因熵增速度不一致带来的代码腐化的传染，以及研发节奏差异带来的工程协同上的问题。

二、 什么是微前端

微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。

微前端架构具备以下几个核心价值：

• 技术栈无关
  主框架不限制接入应用的技术栈，微应用具备完全自主权

• 独立开发、独立部署
  微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新

• 增量升级

  在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略

• 独立运行时
  每个微应用之间状态隔离，运行时状态不共享

三、微前端技术选型

技术方案	描述	技术栈	优点	缺点	单独构建 / 部署	构建速度	SPA 体验	项目侵入性	学习成本	通信难度
iframe	每个微应用独立开发部署，通过 iframe的方式将这些应用嵌入到父应用系统中	无限制	1. 技术栈无关，子应用独立构建部署 2. 实现简单，子应用之间自带沙箱，天然隔离，互不影响	体验差、路由无法记忆、页面适配困难、无法监控、依赖无法复用，兼容性等都具有局限性，资源开销巨大，通信困难	支持	正常	不支持	高	低	高
Nginx 路由转发	通过Nginx配置实现不同路径映射到不同应用	无限制	简单、快速、易配置	在切换应用时触发发页面刷新，通信不易	支持	正常	不支持	正常	低	高
Npm 集成	将微应用抽离成包的方式，发布Npm中，由父应用依赖的方式使用，构建时候集成进项目中	无限制	1. 编译阶段的应用，在项目运行阶段无需加载，体验流畅 2.开发与接入成本低，容易理解	1. 影响主应用编译速度和打包后的体积 2. 不支持动态下发，npm包更新后，需要重新更新包，主应用需要重新发布部署	不支持	慢	支持	高	高	正常
通用中心路由基座式	微应用可以使用不同技术栈；微应用之间完全独立，互不依赖。统一由基座工程进行管理，按照DOM节点的注册、挂载、卸载来完成。	无限制	子应用独立构建，用户体验好，可控性强，适应快速迭代	学习与实现的成本比较高，需要额外处理依赖复用	支持	正常	支持	高	高	正常
特定中心路由基座式	微应用业务线之间使用相同技术栈；基座工程和微应用可以单独开发单独部署；微应用有能力复用基座工程的公共基建。	统一技术栈	子应用独立构建，用户体验好，可控性强，适应快速迭代	学习与实现的成本比较高，需要额外处理依赖复用	支持	正常	支持	高	高	正常
webpack5 模块联邦	webpack5 模块联邦 去中心模式、脱离基座模式。每个应用是单独部署在各自的服务器，每个应用都可以引用其他应用，也能被其他应用所引用	统一技术栈	基于webpack5，无需引入新框架，学习成本低，像引入第三方库一样方便，各个应用的资源都可以相互共享应用间松耦合，各应用平行的关系	需要升级Webpack5技术栈必须保持一致改造旧项目难度大	支持	正常	支持	低	低	正常

市面框架对比：

• magic-microservices 一款基于 Web Components 的轻量级的微前端工厂函数。
• icestark 阿里出品，是一个面向大型系统的微前端解决方案
• single-spa 是一个将多个单页面应用聚合为一个整体应用的JavaScript 微前端框架
• qiankun 蚂蚁金服出品，基于 single-spa 在 single-spa 的基础上封装
• EMP YY出品，基于Webpack5 Module Federation 除了具备微前端的能力外，还实现了跨应用状态共享、跨框架组件调用的能力
• MicroApp 京东出品，一款基于WebComponent的思想，轻量、高效、功能强大的微前端框架

综合以上方案对比之后，我们确定采用了 qiankun 特定中心路由基座式的开发方案，原因如下：

• 保证技术栈统一 Vue、微应用之间完全独立，互不影响。
• 友好的“微前端方案“，与技术栈无关接入简单、像iframe一样简单
• 改造成本低，对现有工程侵入度、业务线迁移成本也较低。
• 和原有开发模式基本没有不同，开发人员学习成本较低。
• qiankun 的微前端有 3 年使用场景以及 Issue 问题解决积累，社区也比较活跃，在踩坑的路上更容易自救～

四、我们需要明确的

微前端并不是万能的”解药“，没有正确治理，所有的 codebase 的归宿都是”屎山”

1、微前端的运行时容器

• qiankun 所帮我们解决的这一块实际上是微前端的运行时容器，这是整个微前端工程化里面其中一个环节
• 从这个角度来讲 qiankun 不算是一个完整的微前端解决方案，而是微前端运行时容器的一个完整解决方案，当我们用了 qiankun 之后，我们几乎能解决所有的微前端运行时容器的问题，但是更多的一些涉及工程和平台的问题，则需要我们去思考与处理。
• 我们的版本管控、配置下发、监控发布，安全检测、等等这些怎么做，都不是 qiankun 作为一个库所能解答的

2、迁移成本

对于后期将Lims、IOT等平台接入时，我们很难做到零成本的接入，须要在开发的时候要预留足够的踩坑，魔改代码的时间。并且会因为前期项目不规范编码，所产生的各种奇怪的兼容性问题。

3、 技术栈的选择

• 微前端的核心不是多技术共存，而是分解复杂度，提升协作效率，支持灵活扩展，能把“一堆复杂的事情”变成“简单的一件事情”，但是也不是无脑使用的，每多一个技术栈都会增加：维护成本，兼容成本，资源开销成本，这些都会无形的拖累生产力。
• 基座应用与微应用之间，尽量使用相同的技术栈，相同的技术栈可以实现公共依赖库、UI库等抽离，减少资源开销，提升加载速度，最重要的是：“减少冲突的最好方式就是统一”，通过约束技术栈可以尽可能的减少项目之间的冲突，减少工作量与维护成本。（目前我们产品都是使用Vue所以可以很好的去避免冲突，但由于Lims、IOT、VMC等系统的架构与UI设计风格差距较大，后期在接入时，如何去平衡各项目之间兼容问题是一个大问题）

4、标准化才能提升生产力

• 混乱的项目会拖累生产效率，同时混乱的微前端也会加剧内耗，所以只有标准化才能提升生产力。
• 解决微前端的接入问题是最简单的，但是微前端接入后的：工程化，应用监控，应用规范，应用管理才是微前端中困难的地方，如果我们只是想简单的嵌入一个应用，推荐使用Iframe解决（目前IOT项目嵌入安全即是此方案）

5、qiankun 不支持 Vite

6、qiankun并不难

• 对于qiankun的学习不用很担心，因为 qiankun 真的很简单满打满算 10个API 都没有，但是难在创建基座项目与接入老项目时对各子应用的魔改
• [Link qiankun 官网文档]

五、微应用拆分规则

微应用的拆与合思考：拆的是系统复杂度，合的是系统复用度 核心原则：高内聚，低耦合

1. “尽量减少彼此的通信和依赖“，微前端的通信交互、链接跳转等操作所带来等成本其实是很大的，所以在拆分的时候尽量“完全独立，互不依赖”

2. 微应用的拆分的时候切忌“盲目细致拆分”，过度拆分会导致 “做的很牛逼，但是没有用的困局”，微应用的拆分并不是一步到位的，我们要根据实际情况逐步拆分。如果一开始不知道应该划分多细，可以先粗粒度划分，然后随着需求的发展，逐步拆分。

   • 如：现在有一个售后管理系统，我们按业务线拆分为：客服管理，库存管理，物流管理，未来客服管理需求功能持续庞大再拆解为：智能客服、电话客服、在线客服。而这些客服，又可以嵌入LIMS等相关项目使用。

3. 在拆分的时候我们应该尽量考虑未来场景：渐变式技术栈迁移，前端应用聚合、多系统业务复用，如何做业务解耦和代码复用。

4. 应用之间应该尽量解耦，子应用的事情就应该由子应用来做。

   • 如：子应用的一些标识，如：路由前缀，应用名称，根节点容器名称，依赖库的使用
   • 需要明确什么是子应用应该维护的，什么是父应用应该维护的，如果什么资源都一股脑的使用父应用下发，则会导致应用之间耦合严重。