---

随着互联网行业的快速发展，前端应用的规模和复杂度也在不断增加。为了应对这种挑战，越来越多的企业和开发者开始探索新的前端架构模式。微前端作为一种新兴的前端架构模式，凭借其高度模块化、独立部署、易于扩展等特点，逐渐成为了业界的热门话题。本文将通过一个实际案例，详细介绍微前端的概念、原理以及在实战中的应用。

一、微前端简介

微前端（Micro Frontends）是一种将大型单页应用拆分为多个独立的小型应用的技术方案。每个小型应用都可以独立开发、部署和运行，它们之间通过共享公共资源（如样式、组件等）来实现数据和状态的同步。微前端的核心思想是将前端应用分解为一组可独立维护、独立部署的子应用，从而提高开发效率、降低维护成本，同时保证系统的灵活性和可扩展性。

二、微前端的优势

1. 高度模块化

微前端将大型应用拆分为多个小型应用，每个应用负责一个特定的功能或模块。这种模块化的设计使得开发者可以更加专注于某个功能的开发，提高开发效率。

2. 独立部署

每个微应用都可以独立部署，无需对整个应用进行整体部署。这大大简化了部署过程，降低了部署风险。

3. 易于扩展

当需要添加新功能时，只需开发一个新的微应用并将其集成到主应用中，而无需修改现有的代码。这使得系统具有良好的可扩展性。

4. 技术栈无关

微前端允许每个微应用使用不同的技术栈，这为团队提供了更大的技术选择空间，同时也降低了技术选型的风险。

5. 独立升级

当某个微应用需要升级时，只需对该应用进行升级，而不会影响其他应用。这有助于保持整个系统的稳定和可靠。

三、微前端的原理

微前端的核心原理是通过定义一个容器来承载多个独立的微应用。这个容器负责管理各个微应用之间的通信和资源共享。具体来说，微前端主要包括以下几个部分：

1. 主应用：主应用是整个系统的入口，它负责加载和管理各个微应用。主应用通常包含一个容器元素，用于承载各个微应用的内容。此外，主应用还需要提供一些基础设施服务，如路由管理、状态管理等。

2. 微应用：微应用是主应用中的一个子应用，它可以独立开发、部署和运行。每个微应用都包含一个容器元素，用于承载该应用的内容。此外，微应用还需要提供一些与主应用交互的接口，如共享资源、通信等。

3. 通信机制：微前端需要实现各个微应用之间的通信和资源共享。这通常通过定义一套统一的通信协议和API来实现。例如，可以使用自定义事件、消息队列等方式来实现微应用之间的通信；可以使用Webpack、Rollup等打包工具来实现资源的共享和提取。

四、微前端案例思路

下面我们通过一个简单的案例思路来模拟如何使用微前端技术构建一个高效的前端应用。假设我们要开发一个包含多个子功能的在线教育平台，如课程管理、在线考试、学习社区等。我们可以采用以下步骤来实现这个系统：

1. 拆分功能模块：首先，我们需要将整个在线教育平台拆分为多个独立的功能模块，如课程管理模块、在线考试模块、学习社区模块等。每个模块都可以作为一个独立的微应用进行开发和维护。

2. 设计通信协议：为了实现各个微应用之间的通信和资源共享，我们需要设计一套统一的通信协议和API。例如，我们可以定义一个emit方法来触发自定义事件，以及一个on方法来监听自定义事件；我们还可以使用Webpack的CommonsChunkPlugin插件来实现公共资源的提取和共享。

3. 开发主应用：主应用是整个在线教育平台的入口，它负责加载和管理各个微应用。主应用需要提供一个容器元素来承载各个微应用的内容，并提供一些基础设施服务，如路由管理、状态管理等。此外，主应用还需要实现与各个微应用的通信和资源共享。

4. 开发微应用：每个微应用都是一个独立的功能模块，它可以独立开发、部署和运行。每个微应用都需要提供一个容器元素来承载该应用的内容，并提供一些与主应用交互的接口，如共享资源、通信等。此外，微应用还需要实现自身的业务逻辑和界面展示。

5. 集成测试：在完成各个微应用的开发后，我们需要对整个系统进行集成测试，确保各个微应用之间的通信和资源共享正常工作。此外，我们还需要对整个系统的性能、稳定性等进行测试和优化。

---

《微前端实战》

编辑推荐

就像微服务为后端系统带来了灵活性和可维护性，微前端也为基于浏览器的应用程序提供了同样的优势。你可以将项目设计为包含多个单独的组件，每个组件中包括各自的接口、逻辑和存储功能，这样就可以独立开发这些组件，并在浏览器中组合使用它们。

