丰富的线上&线下活动，深入探索云世界
做任务，得社区积分和周边
最真实的开发者用云体验
让每位学生受益于普惠算力
让创作激发创新
资深技术专家手把手带教
遇见技术追梦人
技术交流，直击现场
海量开发者使用工具、手册，免费下载
极速、全面、稳定、安全的开源镜像
开发手册、白皮书、案例集等实战精华
为开发者定制的Chrome浏览器插件
摘要：蚂蚁金服前端技术专家有知在D2带来以“标准微前端架构在蚂蚁的落地实践”为题的演讲。首先提出了微前端的场景域在蚂蚁落地时常遇到的问题，然后详细介绍了微前端的定义，最后通过实施一个标准的微前端架构，提出面临的技术决策以及需要处理的技术细节，经过在蚂蚁的实践证明，微前端是一个具有优势的方案。
在选择一个微前端方案之前，常常需要思考这样一个问题，我们为什么需要微前端。通常对微前端的诉求有两个方面，一是工程上的价值，二是产品上的价值。
对于工程上的价值，可以从一个三年陈的项目来看，如上图所示，左上角commit的记录显示，第一次提交是2016年8月。它的下面是一个codebase代码，中间是基本的依赖树dependencies，右侧为打包的体积。
对于产品体验上的问题，例如上图所示，要完成一个跳多个控制台任务，在过程中发现每个控制台视觉不统一、流程出现断点以及重复加载或认证的问题导致整个产品的体验较差。
上图是来自MicroFrontends网站对微前端的定义。意思是所谓微前端就是一种多个团队之间可以使用不同技术构建一个现代化web的技术手段以及方法策略。其中的关键字是多团队、采用不同的技术栈以及现代化的web。
微前端的思路是继承自微服务的思想，如上图所示。
上图所示为微前端的架构图，其中上层为统一共享的拼接层，主要做一些基础信息的加载，和对来自不同团队不同技术栈的客户端在运行时动态组成一个完整的SPA应用，以及生命周期的调度和事件的管理。总之，微前端是将微服务概念做了一个很好的延伸和实现。
按架构类型区分，常规web应用的架构类型分为两种，一种是MPA，另一种是SPA。如上图所示为2017年各云产品控制台架构调研，除了googlecloud之外，大部分的云厂商都使用MPA架构。MPA的优点在于部署简单，具备独立开发和独立部署的特性。但是，它的缺点是完成一个任务要跳到多个控制台，并且每个控制台又是重复刷新的。而SPA能极大保证多个任务之间串联的流畅性，但问题是通常一个SPA是一个技术栈的应用，很难共存多个技术栈方案的选型。SPA和MPA都是微前端方案的基础选型，但是也都存在各自的问题。
按运行时特性区分，微前端包含两个类别，一类是单实例，另一类是多实例。单实例场景如上图中左侧，通常是一个页面级别的组合，例如一个运行时只有一个App被激活。多实例场景如上图右侧，像一个组件或者是容器级别的应用，运行时可以做到多个应用被同时激活。这两种模式都有自己适应的场景和优势。微前端架构的核心诉求是实现能支持自由组合的微前端架构，将其他的SPA应用以及其他组件级别的应用自由的组合到平台中。那么，如何选择SPA和MPA以及单实例和多实例是一个问题，我们是否能探索出一种方案，将SPA和MPA工程上的特点结合起来，同时兼顾多实例和单实例运行时的场景来实现。
为了实现上述的方案，在技术细节上的决策需要注意以下问题：
一是如何做到子应用之间的技术无关；
二是如何设计路由和应用导入；
三是如何做到应用隔离；
四是基础应用之间资源的处理以及跨应用间通信的选择。
对于如何做到子应用之间的技术无关问题，我们是通过协议来解决的。如上图所示的方式，就可以完成子应用的导入。如果子应用接入时做了一些框架上的耦合或者依赖一个具体实现库的机制，就一定会存在与实现库版本耦合的可能，不利于整个微前端生态的统一和融合。
如上图所示是一个不与某个具体框架实现耦合的例子。
对于路由的问题，如上图所示。这样一条访问链路后，刷新当前URL通常情况下会发生什么？正常访问一个站点，经过一番操作之后，进入到站点的列表页，路由会变大很复杂，但如果是一个微前端用户，刷新一下页面会出现404的情况。解决思路是将404路由fallback到一个异步注册的子应用路由机制上。
对于应用导入方式的选择，比较常见的方案是ConfigEntry，如上图所示。通过在主应用中注册子应用依赖哪些JS。这种方案一目了然，但是最大的问题是ConfigEntry的方式很难描述出一个子应用真实的应用数据信息。真实的子应用会有一些title信息，依赖容器ID节点信息，渲染时会依赖节点做渲染，如果只配JS和CSS，那么很多信息是会丢失的，有可能会导致间接上的依赖。
另外一种方案是HTMLEntry，如上图所示，直接配html，因为html本身就是一个完整的应用的manifest，包含依赖的信息。HTMLEntry的优点是接入应用的信息可以得到完整的保留，接入应用地址只需配一次，子应用的原始开发模式得到完整保留，因为子应用接入只需要告知主应用html在哪，包括在不接入主应用时独立的打开。它的缺点是将解析的消耗留给了运行时。而ConfigEntry相较于HTMLEntry减少了运行时的解析消耗。ConfigEntry的缺点是主应用需配置完整的子应用信息，包含初始DOM信息、js/css资源地址等。
对于样式隔离问题，例如BEM，每个子应用在写样式之前要加一些前缀，做一些隔离，但是这个做法并不推荐。相对而言，CSSModule更简单高效，也更智能化，是比较推荐的方式，但是也存在着问题。而WebComponents看上去很不错，但在实践过程中也会发生一些问题。
例如在WebComponents渲染的流程中出现了问题，如上图所示。
解决方案为上图所示。在antd中提供了全局的API，可以提前设置好所有的弹框的container，但是也不是每个组件库都能像antd一样完成度那么高。
蚂蚁所采用的解决方案是做动态的加载和卸载样式表，如上图所示，这种方案是很有效的。
对于JS隔离，蚂蚁提出了JSSandbox机制，如上图所示，其中bootstrap、mount及unmount生命周期是子应用需要暴露出来的，因为子应用的整个生命周期都是被主应用所管理的，所以可以在主应用中给子应用插入各种拦截的机制，也可以捕获到子应用在加载期间做了哪些全局上的修改。在unmount时，可以将全局上的副作用全部手动移除掉，同时也可以实现在重新进来时，将上次忘记卸载的副作用重建一遍，因为需要保证下次进来时能完整回复到与上次一致的上下文。
对于资源加载问题，在微前端方案中存在一个典型的问题，如果子应用比较多，就会存在之间重复依赖的场景。解决方案是在主应用中主动的依赖基础框架，然后子应用保守的将基础的依赖处理掉，但是，这个机制里存在一个问题，如果子应用中既有react15又有react16，这时主应用该如何做？蚂蚁的方案是在主应用中维护一个语义化版本的映射表，在运行时分析当前的子应用，最后可以决定真实运行时真正的消费到哪一个基础框架的版本，可以实现真正运行时的依赖系统，也能解决子应用多版本共存时依赖去从的问题，能确保最大程度的依赖复用。
对于应用之间数据共享及通信的问题，蚂蚁提出了两个原则，第一个原则是基于props以单向数据流的方式传递给子应用。第二个原则是基于浏览器原生事件做跨业务之间的通信。
在真实的生产实践中，蚂蚁总结出了几点经验及建议：兄弟节点间通信以主应用作为消息总线，不建议自己封装的Pub/Sub机制，也不推荐直接基于某一状态管理库做数据通信。
上图所示为蚂蚁在实践中做的性能优化，包括异步样式导致闪烁问题的解决以及预加载问题的解决。
在蚂蚁金服做了大量关于微前端方案之后，总结了衡量一个微前端方案是否友好的两个标准，第一个标准是技术无关，也是微前端最核心的特性，不论是子应用还是主应用都应该做到框架不感知。第二个标准是接入友好，子应用接入应该像接入一个iframe一样轻松自然。
蚂蚁内部基于微前端基础架构提出了一体化上云解决方案，称为OneX，是一个基础的平台，它可以将各种流程和工具串联，其价值体现在品牌、产品和技术方面。
品牌价值指的是统一的界面框架、UI、交互形成了蚂蚁金服科技品牌心智。
上图所示为蚂蚁的一个真实应用的例子，除了中间接入的产品是自己控制之外，其他内容都是由平台提供，这样，如论是一个三年陈项目还是新做的项目，在基本的视觉上可以做到统一。
产品价值指的是产品具有自由组合能力。之前的产品是多个产品、多个站点的控制台，而现在只需要一个控制台，将多个产品自由的组合，这样，可以在商业上有更多的相应空间以及更多自由的搭配。基于这样的系统也可以做一些全局性的事情，例如埋点、用户的转化跟踪业务。
技术价值指的是研发上的提效。经过微前端的改造后，蚂蚁可以将大型的系统解耦成可以独立开发的并行的小型的系统，这些小型系统可以交给别的团队或者使用可视化的系统去实现，最后在运行时只需要将他们集成起来。
在技术价值方面也可以实现交付上的提效，只需要在某一个环境的任意一个环境中做平台上的接入，应用就可以做到在多余的环境中不改代码，直接运行。
上图所示为阿里云刚上市的一个产品例子，其中包括15个来自不同团队的应用进行维护，它的特点是并不是单独为阿里云而设计的，之前在蚂蚁也有运行，只不过在阿里云中做了动态的组合。OneTour微应用组件主要解决的是在多个产品控制台之间自由切换导致流程割裂的问题。
蚂蚁微前端的落地成果包括：有70+线上应用接入（阿里云+蚂蚁云+专有云），最复杂一个控制台同时集成15个应用，并且有4+不同技术栈，以及开发到发布上线全链路的自动化支持，一云入驻多云运行。