摘要：蚂蚁金服前端技术专家有知在 D2 带来以“标准微前端架构在蚂蚁的落地实践”为题的演讲。首先提出了微前端的场景域在蚂蚁落地时常遇到的问题，然后详细介绍了微前端的定义，最后通过实施一个标准的微前端架构，提出面临的技术决策以及需要处理的技术细节，经过在蚂蚁的实践证明，微前端是一个具有优势的方案。

微前端的场景域

在选择一个微前端方案之前，常常需要思考这样一个问题，我们为什么需要微前端。通常对微前端的诉求有两个方面，一是工程上的价值，二是产品上的价值。

对于工程上的价值，可以从一个三年陈的项目来看，如上图所示，左上角commit的记录显示，第一次提交是2016年8月。它的下面是一个codebase代码，中间是基本的依赖树dependencies，右侧为打包的体积。

虽然这个三年陈的项目看上去版本比较低，但仍然是相对主流的全家桶方案。这样一个乐观的项目，在真实的场景中经过三年的时间，也不实用了。因为开发的时间比较长，并且人员流动也比较大，会导致一些祖传的代码出现，其次，在技术上不能及时的升级，导致开发体验变得很差，例如打包的时间就超过三分钟。也有可能在不经意间依赖一些不兼容的框架，导致项目无法升级。种种原因，最后很有可能变成一个遗产项目。

对于产品体验上的问题，例如上图所示，要完成一个跳多个控制台任务，在过程中发现每个控制台视觉不统一、流程出现断点以及重复加载或认证的问题导致整个产品的体验较差。

微前端的定义

上图是来自Micro Frontends网站对微前端的定义。意思是所谓微前端就是一种多个团队之间可以使用不同技术构建一个现代化web的技术手段以及方法策略。其中的关键字是多团队、采用不同的技术栈以及现代化的web。

微前端的思路是继承自微服务的思想，如上图所示。

上图所示为微前端的架构图，其中上层为统一共享的拼接层，主要做一些基础信息的加载，和对来自不同团队不同技术栈的客户端在运行时动态组成一个完整的SPA应用，以及生命周期的调度和事件的管理。总之，微前端是将微服务概念做了一个很好的延伸和实现。

在具体实践中，衡量一个微前端方案是否是可利用的，需要满足以下几个条件，一是技术栈无关性，不仅指子应用之间使用多个不同的框架，也指在使用同一个框架时，有可能在一个长的时间跨度下，由于框架的不兼容的升级，导致应用被锁死的情况。二是开发、发布及部署独立，要求子应用和主应用做到工程上的解耦和独立。三是应用隔离的能力，是指需要考虑如何不干扰到原来子应用的开发模式和部署模式的情况下，做好运行时的样式隔离、JS隔离以及异常隔离等。以上几点是基于工程价值方面考虑的。此外，也需要动态组合的能力，是基于产品价值方面考虑的。

落地的关键问题

微前端架构中的技术选择

按架构类型区分，常规web应用的架构类型分为两种，一种是MPA，另一种是SPA。如上图所示为2017年各云产品控制台架构调研，除了google cloud之外，大部分的云厂商都使用MPA架构。MPA的优点在于部署简单，具备独立开发和独立部署的特性。但是，它的缺点是完成一个任务要跳到多个控制台，并且每个控制台又是重复刷新的。而SPA能极大保证多个任务之间串联的流畅性，但问题是通常一个SPA是一个技术栈的应用，很难共存多个技术栈方案的选型。SPA和MPA都是微前端方案的基础选型，但是也都存在各自的问题。

按运行时特性区分，微前端包含两个类别，一类是单实例，另一类是多实例。单实例场景如上图中左侧，通常是一个页面级别的组合，例如一个运行时只有一个App被激活。多实例场景如上图右侧，像一个组件或者是容器级别的应用，运行时可以做到多个应用被同时激活。这两种模式都有自己适应的场景和优势。微前端架构的核心诉求是实现能支持自由组合的微前端架构，将其他的SPA应用以及其他组件级别的应用自由的组合到平台中。那么，如何选择SPA和MPA以及单实例和多实例是一个问题，我们是否能探索出一种方案，将SPA和MPA工程上的特点结合起来，同时兼顾多实例和单实例运行时的场景来实现。

技术细节上的决策

为了实现上述的方案，在技术细节上的决策需要注意以下问题：

一是如何做到子应用之间的技术无关；

二是如何设计路由和应用导入；

三是如何做到应用隔离；

四是基础应用之间资源的处理以及跨应用间通信的选择。

对于如何做到子应用之间的技术无关问题，我们是通过协议来解决的。如上图所示的方式，就可以完成子应用的导入。如果子应用接入时做了一些框架上的耦合或者依赖一个具体实现库的机制，就一定会存在与实现库版本耦合的可能，不利于整个微前端生态的统一和融合。

如上图所示是一个不与某个具体框架实现耦合的例子。

对于路由的问题，如上图所示。这样一条访问链路后，刷新当前URL通常情况下会发生什么？正常访问一个站点，经过一番操作之后，进入到站点的列表页，路由会变大很复杂，但如果是一个微前端用户，刷新一下页面会出现404的情况。解决思路是将404路由fallback到一个异步注册的子应用路由机制上。

对于应用导入方式的选择，比较常见的方案是Config Entry，如上图所示。通过在主应用中注册子应用依赖哪些JS。这种方案一目了然，但是最大的问题是ConfigEntry的方式很难描述出一个子应用真实的应用数据信息。真实的子应用会有一些title信息，依赖容器ID节点信息，渲染时会依赖节点做渲染，如果只配JS和CSS，那么很多信息是会丢失的，有可能会导致间接上的依赖。

