微前端热度不再？qiankun 作者有话说

作者 ｜贾亚宁

嘉宾 ｜刘奎

近年来随着互联网的飞速发展，很多企业的业务复杂度都会上升，参与业务的人员也越来越多，这带来了严重的维护成本。为了解决这个问题，微前端一度成为技术热点，各大公司相继在微前端加大投入。面对微前端在落地实践中暴露的一些问题，很多公司也相继提出了解决方案，比如蚂蚁集团的 qiankun，京东的 MicroApp 等等。

微前端是一种架构理念，它类似于微服务的架构，将微服务的理念应用于浏览器端，即将单页面前端应用由单一的单体应用转变为把多个小型前端应用聚合为一的应用。各个前端应用还可以独立开发、独立部署。微前端听起来美好，但是在具体的落地过程中会有很多问题：什么场景适合微前端，如何判断开展微前端的最佳时机？如何拆分业务最高效？微前端是否势头已过，它又将如何发展呢？

出于对以上问题的好奇，我们特地采访了蚂蚁集团体验技术部前端工程师刘奎老师，同时他也是qiankun 作者，目前在 GitHub 上，qiankun 的 Contributor NO.1，妥妥的开源软件爱好者。

同时，刘奎老师也是 3 月中旬上线的 QCon+ 案例研习社「微前端架构模式的实践与探索」专题的讲师，带来了【蚂蚁微前端研发模式的产品化探索】的分享。因此我们针对微前端技术的相关问题对刘奎老师进行了采访，一起来看看他的实践和思考吧。

InfoQ：你最近在负责什么样的工作呢？

刘奎：我目前在蚂蚁的工作主要分两部分：第一部分是和团队同学一起，去定义蚂蚁统一的微前端研发模式。这个研发模式不仅仅是去做一些微前端相关的基础框架、库的研发，更包括覆盖整个微应用研发生命周期中的一些产品化的流程设计。比如从一个微应用如何在内部研发平台上创建，到如何描述这个微应用跟其他微应用的关联关系、怎么在产品上清晰地表达出来，到如何实现微应用的灰度分发，以及最终上线后的监控、异常应急等能力。总的来讲我们在做的是一个针对微前端场景特性的研发平台。

第二部分是基于目前的微前端应用模型，如何将这一套动态化的机制应用到其他的中台场景，进而将我们内部的中台研发模式统一，以便解决其中的一些共性问题。比如中台应用的页面托管及灰度、应用多环境部署（公有云、专有云），这些是不论你是否使用微前端都会需要解决的问题。

InfoQ：在微前端的日常工作中，你有遇到过什么困难吗？可以具体分享一下吗？

刘奎：从我的视角来看，微前端研发中有几个比较典型，也是我们经常会讨论的问题：第一个是我们要如何对一个巨石应用做拆分，拆分的粒度和边界是什么；第二个是多个微应用之间如何去做依赖复用；第三个就是微应用如何治理的问题。

我们先来看第一问题。在对一个巨石应用做微前端拆分时，最常见的粒度是按页面维度来拆，这通常是没什么问题的。但也有一部分场景，我们期望将页面中某个局部的 UI 抽成一个微应用，供其他应用直接集成复用，这种时候就会比较纠结，到底是该往大了拆还是往小了拆？往大了拆容易出现一些组合场景不好复用从而造成代码冗余，往小了拆则可能导致微应用之间协作起来特别麻烦，反而降低了开发效率。

这里面其实涉及到一个问题，就是我们该怎么划分微应用的服务边界。比较合理的方式是按照服务完整性去划分，看这个微应用是否能独立地、完整地提供一个服务出来。而不仅仅从前端组件的角度，去是看这个 UI 是不是可复用的。有一个简单的评估手段：看你的微应用是否需要频繁跟其他微应用通信？如果答案是肯定的，那你可能就需要考虑下拆分的粒度是否过细了。

第二个问题，也是社区经常会讨论的问题：如何做微应用之间的依赖复用。其实在大部分情况下，这都是一个伪命题，因为复用依赖会导致微应用之间产生隐性的耦合，进而导致微应用无法独立地演进，而这正是与微前端架构背道而驰的。不过目前这个问题也不是无解的，基于 esm/bundless 等手段，我们可以实现微应用独立运行时使用自有依赖，而被集成时则尽可能复用容器同版本的依赖，不过这个目前社区还未有成熟的方案，我们也正在探索当中。

第三个是微应用的治理问题。当我们在公司内大规模实践微前端，或者微应用的数量变多、依赖关系变得复杂的时候，就很容易碰到架构治理相关的问题。比如如何确保宿主应用使用到匹配环境的微应用资源，而不会因为线上引用了线下的微应用导致故障；比如如何确保应用之间的高可用等级是对等的，而不会因为一个核心链路的应用，依赖了一个低服务级别的应用，而导致服务经常不可用的问题。要治理这些问题，我们需要尽早地从平台侧出发，做相关的研发阶段的数据收集跟统计，然后基于这些数据参考，去设计我们体系化的产品及研发思路，从整个平台层面收敛掉研发流程。

InfoQ：你认为哪些场景下适合采用微前端，哪些场景不适合呢？

刘奎：回答这个问题之前，我们可能要先来回答一下微前端解决了什么问题。

从工程角度来看，微前端其实解决的是在前端技术高速迭代、组织架构频繁变更的背景下，如何通过一些物理隔离的手段降低系统组件间的耦合，从而确保每个组件的开发独立、交付独立，进而实现整个系统渐进式演进的能力。

从产品角度来看，微前端解决的是如何在技术栈无感知的情况下，实现整个产品的平台性及动态性。针对不同的场景及用户角色，动态地将来自不同系统的服务组装起来。

明白了这两个要点，我们就能回答这个问题了，简单来说就是：

如果你不是要在一个长尾应用上做持续交付，你就不需要微前端；如果你的产品都是同一个小的团队开发的，你就不需要微前端；如果你的产品没有集成 / 被集成的诉求，你就不需要微前端。反之亦然。