如何在应用架构中设计微前端方案-icestark - 阿里云开发者社区

微前端的技术架构，它给大型单体应用场景和工作台场景带来技术架构优化的方案，通过引入微前端的技术架构去解决当前系统遇到的问题和瓶颈， ... 开发者社区> 温柔的养猫人> 正文 如何在应用架构中设计微前端方案-icestark 来自：AlibabaF2E 2020-09-03 1041 简介： 微前端的技术架构，它给大型单体应用场景和工作台场景带来技术架构优化的方案，通过引入微前端的技术架构去解决当前系统遇到的问题和瓶颈，也能给上古代码找到一个重新焕发生机的机会。

+关注继续查看 作者|鲲尘 微前端在2016年ThoughtWorks的一个技术雷达上面提出后，不断有团队尝试将单体的前端web应用按不同维度进行拆分或者组合，再聚合到一个整体的应用架构下面。

无论从系统体验优化还是技术架构升级的角度，都对微前端的方案提出了各种高要求。

本文将围绕icestark对于不同场景的思考和设计，来尝试给出解决方案。

场景分析 在聚焦希望引入微前端技术架构的场景上，不难发现，以下的两类场景的诉求会相对强烈：1.工作台的场景，基于产品体验的纬度2.大型单体应用，这种场景更侧重于想从技术维度进行优化，能系统可持续的迭代发展。

工作台场景 在工作台场景，从产品侧的诉求来看，希望跨系统的操作能够更加简易，能够带来系统操作和体验的一致性；而从技术架构的角度，各个独立的系统缺乏统一的管控手段，许多能力都在重复建设。

大型单体应用 面向大型单体应用的场景，也就是我们常见的巨石应用，随着业务需求的迭代，系统的复杂度直线上升。

从直观的感受来讲，这个应用构建的速度越来越慢，生成的bundle大小越来越大。

日常的调试开发体验也收到一定程度的影响。

从另一方面来看，伴随着业务功能体量的提升，也导致了开发和协作成本的上升，常见的问题就是局部技术架构升级会变得非常困难，业务的扩展和其他业务能力的接入都会对单体SPA架构带来要求。

技术选型 对于应用架构的设计上，除了微前端的技术架构外，还有几种场景的技术选型。

SPA/MPA 巨石应用也就是SPA/MPA的技术架构。

这里想单独提一下，针对产品体验的场景，一个简单的SPA应用、肯定是能够给到一个整体的系统体验，并且能够管控系统的技术复杂度。

但如果系统越来越臃肿，就会遇到上面到的技术纬度的问题。

SPA/MPA是前端技术架构中最为常见的，对于一个独立的系统它能在整体体验和技术复杂度上做到很好的管控。

但是为了防止这个项目后续发展成一个上古项目，无论是在功能迭代还是公用模块的管理上都会提出很高的要求。

不然随着系统的臃肿，系统健壮性和可持续迭代的复杂度问题都会随之而来。

iframe iframe在微前端方案流行前，它其实是一个比较好的解决方案。

不管是一些二方或是三方的接入，它都能够很好地满足需求。

但它存在一个致命的问题，就是用户体验。

举个常见的问题，iframe如果不去做一些特殊处理，嵌入的页面双滚动条、路由无法同步、页面内部存在弹出遮罩交互等问题都是体验纬度上的硬伤。

框架组件 框架组件，简单来讲就是跨系统复用的公共组件。

通常将一些通用的头部或吊顶中常用的逻辑封装成一个组件，然后以npm的形式进行维护，通过这种方式能够非常方便的将复用逻辑/UI提供出去。

但本质上没有解决去解决技术架构持续升级和多系统用户体验优化的问题。

微前端 微前端技术架构虽然会映入一些技术的复杂度，但基于上述两种核心场景能够从体验和效率维护去寻找一个平衡点，让前端的协作模式发生改变，功能模块拆分后独立开发，独立部署，最终再集成到一个系统当中。

微前端架构 在应用架构中接入微前端，核心需要处理框架应用和微应用之前的关系。

icestark将微前端方案中需要处理的技术细节进行屏蔽。

框架应用去不用关心路由处理逻辑或者接入微应用的处理，只需要完成微应用的配置及其应用上的一些业务逻辑，比如鉴权、应用埋点等业务逻辑即可。

