这篇文章算是我对在阿里做微前端的一个总结吧，没有写的事无巨细，更像是一个对本人的备忘录，很多中央因为做的比拟久了记忆也比拟含糊了我也会缓缓补充。

我对微前端的了解

当咱们在议论微前端的时候，往往提到的是一个前端的架构模式：一种瓦解前端“巨石利用”的分治计划。然而在我看来，随着微前端在企业级中后盾利用的宽泛应用，咱们在议论微前端的时候曾经衍生到一整套前端生态闭环（加载器、路由、公布零碎、利用插件等等），甚至当这套生态跑晦涩之后能够落地出一整套微前端的解决方案。

因而，我对微前端的了解就是：

• 前端架构
• 生态闭环
• 解决方案

而抛去以上架构层面的认知，我感觉微前端首要解决的问题是团队单干 / 效力所带来的前端工程化问题。

架构背景

我始终认为当咱们议论生态闭环或者解决方案的时候配合架构背景会更有说服力，也能让大家了解咱们很多中央为什么要这么做。

之前微前端系列的第一篇文章曾经具体介绍了咱们的我的项目架构背景，这里在简略回顾下，详情见《解密微前端：” 巨石利用 ” 的诞生》

模版架构

弊病：

• 后端解析模版，挂载模版；
• 后端管控路由，前端失去了对路由的掌控权，并且多个团队路由规定管控较难；
• 奴才利用作用域不隔离；
• 每一次前端公布须要先公布动态资源再公布模版，公布繁琐容易出错；

iframe 架构

诉求：

• 须要不依赖后端模版；
• 须要管控路由并制订对立的路由规定；
• 奴才利用的沙箱隔离；
• 尽量对子业务的改变做到最小化，很多业务包袱很重；
• 疾速落地并实现高可用；

弊病：

• 通信形式简略，简略的 postmessage API 并不能满足业务的需要；
• 款式割裂，iframe 会导致诸如 Dialog 这样子的全局蒙层仅在 ifame 区块内展现，使咱们零碎更像是“拼凑”进去的；
• 性能瓶颈，路由的切换会导致 iframe 内子利用的从新加载，性能堪忧；
• 跨域问题，chrome80 的 samesite 策略会导致 iframe 计划的跨域 cookie 无奈带给后端；

微前端架构

诉求：

• 改变老本；
• 沙箱隔离；
• 兼容 iframe；
• 路由不变性；
• 通信不变性；
• 灰度管制、容灾降级；
• 适配三端：pc、桌面端、POS 机；
• 子利用存在投放不同平台的场景，尽可能让子利用对投放平台无感知，宿主环境无感知;
• 兼容搭建平台；

业界痛点

这里我在搭建微前端生态的时候和阿里的其余的团队做了交换，收集了其余团队在微前端生态搭建过程中的遇到的痛点：

• 微前端生态须要适配搭建零碎；
• 须要具备兼容 icestark、qiankun、singleSPA 的能力；
• 兼容已有的 iframe 架构以及 iframe 生态；
• 业务体量大，稳定性要求高；
• 适配已有的前端基建（公布零碎、埋点零碎、监控零碎）；

咱们在微前端生态相干的建设

微前端框架

微前端框架在咱们的技术选型是 qiankun，过后的选型指标比较简单粗犷：

• 接入简略侵入少：我不想接入一套新的计划间接对老零碎重构；
• 兼容 iframe 生态：曾经存在比拟成熟的生态体系，并且曾经累计接入了近百个子利用；
• 没有足够的人力自建 / 保护自在的微前端框架：只有我一个人力，并且不激励反复造轮子；

而在我看来作为微前端生态中最终要的一环，微前端款框架应该集成了最外围的性能：

• 子利用加载
• 沙箱隔离
• 路由劫持
• 利用间通信

前三点都是采纳的框架自身提供的能力，而利用间通信咱们采纳了自建的计划。

为什么自建通信模型？

其实框架侧提供的通信计划基本上能满足大部分业务场景，然而咱们再次根底上有着更高的诉求：

• 已有比拟成熟的 iframe 通信计划，是否兼容 iframe 计划，升高 iframe 利用革新老本；
• 是否反对在 iframe 和微前端两套接入计划下自在切换而子利用无感知；

为此，咱们在 iframe 通信模型的根底上，基于宿主环境判断封装了微前端的公布订阅模型，采取完全相同的 API，子利用不再关怀本人的接入形式和宿主环境。

利用治理