另外一种方案是HTML Entry，如上图所示，直接配html，因为html本身就是一个完整的应用的manifest，包含依赖的信息。HTML Entry的优点是接入应用的信息可以得到完整的保留，接入应用地址只需配一次，子应用的原始开发模式得到完整保留，因为子应用接入只需要告知主应用html在哪，包括在不接入主应用时独立的打开。它的缺点是将解析的消耗留给了运行时。而Config Entry相较于HTML Entry减少了运行时的解析消耗。Config Entry的缺点是主应用需配置完整的子应用信息，包含初始DOM信息、js/css 资源地址等。

对于样式隔离问题，例如BEM，每个子应用在写样式之前要加一些前缀，做一些隔离，但是这个做法并不推荐。相对而言，CSS Module更简单高效，也更智能化，是比较推荐的方式，但是也存在着问题。而Web Components看上去很不错，但在实践过程中也会发生一些问题。

例如在Web Components渲染的流程中出现了问题，如上图所示。

解决方案为上图所示。在antd中提供了全局的API，可以提前设置好所有的弹框的container，但是也不是每个组件库都能像antd一样完成度那么高。

蚂蚁所采用的解决方案是做动态的加载和卸载样式表，如上图所示，这种方案是很有效的。

对于JS隔离，蚂蚁提出了JS Sandbox机制，如上图所示，其中bootstrap、mount及unmount生命周期是子应用需要暴露出来的，因为子应用的整个生命周期都是被主应用所管理的，所以可以在主应用中给子应用插入各种拦截的机制，也可以捕获到子应用在加载期间做了哪些全局上的修改。在unmount时，可以将全局上的副作用全部手动移除掉，同时也可以实现在重新进来时，将上次忘记卸载的副作用重建一遍，因为需要保证下次进来时能完整回复到与上次一致的上下文。

对于资源加载问题，在微前端方案中存在一个典型的问题，如果子应用比较多，就会存在之间重复依赖的场景。解决方案是在主应用中主动的依赖基础框架，然后子应用保守的将基础的依赖处理掉，但是，这个机制里存在一个问题，如果子应用中既有react15又有react16，这时主应用该如何做？蚂蚁的方案是在主应用中维护一个语义化版本的映射表，在运行时分析当前的子应用，最后可以决定真实运行时真正的消费到哪一个基础框架的版本，可以实现真正运行时的依赖系统，也能解决子应用多版本共存时依赖去从的问题，能确保最大程度的依赖复用。

对于应用之间数据共享及通信的问题，蚂蚁提出了两个原则，第一个原则是基于props以单向数据流的方式传递给子应用。第二个原则是基于浏览器原生事件做跨业务之间的通信。

在真实的生产实践中，蚂蚁总结出了几点经验及建议：兄弟节点间通信以主应用作为消息总线，不建议自己封装的Pub/Sub机制，也不推荐直接基于某一状态管理库做数据通信。

上图所示为蚂蚁在实践中做的性能优化，包括异步样式导致闪烁问题的解决以及预加载问题的解决。

上图所示为微前端方案涉及到的技术点，本文分享了图中三分之二的内容。

在蚂蚁金服做了大量关于微前端方案之后，总结了衡量一个微前端方案是否友好的两个标准，第一个标准是技术无关，也是微前端最核心的特性，不论是子应用还是主应用都应该做到框架不感知。第二个标准是接入友好，子应用接入应该像接入一个iframe一样轻松自然。

蚂蚁的微前端落地的实践成果

蚂蚁内部基于微前端基础架构提出了一体化上云解决方案，称为OneX，是一个基础的平台，它可以将各种流程和工具串联，其价值体现在品牌、产品和技术方面。

品牌价值指的是统一的界面框架、UI、交互形成了蚂蚁金服科技品牌心智。

上图所示为蚂蚁的一个真实应用的例子，除了中间接入的产品是自己控制之外，其他内容都是由平台提供，这样，如论是一个三年陈项目还是新做的项目，在基本的视觉上可以做到统一。

产品价值指的是产品具有自由组合能力。之前的产品是多个产品、多个站点的控制台，而现在只需要一个控制台，将多个产品自由的组合，这样，可以在商业上有更多的相应空间以及更多自由的搭配。基于这样的系统也可以做一些全局性的事情，例如埋点、用户的转化跟踪业务。

技术价值指的是研发上的提效。经过微前端的改造后，蚂蚁可以将大型的系统解耦成可以独立开发的并行的小型的系统，这些小型系统可以交给别的团队或者使用可视化的系统去实现，最后在运行时只需要将他们集成起来。

在技术价值方面也可以实现交付上的提效，只需要在某一个环境的任意一个环境中做平台上的接入，应用就可以做到在多余的环境中不改代码，直接运行。

上图所示为阿里云刚上市的一个产品例子，其中包括15个来自不同团队的应用进行维护，它的特点是并不是单独为阿里云而设计的，之前在蚂蚁也有运行，只不过在阿里云中做了动态的组合。OneTour微应用组件主要解决的是在多个产品控制台之间自由切换导致流程割裂的问题。

蚂蚁微前端的落地成果包括：有70+线上应用接入（阿里云+蚂蚁云+专有云），最复杂一个控制台同时集成15个应用，并且有4+不同技术栈，以及开发到发布上线全链路的自动化支持，一云入驻多云运行。

蚂蚁也热衷于分享技术上的成果，包括微前端内核的开源、umi插件。上图所示为qiankun方案，是与框架无关的微前端内核，umi-plugin-qiankun是基于umi应用提供的一个插件，如果是umi应用，就可以通过集成插件和更改配置成为微前端应用。基于上述实践的检验和内部的实践结果来看，在大规模中后台应用场景下，微前端架构是一个值得尝试的方案。

关注「Alibaba F2E」
把握阿里巴巴前端新动向