接下来也将针对icestark内部技术架构的设计进行分享。

核心概念 icestark里面引入的核心概念，主要两个点：框架应用和微应用。

框架应用就负责整体的Layout跟微应用配置与注册渲染。

框架应用通常会有的一个通用的头部Header，侧边栏SiderBar，除了Layout之外，还需要配置微应用的信息，配置中会包含微应用的核心信息，比如资源url和基准路由。

微应用它其实就是按业务维度拆分开来的一些应用，通常来讲它可能就是一个SPA应用，并且会包含至少一到多个页面或路由。

微应用注册 框架应用通过icestark提供的AppRouter组件可以快速地完成微应用的挂载 核心配置信息中path代表基准路由，声明了访问路由地址是对应微应用将会被加载；url信息代表了应用的bundle资源；除此之外，通过entry的方式可以把html整体引入，不再需要关心页面中加载的js资源和css样式。

工作流程 引入微前端架构后的工作流程可以从两个方面发生变化 微应用的开发模式。

微应用开发有独立的仓库，独立的开发、测试、布署流程。

开发测试部署完之后，将应用的发布产物统一注册到框架应用里面，这些产物可能是JSbundle或html资源。

框架应用的整体流程，框架应用会维护微应用的注册信息。

用户在访问系统的时候，根据它之前注册的路由信息，它能够精确地匹配到当前需要加载的应用信息，根据相应的信息去加载应用的资源并最终渲染应用。

用户点击触发跳转的时候，如果路由变化触发的是一个内部应用跳转，那应用将会直接根据应用内部的路由逻辑渲染页面。

如果涉及到一些跨应用的跳转，则又重新回到了上面路由的查找流程当中。

路由规则 微应用能按照SPA体验根据路由的变化进行加载，取决为icestark内部路由管理的设计。

icestark里面的路由规则非常简单，接触过react-router的开发者不难发现两者在配置上其实是有很多相似的地方，比如path、exact的配置规则。

当访问框架应用页面时，icestark内部会去做一个路由的分发。

如上图中注册的三个微应用配置： 访问/seller路由时，匹配到了第一个注册信息 访问/data或者/message时，匹配到第二个注册信息 访问/seller/a的时候，匹配到的是第三个路由 第一个注册配置中设置了excat属性。

只有在精准匹配/seller路由的时候才会匹配到第一份注册信息 兜底路由 如果在微应用架构里面去设置了path为/的一个微应用，那它将整个系统的一个兜底路由，所有不匹配已注册的路由配置都会由兜底路由进行渲染。

兜底路由一般情况都会用来渲染通用页面，比如跟框架应用有比较强的耦合页面，比如登陆页面，404页面或者说退出登录的页面。

所以实践上面我们也将兜底路由作为框架应用自身路由的渲染。

路由劫持 为了能够让icestark响应页面路由的变化，并对相应的微应用进行加载，icestark对两类路由事件进行了劫持： historyAPI中的popstate和hashChange window上的路由事件pushState和replaceState（通常在浏览器上进行前进后退操作的时候会触发）。

一旦应用间发生跳转，通过上述事件的劫持能够拿到对应的路由信息，再根据路由的匹配规则来决定哪个微应用进行挂载。

一个微应用可能会有多个路由设置，如果在没有发生应用间跳转的情况下，由于匹配到的是当前的微应用，所以不会再次加载资源，内部路由跳转逻辑则根据微应用自身路由配置决定渲染。

路由劫持发生的时机在整个微前端配置初始化阶段，即AppRouter的挂载，一旦AppRouter卸载对应的劫持也将会移除。

应用通信 从微前端的设计原则上来说，并不希望微应用太多地去依赖框架应用或者其它微应用提供的能力。

这样在微应用独立开发的时候需要额外创建一个框架应用环境，不利于技术架构的结偶和维护。

但基于一些轻量的应用场景，比如通过通信机制让框架应用和微应用的多语言设置保持一致，一旦多语言设置发生切换，微应用能够监听到这个变化。

icestark提供了一个应用通信机制，在实际开发过程中推荐轻量的去使用，不要耦合过多的业务逻辑@ice/stark-data中提供了应用通信的能力，核心的实现是一个EventBus的机制，框架应用跟微应用之间的通讯，以window这样一个全局变量作为桥梁。

