深扒阿里开源的微前端架构 icestark：前端又要变革了吗

随着微前端技术架构的出现，不断有团队尝试将单体的前端 Web 应用按不同维度进行拆分或者组合，再聚合到一个整体的应用架构下面。无论从系统体验优化，还是技术架构升级的角度，都对微前端的方案提出了各种高要求。因此，我们邀请了淘宝前端架构团队前端技术专家夏温武（QCon+案例研习社讲师），请他来分享一下飞冰 icestark 微前端架构对于不同场景的思考和设计，尝试帮你找到解决方案。

InfoQ：能否简单介绍一下您的过往经历？

夏温武：我是 2018 年加入大淘宝-前端团队的，加入之后致力于提升前端开发的体验和效率，工作主要可分为以下三件事情：

首先是前端工程构建 build-scripts。它是基于 Webpack 的插件化工程构建工具，为上层的项目开发、组件开发、模块开发提供标准化的工程解决方案，并借助插件化的生态，让整个工程生态能力在不同场景和不同业务间流转互通。

其次是基于微前端的研发模式，主要借助 icestark 微前端框架为开发者无痛迁移巨型应用，除此之外在微前端的生态上探索中心化权限、版本管控等业务方案，为开发团队解决协同和研发流程上的问题。从微前端应用的创建、到应用架构的设计、如何组织主子应用的关系以及最终的上线和监控我都有涉及。

目前主要负责 ICE 研发框架的开发，即研发用户源码开发阶段依赖的上层框架，为开发者提供基于 React 的研发解决方案。ICE 研发架构能够让开发者在享受极致的开发体验的同时，简单地构建出高性能的 Web 应用。同时我们还会结合一些研发模式来提升开发效率，比如 ICE 研发框架结合微前端的架构，就可以开箱即用地将普通项目一键转化为主应用或者子应用

InfoQ：阿里巴巴为什么要做开源微前端架构 icestark 呢？它跟飞冰 ICE 是什么关系？

夏温武：icestark 是面向大型系统的微前端解决方法，目的是为应用聚合和巨石应用的架构提供解决方案。而飞冰 ICE 旨在提供基于 React 的研发解决方案，除了基础的框架之外，我们会围绕它营造一个完整的开发生态，比如大量的官方模版、基于 VSCode 插件的研发工具、物料体系（比如组件）的开发等生态。

icestark 微前端解决方案在 ICE 研发体系占据非常重要的作用，它为传统协作模式带来突破性的变化。icestark 首先在淘宝内部进行了大量的实践，比如淘系的运营工作台，icestark 支持 8 个以上系统进行了平滑迁移，集成近 30 个子应用，包含 800 多个页面。面对工作台系统集成和巨石应用架构升级的场景 icestark 微前端解决方案能够带来效率的提升和架构的优化。我们希望能够将 icestark 微前端的解决方案分享给社区，协同社区的业务场景和需求，相互交流、相互促进，让 icestark 解决方案能够不断突破和优化。

InfoQ: icestark 的核心架构是如何设计的？当时主要考虑了哪几方面的因素呢？

夏温武：微前端作为微服务理念在前端领域的延伸，让前端应用在独立开发的同时也能集成一个 web 应用并提供系列功能，结合这个理念，我们确定了四个设计原则：

• 技术栈无关：这是微前端的基本设计原则，不论什么样的技术栈都需要能被微前端架构集成

• 开发体验一致：微前端架构的引入不应导致太多应用的改造，开发阶段也不需要接触新的概念和流程

• 中心化路由：应能简化应用的集成，应用能够自动响应路由变化

• 独立开发部署：主子应用都能够独立开发、独立部署，高效进行协作

微前端的技术架构将应用区分为了主应用和子应用

• 主应用：定义路由加载规则 + 配置子应用资源

• 子应用：定义应用加载的生命周期

上述职责的区分意味着一个微前端框架需要考虑以下三方面的设计：

• 路由系统：基于路由的微前端架构，核心需要解决的就是不同应用对于路由的响应，因此 icestark 在主应用初始化之后将会劫持路由事件，这样 icestark 可以掌握子应用加载时机，而触发劫持的路由事件可以让子应用响应路由变化

• 应用调度：完成路由接触之后，框架还需要设计应用的调度，包括激活应用和卸载应用，而应用的生命周期，比如 mount（激活）、unmout（卸载）等事件也将相应被触发