《微前端实战》一书指导读者将微服务方法应用于前端领域。本书首先会介绍微前端的核心设计思想，之后你将亲手创建一个电商应用程序，并在开发过程中处理一些实际问题，如服务端组合和客户端组合、路由、确保外观和交互的一致性等。最终，你将深入了解团队工作流模式，这种模式能够化地突显独立开发应用程序组件的优势。

内容简介

• 将多个独立的应用程序组合成一个统一的前端应用程序

• 将基于不同框架的代码组合在一起

• 浏览器端组合、服务端组合以及路由

• 高效的开发团队实践和项目工作流

作者简介

Michael Geers是一名软件开发者，专注于用户界面相关开发领域。他从十几岁起就开始为网站开发软件。在过去的几年里，他参与过多个垂直架构的项目，在多个国际性会议上分享了自己的经验，并在杂志上发表了一系列相关的文章。目前，他仍在持续运营https://micro-frontends.org站点。

目录

第Ⅰ部分 微前端初体验

第1章 什么是微前端 3

1.1 概览图 4

1.1.1 系统和团队 5

1.1.2 前端 8

1.1.3 前端集成 11

1.1.4 公共话题 13

1.2 微前端解决了哪些问题 14

1.2.1 优化功能开发 14

1.2.2 不再有前端巨石架构 15

1.2.3 适应变化 16

1.2.4 自主的优势 19

1.3 微前端的缺点 21

1.3.1 冗余 21

1.3.2 一致性 21

1.3.3 异质性 22

1.3.4 更多的前端代码 22

1.4 使用微前端的合理时机 23

1.4.1 适合大中型项目 23

1.4.2 在Web应用程序中使用效果最好 23

1.4.3 效率与开销 24

1.4.4 微前端不适用的场景 25

1.4.5 谁在使用微前端 26

1.5 本章小结 26

第2章 我的第一个微前端项目 29

2.1 The Tractor Store简介 30

2.1.1 准备开始 30

2.1.2 运行书中的示例代码 32

2.2 通过链接进行页面跳转 35

2.2.1 数据所有权 35

2.2.2 团队契约 36

2.2.3 如何实现 37

2.2.4 处理URL的变化 40

2.2.5 优点 41

2.2.6 缺点 42

2.2.7 何时使用链接集成技术 42

2.3 通过iframe进行组合 42

2.3.1 如何实现 43

2.3.2 优点 45

2.3.3 缺点 45

2.3.4 何时使用iframe集成技术 46

2.4 内容预告 46

2.5 本章小结 47

第Ⅱ部分 路由、组合与通信

第3章 使用Ajax进行组合与服务端路由 51

3.1 通过Ajax进行组合 52

3.1.1 如何实现 53

3.1.2 样式与脚本的命名空间 55

3.1.3 声明式地加载h-include 59

3.1.4 优点 59

3.1.5 缺点 61

3.1.6 何时使用Ajax集成 62

3.1.7 总结 62

3.2 通过Nginx实现服务端路由 63

3.2.1 如何实现 66

3.2.2 资源的命名空间 69

3.2.3 路由配置的方法 70

3.2.4 基础设施的归属 71

3.2.5 何时应使用单个域名 73

3.3 本章小结 73

第4章 服务端组合 75

4.1 通过Nginx和服务端包含(SSI)进行组合 76

4.1.1 如何实现 77

4.1.2 更少的加载次数 80

4.2 处理不可靠的片段 81

4.2.1 可分离的片段 82

4.2.2 集成Near You片段 83

4.2.3 超时和回退 84

4.2.4 回退内容 86

4.3 深入研究标签的组装性能 87

4.3.1 并行加载 87

4.3.2 嵌套的片段 88

4.3.3 延迟加载 89

4.3.4 首字节时间和流式输出 90

4.4 其他解决方案概述 92

4.4.1 Edge-Side Includes 92

4.4.2 Zalando Tailor 93

4.4.3 Podium 95

4.4.4 哪种方案更适合 102

4.5 服务端组合的优缺点 104

4.5.1 优点 104

4.5.2 缺点 104

4.5.3 使用服务端集成的时机 105

4.6 本章小结 106

第5章 客户端组合 107

5.1 使用Web Component封装微前端 108

5.1.1 如何实现 110

5.1.2 将框架封装在Web Component内 115

5.2 使用Shadow DOM实现样式隔离 117

5.2.1 创建shadow root 117

5.2.2 样式隔离 118

5.2.3 何时使用Shadow DOM 120

5.3 使用Web Component进行组合的优缺点 121

5.3.1 优点 121

5.3.2 缺点 122

5.3.3 使用客户端集成的时机 122

5.4 本章小结 123

第6章 通信模式 125

6.1 用户界面通信 126

6.1.1 父级页面到片段 127

6.1.2 片段到父级页面 131

6.1.3 片段到片段 135

6.1.4 使用Broadcast Channel API发布/订阅 140

