前端传递过来的json有转义_适用于既有大型MPA项目的“微前端”方案

点击关注“有赞coder”

获取更多技术干货哦～

作者：杨超 团队：业务中台

一、背景

对于大多数有点历史的复杂前端项目来说，应该已经经历了从刀耕火种的大型单仓库构建到多业务应用独立开发部署的过程。当用户访问页面时，由 nigix等负责根据路由分发到不同的业务应用，由各个业务应用完成资源的组装后返回给浏览器。这种情况下，开发、构建已经可以各自独立进行，在这样一套健全体系下的开发者们，想必是很幸福的。

以有赞微商城后台为例，针对B端业务，我们就已经划分了数十个的应用，可独立进行开发、打包和部署。如下图所示：

但在业务日趋复杂，页面依赖资源越来越多的情况下，翻开 页面加载优化的万能工具箱，用尽各种招数，都很难达到接近单页的效果。毕竟， MPA架构的前端不是 生而为快，其最大的优势在于开发和维护的高效。

那么，在面对一个大型的 MPA架构前，我们的页面还可以再快一点吗？对于有赞的前端体系来讲，在进行业务域的拆分应用后，业务级别的独立开发、部署已经变成了日常。在单个业务域内，其实也存在SPA的模式，但大都仅限于一个功能点下的列表——详情页的跳转。要完成业务域内的全单页，需要完成的工作量和踩的坑已不敢想象，更别说仅实现了业务域内单页，带来的实际体验提升并不大。那我们还有别的办法吗？

这时候天空飘来了两个字—— MicroFrontend，微前端。微前端的定义想必大家都看了很多，大多数是起源自于 micro-frontends.org 和各个大牛自己的独到见解。本文所介绍的方案并非全套的微前端方案，不包含独立发布、部署、依赖拆分这一部分的内容。这次分享的目标是以有赞微商城后台的改造为例，提供一些可参考的经验，如何在一个已经完成独立发布、部署的MPA体系下，实现微前端中的子页面分发和组合的部分，实现接近单页的效果。

---

二、概述

目前业界已经产出了一些优秀的微前端方案，比如热门的基于 single-spa的 qiankun。在分析了这些微前端方案的实现，并结合团队内的现状后，我们实现了自己的渐进式微前端方案——ZanSpa(命名就是这么简单朴素)。主要设计思路如下图所示：

其中核心模块为 RouteMonitor和 PageLoader两部分，分别负责路由导航和子页面资源的解析组装。好了，有了整体的印象，接下来会依次介绍各个主要模块和流程的实现。

三、说细点

3.1 子页面组合方式

微前端的子页面组合方式：包含构建时组合和运行时组合，既然是低成本接入，基于已有的业务独立打包的形式，同时能做到真正的技术栈无关跟独立部署，运行时组合自然成了我们的首选。

3.2 子页面拆分

开始前，我们对现有的页面加载流程做一些简单分析。

我们在浏览器输入youzan.com，请求经过无线网有线网，A机房B机房，终于到了我们稳定的有赞服务器，接入层根据请求路由特征，转发到对应业务应用的机器，业务应用的 node服务再组装返回 html。其中包含了微商城后台前端各业务都会依赖的公共资源，包括脚本和样式，和业务页面自身依赖的资源。

对于上图中所示的静态资源，这里我们以业务A(对应路由/routeA)和业务B(对应路由/routeB)为例，可以分为三类：

1. 跨业务共用资源(shared-css、shared-js)，routeA和routeB下页面都会请求

2. 业务应用内基础资源(base-css、base-js)，routeA路由下子页面都会请求

3. 页面级资源(page-css、page-js)，routeA路由下的页面C才需要，同是routeA下的页面D可能就不需要

在页面切换中，对于在微商城后台内所有的业务，跨业务的共用资源其实只需要被加载一次，而业务内的基础资源，在业务域的页面间跳转时，比如从 /routeA/list到 /routeA/detail也只需要加载一次。这样，最优的情况下，我们只需要加载页面本身需要的 page-css和 page-js，从而极大的提高页面切换加载的速度。

于是我们对