基于 qiankun 的微前端实践

前言

微前端（Micro-Frontends）是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。

微前端并不是前端领域的新概念。早期希望前端工程能够像后台的微服务一样，项目分开自治，核心的诉求是：

1、兼容不同技术栈

2、将项目看作页面、组件，能够复用到不同的系统中

早期比较成熟的 single-spa，从早期 React 的现代框架组件生命周期中获得灵感，将生命周期应用于这个应用程序，即将整个页面作为组件。

后来蚂蚁金融团队孵化了基于 single-spa 的 qiankun 架构，将微前端进一步的深耕，目标直指巨石应用业务难题，旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用 (Frontend Monolith) 后，随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。

本人在深入实践微前端之后，深感 qiankun 受制于前端架构的定位，无法使用 Nodejs 等能力快速解决快速发布，构建，管理的困境，因此在此基础上做了一定程度的 APAAS 探索，将本文的项目作为 APAAS 应用快速集成到其他业务系统。

qiankun 介绍

首先基于作者自己的思考，给大家梳理下 qiankun 微前端的渲染流程，方便不了解微前端的同学有个大体的认识。

假如你不了解微前端的话，对于这个新事物的学习和探索，一般是按照 5Ws 的学习规律来学习：

1.Who is it about?
2.What happened?
3.When did it take place?
4.Where did it take place?
5.Why did it happen?

本文也按照类似的方式一个具体的案例去梳理 qiankun 的核心概念。

本文有一个业务系统 A，希望集成业务系统 B 的_欢迎卡片配置_功能页面。

那么 who 包含 qiankun 客户端、主应用 A、微应用 B 三部分，三者协作完成了微前端的设计。从产品使用的角度来看，第一步则是注册路由，确定微前端启动的时机和启动渲染的内容（when 和 where）。

import { registerMicroApps, start } from'qiankun';

registerMicroApps([{name: 'smart-contact-cms-index', // app name registeredentry: '//localhost:7100',container: '#yourContainer',activeRule: '/yourActiveRule',},
]);

start(); 

上面的实例十分简单，通过 name 来作为微应用 B 的唯一标识， entry 作为微应用 B 的资源加载地址。当路由映射到 ‘/yourActiveRule’ 时，则请求微应用 B 的页面资源地址，解析其中的 JS 和 CSS 资源，将微应用 B 的页面渲染到 id 为 #yourContainer 的 DOM 节点。

const packageName = require('./package.json').name;

module.exports = {output: {library: `${packageName}-[name]`,libraryTarget: 'umd',jsonpFunction: `webpackJsonp_${packageName}`,},
}; 

上面是一段微应用 webpack 的配置，library 就是注册路由时的唯一标识 name 了。这里也十分好理解为啥 qiankun 要在构建资源时给 js 增加标识。

qiankun 客户端 entry 配置的 HTML 页面资源的地址，拉取到页面资源之后劫持 HTML 解析，自行构建 Http 请求去加载 JS 文件。很明显页面中肯定不止一段 JS 代码，就需要标识来标识那一段的入口 JS 代码了。