这篇文章可以看作是我在阿里做微前端的总结。细节中没有细节。它更像是给自己的备忘录。很多地方都是因为比较久了，记忆越来越模糊，慢慢补充。我对微前端的理解当我们谈及微前端时，往往会提到一种前端架构模式：一种分而治之的解决方案，打破前端“单体应用”。但在我看来，随着微前端在企业级中后端应用中的广泛应用，当我们谈到微前端时，衍生出一套完整的前端生态闭环（loader、routing、发布系统、应用插件等），甚至在这套生态运行顺畅的情况下，也可以实现一整套微前端的解决方案。因此，我对微前端的理解是：前端架构的生态闭环解决方案。抛开以上架构层面的认知，我认为微前端要解决的首要问题是团队协作/效率带来的前端工程问题。建筑背景我??一直觉得，我们在讲生态闭环或者解决方案的时候，配合建筑背景会更有说服力，也会让大家明白我们为什么很多地方会这样做。上一篇微前端系列的第一篇已经详细介绍了我们的项目架构背景。这是一个简短的评论。详见《解密微前端："巨石应用"的诞生》模板架构缺点：后端解析模板，挂载模板；backend控制路由，frontend失去对路由的控制，多个团队的路由规则难以控制；主应用范围和子应用范围不是孤立的；前端每次发布都需要先释放静态资源，再释放模板，繁琐且容易出错；终端模板；需要控制路由，制定统一的路由规则；主应用和子应用的沙箱隔离；尽量减少对子服务的改动，很多业务负担很重；快速实施并实现高可用性；缺点：通信方式简单，简单的postmessageAPI不能满足业务需求；样式分离，iframe会导致Dialog等全局掩码只显示在ifame块中，让我们的系统更像是一个“拼凑而成”；性能瓶颈，路由切换会导致iframe中子应用重新加载，性能堪忧；跨域问题，chrome80的samesitepolicy会导致iframe解决方案的跨域cookie无法带到后台；微前端架构需求：变更成本；沙箱隔离；与iframe的兼容性；路由不变性；通信不变性；灰度管控、容灾降级；适配PC、台式机、POS机三种终端；子应用程序具有在不同平台上启动的场景。不了解环境；与构建平台兼容；行业痛点这里我在搭建微前端生态的时候和阿里其他团队进行了交流，收集了其他团队在搭建微前端生态过程中遇到的痛点：微前端生态需要适配建设系统;需要兼容icestark、qiankun、singleSPA；兼容现有的iframe架构和iframe生态；业务量大，稳定性要求高；适配现有前端基础设施（发布系统、嵌入式系统、监控系统）；我们正在构建与微前端生态相关的微前端框架。微前端框架是我们技术选型中的qiankun。该方案直接重构旧系统；兼容iframe生态：已经有比较成熟的生态，已累计接入近百个子应用；没有足够的人力来构建/维护一个免费的微前端框架：我是唯一的人力，不鼓励重新发明轮子；在我看来，微前端框架作为微前端生态的最后一环，应该集成最核心的功能：前三点子应用加载沙箱隔离路由劫持应用间通信都是由微前端提供的能力框架本身和应用程序我们采用了自建的通信解决方案。为什么要自己搭建通信模型？其实frame端提供的通信方案基本可以满足大部分业务场景，但是我们在基础上有更高的要求：有比较成熟的iframe通信方案，是否能兼容iframe方案，降低成本iframe应用改造；支持iframe和微前端接入方案自由切换，无子应用感知；为此，我们基于iframe通信模型，封装了微前端基于宿主环境判断的发布-订阅模型，采用完全相同的API，子应用不再关心自己的访问方法和宿主环境。应用管理路由管理说应用管理之前，先说说路由管理。对于大型的B端系统来说，一套合理的路由规则是极其重要的，尤其是我们的系统是对外使用的：规则需要在前期设置好，不能随性随性，很多用户直接保存对应的页面链接；子应用之间存在跨应用路由跳转的场景，合理的路由规则也便于跨应用层级的路由控制和路由管理；我们还需要基于路由做粗略的权限控制；这里，首先，在路由约束下，我采用了如下规则：/:platform/:privilegeKey/:childHashplatform:platform:pc,desktop,pos;privateKey：权限点，与子应用microKey有n-n关系；childHash：子应用的实际哈希值。注册为微前端子应用时，需要使用/:platform/:privilegeKey作为basePath；子应用版本控制为国内主流微前端解决方案提供了两种接入方式入口：入口：直接配置子应用的html链接，框架解析，解析子应用的html，实现资源注入；资源配置：配置js、css等cdn资源，实现资源注入；这两种方式决定了发布系统如何配合我们的微前端生态，这里我们采用第一种方案。为什么要使用入口模式？存在子应用部署在多个业务平台的场景。你不能因为获得一套解决方案而放弃别人。入口表单还赋予子应用程序作为应用程序独立运行的能力——；子应用灰度：html入口自然存在于发布平台Control上；容灾（应急策略）是在容灾和降级这边，因为我们已经有比较成熟的iframe生态，微前端方案我在设计的时候有多种向下兼容的策略，所以我们的容灾降级是为了降级到iframe解决方案。对于iframe还是异常的场景，我们只能通过监控告警来摸清底线。Downgradeiframe热降级：catchmounterror自动降级iframe；冷降级：手动移除微前端配置降级iframe；监控微前端配置加载监控；子应用挂载成功率监控；子应用内部异常捕获监控；子应用赋能在我看来，子应用赋能是微前端不可或缺的一部分。下面给大家介绍一下我在子应用赋能方面做的一些事情。通信模型通信模型上面已经简单提到过，这里不再赘述。自动埋主子app同时挂载埋地SDK是没有意义的。该设置会增加数据的“噪音”，所以只有主应用需要挂载SDK。这里我根据群里的埋点SDK做了一个二次包。主应用准备好后，挂载埋点SDK，以当前microKey作为埋点的id，聚合子应用的埋点，开启埋点给子应用的Call事件。总结一下：聚合埋点SDK；自动采集PV/UV；手动触发埋点事件；埋点扩展：业务级全埋点自动采集；形式，并使用microKey来监控聚合。但不同的是，在监控部分，我们将卸载主应用监控的事件暴露给了子颖。连接的不同团队的不同应用可能采用完全不同的监控系统，而监控SDK底层远不是劫持fetch等nativeEvent来做，不同sdk之间很可能存在污染。在路由规则和权限点的基础上，路由平台还实现了自己的路由管控配置平台。我们关闭了所有子应用之间路由跳转的url，换成了路由事件+schema形式的子应用，这样当子应用自己的链接随着业务迭代时，只需要同步到路由中心，其他子应用不需要同步更新路由链接。其他赋能根据我们的业务领域定制的其他能力还有很多，就不一一细说了：单子业务域多实例挂载；子应用后台挂起，keepalive，keepalive；不同的浏览器访问行为：打开新页面、重定向（无滑动）、重定向（刷新）；针对不同平台的适配层：pos、desktop、browser；...最后简单说一下我个人认为的微前端的最佳实践Bar：一个大型的B端系统，涉及多个业务领域，多-团队维护，子服务之间耦合度低，业务边界清晰；你不能要求更多的子应用程序，但不能太少，一两个子应用程序微前端将失去它们的用处。值，或者有更合适的选择；团队无法再承受iframe或其他替代方案带来的痛点；微前端会伴随配套周边的制作，需要考虑ROI；
