微前端：化解前端开发困境之道

李成泽
23 阅读6分钟

一、面临的痛点

（一）巨石项目之困

项目随着业务拓展，代码量迅猛增长，演变成巨石项目。这种项目犹如一座庞大且复杂的 “巨石”，牵一发而动全身。开发新功能或修改既有功能时，开发人员不得不深入钻研整个庞大的代码库，开发效率大幅降低，同时出错风险显著提高。

（二）技术栈混杂带来的高维护成本

在企业的发展进程中，不同阶段或不同团队基于各种因素，选用了各式各样的前端技术栈。多种技术栈共存的局面，使得项目维护的复杂度直线上升。开发人员不仅需要掌握多种技术，增加了学习成本，而且团队协作难度加大，不同技术栈之间的整合与兼容更是困难重重。

（三）复用层的挑战

在传统架构里，复用层的设计与维护常常不尽如人意。一方面，复用组件可能因与整体项目耦合度过高，难以在其他项目或模块中顺利复用；另一方面，复用层的更新与优化，可能会对依赖它的各个部分产生难以预料的影响，导致维护成本攀升，复用效果大打折扣。

二、解决方案

（一）iframe 实现

iframe 提供了一种简单直观的方式，能够将不同的子应用嵌入到主页面。每个 iframe 宛如一个独立的窗口，其中的子应用可独立进行开发与部署，具备一定程度的隔离性。不过，该方式也存在一些弊端，比如 iframe 之间的通信相对复杂，样式隔离并非十全十美，还可能出现滚动条等兼容性问题。

以下是一个简单的使用 iframe 嵌入子应用的 HTML 示例：

html

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF - 8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Using iframe for Micro - Frontend</title>
</head>

<body>
    <h1>Main Application with iframe</h1>
    <iframe src="sub - application.html" width="800" height="600"></iframe>
</body>

</html>

（二）框架整合方案

诸如 single - spa 和 qiankun 这类框架，为微前端提供了更为完善的解决方案。它们能够将采用不同技术栈开发的子项目、子应用接入到统一平台。借助这些框架，主应用能够更有效地管理子应用的加载、卸载、路由等操作，达成不同技术栈子应用的无缝集成。

以 single - spa 为例，以下是一个简单的 single - spa 主应用注册子应用的 JavaScript 示例（假设使用 React 技术栈）：

javascript

import singleSpa from'single - spa';
import { registerApplication, start } from'single - spa';

// 注册 React 子应用
registerApplication({
    name: '@single - spa/react - app',
    app: () => import('@single - spa/react - app'),
    activeWhen: ['/react - app']
});

start();

（三）微前端体系设计

从宏观层面规划微前端体系，涵盖明确各个子应用的职责边界，精心设计合理的通信机制，以及妥善解决子应用之间的样式隔离与集成等问题。通过全面系统的体系设计，保障微前端架构高效、稳定地运行。

例如，在微前端体系中，可以通过自定义事件来实现子应用间的通信。以下是一个简单的自定义事件通信示例（以 JavaScript 原生代码为例）：

javascript

// 子应用 A 触发事件
const event = new CustomEvent('subAppAToSubAppBEvent', {
    detail: {
        message: 'Hello from Sub - App A'
    }
});
document.dispatchEvent(event);

// 子应用 B 监听事件
document.addEventListener('subAppAToSubAppBEvent', function (e) {
    console.log('Received message from Sub - App A:', e.detail.message);
});

三、核心内容

（一）微前端架构的关键要素

  1. 主应用：承担着整体布局的规划任务，犹如城市的规划师，决定各个区域（子应用）的位置与展示方式。同时，主应用负责管理路由，如同交通指挥员，引导用户在不同子应用之间顺畅切换。此外，主应用还肩负着子应用的加载工作，确保子应用在需要的时候能及时呈现在用户面前。
  2. 子应用：每个子应用专注于一个特定模块，像是城市中各司其职的功能区。它们拥有独立的视图，为用户呈现独特的界面；具备自己的路由，以便在子应用内部实现页面跳转；同时拥有独立的状态，保证自身业务逻辑的完整性与独立性。
  3. 应用之间的通信：子应用之间需要一套有效的通信机制，就像城市中不同功能区之间的交通网络，确保信息能够顺畅流通。这有助于实现子应用之间的协同工作，比如一个子应用中的数据更新，能够及时通知相关的其他子应用进行相应调整。
  4. 隔离与集成：要确保不同子应用之间的样式相互隔离，避免样式冲突，如同每个功能区都有自己独特的建筑风格，互不干扰。同时，又要实现子应用之间的有机集成，使整个微前端应用在用户看来是一个统一、协调的整体。

（二）微前端的技术方案

  1. single - spa

    • 多框架支持 / 框架无关性：如同一个包容万象的舞台，single - spa 支持运行多个前端框架，能够将不同技术栈的应用集成到同一个大应用中。无论子应用是基于 React、Vue 还是 Angular 开发，都能在 single - spa 的框架下和谐共处。
    • 灵活性和扩展性：它提供了一套完整的生命周期管理机制，好比为每个子应用配备了一个专属的日程表。开发人员可以在应用加载、渲染、卸载等各个阶段插入自定义逻辑，根据项目需求灵活定制子应用的行为。
    • 应用集成管理：通过注册多个微应用，single - spa 能够像智能管家一样，按需加载和卸载子应用，避免资源的无端浪费。只有在用户真正需要某个子应用时，才将其加载并投入使用，提升了应用的整体性能。
    • 活跃的社区和文档：作为一个活跃的开源项目，single - spa 拥有丰富的文档资源，如同详尽的使用手册，为开发人员提供了全面的指导。同时，活跃的社区为开发人员搭建了交流平台，遇到问题时能够迅速获得帮助与建议。

  2. qiankun：qiankun 同样是一款优秀的微前端框架，它基于 single - spa 进行了进一步的封装与拓展，针对国内开发者的使用习惯和常见业务场景，提供了更为便捷、高效的微前端解决方案。它在继承 single - spa 诸多优点的基础上，对应用的加载、通信、样式隔离等方面进行了优化，使得微前端架构的搭建与维护更加简单和直观 ，帮助开发团队更快速地实现不同技术栈子应用的整合与管理。

avatar
文章
阅读
粉丝