• 应用加载：在应用被激活之后，我们需要考虑加载应用面对不同标准的应用时，框架需要采取的加载策略也不同。比如常规的 JS bundle 和 UMD 规范的资源，我们可以借助 Fetch 或者 script 标签能力直接进行加载，但对于 ESM 标准的应用，则直接采用 dynamic import 即可

除此之外由于微前端的架构下同时出现主应用和子应用，不可避免地需要考虑：

• 应用通信：基于微前端架构下应用能够独立开发部署的原则，大部分场景下仅需要轻量的事件通信机制即可

• 样式隔离：业务上推荐以 CSS prefix 和 CSS modules 的方式实现低成本隔离，在强隔离诉求上探索 Shadow DOM 的能力

• 运行沙箱：利用 Proxy 能力对 Window 上的全量变量实现轻量化的沙箱隔离

InfoQ: icestark 在落地时遇到过什么困难吗？当时您和团队是怎么解决的？

夏温武：icestark 落地的第一个重要业务是淘系的工作台业务，其产品的诉求是统一产品的交互体验，将多个小二操作系统进行融合。由于多个系统之前存在着操作流程的依赖，如何拆分应用进行整合变成了首先需要解决的问题。这是一个典型的巨石应用拆解问题。

按现有系统的维度进行拆分，会导致单一路由下加载过多的资源，系统整体加载体验不佳，而过细的拆分粒度，则会增加开发维护的难度，并且一些公共模块的复用变得困难。因此一个基础的判断便是按功能维护进行划分，被划分的应用能够独立完整的提供一个功能，在实际业务实践上再去结合是否被其他应用集成以及跨应用的复用等维度进行调整。

另一个遇到比较多的问题是子应用配置如何进行管控，即多应用该如何集成：

一个比较简单的实践是直接将该应用下涉及到所有的子应用配置以源码的方式直接放在主应用中，这样虽然简单但带来的问题也很明显，即所有子应用的发布，必定带来主应用的发布，对于高频发布和跨团队协作的场景下将造成研发流程的阻塞。

另一种方式便是将子应用配置维护在服务端，主应用每次都动态进行获取。一旦子应用的资源配置发生变更能够实时的反映到主应用上，对于一些中心化权限判断的场景也能够按用户权限返回对应的应用链接。在具体的实践过程中，我们通过一个微前端的管控平台针对资源的变更、资源灰度、上线发布和监控等一系列流程进行串联，来提升整体研发流程的效率。

InfoQ：icestark 还做了哪些技术创新呢？ 

夏温武：除了常规的巨石应用拆解和多应用集成的实践之外，这块单独介绍下 icestark 微前端架构下衍生的微模块方案。

相比应用级别微前端架构，微模块的粒度更细，并且 icestark 定义下的微模块不依赖路由系统，这意味着页面中路由的变化不会影响到模块的渲染。而通过 icestark 微前端架构中提供的应用加载的通用能力，可以完全掌控模块的加载时机。

比如多页签的场景，其交互的特点决定了同一路由下存在的多个独立功能模块的诉求。如果每个 Tab 页签下都是一个子应用，并且包含对路由的响应，那意味着一旦路由变化，页签下面的子应用状态将变得不可掌控。

而通过微模块的方案，可以便捷地实现多个应用共存，就像是渲染一个独立组件一样控制渲染应用。在结合研发框架的体系下，icestark 也可以便捷地利用 static router 的特性，将一个 SPA 应用作为一个独立模块进行渲染，从而大大降低业务上落地的难度。

InfoQ：您认为什么场景适合微前端呢？什么时机适合开展微前端呢？

夏温武：微前端的技术架构定义了两大主要解决的场景：

一个是巨石应用，特别是历史的项目，其项目量级随着业务诉求逐渐变大，开发效率低下、技术栈迁移成本高、二方业务接入成本高。这样的项目通过微前端的架构可以低成本的方式升级应用架构，让整个应用可以渐进式地升级，可持续的逐步演进。

另一个场景就是工作台的场景，应用间相互独立，但业务操作流程中又相互关联，不同的系统体验不一致，来回的跳转导致操作效率低下，并且多个相关系统下存在着大量重复建设。借助微前端的架构我们可以建立一套统一体验的产品，重复的能力比如登录、鉴权可以收敛到主应用，子应用以统一的标准进行接入。

除了上面的两大场景外一些基础的判断也可以帮助我们决定是否使用微前端：

• 是否涉及跨团队间的应用协作开发→是，则可使用微前端

• 是否需要渲染不可控的第三方内容→是，则可使用微前端