这样不管是微应用添加的事件或数据，还是框架应用添加的事件或数据都可以访问到。

微前端隔离 icestark在设计隔离的方案时候，有两个基础原则： 首先认为研发体验是高于隔离的。

假如说我引入一个完美的隔离方案，但它需要让我去做很多额外的处理逻辑，那这个方案肯定是不被接受的。

无论是改造成本还是开发体验效果都会受到非常大的影响。

其次是二方的场景要高于三方的场景。

因为大多数微前端的应用场景，都是二方场景，一个统一的独立的系统，很少碰到要去接一个完全不受控的三方产品。

而二方场景的接入其逻辑和安全性都是可控的。

基于上述的两个因素，在实践过程中并不一定说是要实现了一个完美的隔离方案之后，然后才在微前端技术架构中去使用。

如果当前方案能够满足基础的业务的诉求，那就让这个方案在业务中使用。

通常微前端中的隔离场涉及两个方面：一个就是CSS的隔离，另一个就是JS的隔离。

样式隔离 样式隔离上面，推荐的方案是基于一些约定的隔离，用低成本的隔离方式，让样式之间不会相互影响。

样式隔离主要分两类： 开发者自己业务代码中的样式隔离，业务代码的隔离推荐通过CSSModule的方式，能够自动生成hash后缀的样式名，基于每个不同的应用构建出来的样式，在天然上就能够做到隔离。

基础组件样式隔离，大多数社区的一些基础组件，在设计上都考虑到样式前缀的替换。

基础组件能够支持CSSprefix的方式，可以为所有样式添加一个前缀，在实践过程中将框架应用的前缀和微应用前缀进行区分，来完成样式的隔离。

如果有不支持CSSprefix的样式，我们也能够借助社区PostCSS的能力给组件样式加上namespace，框架应用跟微应用通过不同的namespace进行样式隔离。

shadowDOM的方案 为什么我们没有直接去使用shadowDOM，本质的原因还是shadowDOM的方案还不够开箱即用。

目前shadowDOM对于业务上的改造还是有一定成本和问题： 比如如果使用的基础依赖的组件库，并没有设计让Dialog等弹出层在指定的dom节点中插入结构的话，弹出层都是会逃离你当前的shadowDOM。

逃离之后，它就是一个无样式的弹框。

这种无样式的弹框对于业务上来说是不可以接受的，因此弹框逻辑需要去做一些兼容，更甚至需要对底层组件去做改造。

在React场景下，shadowDOM的使用会涉及到事件机制的问题，因为React的事件机制是代理到document的，但基于shadowDOM处理的话，它可能会阻断事件到它的host层，也就是你渲染shadowDOM的那一层。

虽然说社区也有对应的包去做一些兼容处理，但它对业务上来说还是会有一些实现成本。

除此之外还包括其它的问题。

比如CSS@font-face，或者说一些字体属性，svg都会有一个不兼容的场景。

虽然shadowDOM问题还是比较多，但是接下来icestark也会这方面继续探索、逐渐完善，争取提供出一个开箱即用的方案，达到启用shadowDOM能够没有太大改造的成本。

脚本隔离 多个应用的bundle多次执行的时候很容易对全局变量造成污染，特别是代码中出现对于window全局变量的依赖。

icestark中通过proxy的沙箱机制实现了脚本的隔离。

Prxoy沙箱的基本原理是通过with+newFunction的形式阻断代码中对于window的直接访问，并通过Proxy的方式拦截对于window变量的访问和写入，沙箱的隔离使代码不能直接访问到window对象，通过ES6的新特性Proxy可以定制get/set的逻辑，这样就能对window上的一些全局变量变化进行快照记录，以便微应用切换的时候进行恢复。

另外像一些应用初始化时，会在window上面设置setTimeout、setInterval，如果在卸载阶段没有很好的处理，将会影响到下一个挂载微应用的执行。

所以在沙箱中针对这类方法进行了特殊处理，在沙箱挂载前对相应的方法进行劫持，在卸载的时候，再对它进行恢复。

三方隔离 对于不授信的三方最简单最安全的隔离方式是iframe。