路由治理

在聊利用治理之前我想先聊一下路由治理，对于大型的 B 端系统，一套正当的路由规定是极其重要的，尤其咱们的零碎是对外应用的：

• 后期须要定好规定，不能随着性子轻易扭转，用户很多都间接保留了对应页面链接；
• 子利用间存在跨利用间路由跳转的场景，正当的路由规定也便于跨利用层级的路由管制和路由治理；
• 咱们也须要基于路由做粗力度的权限管制；

这里首先在路由束缚下，我是采取了上面的规定：/:platform/:privilegeKey/:childHash

• platform：平台：pc、desktop、pos；
• priviateKey：权限点，和子利用 microKey 有 n – n 关系；
• childHash：子利用理论 hash，注册为微前端子利用时须要以 /:platform/:privilegeKey 作为 basePath；

子利用版本控制

对于国内支流的微前端计划来说都提供了两种形式的接入：

• entry：间接配置子利用的 html 链接，框架测剖析解析子利用 html 并实现资源注入；
• 资源配置：配置 js、css 等 cdn 资源从而实现资源注入；

这两种形式决定了公布零碎如何配合咱们的微前端生态，这里咱们采取的是第一种计划。

为什么采纳 entry 模式？

• 子利用存在投放多个业务平台的场景，不能因为接入一套计划而放弃其余，entry 模式也给了子利用作为利用独立运行的能力 -；
• 子利用灰度：html entry 在公布平台人造存在版本控制；

容灾（应急策略）

在容灾降级这边，因为咱们曾经有了一套比拟成熟的 iframe 生态，并且微前端计划在我设计的时候就多处做好了向下兼容的策略，因而咱们对于容灾降级就是降级成 iframe 计划，对于 iframe 仍旧异样的场景就只能通过监控报警来兜底了。

• 降级 iframe

  • 热降级：捕捉挂载谬误主动降级 iframe；
  • 冷降级：手动移除微前端配置降级 iframe；

• 监控

  • 微前端配置加载监控；
  • 子利用挂载成功率监控；
  • 子利用外部异样捕捉监控；

子利用赋能

在我看来，子利用赋能是微前端中不可或缺的一环，上面次要向大家介绍下我在子利用赋能方面所做的一些事。

通信模型

通信模型下面曾经简略提过了，这里就不过多赘述了。

主动埋点

奴才利用同时挂载埋点 SDK 的话是没有意义的，设置会减少数据“乐音”，因而仅须要主利用挂载 SDK 即可。我这里基于团体的埋点 SDK 做了二次封装，在主利用 ready 的时候挂载埋点 SDK，并以以后的 microKey 作为埋点的 id 聚合子利用的埋点，并且对子利用凋谢埋点调用事件。

总结起来就是：

• 聚合埋点 SDK；
• 主动采集 PV / UV；
• 手动触发埋点事件；
• 埋点扩大：业务级全埋点主动采集；

异样监控

和埋点一样，异样监控咱们也采纳主利用挂载的模式，并以 microKey 做监控聚合。然而不同的是，监控这块咱们裸露了卸载主利用监控的事件给子应，接入的不同团队的不同利用可能采取了齐全不同的监控体系，而监控 SDK 的底层远离都是劫持 fetch 等原生事件去做的，不同的 sdk 间很可能呈现净化。

路由中台

在路由规定和权限点的根底上，咱们也落地了本人的路由管控配置平台，咱们收口了全副子利用间路由跳转的 url，替换为依照路由事件 + schema 的模式让子利用调用，这样在子利用自有链接随着业务迭代的时候只须要同步到路由中台，便不须要其余子利用同步更新路由链接了。

其余赋能

这里还有很多依据咱们业务域定制的一些能力，我就不一一细说了：

• 单子业务域多实例挂载；
• 子利用后盾挂起、keepalive、保活；
• 不同的浏览器拜访行为：关上新页、重定向（无刷）、重定向（刷新）；
• 不同平台的适配层：pos、桌面端、浏览器；
• …

最初

最初简略说下我集体认为的微前端最佳实际吧：

• 大型 B 端系统，波及多业务域，多团队保护，子业务间耦合度较低，业务边界清晰；
• 不能要求子利用要多，然而不能太少，一两个子利用微前端失去了该有的价值，或者说有更适合的代替计划；
• 团队内曾经无法忍受 iframe 或其余代替计划带来的痛点；
• 微前端会随同着配套周边的生产，思考好 ROI；