• 是否存在多个技术栈的可能→是，则可使用微前端

InfoQ：微前端和低代码是什么关系？

夏温武：低代码一般借助平台以可视化的方式让开发者完成功能需求，推崇少写代码。从大多数产品的交互形态上看，开发者通过拖拽模块的方式就完成页面乃至应用的搭建。

根据搭建粒度的不同，可以判断是否需要微前端技术架构的引入：

• 组件级别的页面搭建：搭建页面的元素粒度较细，大多都是组件级别的元素，各组件间按 Schema 描述完成渲染，相互独立互不影响，并不需要借助微前端架构进行聚合

• 页面级别的搭建：搭建的最小纬度是页面级别，每个页面能够独立地开发和部署，完成相应的功能，并且将在不同场景下被集成，通过微前端的引入可以让整个页面的渲染隔离，降低系统间不同页面间的耦合，从而保障系统健壮并持续演进

这意味着通过低代码搭建出来的模块规范如果和微前端规范保持一致，做到两者互通，那么它搭建的渲染引擎是有机会基于微前端架构进行设计。

对于应用级别的项目而言，不管是 Pro-code、Low-code 还是 No-code 搭建的应用，只要符合微前端框架下定义的规范都可以快速地被集成，这也正是微前端架构技术栈无关能力带来的特点。

InfoQ：阿里巴巴在微前端有什么技术上的创新吗？您怎么看待微前端的未来呢？

夏温武：阿里巴巴在早些时间就确定了微前端的技术规范，明确了子应用的规范，包括生命周期、接入规范、导出规范等等，这意味不管上层使用的技术框架是什么样的，子应用都能很好地在体系内进行流通。

而随着微前端的逐步发展，从技术侧看，微前端领域的技术将逐渐标准化，比如结合 ESM 利用浏览器标准能力进行模块的加载，TC39 下 ShadowRealm 的沙箱提案等等。

从产品侧看，微前端的技术架构意味着将更多的技术复杂度下沉到基础建设中，因此产品设计上需要解决的是在微前端架构能力相对稳定的现在，如何定义好微前端项目的工作流程和协助方式，这将对前端开发效率带来突破性的提升。比如阿里内部针对微前端研发了管控治理平台，它提供管控微前端项目的创建、应用发布的版本管控、微前端配置的自动下发以及灰度、监控等应用研发全流程相关的能力。这些能力如果有机会将标准化、服务化，作为微前端生态至关重要的一环。

InfoQ：您认为开源是另一种内卷吗？您怎么看待现在的开源大潮？

夏温武：我个人认为开源恰恰是为了打破内卷的一种方式。如果大家都是闭门造车，相比于开放的技术环境和生态，更加容易缺少技术的创新从而走向重复的轮子。相比于闭源的开发，以开源的方式运作项目可以让项目发展和设计更加透明，同社区相互交流，相互启发，接触更多颠覆性的思路才是打破内卷最好的方式。

现下蓬勃的开源社区的成因，一方面是社区普遍存在技术生产力提升的诉求：比如前端领域各种复杂的工程构建和技术方案，对于专注业务开发者而言，能够提供开箱即用的方案将大大提供研发的效率；另一方面也是意见领袖建立技术影响力需要：通过开源的项目运作，输出在专业领域的思考和设计，对成为领域内的意见领袖起着至关重要的作用。

面对开源大潮，我认为技术的发展本质还是回归到业务，互联网的寒冬并不会因为开源的大潮而有所减缓，面对社区开源的技术和自身的产品，我们更应该思考如何利用好技术、演进自身产品来服务业务，从而实现技术本身该有的价值。

嘉宾介绍：夏温武，阿里巴巴，淘宝前端架构团队 前端技术专家。任职于淘系前端架构团队，负责飞冰 ICE 开源技术产品，在前端工程化、前端框架和微前端领域有一些沉淀。

活动推荐：前端除了微前端化以外，很多团队已经在前端研发领域拥抱 Serverless，实现了 App 占用资源成本降低、前端岗位职能延展、内外技术栈互通等效果，推动了前端在行业里的新变革。在今年 7 月的 ArchSummit 全球架构师峰会（深圳站）中，我们策划了【前端 Serverless 研发体系建设】专题。

本专题会围绕前端实现 Serverless 研发体系遇到的挑战该如何解决，如何让“云+端”的开发变得更高效，如何通过云原生 Serverless 去升级业务的研发模式，扩大前端的价值，同时了解未来前端行业的发展趋势。