在icestark中可以简单定义好基准路由path，再通过自定义渲染的方法render将iframe相关的内容渲染出来。

微模块能力 微模块的能力其实是对微前端方案的一个补充，通常一个微模块并不会耦合路由，在一个页面中可以随意组合和挂载。

它的应用场景主要有以下两种模式： 模块共存问题：常见为微前端的技术体系下面去实现一个多tab方案。

设想一下，最低成本的一个解决方案会是什么样的，是不是让一个模块能够在不同的位置正常渲染就行了？ 模块动态组合：一个页面里面会有信息模块，表单模块，以及列表模块。

在一些对外输出复用的场景中，如果直接接入整个页面，其通用性并不是特别强，但如果各个模块能够进行自由组合，就可以按需组合出不同需求的页面 微模块架构 icestark对于微模块的应用场景上会有一个明确的定义，微模块其实是不会再去耦合路由的。

之前提到的微应用的内部基本上是一个SPA它至少有一个路由或者是一个页面，但是微模块的使用上我们希望尽量简单，因为一旦多个模块都大量耦合路由的话，这会使路由处理变得复杂。

在模块的标准上面，微模块是以UMD的方式直接打包，通过这种标准模式打包，即便是以npm包的形式也可以正常使用。

在微模块内部除了默认导出模块方法外，还需要定义挂载（mount）和卸载（unmount）的生命周期。

微模块的应用场景其实是对微应用的一个补充，它更适用于更加细粒度的功能拆分和动态搭建的场景。

微模块挂载 根据模块资源在执行的位置渲染模块： import{MicroModule}from'@ice/stark-module'; constApp=()=>{ constmoduleInfo={ name:'moduleName', url:'https://localhost/module.js', } return; } 通过组件方式的挂载，将微模块渲染至指定位置，而上层的切换展示逻辑均由业务进行控制。

总结 微前端的技术架构，它给大型单体应用场景和工作台场景带来技术架构优化的方案，通过引入微前端的技术架构去解决当前系统遇到的问题和瓶颈，也能给上古代码找到一个重新焕发生机的机会。

同时结合微模块的方案，让基于标准化模块的上层方案有更大的想象空间，未来面向的场景和方案也将更加丰富。

如果对于飞冰的前端架构方案和微前端的技术架构有兴趣的，如果项目对你有帮助，欢迎关注starICE技术架构：https://github.com/ice-lab/icestarkhttps://github.com/alibaba/ice 关注「AlibabaF2E」把握阿里巴巴前端新动向 版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。

具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。

如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

自然语言处理 前端开发 JavaScript 安全 API UED 开发者 ice ice问题 价格ice ice发布 ice总结 ice进程 开发者社区> AlibabaF2E 作者高分内容 更多 2021年前端趋势预测 15745 跨端的另一种思路|D2分享+文章 735 前端故障演练的探索与实践|D2分享视频+文章 1062 如何建设灰度跨端监控|D2分享视频+文章 506 10万级大型场馆背后的绘选座技术|D2分享视频+文章 516 相关文章 青衫无名 前端通信：ajax设计方案（七）---增加请求错误监控、前端负载均衡以、请求宕机切换以及迭代问题修复 3383 0 技术小甜 《.NET应用架构设计：原则、模式与实践》新书博客-2.1.1-设计原则简述 1041 0 技术小甜 《.NET应用架构设计：原则、模式与实践》新书博客--试读-1.2正确理解设计的含义 1038 0 异步社区 《超越平凡的Web设计——HTML5+CSS3专业应用之道（iWeb会场抢先版）》——第一部分——前端工程师之路第1章超越平凡的Web设计 1018 0 jerrywangsap 使用SAP云平台MobileService开发移动应用 1141 0 技术小阿哥 DataGrid基础应用 864 0 狗尾巴呢 Web系统下Office文档的处理之OpenXml应用分类资料 本文对常见的处理参考和工具提供一个简要的参考。

对于实际的解决方案参考如下地址（有很多的分类知识） http://blogs.msdn.com/b/ericwhite/archive/2008/10/20/eric-white-s-blog-s-table-of-contents. 1019 0 狗尾巴呢 MicrosoftAccess应用可以这么玩 Access作为一个轻量级的个人数据库，很久以前是数据库设计的流行工具，整理资料的过程中看到一个基于access的accdb格式的应用，功能也很强大。