6.1.5 UI通信更适合什么场景 142

6.2 其他通信机制 143

6.3 本章小结 148

第7章 客户端路由和应用程序容器 149

7.1 应用程序容器中的扁平化路由 1521

7.2 双层路由的应用程序容器 162

7.3 single-spa元框架的简述 171

7.4 来自统一单页面应用的挑战 178

7.5 本章小结 183

第8章 组合和多端渲染 185

8.1 结合使用服务端和客户端组合 187

8.2 何时适合采用多端组合 195

8.3 本章小结 197

第9章 适合我们项目的架构 199

9.1 复习专业术语 200

9.2 复杂度的比较 206

9.3 是构建网站还是应用程序 208

9.4 选择正确的架构和集成技术 211

9.5 本章小结 216

第Ⅲ部分 如何做到快速、一致、有效

第10章 资源加载 221

10.1 资源引用策略 222

10.2 打包粒度 238

10.3 按需加载 241

10.4 本章小结 242

第11章 至关重要的性能 243

11.1 高性能架构设计 244

11.2 精简并复用vendor库 251

11.3 本章小结 272

第12章 UI设计系统 275

12.1 为什么需要一个设计系统 276

12.2 公用设计系统与自治团队 279

12.3 运行时整合与构建时整合 286

12.4 样式库中的组件：通用与定制 293

12.5 哪些组件应该沉淀到中心化的样式库中 298

12.6 本章小结 303

第13章 团队及职责边界 305

13.1 将系统与团队对齐 306

13.2 知识分享 314

13.3 横向共性问题 317

13.4 技术多样性 319

13.5 本章小结 323

第14章 迁移、本地开发及测试 325

14.1 迁移 326

14.2 本地开发 333

14.3 测试 339

14.4 本章小结 341

前言/序言

我是一名有着20年经验的Web开发人员。在这20年中，我参与了各种规模的项目，其中包括独自一人开发的微型创业项目，与其他几位同伴一同完成的小型项目，也参与过多人合作的大型项目(人数肯定超过了我家餐桌旁摆放的椅子数量)。

2014年，我和neuland Büro für Informatik的同事们负责为一家连锁百货公司重建电子商务系统。其现有的电子商务系统不仅存在性能问题，而且结构非常混乱，在其基础上开发新的功能需要耗费很长时间，通常还会引发系统其他功能的故障。随着相关开发团队规模的逐渐扩大，系统愈发难以维护。客户要求新的系统除了具有更加合理的架构外，还希望在此架构上，不同的开发团队能够独立开展工作，互不影响。这种并行开发的能力，对于客户以信息化为基础快速扩张业务的计划，有着至关重要的意义。为此，我们选择了一种“垂直化”的系统架构：按照职能划分，设立多个独立的团队，每个团队专门负责一块特定业务的开发，包括从数据库到前端页面展示的所有工作。这样每个团队所负责开发的部分都是独立和自治的，最终会在前端页面层面整合在一起。从概念上来看，前端整合似乎没有什么难度，但事实上我们需要掌握大量的知识才能有效地实现前端整合。随着项目的深入，我们逐步完善了所采用的技术，并从实践中总结了大量经验。

与此同时，其他公司也在采用类似的技术方案。然而业界对这种方案没有一个统一的命名。每当我想通过搜索引擎了解多个独立且自治的团队在共同完成一个Web应用程序所面临的挑战时，总是无法找到合适的搜索词来恰当地描述我的意图。在2016年11月，ThoughtWorks Technology Radar将这种技术方案命名为“微前端”，这一术语的出现更加便于大家在开发社区中围绕一致的技术架构分享最佳实践、技术和工具。

在2017年的夏天，我抽空对实践中的一些经验进行了总结。将所使用的技术凝结为独立的示例项目，并发布到https://micro-frontends.org上。从那时起，情况发生了一些变化，我被邀请在各种会议上发言，也收到了许多杂志社的约稿。社区中的开发人员还将网站翻译成各种语言。

最重要的是，去年年初，Manning出版社的Nicole和Brian找到了我。他们邀请我写一本关于微前端的书。收到邀请时我首先想到的是：“这有点离谱，我可不是一名作家！我甚至不喜欢阅读文字，而更喜欢倾听、编写代码、搭建系统以及解决问题”。但这看起来又是一个千载难逢的机会，在给出答复之前我经过了慎重考虑，并与家人和朋友讨论了多次。最后我决定抓住机会，接受这个邀请。毕竟，我非常喜欢表达和阐述。将思考总结成书，以图(我非常喜欢图)和代码示例的方式呈现，对我来说也是一种挑战，在整个过程中我也能学到很多东西。回顾编写本书的历程，我很满意当初的决定，以及这个决定的最终产物，也就是各位现在看到的这本书。