生产可用：是时候来一个微前端架构了！

微前端的场景域

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

对于工程上的价值，可以从一个三年陈的项目来看，如下所示， commit 的记录显示，第一次提交是 2016 年 8 月。

依赖树 dependencies：

打包体积：

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

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

微前端的定义

Techniques, strategies and recipes for building a modern web app with multiple teams using different JavaScript frameworks.
—— Micro Frontends。

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

微前端的架构图

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

在具体实践中，衡量一个微前端方案是否是可利用的，需要满足以下几个条件：

• 技术栈无关性，不仅指子应用之间使用多个不同的框架，也指在使用同一个框架时，有可能在一个长的时间跨度下，由于框架的不兼容的升级，导致应用被锁死的情况。
• 开发、发布及部署独立，要求子应用和主应用做到工程上的解耦和独立。
• 应用隔离的能力，是指需要考虑如何不干扰到原来子应用的开发模式和部署模式的情况下，做好运行时的样式隔离、JS 隔离以及异常隔离等。

以上几点是基于工程价值方面考虑的。此外，也需要动态组合的能力，是基于产品价值方面考虑的。

落地的关键问题

微前端架构中的技术选择