在目前网络应用主流的今天这样的应用比较少，不过在特定的场景下采用这个方案仍是一个高效快速的解决方案。

911 0 技术小甜 《.NET应用架构设计：原则、模式与实践》新书博客--试读-2.1.2设计原则实战 1063 0 最美的回忆 JSP中的TagLib应用 1057 0 +关注 温柔的养猫人 1172 文章 2 问答 作者高分内容 更多 2021年前端趋势预测 15745 跨端的另一种思路|D2分享+文章 735 前端故障演练的探索与实践|D2分享视频+文章 1062 如何建设灰度跨端监控|D2分享视频+文章 506 10万级大型场馆背后的绘选座技术|D2分享视频+文章 516 来源圈子 更多 AlibabaF2E 1334 +订阅 文章排行榜 最热 最新 1 CloudComputing：基于无影云电脑利用Python语言实现绘制“可爱小老虎”虎年快乐及无影云电脑简介、应用场景、使用体验(五步快速上手)分享图文教程之详细攻略 187434 2 【ElasticEngineering】开始使用Elasticsearch（1） 178065 3 一文读懂云原生一体化数仓 67116 4 Python多任务编程——线程之间共享变量 43155 5 阿里云PAIStudioPython脚本组件使用QuickStart 19665 6 【资源分享】阿里云盘资源永久汇总页 18540 7 Python网络编程——TCP服务端多线程 17642 8 Python多任务编程——线程锁死锁 22061 9 Python多任务编程——多线程的使用 21638 10 Python网络编程——静态Web服务器进阶版 14042 11 Python网络编程——静态Web服务器实现 14024 12 码栈PRO助力三只松鼠，全面提升电商运营效率，赋能品牌发展 10380 13 虚拟偶像诞生记-数字人行业和技术探究 9464 14 免费体验！阿里云智能LOGO帮你解决设计难题 9181 15 如何大规模交付高质量、高一致性的RESTfulAPI及配套产物 9040 16 求职准备|准备简历和面试时最容易踩哪些坑 8241 17 分析服务一体化理念解读 7974 18 【ElasticEngineering】Elasticsearch中的一些重要概念:cluster,node,index,document,shards及replica 18574 19 【ElasticEngineering】如何在Linux，MacOS及Windows上进行安装Elasticsearch 17869 20 【ElasticEngineering】Elasticsearch简介 20114 1 数据库基本知识汇总 760 2 从运营角度体验云效（纯个人分享） 97 3 线上leaderelectionlost导致Kubernetes组件异常退出的问题排查 73 4 Unity跨平台UI解决方案：可能是最全的FairyGUI系列教程-第八天 79 5 Unity跨平台UI解决方案：可能是最全的FairyGUI系列教程-第七天 66 6 Unity跨平台UI解决方案：可能是最全的FairyGUI系列教程-第二天 103 7 SQL基础（三）数据表的创建与管理实践 1469 8 可视化接口管理平台YApi，让你轻松搞定API的管理问题 102 9 秒懂Git与Gitee(码云) 1505 10 实用工具——开发必备 242 11 Vscode重定向.exe文件生成位置 1341 12 C++拷贝构造函数剖析 134 13 C++静态成员函数访问非静态数据成员 429 14 C++课程设计：图书管理系统【附源码】 501 15 ECS子账号或者角色基于标签权限管理方案 73 16 OnlineJudgeSystem中术语含义：OJ、AC、WA、TLE、OLE、MLE、PE、RE、CE 776 17 DingTalk「开发者说」第8期钉钉微应用开发实战 56 18 不用已知解决未知，踏足数据科学家培养的“无人之境” 4428 19 python包之xlwt操作excel教程 78 20 YOLOv5-GPUJetsonNano部署教程 60 推荐文章 云效DevOps全家桶评测火热开启！千元猫超卡和云效产品礼包等你赢取 CentOS8的用户请注意，请尽快切换镜像源！ 智能客服领域内首部知识运营白皮书 乘风者计划邀您入驻社区，精彩权益即刻享 相关电子书 更多 阿里云智能客服知识运营白皮书 立即下载 《零基础CSS入门教程》 立即下载 《零基础HTML入门教程》 立即下载