Skip to main content

微前端

微前端​

微前端这个名词，是 2016 年底在 ThoughtWorks Technology Radar 被提出，这个概念和后端的微服务概念相对应。

微服务允许后端体系结构通过松散耦合的代码库进行扩展，每个代码库负责自己的业务逻辑，并公开API，每个API均可独立部署，并且各自由不同的团队拥有和维护。

现代的前端应用的发展趋势正在变得越来越富功能化，富交互化，也就是SPA(单页面应用)。这样越来越复杂的单体前端应用，背后的后端应用则是数量庞大的微服务集群。被一个团队维护的前端项目，随着时间推进，会变得越来越庞大，越来越难以维护，这种应用称为巨石单体应用。

在微服务的架构中，后台的服务已经按照业务进行了分离，而前端仍然是一个单体构建，通过网关来调用不同的后台服务。这与微服务的思想是相违背的，这也就造成了后端团队是按照业务分割的，而前端仍然是一个整体。微前端可以有效地改进这一点。

前端架构经历了从单体，到前后端分离，再到微服务，最终发展到现在的微前端：

Micro

核心价值​

  • 微前端是一个大项目中的小应用的开发方式，其核心是微应用。
  • 将一个复合型项目拆分成小应用进行开发，最后将所有的小应用整合成一个项目。
  • 在项目整体框架下，可以独立开发、打包、部署、发布的微应用。
  • 独立应用的调试和部署对整个项目的运行影响比较小。
  • 应用的独立性强，复用性也就强，且技术栈无限制。

解决的问题​

  • 优化功能开发

微前端和其他架构最显著的区别在于团队结构。在传统的项目架构中，功能的完成时间取决于最后一个团队的完成时间。

在微前端的模型中，所有参与创建功能的人员都在同一个团队中，虽然需要完成的工作总量是相同的，但是团队内的沟通会更加的快速，可能不需要跨部门，也不需要那么正式，迭代会进行的更快。不必等待其他团队，也不必讨论任务的优先级。

优化功能开发
  • 减少巨石应用

有了微前端，包括前端在内的应用程序被分割成更小的垂直系统。每个团队都有自己的一小块前端。这与一个前端巨石应用相比，构建和维护一个较小的前端更具有优势。

  • 快速适应变化

处理遗留系统在前端也日益成为一个较普遍的话题。开发人员要花费大量时间重构遗留代码和执行迁移策略，这将花费大量精力。

技术是在不断发展的，当构建特定规模的应用程序，并希望保持竞争力时，如果新技术能为团队提供价值，那么能够自由的转向新技术，并且还能将试错的成本保持最小，这至关重要。

如果使用微前端，那么就意味着不需要每隔几年重写整个前端项目以使用当前流行的技术，微前端的每一块应用都可以本地决策。甚至可以先拿出一个应用模块进行试错，然后直接整合到现有的平台上即可。

  • 自治性强

微服务架构的核心优势之一是自治，微前端也是这样。

如果某一个应用团队需要更新某个新的功能，这个功能可能甚至导致整个JS框架的升级。在微前端框架中，完全不必纠结，直接处理就行。但是如果是以前的巨石应用，那就是一个头痛的大问题了，不知道需要协调多少部门，多少人员，多少代码。

团队之间的沟通是昂贵的，当想要更改别人的一段代码，即使只是一个工具库，也需要通知所有人，等待他们的反馈，也许还要讨论其他的选项。参与的人越多，处理起来越麻烦。

开发方式​

微前端主要有两种开发方式，即多页面应用和单页面应用。

MPA​

多页面应用 (Multi-Page Application, MPA) 是一种传统的 Web 开发架构模式，每个页面都有一个独立的 HTML 文件，页面之间的跳转通常需要进行完整的刷新。

SPA​

单页面应用 (Single Page Application, SPA) 是一种现代 Web 应用架构模式，通过动态加载内容和资源，在单一的 HTML 页面内实现不同的页面功能和内容切换，而无需刷新整个页面。

实现方式​

每个团队的前端页面，最终都需要整合集成，将所有内容组装到一起。很多时候，也并不是每个团队提供的都是一整个页面，可能是一个页面，也可能是一个或者多个页面的片段，根据具体的业务需求来整合集成。

这种前端的集成，大体分为三类：路由、组合和通信。

Micro Intergated

可以通过路由，直接跳转到其他子应用，也可以把每一个子应用看成一个 SPA 的单页应用，然后进行路由单页跳转。

如果页面有一些比较复杂的业务，需要应用之间传递信息，然后获取不同的页面效果，那么就需要页面之间的通信。

解决方案​

目前已有一些微前端架构的解决方案：

  • iframe。

通过 iframe 实现微前端是一种经典的方式，适用于对隔离性要求高且对性能要求不高的场景。随着现代微前端技术的发展，iframe 常常被其他实现方式 (如 Web Components 或自定义路由系统) 取代，但在特定场景下仍然是有效且易用的解决方案。

  • single-spa。

single-spa 既是解决方案又是框架，但是其只实现了路由和应用入口，其他如环境隔离、样式隔离等问题都没有解决。

  • Web Components。

通过 Web Components 提供的自定义元素 (Custom Elements)、影子 DOM (Shadow DOM)和模板 (Template) 功能，将每个子应用封装为独立的组件。主应用动态加载和注册子应用组件，使其具有独立的样式和作用域隔离，同时通过属性和事件实现父子应用的数据通信，从而实现模块化和隔离化的微前端架构。

  • Webpack 模块联邦。

Webpack Module Federation 是 Webpack 5 引入的一项功能，用于在多个独立的项目间共享模块。它允许应用在运行时动态加载远程代码，并与本地代码一起无缝运行，实现真正的微前端架构。

框架​

qiankun​

qiankun 是基于 single-spa 的二次开发，实现了 CSS 隔离、路由状态、预加载、JS隔离等功能。

MicroApp​

基于 Web Components的微前端实现，将所有功能都封装到一个类 Web Components 组件中，从而实现在基座应用中嵌入一行代码即可渲染一个微前端应用，提供了JS沙箱、样式隔离、元素隔离、路由隔离、预加载、数据通信等一系列完善的功能。

无界​

无界 是基于 Web Components 容器和 iframe 沙箱的微前端实现。通过 Web Components 进行页面样式的隔离，通过 iframe 的天然优势进行 JS 隔离。

总结​

理想的的微前端是微组件或微模块级别的共享，但就目前而言实现方式而言，其本质都是页面的整合和集成，通过一个基座应用管理子应用，远达不到微模块的水平。

Last updated on